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.
von Daniel P. (zwirbeljupp)


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

von Wolfgang (Gast)


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/

von Timmo H. (masterfx)


Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Das schoss mir auch gerade in den Kopf. Nachdem ich das Video von 
Andreas Spiess (https://www.youtube.com/watch?v=JdV4x925au0) 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
von Klaus R. (klara)


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

von Timmo H. (masterfx)


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
von Klaus R. (klara)


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

von Zeno (Gast)


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.

von Chr. M. (snowfly)


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.

von Daniel P. (zwirbeljupp)


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

von Stefan ⛄ F. (stefanus)


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
von Chr. M. (snowfly)


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
von bingo (Gast)


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?

von Gurgl (Gast)


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

von Klaus R. (klara)


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

von Daniel P. (zwirbeljupp)


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

von Zeno (Gast)


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.

von M.M.M (Gast)


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.

von Wolfgang (Gast)


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.

von Axel S. (a-za-z0-9)


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.

von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe nun einen online-Anbieter gefunden, bei dem ich influxDB und 
Grafana als Cloudservice nutzen und testen kann. Auch wenn das hier 
offensichtlich viele anders sehen - für meine Zwecke die einfachste und 
wirtschaftlichste Möglichkeit, das Konzept zu evaluieren. Das Gespann 
aus InfluxDB und Grafana passt ausgezeichnet zu meinen Anforderungen, 
ggf. werde ich doch irgendwann den Umstieg auf einen eigenen RasPi 
Server durchführen.

Noch einmal zurück zu dem nächsten Problem:
Wie sende ich dem Gerät die Anforderung, nicht direkt nach dem Upload 
der Sensordaten in die influxDB gleich wieder in den DeepSleep zu 
wechseln?
Der Wunsch ist also, über ein ganz simples Kommando das Gerät in einen 
dauerhaften Wach-Zustand zu versetzen, so dass ich mich anschließend 
z.B. per Telnet verbinden kann, um Einstellungen zu ändern oder 
FW-Updates durchzuführen.

Folgende Möglichkeiten hatte ich untersucht:
A) das Gerät (ESP32) vor dem Schlafen 2-3 Sekunden auf eine 
Telnet-Verbindung warten lassen. Problem: ich habe kein Telnet Programm 
gefunden, dass z.B. 2-5 Minuten einen Verbindungsaufbau am Stück 
durchführt, ohne in einen Timeout zu laufen. Hat hier jemand einen 
Ansatz für mich?

B) Auf dem PC einen Telnet Server laufen lassen und den ESP32 vor dem 
Schlafen versuchen lassen, mit diesem Server zu verbinden. Sofern 
erfolgreich, in den Wachmodus wechseln und auf Kommandos warten. Auch 
hier leider kein passendes Programm für Windows 10 gefunden.

Grundsätzlich klingt A) für mich am sinnvollsten, da ich ohnehin die 
Telnet-Verbindung zur Konfiguration nutzen möchte. Komme aber hier nicht 
weiter.
Gibt es noch andere Ideen? Vielleicht gibt es ja noch andere Protokolle, 
die für diesen Zweck noch besser geeignet wären?

Danke & Gruß
Daniel

von Timo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kannst du das nicht evtl. mit mqtt erreichen?
Ich weiß nicht ob das vielleicht dann zu viel wird... Aber die mqtt 
Nachricht erhält der ESP ja auch, wenn er im deep sleep ist. Besser 
gesagt, er empfängt sie, sobald er wieder aktiv wird.

Dann könntest du eine bestimmte mqtt message senden, die der esp erkennt 
und die eine Funktion oder so startet, oder ihn in einen Modus ohne deep 
sleep versetzt.
Kommt stattdessen keine mqtt message macht er so weiter wie sonst.

Dies ist nur eine idee (ich mache es bei mir selbst ähnlich) und 
vielleicht nicht die einfachste / beste.
Den mqtt Server + versenden von Nachrichten würde ja auch von einen 
normalen PC aus gehen.

