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
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/
Angehängte Dateien:
-
weather.jpg
150 KB -
weather2.jpg
160 KB
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
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
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
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
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.
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.
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
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.
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
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?
bingo schrieb: > heute noch von dBase Niemand, allerdings gibt es immernoch ODBC-Treiber dafür, es sollte also rein theoretisch heute noch funktionieren
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
Angehängte Dateien:
-
IMG_8672.jpg
240 KB -
Thingspeak_dashboard.png
46 KB
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
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.
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.
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.
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.
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
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.
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.
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.
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.
@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.
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
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.
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.
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.
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.
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.
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.
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:
1 | <form action="/upload.pl" method="post" enctype="multipart/form-data"> |
2 | Datei / File: |
3 | <br> |
4 | <input type="file" name="filename" size="30"> |
5 | |
6 | <br><br> |
7 | <input type="submit"> |
8 | <input type="reset"> |
9 | </form> |
Das Script auf der anderen Seite sieht dann mindestens so aus:
1 | #!/usr/bin/perl -wT |
2 | use strict; |
3 | use v5.010; |
4 | use CGI; |
5 | use CGI::Carp qw (fatalsToBrowser); |
6 | use File::Copy; |
7 | |
8 | # read parameters |
9 | my $query = new CGI; |
10 | my $file = $query->param("filename");
|
11 | |
12 | print $query->header(); |
13 | if(!$file) {
|
14 | # kein Dateiname gesendet, |
15 | # schicke HTML-Formular |
16 | say "<html><title>Formular</title></html>"; |
17 | } else {
|
18 | # dateiname angegeben |
19 | # prüfen und in Zielordner kopieren |
20 | my $tmpfile = $query->tmpFileName($query->param('filename'));
|
21 | copy($tmpfile, "/srv/www/incoming/$file"); |
22 | say "<html><title>Erfolgreich!</title></html> |
23 | } |
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.
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!
@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
1 | server.modules = ( |
2 | "mod_rewrite", |
3 | "mod_access", |
4 | "mod_setenv", |
5 | "mod_cgi", |
6 | "mod_webdav", |
7 | "mod_accesslog" ) |
8 | |
9 | mimetype.assign = ( |
10 | ".html" => "text/html", |
11 | ".txt" => "text/plain", |
12 | ".jpg" => "image/jpeg", |
13 | ".png" => "image/png" |
14 | ) |
15 | |
16 | cgi.assign = ( ".php" => "c:/php/php-cgi.exe", ".cgi" => "c:/php/php-cgi.exe" ) |
17 | |
18 | server.document-root = "C:\temp\webserver" |
19 | server.port = 80 |
20 | server.username = "www-data" |
21 | server.groupname = "www-data" |
22 | server.upload-dirs = ("C:\temp\webserver\var\tmp" )
|
23 | server.errorlog = "C:\temp\webserver\var\error.log" |
24 | |
25 | accesslog.filename = "C:\temp\webserver\var\web-access.log" |
26 | url.access-deny = ( "~", ".inc" ) |
27 | |
28 | static-file.exclude-extensions = ( ".txt",".php", ".pl", ".fcgi" ) |
29 | |
30 | index-file.names = ( "index.html" ) |
31 | |
32 | ## enable debugging |
33 | debug.log-request-header = "enable" |
34 | debug.log-response-header = "enable" |
35 | debug.log-request-handling = "enable" |
36 | debug.log-file-not-found = "enable" |
37 | debug.log-condition-handling = "enable" |
Code auf der HTML-Seite:
1 | <form enctype="multipart/form-data" action="upload.cgi" method="POST"> |
2 | <input type="hidden" name="MAX_FILE_SIZE" value="10000000"> |
3 | Choose a file to upload: |
4 | <input name="uploadedfile" type="file" id="fileToUpload"> |
5 | <input type="submit" value="Upload File"> |
6 | </form> |
upload.cgi
1 | <?php
|
2 | $uploaddir = 'C:/temp/webserver/uploads/'; |
3 | $uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']); |
4 | echo "<p>"; |
5 | if ( ! is_writeable ( $uploaddir ) ) |
6 | {
|
7 | echo 'Can\'t write to directory, insufficient permissions.'; |
8 | }
|
9 | else
|
10 | {
|
11 | if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) { |
12 | echo "File is valid and was successfully uploaded.\n"; |
13 | } else { |
14 | echo "Upload failed"; |
15 | }
|
16 | }
|
17 | |
18 | echo "</p>"; |
19 | echo '<pre>'; |
20 | echo 'Here is some more debugging info:'; |
21 | print_r($_FILES); |
22 | print "</pre>"; |
23 | ?>
|
Gruß Daniel
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.
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.