mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Diverse Messdaten z.B. von Wetterstation online speichern - best practice


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Daniel P. (zwirbeljupp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin gerade dabei meinen Bienenstock zu digitalisieren und hätte 
gerne eure Meinungen dazu, wie und wo man die Sensordaten in 2019 denn 
nun am besten online speichert, um jederzeit Zugriff auf die 
Informationen zu haben.

In der Nähe des Bienenstocks wird eine solarbetriebene Einheit 
aufgestellt, die ca. alle 1 - 5 Minuten neue Sensordaten aufnimmt 
(Temperatur, Luftfeuchte, Helligkeit, Gewicht des Bienenstocks, 
akustisches Spektrum,...). Die Messeinheit ist in der Reichweite meines 
Heimnetzwerks, es bietet sich daher an, hier gleich einen 
Mikrocontroller mit einem WiFi-Modul zu verbinden (ich werde 
voraussichtlich einen PIC32 verwenden).

Nun stellen sich folgende Fragen:
+ Wo speichert man diese Daten online am sinnvollsten und in welcher 
Form (z.B. SQL-Datenbank)?
+ Wie kann ich mir komfortabel den Verlauf (z.B. des 
Bienenstockgewichts) darstellen?
+ Welches Protokoll ist für die Datenübertragung am geeignetsten?

Da gefühlt heute jede IT-Firma auf der Webseite die Buzzwords IoT, MQTT, 
Cloud etc. verwendet, treibt einen eine Google-Suche in diesem Bereich 
schnell in den Wahnsinn.
Könnt ihr mich hier bitte mit ein paar Anregungen oder Tutorials in die 
richtige Richtung schubsen?

Hier noch ein paar Anforderungen:
- ein eigener Server zuhause scheidet aus
- einfache Skalierbarkeit von einem auf x Bienenstöcke wäre schön, aber 
kein Muss

Danke & Gruß
Daniel

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel P. schrieb:
> Da gefühlt heute jede IT-Firma auf der Webseite die Buzzwords IoT, MQTT,
> Cloud etc. verwendet, treibt einen eine Google-Suche in diesem Bereich
> schnell in den Wahnsinn.

InfluxDB und Grafana sind dir dann vielleicht auch schon begegnet
https://www.influxdata.com/products/influxdb-overview/
https://grafana.com/

Autor: Timmo H. (masterfx)
Datum:
Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Das schoss mir auch gerade in den Kopf. Nachdem ich das Video von 
Andreas Spiess (Youtube-Video "#255 Node-Red, InfluxDB, and Grafana Tutorial on a Raspberry Pi") gesehen 
habe, habe ich gleich meine Wetterstation auf InfluxDB + Grafana 
umgstellt.
Da bedarf es auch gar keinen Pic oder Atmel zu. Einfach ein ESP8266 
(oder wie in meinem Fall einen ESP8285) der alle paar Minuten aufwacht 
und über WLAN die Daten (Temperatur, rel. Luftfeuchtigkeit, Luftdruck, 
vBat) via MQTT als JSON an meinen RPi sendet (Nodered+Mosquitto). So 
hält mein 800 mAh Akku ein paar Monate durch (MCP1703 als 
Spannungsregler und Deepsleep).

: Bearbeitet durch User
Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timmo H. schrieb:
> Einfach ein ESP8266
> (oder wie in meinem Fall einen ESP8285)

Oder ein ESP32 für 10 €.
https://www.heise.de/make/meldung/Sonderheft-Make-ESP32-Special-jetzt-online-zu-bestellen-4337457.html
mfg klaus

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Timmo H. schrieb:
>> Einfach ein ESP8266
>> (oder wie in meinem Fall einen ESP8285)
>
> Oder ein ESP32 für 10 €.
> 
https://www.heise.de/make/meldung/Sonderheft-Make-ESP32-Special-jetzt-online-zu-bestellen-4337457.html
> mfg klaus
Ja auch nett, dass Problem bei dem Ding ist (wie bei den meisten ESPxx 
Dev-Boards), dass dort als LDO der AMS1117 verbaut ist. Der hat 
zumindest 5-10mA Ruhestrom, für den Batteriebetrieb mit Deepsleep von 
daher völlig ungeeignet. Deswegen habe ich auf meinem Board auch den 
MPC1703 verwendet (und vorhin auch explizit erwähnt), welcher nur 2µA 
Ruhestrom benötigt, das ist Faktor 2000 weniger. Bei 5 Minuten Deepsleep 
+ 200ms (Connect + Send), ist das schon ein ziemlicher Unterschied.

: Bearbeitet durch User
Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
gut das Du dies mit dem hohen Ruhestrom erwähnst. Ich würde den dann 
tauschen. Jedoch habe ich noch eine andere Lösung bestellt.
Einen MYAMIA Cjmcu-25504 Boost Converter Solar Zellen Management 
Nanopower Energie Sammler. Wäre direkt beim Chinesen nur halb so teuer, 
hatte aber Probleme mit dem Bezahlvorgang. Was soll es, ich teste das 
Ding mal.

Ähnlich diesem Artikel, der 25504 soll nur besser geeignet sein.
https://randomnerdtutorials.com/power-esp32-esp8266-solar-panels-battery-level-monitoring/
https://www.hackster.io/shantam/self-sustained-wifi-sensor-node-ad187e
mfg klaus

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Deine Zwecke nimmt man eine passend eingerichtete RRD-Datenbank. Da 
speicherst Du Deine Messwerte für z.B. 30 Tage unverdünnt, d.h. bis 30 
Tage zurück kannst Du jeden einzelnen Messwert abrufen. Alles was älter 
als 30 Tage ist wir jeweils zu einem Tageswert zusammengefaßt. Diese 
Werte werden dann für z.B 10 Jahre gespeichert. Datensätze älter 10 
Jahre werden verworfen.

Die Intervalle kann man natürlich auch anders machen. Für meine 
Wetterstation nehme ich z.B. 30 Tage / 30 Jahre.

Schau Dir mal die rrdtools von Tobias Oetiker an. Das wäre für Dich 
genau die richtige Datenbank. Mit der Datenbank kann man auch gleich 
passende Diagramme erstellen.

Autor: Chr. M. (snowfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel P. schrieb:
> - ein eigener Server zuhause scheidet aus

Warum scheidet der aus?
Bei der obigen InfluxDB/Grafana Lösung braucht es z.B.
einen RaspPi als Server.

Autor: Daniel P. (zwirbeljupp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

vielen Dank, influxDB + grafana oder auch rrdtools ist schon sehr nah an 
dem, was ich suche. Insbesondere der Begriff "time series database" ist 
hier der Schlüssel.
Die Visualisierungsmöglichkeiten mit grafana sehen top aus, das wird auf 
jeden Fall meine Zwecke erfüllen.

Allerdings hatte ich gehofft, dass es bereits schlüsselfertige 
Online-Datenbank-Lösungen gibt, an die ich bloss zyklisch meine 
Datensätze schicke, ohne mir selber einen Server hinstellen zu müssen. 
Gibt es auch, aber selbst für den kleinsten Datenplan werden gleich >40$ 
pro Monat fällig.
Klar, ich könnte mir jetzt einen rPi hinstellen, aber das Aufsetzen und 
Verwalten des Systems ist nicht das, was ich mir unter Quality Time 
vorstelle :)
Kennt jemand zufällig einen kostenlosen bzw. günstigen InfluxDB Anbieter 
für geringe Datenmengen?

Der ESP32 ist natürlich preislich sehr interessant. Danke für das Teilen 
Eurer Erfahrungen mit dem Setup, sieht gut aus!
Ich würde aber gerne beim PIC32 bleiben, einerseits weil ich damit 
bereits viel Erfahrung habe und andererseits soll neben der Erfassung 
einfacher Sensordaten eine Analyse des Audiospektrums erfolgen (d.h. 
zyklisch die FFT eines ca. 4-Sekunden-Samples berechnet werden). Ich 
befürchte, der ESP32 ist dazu nicht geeignet.

Was mir noch unklar ist, was benötige ich zusätzlich zu einem TCP/IP 
Stack noch, um Datensätze an die influxDB zu senden? Gibt es Lösungen 
(z.B. für ESP32), die sich einfach auf einen PIC32 portieren ließen?

Danke & Gruß
daniel

Autor: Stefan F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte jetzt auch rrdtools empfohlen - in Kombination mit einer 
MariaDB und einem Apache HTTP Server mit Mod_PHP.

Das habe ich vor langer Zeit mal zur Erfassung und Darstellung von 
Performance Statistiken benutzt und fand es sehr angenehm.

https://www.mrtg.org/rrdtool/
https://www.php.net/manual/de/book.rrd.php

> Allerdings hatte ich gehofft, dass es bereits schlüsselfertige
> Online-Datenbank-Lösungen gibt

Das würde ich vermeiden. Lieber gar nicht bauen, als das Projekt von 
einem Cloud Service abhägig zu machen, dem ich nicht vertraue. Es ist 
doch immer so, dass du den Dienst entweder mit Geld oder mit der 
Herausgabe deiner Daten finazieren musst.

> Was mir noch unklar ist, was benötige ich zusätzlich zu
> einem TCP/IP Stack noch, um Datensätze an die influxDB zu senden?

Von influxDB habe ich keine Ahnung. Bei MariaDB würde ich ein PHP Script 
schreiben, was die Daten in Form von HTTP POST Requests empfängt und in 
die DB schreibt. Damit entfällt die Notwendigkeit, auf dem µC einen 
"echten" ODBC Treiber (oder sowas ähnliches) zu implementieren.

: Bearbeitet durch User
Autor: Chr. M. (snowfly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel P. schrieb:
> Was mir noch unklar ist, was benötige ich zusätzlich zu einem TCP/IP
> Stack noch, um Datensätze an die influxDB zu senden?

Eigentlich nur den String um die REST-API zu bedienen.
https://docs.influxdata.com/influxdb/v1.7/tools/api/
und das was du für Authentifikation und auswerten der Antwort brauchst.

: Bearbeitet durch User
Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich betreibe seit etlichen Jahren mehrere Wetterstationen mit diversen 
Parametern. Die Daten speichere ich spaltenweise als ASCII in einer 
Datei je Monat ab und werte die mit gnuplot aus.

Funktioniert auch in 30 Jahren noch, wenn MariaDB & Co schon längst out 
sind. Wer redet heute noch von dBase?

Autor: Gurgl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bingo schrieb:
> heute noch von dBase

Niemand, allerdings gibt es immernoch ODBC-Treiber dafür, es sollte also 
rein theoretisch heute noch funktionieren

Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gurgl schrieb:
> Niemand, allerdings gibt es immernoch ODBC-Treiber dafür, es sollte also
> rein theoretisch heute noch funktionieren

Mußtest Du damals ein Netzwert mit Novell zum Laufen bringen?
Lassen wir mal die Geister da wo sie hingehören.
mfg Klaus

Autor: Daniel P. (zwirbeljupp)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

nachdem ich mich auf Basis der hier genannten Stichworte weiter 
informiert habe, bin ich doch zum Schluß gekommen, dass ich mit dem 
ESP32 hier am schnellsten zum Ziel komme. Anfangs hat es mir ziemlich 
widerstrebt, "Sketches" in der Arduino IDE zusammenzuklicken, aber ich 
hatte nach sehr kurzer Zeit einen ersten proof-of-concept fertig, der 
schon sehr nahe an dem war, was ich mir vorgestellt hatte.

Das System soll solarbetrieben arbeiten, daher musste ich 
überproportional viel Arbeit in die Stromversorgung, das 
Batteriemanagement und niedrigen Stromverbrauch investieren. Das 
Powermanagement habe ich auf Basis des Solar-Lader-ICs LT3652 in 
Verbindung mit einem LiFePo4 Batteriepacks aufgebaut. Die Ladeschaltung 
ist so abgestimmt, dass die Akkus im Spannungsbereich zwischen 2.6V bis 
3.55V betrieben werden - ideal für die direkte Versorgung des ESP32 und 
aller Sensoren. Für den Batteriepack habe ich eine Gas Gauge von TI 
(bq34z100) verwendet, um eine präzise Aussage über den Ladezustand zu 
ermöglichen. Insbesondere bei den LiFePo4 Akkus auf Grund der flachen 
Kennlinie sehr hilfreich.

Auf der Hauptplatine befinden sich zwei HX711 load cell AD-Wandler für 
die Gewichtsmessung, in I²C EEPROM, ein Lichtsensor (BH1750), ein 
Micro-SD Slot und ein FT231X USB/Seriell-Wandler. Weitere Sensoren 
können per I²C angeschlossen werden. Eine größere Herausforderung war, 
alles für minimalen Stromverbrauch im DeepSleep auszulegen. Unter 
anderem habe ich deshalb einen Buffer/Line Driver zwischen den ESP32 und 
den FT231X setzen müssen, um eine parasitäre Versorgung des FT231X bei 
nicht verbundenem USB auszuschließen.
Durch sorgfältige Anpassung der Firmware ließ sich der Stromverbrauch 
des Systems auf ca. 250µA im DeepSleep drücken, was so in etwa auch 
meinen Berechnungen im Vorfeld entspricht. Im Aktivmodus verbraucht das 
System natürlich deutlich mehr Strom, dies jedoch immer nur für 2 bis 5 
Sekunden mit anschließendem Deep Sleep für 60 Sekunden.

Fürs erste nutze ich Thingspeak, um meine Daten online zu sammeln und 
auszuwerten. Erfüllt meine Bedürfnisse nicht vollständig, für das 
Prototyping aber sehr gut geeignet.

Es hat sich nun gezeigt, dass es einerseits natürlich klasse wäre, die 
Firmware direkt per WLAN updaten zu können. Ausserdem wäre ein einfaches 
Konfigurationsinterface prima (z.B. per Telnet), um Einstellungen 
anzupassen und Aktionen auszulösen (z.B. Tara der Gewichtsmessung). Hier 
fehlt mir allerdings ein geeigneter Ansatz, da ich natürlich nicht 
dauerhaft eine Telnet-Verbindung aufrecht erhalten kann.
Wie kann man das lösen? Ich brauche eine Möglichkeit, den ESP32 in 
seiner kurzen Wach-Phase mitzuteilen, dass er in einen Wartungsmodus 
gehen soll. Habt ihr dafür eine schlaue Lösung?

Danke & Gruß
Daniel

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du alle Minute Daten sammelst da wird Deine Datenbank aber schnell 
und stetig groß. Brauchst Du wirklich auch noch nach ein oder 2 Jahren 
eine Auflösung von einer Minute? Da sollte doch eine 
Tageszusammenfassung völlig ausreichend sein.
Eine RRD macht das völlig automatisch und kann auch die Charts 
generieren. Das Ganze inclusive Webserver kann auf einem Pi laufen. Das 
Aufsetzen des Servers  ist auch kein Hexenwerk, die Webseite mit ein 
bissel JS und einem serverseitigen PHP-Script ebenso.

Habe ich bei meiner Wetterstation so gemacht und das funktioniert 
bestens.

Autor: M.M.M (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
> Wenn Du alle Minute Daten sammelst da wird Deine Datenbank aber schnell
> und stetig groß. Brauchst Du wirklich auch noch nach ein oder 2 Jahren
> eine Auflösung von einer Minute? Da sollte doch eine
> Tageszusammenfassung völlig ausreichend sein.

Wo soll denn da das Problem sein? Er hat doch scheinbar Verbindung zum 
Heimnetz und selbst bei 1k Daten pro Minute kommt da nicht mal 1GB im 
Jahr zusammen.

MfG



















> Eine RRD macht das völlig automatisch und kann auch die Charts
> generieren. Das Ganze inclusive Webserver kann auf einem Pi laufen. Das
> Aufsetzen des Servers  ist auch kein Hexenwerk, die Webseite mit ein
> bissel JS und einem serverseitigen PHP-Script ebenso.
>
> Habe ich bei meiner Wetterstation so gemacht und das funktioniert
> bestens.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
> Wenn Du alle Minute Daten sammelst da wird Deine Datenbank aber schnell
> und stetig groß. Brauchst Du wirklich auch noch nach ein oder 2 Jahren
> eine Auflösung von einer Minute? Da sollte doch eine
> Tageszusammenfassung völlig ausreichend sein.

Das kommt wohl drauf an, was man mit den Daten vorhat.
Nicht immer ist RRD die passende Strategie.
Wenn du später nur die Tageszusammenfassung hast und plötzlich auf die 
Idee kommst, einen neuen Parameter aus den Daten zu bestimmen, kannst du 
plötzlich ziemlich doof da stehen.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:

> kommt wohl drauf an, was man mit den Daten vorhat.
> Nicht immer ist RRD die passende Strategie.

Das ist genauso richtig wie eine Binse. Andererseits ist das:

> Wenn du später nur die Tageszusammenfassung hast und plötzlich auf die
> Idee kommst, einen neuen Parameter aus den Daten zu bestimmen, kannst du
> plötzlich ziemlich doof da stehen.

kein überzeugendes Gegenbeispiel. Warum sollte man dafür 2 Jahre alte 
Daten brauchen? Denn für kürzer zurückliegende Zeiträume hat man die 
Daten ja in voller Auflösung.

Gerade Anfänger [1] scheitern gern daran, daß sie das Datenmanagement 
"vergessen". Später wundern sie sich dann, daß ihre Datenbank langsam 
wird und/oder der Massenspeicher voll wird. RRD hat den Vorteil, daß es 
die Leute dazu zwingt, eine Entscheidung zu treffen, wie lange und mit 
welcher Auflösung sie die Daten vorhalten wollen. Und es hat dann 
konstante Größe und Geschwindigkeit.


[1] nicht nur Anfänger, auch Profis. Ich erinnere mich an die Anfänge 
des MySQL Monitors. Der speicherte seine Daten (natürlich!) in einer 
MySQL Datenbank. Das Operating war eine Katastrophe. Beim Purgen alter 
Daten stand die Datenbank für Sekunden komplett still. Tablespaces 
fragmentierten und wuchsen auf der Platte. Und mit vielen Quellen (wir 
hatten Kunden mit Hunderten Servern) wurde es quälend langsam.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.