von Zeno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn von Deinem Bienenstock das Heimnetzwerk in Reichweite ist, dann 
bietet es sich an die Daten auch auf einer NAS-Platte zu speichern.
Wenn Du so etwas noch nicht hast würde ich über einen Raspi mit einer 
USB-Platte nachdenken. Das Rootsystem des Raspi's legst Du auf die 
USB-Platte, so das die SD Card nur zum Booten gebraucht wird.
Der Raspi kann auch gleich als Webserver dienen. Damit das funktioniert 
brauchst Du halt einen dynamic DNS Dienst. Ich habe DD-DNS - die sind 
kostenlos. Es gibt aber auch andere.
Wenn Du so einen kostenlosen DNS Dienst nutzt, dann fallen lediglich die 
Stromkosten für den Raspi an.Der Raspi braucht ca. 5W. Je nachdem ob 
eine SSD oder eine normale Festplatte anschließt kommen noch einmal 
2-10W dazu.
Du bist dann in jedem Fall der Herr der Daten und unabhängig.
Der Raspi kann den Speicherplatz im Netzwerk zur Verfügung stellen und 
gleichzeitig als Webserver agieren.

Als Datenbank würde ich eine RRD-Datenbank empfehlen. Habe ich für meine 
Wetterstation und das funktioniert bestens. Die Datenbank wird so 
konfiguriert das ab einem bestimmten Zeitpunkt die Daten komprimiert 
werden.
Beispiel: Du hast alle 5 Minuten einen neuen Datensatz. Macht 12 
Datensätze pro Stunde und 288 Datensätze pro Tag. Diese werden für einen 
bestimmten Zeitraum unverdünnt gespeichert, d.h. während dieser Zeit 
hast Zugriff auf jeden einzelnen Datensatz. Nach 30 oder 60 oder 90 
Tagen werden die Datensätze eines Tages zu einem Datensatz zusammen 
gefasst. Dabei werden für jeden Tag Minima, Maxima und Mittelwert 
gespeichert. Diese geschrumpften Daten werden für z.B. 20Jahre 
aufbewahrt. Der Zeitraum kann natürlich auch länger sein. Danach werden 
die Daten verworfen.
Diese Art der Datenspeicherung hat sich bewährt, denn nach einem muß man 
nicht mehr wissen wie die Temperatur am 13.01.2019 um 6:05Uhr war. Der 
Tagesmittelwert ist da völlig ausreichend.
Die RRD-Datenbank kann das Ganze auch grafisch darstellen. Schau einfach 
mal hier https://oss.oetiker.ch/rrdtool/, da findest Du alles 
Wissenswertes zu dieser Datenbank.


Habe es grad noch gelesen "Eigener Server zu Hause scheidet aus". Na ja 
wenn das in Stein gemeiselt ist dann vergiß den Vorschlag mit dem Raspi. 
Was hast Du gegen den Server zu Hause? Evtl. funktioniert das auch schon 
mit dem Router selbst, ich da schon mal was gelesen aber mich nicht 
näher damit befasst, da dies für mich keine Option war. Den wirst Du ja 
haben und der läuft ja 24/7.

von Zeno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ups .gerade mitbekommen der Thread ist ja schon steinalt und ich hatte 
mich zum Thema schon so ziemlich gleichlautend geäußert. Also vergesst 
meinen letzten Post einfach.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
> ich hatte mich zum Thema schon so ziemlich gleichlautend geäußert

Und ich dachte schon, ich hätte ein Déjà-vu wegen Fehler in der Matrix.

: Bearbeitet durch User
von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
@Zeno: danke für deinen ausführlichen Beitrag. Wie gesagt, influxDB und 
Grafana lassen momentan keine Wünsche mehr übrig. Ob in der Cloud oder 
auf dem eigenen rPi - diese Entscheidung vertage ich aber gerne noch.

Timo schrieb:
> Kannst du das nicht evtl. mit mqtt erreichen?
Danke, das ist eine gute Idee! Ich werde mir mal einen MQTT Broker in 
Windows installieren und schauen, ob das praxisgerecht funktioniert.

von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
Kleiner Zwischenstand:

MQTT sah eigentlich erst einmal ganz vielversprechend aus. Da ich nach 
wie vor keinen eigenen Server für das Vorhaben betreiben möchte, habe 
ich die MQTT-Kommunikation mittels io.adafruit.com (kostenloser MQTT 
broker) evaluiert. In meiner Anwendung hat sich leider gezeigt, dass das 
Abholen von gespeicherten Nachrichten sehr lange dauert (bis zu 10 
Sekunden). Das ist für meinen Anwendungsfall nicht ganz optimal.

