Diese Projektidee basiert auf einem von Klaus' Anwendungswünschen. Er möchte Temperaturverläufe in einer Sporthalle erfassen, wo keine WLAN-Verbindung hierfür genutzt werden kann.
Vorgesehene Geräte
- Shelly Plus 1 mit AddOn und digitalem Temperatursensor als Messeinrichtung
- Raspberry Pi mit installiertem Node-RED, MQTT Broker als Ziel für die persistente Speicherung der Messwerte
(später nicht zwingend, aber nützlich: InfluxDB, Grafana)
Das Ziel
Der Shelly soll über eine Zeitspanne von einer Woche die örtliche Temperatur sammeln und gesammelte Werte komplett übertragen. Nach der Übertragung soll eine neue Messreihe begonnen werden. Die Messwerte sollen langzeitlich analysiert werden können.
Realisierungsumgebung
- Als langzeitliches Speicherziel kann ein Raspberry Pi dienen, der bspw. per Node-RED Anwendung die Daten vom Shelly empfängt und zunächst in einer Textdatei speichert. Später kann zur Speicherung eine Zeitreihendatenbank verwendet werden. Dann können diese Werte per grafischer Abbildungen als Zeitfunktion leicht in ihrem Verlauf analysiert werden. Hierzu können InfluxDB und Grafana genutzt werden.
- Zur Übertragung der gesammelten Werte gibt es folgende Varianten.
- Ein mobiles Gerät wie ein Smartphone empfängt die Werte zwecks Zwischenspeicherung.
Vorteil: Die Messeinrichtung kann an Ort und Stelle bleiben und die nächste Messreihe starten
Nachteil: Ein Smartphone kann entweder nur die Werte anzeigen oder braucht eine App zur Speicherung der Werte, um diese später dem eigentlichen Speicherziel zuzuführen. Dieser Nachteil wirkt sich dann nicht aus, wenn das Speicherziel, bspw. der erwähnte Raspberry Pi, zur Messeinrichtung transportiert wird. - Ein Notebook am Messort kann zum Zweck der Übertragung vielseitig eingesetzt werden. Es muss dazu per (W)LAN mit dem Shelly gekoppelt werden, wozu der Shelly eigene Access Point genutzt werden kann.
- Per Web Browser öffnet man die Web UI des Shelly, wählt im Menü "Scripts" und öffnet die Datei "data" (nicht starten!). Nun kann man alle Daten per Strg+A (alles auswählen), Strg+C (Kopieren -> Zwischenspeicher) und in einem Editor die Daten per Strg+V einfügen.
Vorteil: Es werden ausschließlich Standardanwendungen und nichts zusätzliches benötigt.
Nachteil: Es ist keine Automatisierung möglich. Alle Schritte müssen manuell vorgenommen werden. - Auf dem Notebook arbeitet ein MQTT Broker und ein MQTT fähiges Programm, bspw. ein Node-RED Flow. Hiermit können die Daten vom Shelly auf das Notebook übertragen werden. Bei Bedarf kann ein Node-RED Dashboard zur Steuerung des Shelly erstellt werden.
Vorteile: Die Übertragung kann weitgehend automatisiert erfolgen. Es ist kein zentrales, übergeordnetes System erforderlich.
Nachteile: Das relativ große Notebook muss zur Messstelle transportiert werden. Eine zentrale Speicherung findet nicht automatisch statt.
- Per Web Browser öffnet man die Web UI des Shelly, wählt im Menü "Scripts" und öffnet die Datei "data" (nicht starten!). Nun kann man alle Daten per Strg+A (alles auswählen), Strg+C (Kopieren -> Zwischenspeicher) und in einem Editor die Daten per Strg+V einfügen.
- Die Messeinrichtung wird zum Übertragungsort transportiert, wo die gesammelten Werte langzeitlich gespeichert werden.
Vorteil: Es wird keine Zwischenspeicherung der Werte benötigt.
Nachteil: Während der Abwesenheit der Messeinrichtung vom Einsatzort kann keine Messung stattfinden. Dies kann durch eine zweite, baugleiche Messeinrichtung zwecks Austausch vermieden werden. - Es wird ein öffentlicher MQTT Broker zur Steuerung und Datenübertragung genutzt.
Hierfür ist eine Zusammenstellung folgender Dinge geeignet.- Ein Smartphone, welches einen Hotspot zur Verfügung stellt. Damit erreicht der Shelly das Internet, einen Zeitserver und insbesondere den MQTT Broker.
- Eine auf dem Smartphone installierte MQTT App. Ich bevorzuge die Android App MQTT Dash.
- Zu Hause ein MQTT fähiges Gerät, welches die MQTT Topics auf dem öffentlichen MQTT Broker abonniert (Subscriber). Hierfür ist bspw. ein Raspberry Pi mit installiertem Mosquitto und Node-RED geeignet.
- Ein mobiles Gerät wie ein Smartphone empfängt die Werte zwecks Zwischenspeicherung.
Die letzte Variante besitzt nach Einrichtung aller Dinge die einfachste Handhabung. Es genügt, den Hotspot auf dem Smartphone zu aktivieren und die Übertragung per MQTT App zu starten.
Welche Ausstattung und welches Verfahren schließlich eingesetzt werden, ist dem Anwender überlassen. Ich werde jedenfalls keine Smartphone App zur Zwischenspeicherung zur Verfügung stellen. Die Implementation im Shelly ist davon unberührt.
Lösungsansatz im Shelly
Nach reiflichen Überlegungen während des Schreibens dieses Beitrags möchte ich zunächst den am leichtesten zu implementierenden Anwendungsfall aufzeigen.
- Bei Stromausfall verliert der Shelly alle bisher gesammelten Messwerte.
- Der Zielspeicher, hier ein Raspberry Pi, wird zwecks Messwertübertragung zur Messeinrichtung (Shelly) transportiert. Der Shelly bleibt somit immer am Messort.
Für diesen einfachsten Anwendungsfall brauchen die Messwerte nicht per KVS gespeichert zu werden. Hierfür genügt die Speicherung im flüchtigen Speicher (RAM) des Shelly, da die Messeinrichtung nicht von der Stromversorgung getrennt wird.
Zwecks Übertragung von gesammelten Messwerten ist der Raspberry Pi mit dem Shelly per WLAN zu verbinden. Ob hierfür der Shelly seinen Access Point (AP) zur Verfügung stellt oder dies der Raspberry Pi tut, bleibt dem Anwender überlassen.
Während der fortlaufenden Messwerterfassung wird jeder neue Wert in einem Datenfeld abgelegt, dessen Länge somit schrittweise zunimmt.
Der Eventhandler speichert schlicht den empfangenen Messwert in einer temporären Variablen "Temp". Später kann bei Bedarf eine Mittelwertbildung zwischen zwei Speicherungen im Datenfeld ergänzt werden.
Es ist eine feste Abtastfrequenz vorzusehen, bspw. alle 10 Minuten ein zu speichernder Messwert. Da die Messwerte in nicht genauen und insbesondere zu kurzen Zeitabständen dem Eventhandler mitgeteilt werden, ist hier die Verwendung eines Schedule Jobs vorzusehen, der bspw. alle 10 Minuten eine Funktion "store()" aufruft. store() fügt den Wert in "Temp" dem Datenfeld hinzu.
Eine MQTT-Subscriber callback Funktion zum Topic "send" sendet bei Empfang einer Nachricht alle Werte des Datenfeldes in einer MQTT-Nachricht oder mehreren weniger umfangreichen Nachrichten und leert anschließend das Datenfeld. Damit beginnt die Messwertaufzeichnung von vorne. Später können bei Bedarf die Zeitinformationen (Beginn der Messwertsammlung, Periodendauer bspw. 10 Minuten) sowie deren Übertragung hinzugefügt werden.
Die Erfassung der Periodendauer kann später automatisiert werden. Hierfür sind bei Skriptstart (reboot) die Schedule Jobs einzulesen, der passende Job (vermutlich existiert nur einer) per Id zu selektieren, aus dessen timespec-Wert die Periodendauer zu ermitteln und diese in der Zeitinformationsvariablen abzulegen.
Beispiel:
timespec="0 */10 * * * *" kann in 6 Teile zerlegt werden, der zweite Teil enthält "*/10", worin der Wert hinter dem Slash die Periodendauer enthält. Falls darin kein Slash existiert, muss die Periodendauer anders ermittelt werden, was nicht schwierig ist. Bei Bedarf später dazu mehr.
Zusammenfassung zur ersten funktionstüchtigen Implementation
Benötigt werden
- eine Skript-globale Variable "Temp" zwecks Speicherung des neuesten Messwertes (mit null zu initialisieren),
- eine Skript-globale Variable "Values" zwecks Speicherung aller gesammelten Messwerte (leer zu initialisieren),
- der Eventhandler zwecks empfangen eines neuen Messwertes und dessen Speicherung in "Temp",
- eine Funktion "store()" zwecks anfügen des letzten Messwertes (in "Temp") an das Datenfeld "Values",
- ein MQTT Subscriber zum Topic "send" zwecks senden aller im Datenfeld "Values" gespeicherten Werte,
- ein Schedule Job, der in regelmäßigen Zeitabständen die Funktion "store()" aufruft.
Zu 5.
Das komplette Topic ist aus einem Pfad zur Messeinrichtung und dem Wort "send" zusammenzusetzen, bspw. "Turnhalle/Station01/send". Das Senden erfolgt per MQTT.publish() mit passendem Topic, bspw. "Turnhalle/Station01/receive".
Dies ist die imho einfachst mögliche Implementation in diesem Projekt. Sie kann bei Bedarf später durch weitere Teile ergänzt werden, welche bspw. die Nutzbarkeit (usability) verbessern. Auch kann die Ausfallsicherheit erhöht werden, was allerdings nicht trivial ist.
Zum Raspberry Pi
Die Übertragung sowie persistente Speicherung der Messwerte kann per Node-RED implementiert werden. Die einfachste Form wird ausschließlich per Flow-Editor gesteuert. Darin kann per inject node das Senden einer MQTT-Nachricht mit dem passenden Topic ausgelöst werden. Ein mqtt-in node mit dem im Shelly verwendeten Sende-Topic, wie "Turnhalle/Station01/receive", empfängt die Messwerte, die nach dem Empfang geeignet zu verarbeiten und zu speichern sind.
Dies ergibt einen relativ kleinen Flow, welcher relativ leicht zusammengestellt werden kann. Später kann dieser Flow für ein benutzerfreundliches Dashboard erweitert werden.
Zur Speicherung der Messwerte kann zunächst eine Textdatei verwendet werden, was recht einfach ist. Diese Datei kann mit einem einfachen Editor geöffnet und der Inhalt gelesen werden. Später ist die Speicherung in einer Influx Datenbank zu empfehlen. Für die Abfrage der Messwerte ist jedoch eine Einarbeitung erforderlich.
Zur grafischen Darstellung der per InfluxDB gespeicherten Messwerte ist Grafana sehr gut geeignet, worin man sich einarbeiten muss. Das Resultat wird aber sehr überzeugend sein.
Auf Grund neuerer Erkenntnisse können die Messwerte in einer persistenten Datei auf dem Shelly gespeichert werden. Dieses Verfahren wird bevorzugt.
2024-02-21