Da sich die ESP32 immer in meinem Heim-WLAN befinden werden, habe ich 
einen zweiten Weg untersucht: Auf meinem PC lasse ich über "lighttpd" 
einen einfachen Webserver laufen. Die ESPs versuchen sich bei jedem Boot 
mit diesem Server zu verbinden und suchen dort nach einer Textdatei, die 
nach der jeweiligen MAC-Adresse benannt ist. In dieser Datei habe ich 
JSON-kodiert Konfigurationsdaten abgelegt bzw. bei Bedarf einen Verweis 
auf eine Firmware-Binary, die ebenfalls auf dem Server liegt. Dies 
funktioniert soweit super. Allerdings habe ich es bislang nicht 
geschafft, einen "Rückkanal" zu implementieren. Ich würde gerne z.B. 
nach erfolgtem Firmware-Update eine JSON-Datei (oder einfache Textdatei) 
mit einem Statusreport auf den Server ablegen. Sowie die Möglichkeit 
haben, regelmäßig Log-Dateien auf diesen Server hochzuladen.

An dieser Stelle hapert es bei mir aber komplett bei den Grundlagen. Wie 
muss ich den lighttpd-Server konfigurieren, um Dateiuploads zu 
ermöglichen? Welche Infrastruktur (PHP-Skript etc.) benötige ich auf dem 
Server, um Dateien zu empfangen? Bin an dieser Stelle leider etwas 
hilflos gerade. Hat jemand von Euch damit Erfahrung?

Danke & Gruß
Daniel

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel P. schrieb:
> In meiner Anwendung hat sich leider gezeigt, dass das
> Abholen von gespeicherten Nachrichten sehr lange dauert (bis zu 10
> Sekunden).

Du kannst einen irgendwo in der Cloud laufenden kostenlosen MQTT Server 
in der Performence realistisch betrachtet wohl schlecht mit einer lokal 
bei dir auf dem Rechner laufenden Anwendung vergleiche.

Da liegt die Schuld nicht bei MQTT.

von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Da liegt die Schuld nicht bei MQTT.

Habe ich auch nirgends behauptet. Ich sagte, dass der von mir getestete 
Prozess (im beschriebenen Setup) ungeeignet für meinen Anwendungsfall 
ist.

Neben der Performance der MQTT-Kommunikation löst MQTT aber auch nicht 
mein Problem der Übertragung von ~1 MB Firmware Images.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel P. schrieb:
> Neben der Performance der MQTT-Kommunikation löst MQTT aber auch nicht
> mein Problem der Übertragung von ~1 MB Firmware Images.

Dafür ist MQTT auch nicht gemacht. Diese Anforderung ist dann wohl 
später dazu gekommen. Aber mal ehrlich - wie oft musst du bei einem 
Bienenstock die Firmware updaten, wenn das Ding erstmal läuft.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Daniel P. schrieb:
> Wie muss ich den lighttpd-Server konfigurieren, um
> Dateiuploads zu ermöglichen?

Ich denke, der Sinn dieses lighttpd besteht darin, Dateien an den Client 
auszuliefern. Punkt.

Für Uploads brauchst du eine Server-Anwendung, die den Uploads empfängt 
und entscheidet, was damit zu tun ist. Ich kenne keinen generischen HTTP 
Server, der beliebige Uploads annimmt und einfach irgendwo abspeichert.

Im Job programmiere ich solche Dinge mit einem Java EE Server (Wildfly). 
Für deinen Zweck reicht sicher der wesentlich schlankere Apache Tomcat.

Zu hause würde ich das eher quick&dirty mit einem Apache HTTP Server und 
PHP Scripten machen.

Früher in den Anfangszeiten des Webs hatte man das mit CGI Scripten in 
Perl gemacht - auch basierend auf dem Apache HTTP server.

Jetzt hast du ein paar Stichworte zum Googeln.

: Bearbeitet durch User
von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Das Einfachste, unter der Bedingung kein Server zuhause wäre in dem 
Fall, die Daten im Bienenstock Controller als Webseite abrufbar zu 
haben. Gespeichert auf etwas Dauerhaftem, wie zB Flasch, MagnetRam, SD, 
oder so.

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wetterdaten online zu Wunderground oder OpenWeatherMap, dann gibts auch 
Daten zurück. Kein lokaler Server erforderlich, Daten per Web und API. 
Keine Kosten.

Stockgewicht, Zähler in/out per 7-Segment-Anzeige über Webcam... Alles 
auf einer Seite.

Und die lokalen, statt Influx mal Prometheus anschauen.

Weiterbashen.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich denke, der Sinn dieses lighttpd besteht darin,
> Dateien an den Client auszuliefern. Punkt.

Ich fürchte, da hast du mal wieder einen Bock geschossen.
Du bist nicht hilfreich, wenn du Stuss erzählst.

Man braucht keinen großen Enterprise-Service, um eine Datei irgendwo 
hinzuspeichern. Das kann jeder POST-fähige Webserver.

Daniel P. schrieb:
> An dieser Stelle hapert es bei mir aber komplett bei den
> Grundlagen. Wie muss ich den lighttpd-Server konfigurieren,
> um Dateiuploads zu ermöglichen?

Du definierst in lighttpd.conf einen Ort für temporäre Dateien 
("server.upload-dirs") und dann brauchst du noch einen Handler für die 
Daten. Das kann z.B. ein Perl- oder PHP-Script mit CGI sein, je nachdem 
was du hast. In meinem Fall ist das ein etwas älteres Perl-Script.

Die lighttpd.conf kann ich dir nicht mehr zeigen, da ich vor einigen 
Jahren auf nginx umgestellt habe.

Du erzeugst also eine HTML-Seite mit ungefähr sowas:
  <form action="/upload.pl" method="post" enctype="multipart/form-data">
    Datei / File:
    <br>
    <input type="file" name="filename" size="30">

    <br><br>
    <input type="submit">
    <input type="reset">
  </form>

Das Script auf der anderen Seite sieht dann mindestens so aus:
#!/usr/bin/perl -wT
use strict;
use v5.010;
use CGI;
use CGI::Carp qw (fatalsToBrowser);
use File::Copy;

# read parameters
my $query = new CGI;
my $file = $query->param("filename");

print $query->header();
if(!$file) {
  # kein Dateiname gesendet,
  # schicke HTML-Formular
  say "<html><title>Formular</title></html>";
} else {
  # dateiname angegeben
  # prüfen und in Zielordner kopieren
  my $tmpfile = $query->tmpFileName($query->param('filename'));
  copy($tmpfile, "/srv/www/incoming/$file");
  say "<html><title>Erfolgreich!</title></html>
}

Pass auf, dass die Dateinamen nicht seltsam sind 
("../../../etc/passwd"), dass nicht jeder einfach so Dateien schicken 
kann, dass die Dateien eine maximale Größe haben, dass die Daten gültig 
sind, usw. und schicke vielleicht eine E-Mail, dass Daten gesendet 
wurden.

Du kannst so ein Script auch in C/C++ oder einer beliebigen anderen 
Sprache schreiben. Die Daten, die ich aus $query hole, werden vom Server 
als Umgebungsvariable abgespeichert. Vermutlich reicht also auch ein 
Shellscript - der lighttpd muss es aber ausführen können.

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich fürchte, da hast du mal wieder einen Bock geschossen.
> Du bist nicht hilfreich, wenn du Stuss erzählst.

> dann brauchst du noch einen Handler für die
> Daten. Das kann z.B. ein Perl- oder PHP-Script mit CGI sein, je nachdem
> was du hast. In meinem Fall ist das ein etwas älteres Perl-Script.

Ach nee, das gleiche habe ich auch empfohlen, allerdings mit dem Apache 
Server, weil ich bei dem halt weiß, wie es geht.

Jedenfalls geht es nicht ohne so ein Script, da sind wir und doch einig, 
oder?

> Man braucht keinen großen Enterprise-Service

Auch das habe ich geschrieben. Wenn du schon über meine Beiträge ab 
lästerst, dann lies sie wenigstens vorher durch. Nicht schon nach dem 
ersten Satz das Hirn abschalten!

: Bearbeitet durch User
von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
@stefanus, svenska:
Herzlichen Dank, ihr habt mir die entscheidenden Hinweise geliefert! Es 
reicht tatsächlich ein einfaches PHP script, um den Dateiupload 
durchzuführen (wenn man denn verstanden hat, dass man zunächst PHP 
installieren und entsprechend konfigurieren muss...). Als Referenz hier 
meine Dateien:

lighttpd.conf
server.modules = (
"mod_rewrite",
"mod_access",
"mod_setenv",
"mod_cgi",
"mod_webdav",
"mod_accesslog" )

mimetype.assign = (
  ".html" => "text/html", 
  ".txt" => "text/plain",
  ".jpg" => "image/jpeg",
  ".png" => "image/png" 
)

cgi.assign = ( ".php" => "c:/php/php-cgi.exe", ".cgi" => "c:/php/php-cgi.exe" )

server.document-root = "C:\temp\webserver" 
server.port = 80
server.username = "www-data" 
server.groupname = "www-data" 
server.upload-dirs = ("C:\temp\webserver\var\tmp" )
server.errorlog = "C:\temp\webserver\var\error.log"

accesslog.filename = "C:\temp\webserver\var\web-access.log"
url.access-deny = ( "~", ".inc" )

static-file.exclude-extensions = ( ".txt",".php", ".pl", ".fcgi" )

index-file.names = ( "index.html" )

## enable debugging
debug.log-request-header     = "enable" 
debug.log-response-header    = "enable" 
debug.log-request-handling   = "enable" 
debug.log-file-not-found     = "enable" 
debug.log-condition-handling = "enable" 

Code auf der HTML-Seite:
    <form enctype="multipart/form-data" action="upload.cgi" method="POST">
    <input type="hidden" name="MAX_FILE_SIZE" value="10000000">
    Choose a file to upload: 
    <input name="uploadedfile" type="file" id="fileToUpload">
    <input type="submit" value="Upload File">
    </form>

upload.cgi
<?php        
    $uploaddir = 'C:/temp/webserver/uploads/';
    $uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
    echo "<p>";  
    if ( ! is_writeable ( $uploaddir ) )
    {
        echo 'Can\'t write to directory, insufficient permissions.';
    }
    else
    {
        if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
            echo "File is valid and was successfully uploaded.\n";
        } else {
            echo "Upload failed";
        }
    }

    echo "</p>";
    echo '<pre>';
    echo 'Here is some more debugging info:';
    print_r($_FILES);
    print "</pre>";
?>


Gruß
Daniel

von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Daniel P. schrieb:
>> Neben der Performance der MQTT-Kommunikation löst MQTT aber auch nicht
>> mein Problem der Übertragung von ~1 MB Firmware Images.
>
> Dafür ist MQTT auch nicht gemacht. Diese Anforderung ist dann wohl
> später dazu gekommen. Aber mal ehrlich - wie oft musst du bei einem
> Bienenstock die Firmware updaten, wenn das Ding erstmal läuft.

Klar, wenn alles läuft benötige ich den Firmware upload vermutlich nur 
noch selten. Aber aktuell ist das System am Bienenstock installiert und 
sammelt dort kritische Daten. Parallel baue ich aber weitere Funktionen 
ein. Da ich keine Lust habe, 5x pro Woche mit dem Laptop zum Bienenstock 
zu laufen ist das Remote FW Update gerade jetzt ein unverzichtbares 
Feature.

von Daniel P. (zwirbeljupp)


Bewertung
0 lesenswert
nicht lesenswert
Joggel E. schrieb:
> Das Einfachste, unter der Bedingung kein Server zuhause wäre in dem
> Fall, die Daten im Bienenstock Controller als Webseite abrufbar zu
> haben. Gespeichert auf etwas Dauerhaftem, wie zB Flasch, MagnetRam, SD,
> oder so.
SD Karte ist vorhanden, aber da kein Zugang zum Stromnetz nur 
Akkubetrieb + Solarzelle. Die Stromversorgung ist nicht dafür ausgelegt, 
den ESP32 dauerhaft als Webserver zu betreiben.
Daher der Wunsch, gezielt den Upload von Daten vom ESP32 zum 
lighttpd-Server zu starten.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ach nee, das gleiche habe ich auch empfohlen,
> allerdings mit dem Apache Server, weil ich bei
> dem halt weiß, wie es geht.

Ähm. Lies nochmal deinen Beitrag mit einem anderen Auge...

Erst sagst du, dass lighttpd ungeeignet ist.
Dann sagst du, dass du eine "Server-Anwendung" brauchst.
Dann sagst du, dass normale HTTP-Server das nicht können.
Dann nennst du Enterprise-Software.
Dann nennst du immernoch einen semiprofessionellen Application Server.

Und dann nennst du eine für den TO angemessene Lösung, bezeichnest die 
als "quick&dirty" und auf der Basis von Apache, was der TO nicht nutzt.

Dein ganzer Beitrag klingt jetzt nicht gerade nach "klar geht das, 
machst du so hier", sondern nach "nee, das wird entweder eine furchtbar 
eklige Pfuscherei mit Apache HTTP oder du brauchst einen richtigen 
Application Server mit Administration". Siehst du ein, oder?

Du achtest doch sonst eher auf Didaktik. Den TO in eine völlig falsche 
Richtung zu schicken ist da eher kontraproduktiv... es sei denn, es war 
deine Absicht, aber das unterstelle ich dir mal nicht.

Stefan ⛄ F. schrieb:
> Jedenfalls geht es nicht ohne so ein Script,
> da sind wir und doch einig, oder?

Vermutlich gibt es sogar einige Webserver, die das selbst können. Aber 
ja, normalerweise braucht man dazu ein bisschen serverseitigen Code.

Daniel P. schrieb:
> Es reicht tatsächlich ein einfaches PHP script,
> um den Dateiupload durchzuführen [...]

Wobei ich ja aus Prinzip schon von PHP abraten würde. :-)

> Als Referenz hier meine Dateien:

Nur ein paar Kommentare.

Du kannst Dateiuploads auch über WebDAV machen, wenn du das ohnehin 
schon aktiviert hast. Das Debugging in lighttpd.conf würde ich 
irgendwann abschalten, ehe die Platte volläuft.

Meine PHP-Kenntnisse sind zwar eher dünn, aber spontan würde ich dein 
Uploadscript als Sicherheitslücke betrachten. :-)

Niemand hindert dich daran, eine Datei mit dem schönen Namen 
"../../../ntldr" hochzuladen und den Bootloader zu überschreiben [1]. 
Wenn der Webserver genug Rechte hat, bootet danach das System nicht 
mehr.

Mein Script prüft, ob der Dateiname bestimmten Kriterien genügt (extrem 
streng). Im Webserver selbst habe ich die maximale Dateigröße zusätzlich 
begrenzt (das Formular kann ein Angreifer ignorieren). Außerdem habe ich 
noch eine Liste von Passwörtern im Script, die der Benutzer mitschicken 
muss, sonst wird der Upload direkt abgelehnt. Achso, und ich lasse mir 
für jeden Upload eine E-Mail schicken, um Missbrauch zu erkennen.

Daher meine Empfehlung: Prüfe mehr.

[1] Ja ich weiß, WinXP. Egal.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
PHP ist in vielen Firmen verpönt. Ich persönlich habe als Hauptgrund 
mitbekommen, dass zu viele schlechte Programme in PHP geschrieben wurde. 
Diese haben den Ruf der Programmiersprache noch weiter herunter gezogen, 
als die Sicherheitslücken der Sprache selbst.

Deswegen habe ich die Lösung mit PHP als quick&dirty bezeichnet.

Ich nutze PHP trotzdem ab und zu in privaten Projekten, insofern kann 
ich dem Daniel zu seinem schnellen Erfolg damit nur gratulieren. Für den 
Anfang war das doch gar nicht schlecht. Wie viel Sicherheit für seinen 
Anwendungsfall angemessen ist, kann er nur selbst entscheiden.

Auch Dir S.R. möchte ich für den Hinweis danken, dass der lighthttp 
Server ebenfalls PHP unterstützt. Das hat dem Daniel sicher auch 
geholfen.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Auch Dir S.R. möchte ich für den Hinweis danken,
> dass der lighthttp Server ebenfalls PHP unterstützt.

Naja, so ziemlich jeder Webserver unterstützt CGI
(außer nginx, der kann nur FastCGI). Und wenn man CGI
hat, dann reicht auch ein Shellscript.

Wenn du auf sowas wie mod_php anspielt, das ist eine Apache-eigene 
Performance-Sicherheitslücke. Sowas macht man heutzutage besser nicht 
mehr.

S. R. schrieb:
> Siehst du ein, oder?

Schade.

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.