Die Nutzung von Solaranlagen und Balkonkraftwerken führt ja immer wieder zu der Frage, ob und wenn ja ab wann sich ein Batteriespeicher lohnt und in welcher Größe dieser sinnvoll ist. Im Netz und auf Youtube bekommt man dazu bereits eine Vielzahl von Informationen, aber manche Aussagen scheinen mir dann doch zu weit hergeholt. Auch die viele Formeln zur Berechnung lösen bei mir teilweise Misstrauen aus. In meinem Beitrag zeige ich, wie man mit InfluxDB und Grafana interaktiv verschiedene Szenarien durchspielen kann.

Aufgabenstellung

Für meine Berechnungsgrundlage verwende ich die protokollierten Ertragsdaten einer PV-Anlage (ohne Batteriespeicher) mit einer Größe von ca. 3,2 kWp. Diese Daten liegen in einer InfluxDB 2.x-Datenbank vor und die folgenden Auswertungen mache ich ausschließlich mit Grafana. Eine wesentliche, aber mir unbekannte Größe ist der nächtliche Verbrauch, denn den möchte ich natürlich mit einem Überschuss tagsüber abdecken. Der Gedanke, über mehrere Tage mit einem Speicher "überleben" zu können, ist zwar nett, erfordert aber einen sehr großen Speicher (mehrfacher Tagesbedarf) und somit einer großen Anzahl von PV-Modulen, die aus meiner Sicht auf privaten Hausdächern kaum unterzubringen ist.

Für meine Berechnungen möchte ich die Größe des Speichers und den Strompreis interaktiv verändern können, ebenso wie die Größe der Anlage, die den Strom produziert.

Als Ergebnisse meines Beispiels sollen

• der durchschnittlichen Nachtverbrauch
• die Menge des gesparten Stroms
• der ersparte Wert in Euro

ermittelt werden und der Betrachtungszeitraum variabel sein.

Grafana Variabeln nutzen

Für jede Größe eines Stromspeichern könnte ich eine eigene Visualisierung erstellen, aber das ist mir zu umständlich. Ich möchte gerne per Dropdown-Menü die Größe eines möglichen Stromspeichern auswählen und Grafana soll mir anzeigen, was das bringt.

Variabeln werden immer für ein Dashboard angelegt, so dass man diese auch für mehrere Visualisierungen auf dem Dashboard nutzen kann.

Um Variabeln nutzen zu können, muss man das Konfigurationsmenü für das Dashboard auswählen. Dies befindet sich in der oberen Leiste mit dem Dashboard-Name auf der rechten Seite hinter dem Zahnradsymbol.

Unter "Settings" findet man nun auf der linken Seite den Menüpunkt "Variables".

Nach dem Drücken auf "New Variable" kann man die Variableneigenschaften näher definieren. Da ich eigene Werte zur Auswahl vorgeben möchte wähle ich unter "Variable type" "Custom" aus. Die Variable möchte ich unter dem Name "sinterval" in Grafana-Abfragen benutzen. Auf dem Dashboard soll als Label  "Speichergröße" erscheinen. Und unter Custom options trage ich durch Komma getrennt die Werte ein, die in meiner Dropdownliste erscheinen sollen. Sobald man diese Werte eingetragen hat sieht man die Ergebnisse bereits am untern Bildschirmrand.

Auf diese Weise lege ich drei Variablen an, die Erste für die Größe eines möglichen Batteriespeichers ("sbattery"), die Zweite zur Skalierung der Anlagengröße (und damit des Überschusses ("sscaler") und eine Dritte für den aktuellen Strompreis ("sprice").

Nach dem Anlegen der Variabeln sollte man nicht vergessen, das Dashboard zu speichern.

Durchschnittlichen Nachtverbrauch bestimmen

Ein Batteriespeicher dient primär dazu, Überschuss zu speichern und den Strom dann zu liefern, wenn die Sonne keinen Strom produziert (z.B. nachts). Daher verwendet man häufig die in der Dunkelheit benötigte Menge Strom als Maßstab, um die Mindestgröße eines Batteriespeichers zu bestimmen.

Ich schaue mir also für einen bestimmten Zeitraum an, welche Menge an Strom ich nachts benötige und ermittele hieraus den Mittelwert. Dabei gehe ich davon aus, dass der Zeitraum von Frühjahr (März) bis Herbst (November) ideal für eine Betrachtung ist, da eine Photovoltaikanlage zwischen November und März kaum soviel Leistung erzeugt, dass man Überschüsse erwirtschaftet, die man speichern kann. Als Uhrzeit für den nächtlichen Zeitraum habe ich 21:00 Uhr abends bis 5:00 Uhr morgen definiert.

Die Abfrage für diese Mittelwert sieht wie folgt aus:

Die "date"-Bibliothek braucht man für die hourSelection()-Funktion. Mittels der "timezone"-Bibliothek und der "location"-option löst man die Übersetzung der  UTC-Zeitangabe in die deutsche Zeit auf (im Winter UTC+1 sonst UTC+2 Stunden)

Den Verbrauch ermittele ich aus der Differenz der nächtlichen Zählerstände des Smartmeters. Wie man das macht findet ihr in folgendem Beitrag: SmartMeter mit Tasmota auslesen

Nun schränke ich die ermittelten Differenzen auf die von mir ausgewählte tägliche Zeitspannen mittels der hourSelection()-Funktion ein. Dies erfolgt vor der Aggregat()-Funktion, mit der ich die Summe für die Zählerdifferenzen für jeweils einen Tag bilde.

Und abschließend wird mit der Mean()-Funktion der Mittelwert über alle Nachtverbräuche gebildet. Aus der Auswertung ergibt sich, dass im von mir gewählten Zeitraum (vom März bis Ende Oktober) durchschnittliche 4,1 kWh in der Uhrzeit von 21:00 Uhr bis 5:00 Uhr morgens verbraucht wurden.

Einsparung eines Batteriespeichers berechnen

Im nächsten Schritt berechne ich mittels Grafana, wieviel kWh ich durch einen Batteriespeicher einsparen würde.  Die Werte kann man ebenfalls an einem Smartmeter auslesen, wenn dieser auch die ausgehende Leistung messen kann, die an den Netzbetreiber geliefert wird. Diese Zweirichtungsmessung bieten mittlerweile fast alle Geräte an, wenn man diese Daten für eine Protokollierung freigeschaltet hat.

Der Code hierzu lautet wie folgt:

Wie bei der Ermittlung der Verbräuche bilde ich die Differenzen der Zählerstände und addiere diese für jeden Tag mit der Aggregat()-Funktion.

Anschließend bearbeite ich die Werte mit der map()-Funktion und modifiziere die ermittelten Werte wie folgt:

Die Größe des Batteriespeichers gebe ich (wie oben beschrieben) durch den Wert in der Variabeln  "sinteraval" vor. Daraus ergibt sich, dass ich für alle Tage

• an denen der Überschuss größer als die Größe des Batteriespeichers in der Variabeln "sinterval" ist nur die Größe des Batteriespeichers
• an denen der Überschuss kleiner der Größe des Batteriespeichers in der Variabeln "sinterval" ist den Überschuss des Tages

weiterverwenden kann.

Bei der Berechnung muss ich den Wert in der Variabeln "sinterval" in einen float()-Typ umwandeln, da die Multiplikation sonst zum Typkonflikt führt.

Und mit der folgenden map()-Funktion baue ich noch einen Skalierungsfaktor ein, der "simuliert", wie groß mein Ertrag sein könnte, wenn die Anlage (und damit auch der Ertrag) um den Faktor "sscaler" größer wäre. Auch hier erfolgt eine Typumwandlung.

Ich habe noch ein zweites Panel erstellt, mit dem ich den Wert der Ersparnis in Euro ermittele. Dazu benutze ich die dritte Variable "sprice". Durch Austauschen der letzten Zeile in der vorigen Abfrage kann man diesen Wert in einem neuen Panel wie folgt ermitteln:

Meine Auswertung

Das Ergebnis der drei Panels sieht wie folgt aus:

Diese Daten liefern mit nun Anhaltspunkte für ein Kosten-/Nutzenverhältnis eines Batteriespeichers.  Dabei erhalte ich zuerst die Angabe, dass mein  Batteriespeicher größer ca. 5 kWh groß sein sollte, um den nächtlichen Verbrauch durch den Speicher abdecken zu können. Bei einem Preis von 40  Cent pro kWh würde ich ca. 228 € pro Jahr sparen. Gehe ich davon aus, dass ein Batteriespeicher mind. 2500 Euro kostet würde sich dieser rechnerich nach ca. 11 Jahren amortisieren. Ich gehe bei der Lebensdauer eines Batteriespeichers pessimistisch von 10 Jahren aus, so dass sich dies für den vorliegenden Fall wirtschaftlich nicht lohnen würde, sofern die Strompreise nicht durch die Decke gehen.

Würde ich die Anlage um 1,6 kWp erweitern, dann würde sich ein Batteriespeicher bereits nach 7,5 Jahren lohnen. Den passenden Wechslerichter habe ich hier noch nicht berücksichtigt.

Auch wenn das Modell  Faktoren außen vor lässt, bekommt man ein Gefühlt für die Wirtschaftlichkeit und ich kann die Angebote für diesen Fall jetzt deutlich besser einordnen. Viel Spaß bei den eigenen Berechnungen und Erweiterungen.

Zu Beginn des neuen Jahres ist es spannend, Sensorenwerte des letzten Jahres zu analysieren. Dabei fiel mir ein Fehler bei einigen Zeitreihen auf, in denen zu bestimmten Zeitpunkten Sprünge vorhanden sind. So ein Sprung tritt beispielsweise auf, wenn ich Zählerstände protokolliere, die zwischenzeitlich durch einen Reset oder Stromausfall des Sensors wieder bei Null beginnen. Für weitere Auswertungen führt das beispielsweise bei Differenzfunktionen zu fehlerhaften Berechnungen. Daher möchte ich diese Daten dauerhaft in influxdb korrigieren. Die folgende Vorgehensweise kann unabhängig von meinem Beispiel verwendet werden und zeigt die Korrektur durch einfache Nutzung der Flux-Sprache von InfluxDB 2.x auf.

Lösungsansatz

In meinem Beispiel habe ich Zählerstände eines Balkonkraftwerkes gespeichert. Diese erfasse ich mit einem einem eigenen Sensor (siehe mein Beitrag Leistung eines Balkonkraftwerks mit Homematic IP erfassen).

Durch Konfigurationsänderungen musste ich diesen Zähler mehrmals außer Betrieb nehmen. Dabei wurde der Zähler immer wieder bei Null gestartet und entsprechend protokolliert. Hierdurch werden jetzt verschiedene Auswertungen verfälscht, die diesen Zeitraum betreffen.

Lösen kann ich das, wenn ich den alten Zählerstand als Offset auf die neuen Zählerstande addiere, sowohl für die historischen Daten als auch für die aktuelle Datenerfassung. Damit erzeuge ich wieder eine kontinuierliche Zeitreihe.

(Mittlerweile protokolliere ich übrigens nur noch die Differenzen von Zählerständen, so dass das Thema bei mir gar nicht mehr auftreten kann.)

Zeitpunkt und Offset herausfinden

Im ersten Schritt erstelle ich eine Abfrage im Data Explorer von influxdb 2.0, die die Daten für das betreffende Feld ermittelt. Dabei stelle ich die "AGGREGATE FUNCTION" auf "Custom" und deaktiviere alle Optionen. Die "WINDOW PERIOD" stelle ich ebenfalls auf "Custom",  um die reinen Datenwerte zu erhalten. Das Ergebnis sieht wie folgt aus:

Nun finde ich den Datenwert heraus, bevor der Zähler auf Null umsprint. Dies kann man sehr schöne über den Data-Explorer interaktiv machen, wobei ich die "view raw data" Option hierzu wähle. Der für mich relevante Zeitpunkt ist "2023-04-28T17:41:59.477Z", den ich mir aus der Tabellensicht einfach kopiere. Der letzte Zählerstand zu diesem Zeitpunkt betrug "153.7812" KWh. Diesen Wert bezeichne ich als Offset, den ich für alle neuen Zählerstände addieren muss.

Wichtig: Für ein Funktionieren müssen die UTC-Werte ebenso wie die englischen Zahlen-Werte verwendet werden (mit einem Punkt für die Nachkommastellen).

Relevante Daten ermitteln

Jetzt muss ich alle Datensätze herausfinden, die nach dem betreffenden Zeitpunkt liegen, da ich dort die Werte ändern möchte. Hierzu ziehe ich von dem Datum, an dem der letzte "alte" Zählerstand erfasst wurde das jeweilige Datum jedes Datensatzes ab. Diese Differenz ist größer Null, wenn es sich um Datensätze vor dem betreffenden Zeitpunkt und kleiner Null, wenn es sich um Datensätze dahinter handelt.

Da influxdb keine Berechnungen auf Datumsformaten unterstützt, wandele ich diese Datumsangaben in Integer-Werte um und subtrahiere diese voneinander (im Prinzip ist das die Umwandlung der Datum/Zeitangaben in Nanosekunden im UNIX-Format).

Tipp: In der Flux-Dokumentation wird die Umwandlung in das uint-Format empfohlen. Dieses hat aber den Nachteil, dass es nur positive Werte bei einer Berechnung zulässt. 

Diese Differenz speichere ich zur späteren Kontrolle in einem Feld zu jedem Datensatz ab, indem ich folgende Codezeile einfüge:

Im Data Explorer sieht das Ganze wie folgt aus:

Daten verändern und speichern

Für eine Anpassung habe ich jetzt alles zusammen. Ich addiere anschließend mit einer map()-Funktion für jeden Datensatz, bei dem die Zeitdifferenz kleiner oder gleich Null den Offset zum aktuellen Wert des Datensatzes für den Zähler.

ACHTUNG: Ich kann das zuvor erzeugte Feld "Zeitdifferenz" jetzt nicht nutzen, um die Wert einzusetzen, da die Pipe in Flux, die Werte tatsächlich erst nach einer Ausführung für den jeweiligen Datensatz verfügbar hat. Daher trage ich die Berechnung direkt in die map()-Funktion ein.

Der Code hierzu lautet:

Ein Testlauf sollte jetzt die richtigen neuen Werte ebenfalls als eigenes Feld anzeigen:

Ich empfehle, diese Änderungen so wie beschrieben zu kontrollieren und bei Bedarf Fehler zu korrigieren, damit nicht versehentlich auf den echten Daten falsche Werte geschrieben werden.

Sind alle Daten richtig, kann ich jetzt den Code so ändern, dass die Daten direkt in das _value-Feld der Datensätze geschrieben werden. Dazu ergänze ich ebenfalls noch die to()-Funktion, die die Daten final schreibt.

Der fertige Code für die Änderung sieht wie folgt aus:

Die Daten werden nun endgültig geschrieben.

Sofern es weitere Stellen gibt, die korrigiert werden müssen, kann man diese Korrekturen anschließend mit der gleichen Methode anpassen. Dabei muss mit jeder Datenkorrektur auch der Offset durch den neuen Offset erhöht werden.

Und wenn man weiter (wie in meinem Beispiel) Zählerstände in influxdb protokolliert, muss vor dem Speichern auf den jeweils aktuellen Zählerstand der letzte Offset addiert werden. Dabei empfehle ich, das Speichern neuer Zählerstände solange auszusetzen, bis die Datenkorrekturen abgeschlossen sind.

Ich nutze zum Speichern von Daten die InfluxDB ab Version 2.x. Immer wieder passiert es, dass von einem der Sensoren ein falscher Wert oder im schlimmsten Fall ein ganzer Zeitraum mit falschen Werten geliefert und gespeichert wird. Um bei späteren Auswertungen z.B. mit Grafana keine komischen Grafiken zu erhalten möchte ich diese Werte korrigieren. Im folgenden Beitrag zeige ich, wie man das machen kann.

Fehlerhafte Daten identifizieren

Im ersten Schritt muss man herausfinden, wo die fehlerhaften Daten sind. Ich verwende hierzu die InfluxDB UI. Alternativ kann man das auch über Grafana machen.

Dazu wähle ich im Data-Explorer für mein Bucket als erstes das Measurement und das Feld im Query Builder aus. Wichtig ist, dass man anschließend in den Script Editor wechselt und dort die Aggregate-Zeile löscht. Denn sonst erhält man aggregierte Werte über den voreingestellten Zeitraum.

In der anschließenden Grafik sieht man sehr deutlich Ausreißer, die man nun durch Klicken, Festhalten und Ziehen der linken Maustaste im Grafikfenster  näher eingrenzen kann.

Durch Klicken auf den Zeitbereich und dort auf "Custom Time Range" kann man den Zeitraum dann exakt einstellen, der jetzt von Interesse ist.

Alternativ kann man auch einfach eine zusätzliche Filterfunktion angeben. In meinem Beispiel habe ich nach Werten gesucht die kleiner Null sind.

Das Script sieht dann beispielsweise wie folgt aus:

Nun schalte ich um auf die RAW-Data Ansicht und erhalte den Datenpunkt mit allen Details, der fehlerhaft ist.

Wert ändern

Wenn ich den Wert  nur ändern möchte, dann nutze ich die Möglichkeit der InfluxDB-UI, Werte einfach überschreiben zu können.

Hierzu benötigt man

• den Namen des Measurements
• den Namen des Fields sowie den neuen Wert
• den exakten Timestamp im UNIX-Form mit Millisekunden (ich speichere alle Werte immer nur maximal mit Millisekunden ab).

All diese Daten sind verfügbar, einzig die Zeitangabe für den fehlerhaften Wert muss umgerechnet werden. Dazu verwendet man z.B, die Webseite https://it-tools.tech/date-converter. Mein falsche Zählerstand wurde am "2023-08-03T15:45:06.018Z" (_Time-Spalte) gespeichert. Umgerechnet ins UNIX-Format mit Millisekunden  erhalte ich die Zahl "1691077506018" (bitte Timestamp Feld des Konverters mit den Millisekunden verwenden und nicht das Unix-Feld).

Nun geht man in der InfluxDB-UI auf den Menüpunkt "Load Data / Sources" und wählt dort "Line Protocol" aus. Hier wählt man den Bucket, in dem sich das Measurement befindet, anschließend die Option "Enter manually" und stellt die Zeitangabe auf "precision milliseconds" (wer hier andere Genauigkeiten verwendet, stellt das entsprechend anders ein und rehnet dann auch die Zeit mit anderen Genauigkeiten um).

Jetzt kann ich den folgenden Befehl eingeben, um die falsche Daten zu korrigieren und drücke anschließend "Write Data":

"Erzeugung.HDach.Strom.Zaehlerstand value=875.5 1691077506018"

Es sollte im Anschluss eine grüne Erfolgsmeldung erscheinen und der Wert in der InfluxDB für diesen Zeitstempel wurde den Wert 875.5 geändert

Wert löschen

Alternativ kann ich den Wert auch löschen. Dies geht beispielsweise mit dem curl-Befehl.  Sofern man Windows nutzt, kann man das curl-Kommandozeilen-Tool über den Link https://curl.se/windows/  installieren. Der Befehl, um einenDatensatz mittels curl-Befehl zu löschen sieht wie folgt aus:

Alternativ kann man auch über die influxdb-Konsole einen Löschbefehl ausführen. Ich rufe z.B. in dem Docker Container, in dem influxdb läuft eine bash-Console auf und gebe einfach den folgenden Befehl ein:

influx delete --token --org --bucket nodered --start 2023-08-03T15:45:06.018Z --stop 2023-08-03T15:45:06.018Z --predicate '_measurement="Erzeugung.HDach.Strom.Zaehlerstand"'

In beiden Fällen würde der Eintrag aus der Datenbank gelöscht.

Ergebnis

Ich habe mittlerweile ganze Zeitreihen angepasst, in dem ich über Excel ganz viele Befehlszeilen generiert, in den Line-Protocol-Konsole geladen und anschließend ausgeführt habe.  Die Vorgehensweise ist immer die gleiche, egal ob man einen oder mehrere Werte anpasst.

Im zweiten Teil geht es nun um die Installation von Node-Red, Grafana und die Visualisierung erster Daten von einem MQTT-Server.

Node-Red Container installieren

Image herunterladen

Wie im ersten Teil beschrieben wird als erstes das "nodered/node-red"- Paket heruntergeladen.

Unter dem Verzeichnis Docker reicht es diesmal aus, das Verzeichnis "nodered" und "nodered/data" anzulegen. Ich empfehle hierzu, den DSM 7.x Filemanager zu nutzen.

Auf diesem Verzeichnis muss eine zusätzliche Berechtigung für das Schreiben und Lesen  eingerichtet werden. Dies liegt daran, dass hier z.B. weitere Nodes installiert und gespeichert werden müssen. Dies passiert normalerweise über den in Node-Red angelegt Nutzer (mit der UID 1000). Dieser ist aber im Synology NAS nicht bekannt. Daher wird auf dem NAS am einfachsten für "Everyone" ein Lesen und Schreiben ermöglicht.

Dazu geht man über Filemanager  auf das "/docker/nodered"-Verzeichnis, drückt die rechte Maustaste und wählt das Menü "Einstellungen" aus. Über den Reiter "Berechtigungen" wählt man die Gruppe "Everyone" und gibt dieser diesen die vollständigen Rechte auf das "/data"-Verzeichnis.

Nun müssen für den Container nur noch folgende Daten angegeben werden:

• Beliebiger Name für den Container
• Netzwerk: bridge
• Automatischen Neustart aktivieren
• Lokaler Port 1882 und Container Port 1880, TCP
• Lokaler Port 2062 und Container Port 2062, TCP (nur notwendig, wenn man eine CCU ansprechen möchte)
• Lokaler Port 2063 und Container Port 2063, TCP (nur notwendig, wenn man eine CCU ansprechen möchte)

Die Pfade werden wie folgt gesetzt:

In den Umgebungsvariabeln habe ich die Timezone (Parameter TZ) manuell auf Europe/Berlin als Umgebungsvariable gesetzt, da ich festgestellt habe, dass die TimeZone nicht von Synology DSM 7.x Betriebssystem übernommen wurde und stattdessen eine UTC Zeit eingestellt war, die 2 Stunden zurückliegt.

Nach dem Starten des Containers kann Node-Red über die IP-Adresse der Synology NAS gefolgt von der Portangabe aufgerufen werden (z.B. 192.168.178.135:1882).

Ich empfehle, noch die Bibliotheken (Nodes) zu installieren, mit denen man InfluxDB und eine CCU ansprechen kann (für andere Systeme gibt es auch andere Nodes, MQTT ist hingegen schon im Standard vorhanden). Dazu geht man oben rechts in Node-Red auf den Menüpunkt "Palette verwalten". Unter dem Reiter "Installation" kann man nun die folgenden Zusatzpakete installieren:

• node-red-contrib-ccu
• node-red-contrib-influxdb

Grafana installieren

Auch Grafana lässt sich wie Node-Red und InfluxDB einfach als Docker Container erstellen. Wie in den vorigen Kapiteln beschrieben braucht man hierzu nur das Abbild "grafana/grafana" und die "latest" Version herunterladen.

Für Grafana wird ebenfalls ein Verzeichnis unterhalb von Docker angelegt: "/docker/grafana".

Wie für die Node-Red Installation beschrieben, wird auch hierauf für "Everyone" die volle Berechtigung erteilt.

Für die Installation und das Starten des Containers sollten folgende Parameter angegeben werden:

• Beliebiger Name für den Container
• Netzwerk: bridge
• Automatischen Neustart aktivieren
• Lokaler Port 3000 und Container Port 3000, TCP

Die Pfade werden wie folgt angegeben:

In den Umgebungsvariabeln habe ich ebenfalls die Timezone (Parameter TZ) manuell auf Europe/Berlin als Umgebungsvariable gesetzt, da ich festgestellt habe, dass die TimeZone nicht von Synology DSM 7.x Betriebssystem übernommen wurde und stattdessen eine UTC Zeit eingestellt war, die 2 Stunden zurückliegt.

Nach dem Starten des Containers kann Grafana über die IP-Adresse der Synology NAS gefolgt vom Grafana Port aufgerufen (z.B. 1192.168.178.135:3000) und ein Nutzer erstellt werden.

Authentication Key in InfluxDB erzeugen

Um mit InfluxDB kommunizieren zu können ist neben der Organization und dem Bucket auch ein Token erforderlich.

Auf der Synology DSM 7.x Version geht man mit einem Doppeklick auf den  laufenden InfluxDB Container. Neben den Einstellungen zu diesem Container findet man am oberen Bildschirmrand den Menüpunkt "Terminal".

Hier klickt man oben links auf den Menüpunt "Erstellen". Anschließend erscheint in der Liste der Terminals auf der linken Seite der Eintrag "bash". Auf diesen Eintrag wird geklickt und auf der rechten Seite öfnet sich nun das bash-Terminal mit einer Eingabezeile.

Hier wird nun folgender Befehl eingegeben werden (USERNAME bitte durch denLoginnamen ersetzen, der bei der Erstellung des Containers angegeben wurde):

influx auth list -user USERNAME -hide-headers | cut -f 3

TIPP: Im ersten Moment sieht es so aus, als könnte man mit STRG-V keinen Text in das Fenster kopieren. Wenn man aber vorher STRG-A drückt und dann STR-V wird der Text aus der Zwischenablage auch in das bash-Terminal eingefügt.

Anschließend erscheint ein ganz langer Code, der als Token für den Zugriff auf InfluxDB aus Node-Red und Grafana verwendet wird.

MQTT-Nachrichten mit Node-Red auslesen und in influxDB speichern

Unter Node-Red zieht man einen "MQTT in"-Node auf das Arbeitsblatt und klickt doppelt darauf.

Im anschließenden Fenster klickt man auf das Stiftsymbol neben "SERVER" und legt als erstes eine MQTT-Serververbindung an (heißt in Node-Red auch Konfiguration-Node, den man für alle anderen MQTT-Abrufe verwenden kann).

Hier habe ich nun folgende Daten eingestellt:

• Name: "Beliebiger Name für den MQTT Konfiguration-Node"
• Server: "Meine MQTT-Server IP-Adresse"
• Port: "Meinen MQTT-Server Port"
• Protokoll: "MQTT V3.1 legacy"

Sobald die Daten für den Server erfasst wurden, muss nur noch der "mqtt in"-Node richtig konfiguriert werden. Hier habe ich den Default Parameter bei Ausgang auf "Ein analysiertes (parsed) JSON Objekt" geändert.

Nun wird noch das richtige Topic angegeben, unter dem die Daten auf dem MQTT-Server gespeichert werden und dann kann man sich über einen Debug-Node das payload-Objekt mit den Daten zur Prüfung ausgeben lassen.

Nun möchte ich aus dem erhaltenen payload-Objekt einen Sensorwert (in meinem Beispiel die verbrauchte Stromleistung) in InfluxDB speichern. Da ich einen Objekt mit vielen Werte vom MQTT-Server erhalte, muss ich vor der Weitergabe an InfluxDB den Wert herausfiltern, den ich haben möchte. Dazu verwende ich einen "function"-Node in dem ich per Script nur den Wert, den ich brauche im payload-Objekt speichere (Man findet die Info, wie der Wert genau heißt und wie die Hierarchie ist, im MQTT-Objekt, welches man sich über den Debug-Node ausgeben kann).

Zur Speicherung dieses Werte ziehe ich nun einen "influxDB out"-Node auf das Arbeitsblatt und verbinde dieses mit dem "function"- Node. Nach einem Doppelklick auf den "influxDB out"-Node muss wie bei der Verbindung zu einem MQTT-Server als erstes eine Server-Verbindung zum InfluxDB-Server angelegt werden. Dazu klickt man hinter der SERVER-Zeile auf das Stiftsymbol.

Hier werden nun folgende Parameter angeben:

• Name: "Beliebiger Name für den InfluxDB Konfiguration-Node"
• InfluxDB-Version: 2.0 (hiermit ermögliche ich das Speichern von Daten über Abonnements und Bucket).
• URL: "Meine InfluxDB-Server IP-Adresse (entspricht der IP-Adresse des Docker Containers)"
• Token "Das im vorigen Kapitel erzeugte InfluxDB Token"

Nun brauche ich nur noch zu spezifizieren, unter welchem Namen die Daten in der InfluxDB gespeichert werden sollen. Folgende Parameter müssen angegeben werden:

• bucket: "Den Bucketnamen, der bei der Erstellung des InfluxDB-Containers vergeben wurde"
• Organization: "Die Organization, die bei der Erstellung des InfluxDB-Containers vergeben wurde"
• Measurement: "Den Feldnamen, unter dem in InfluxDB die Werte gespeichert werden sollen".

Das wars. Nun sollten die Werte kontinuierlich in der InfluxDB gespeichert werden.

Daten mit Grafana visualisieren

Verbindung zu InfluxDB erstellen

Nach dem Einloggen in Grafana wird als erstes eine Verbindung zu InfluxDB erstellt. Über den Menüpunkt "Configuration" wird über das Klicken auf "add data source" die dazu notwendige Konfigurationsseite geöffnet.

Wichtig ist, dass im anschließenden Fenster als Query Language "Flux" angegeben, wird. Nur dann können Daten über Organization und Bucket abgerufen werden. Flux funktioniert in Grafana mittlerweile sehr sicher und hat bei der Verarbeitung von Daten durchaus Vorteile. Zusätzlich werden folgende Parameter angebeben:

• Name: "Beliebiger Name für die Data Source"
• URL: "Meine InfluxDB-Server IP-Adresse (hier die Adresse des Docker Containers)"
• Organization: "Der bei der Einrichtung von InfluxDB angegebene Organization Name"
• Default Bucket: "Der bei der Einrichtung von InfluxDB angegebene Bucket Name"
• Token: "Das im obigen Kapitel für den Zugriff auf InfluxDB erzeugte Token"

Nach Drücken auf "Save & test" sollte Grafana das Funktionieren der Verbindung bestätigen.

Dashboard mit Auswertung erstellen

Nun kann ein Dashboard angelegt und dort ein Panel erzeugt werden. Hier muss nun der Flux-Code angegeben werden, um die Daten abzufragen.

Da Grafana noch keinen eigenen Query Builder für Flux mitbringt, empfehle ich folgende Lösung. Man loggt sich in die InfluxDB Oberfläche ein. Hier kann nun über den Menüpunkt "Data Explorer" sehr einfach mit dem Query-Builder von InfluxDB eine Abfrage von Daten (auch sehr komplexe Konstrukte) erzeugt werden. Nach Auswahl der Datenfelder, Filer und Funktioen generiert der Query-Builder bereits eine erste Grafik. Durch Klicken auf "Script Editor" kan man den Code für diese Abfrage einfach kopieren, in Grafana einfügen und dort weiterbearbeiten.

Ich habe nach kurzer Zeit festgestellt, wie einfach aber mächtig dieser Query Builder ist und wie Flux insgesamt funktioniert. Da Grafana deutlich besser visualisiert und umfangreiche Optionen für Anpassungen der Auswertungen besitzt ist, ist dies die einfachste Möglichkeit, schnell voran zu kommen.

Links

Wer eine CCU mit Node-Red ansprechen möchte findet im folgenden Link erste Tipps:

Für die Installation und Nutzung von Grafana können die folgenden Links hilfreich sein:

https://mariushosting.com/how-to-install-grafana-on-your-synology-nas/

Bei der Installation von Node-Red können folgende Links unterstützen:

Und für die Nutzung des Query Builders von InfluxDB ist folgender Link hilfreich:

Wer Smarthome-Komponenten im Einsatz hat weiß, dass diese unglaublich viele Daten liefern können. Diese Daten sind auch im Heimbereich Gold Wert und sollten systematisch protokolliert werden. Aus den Daten ist dann z.B. herleitbar, wie sich z.B. Energiekosten wie Strom, Gas, Wasser senken lassen. Dazu müssen diese Daten möglichst aus verschiedenen Systemen gesammelt und so aufbereitet werden, dass man hieraus das Verhalten eines Systems sowie Verbesserungen ableiten kann.

Aufgabenstellung

Ich möchte ein möglichst einfaches System aus bewährten Software-Komponenten aufbauen, mit dem ich beliebige Inputdaten in eine Datenbank speichern und möglichst vielfältig auswerten kann. Da ich viele Homematic-IP Produkte einsetze und auch verschiedene Sensoren über MQTT kommunizieren lasse, soll das System mindestens diese Inputdaten verarbeiten können. Idealerweise soll der Installations- und Betriebsaufwand möglichst einfach und stabil sein.

Lösungsansatz

Für das Sammeln und Aufbereiten der Daten von verschiedenen Smarthome-Komponenten habe ich mich für Node-Red entschieden. Im Prinzip ist Node-Red eine visuelle Programmierumgebung, die die Kommunikation zwischen vielen IOT Devices ermöglicht. Daneben gibt es auch eine einfache grafische Oberfläche um die Bedienung und Visualisierung von IoT-Devices zu ermöglichen. Für die CCU gibt es bereits ein fertiges Paket Redmatic, mit dem alle Komponenten auf einer CCU eingerichtet werden. Ich möchte allerdings auf der CCU keine zusätzliche Last haben, so dass ich die normale Node-Red Version woanders installiere und dort die notwendigen Pakete ergänzen möchte.

Da relative viele zeitabhängige Daten entstehen (sogenannte Zeitreihen) habe ich mich für ein System entschieden, welches hier eine platzsparende Speicherung sowie einen schnellen Zugriff ermöglicht, nämlich InfluxDB. Dabei wähle ich die 2.x Version von InfluxDB und möchte die Scriptsprache FLUX benutzen (ihr werdet sehen, dass dies einfach ist). Mittlerweile bietet InfluxDB auch eine super Weboberfläche mit Dashboards, Data Exxplorer und Tasks an. Für einfache Aufgaben wird hier schon viel geboten.

Als Visualisierungstool gibt es für mich aber keine Alternative zu Grafana. Mit Grafana kann man beliebige System und Datenbanken anbinden und die grafischen Auswertungsmöglichkeiten lassen kaum Wünsche übrig. Dabei ist das Ganze sehr einfach über ein Webfrontend bedienbar.

Alle Systeme sind frei verfügbar und auf verschiedenen Zielsysteme z.B. auf einem Raspberry PI installierbar. Ich habe mich entschieden, die Systeme als Docker-Versionen jeweils in einer virtuellen Umgebung laufen zu lassen. Dazu nutze ich ein Synology NAS mit einer DSM 7.x Version. Diese Container kann ich recht einfach webbasiert einrichten und immer wieder auf einen neuen Stand bringen, ohne jeweils Daten hin- und her konvertieren zu müssen. Ich setze voraus, dass Docker bereits auf einer Synology DSM installiert ist.

Ich nehme vorweg, dass die Installation aller Pakete sehr einfach war und sich erste Erfolge schnell ergeben haben.

Folgende Links haben mir ebenfalls weitergeholfen:

https://docs.influxdata.com/influxdb/v1.7/introduction/installation/

InfluxDB Container installieren

Image herunterladen

Im folgenden Kapitel beschreibe ich die Konfiguration eines Docker Containers über die Menüführung etwas ausführlicher. Für Node-Red und Grafana ist die Vorgehensweise die gleiche, nur das andere Daten verwendet werden, so dass ich diese Installationen im nächsten Beitrag etwas kompakter beschreiben werde. .

Unter Docker auf dem Synology DSM wir als erstes über den Menüpunkt "Registrierung" das Paket influxdb für die Installation gesucht.

Um zu prüfen, ob es sich um das offiziele Docker-Paket von influxdata handelt kann man den Link hinter dem Namen anklicken. Dort sind dann auch sämtliche Installationsinformationen für sämtliche Zielsysteme vorhanden (siehe Link). Bei der Version empfehle ich immer "Latest" auszuwählen, so dass man das offiziell aktuellste Paket erhält.

Container Parameter einstellen

Nach dem Herunterladen gilt es, den Container mit den richtigen Parametern zu versehen.

Hierzu geht man auf den Menüpunkt "Image", markiert das neue Image und drückt "Starten".

Im folgenden Fenster empfehle ich als Netzwerk "bridge" zu wählen, da man so die Ports nach außen und im Docker Image frei wählen kann.

Im folgenden Fenster vergibt man einen freien Namen und aktiviert die Option "Automatischen Neustart aktivieren", da somit bei einem ungeplanten Herunterfahren der Conmtainer automatisch neu gestartet wird.

Unter "Erweiterte Einstellungen" werden nun die für InfluxDB notwendigen Daten eingegeben. Diese sind:

Ich habe hier die Timezone (Parameter TZ) manuell auf Europe/Berlin gesetzt, da ich festgestellt habe, dass die TimeZone nicht von Synology DSM 7.x Betriebssystem übernommen wurde und stattdessen eine UTC Zeit eingestellt war, die 2 Stunden zurückliegt.

Merkt Euch Username und Passwort, da diese später auch zum Anmelden erforderlich sind.

Nach dem Speichern drückt Ihr auf "Weiter".  Nun muss noch der Port 8086 für den Zugriff auf InfluxDB angegeben werden. Dies erfolgt auf beiden Seiten in der Tabelle  (ihr könnt auch eine eigene Portnummer setzen, wenn dieser belegt sein sollte). Wichtig ist, dass auf der linken Seitene nicht mehr "automatisch" steht, da  sonst influxdb von außen nicht mehr erreicht werden kann.

Nach dem Klicken auf "Weiter" werden nun die Mountpfade eingegeben. Wählt hier nun "Ordner hinzufügen" aus. Legt anschließend über den Button "Ordner erstellen" den Ordner "influxdb" unterhalb des Ordners "docker" an. Unterhalb von Docker legt Ihr ebenfalls über "Ordner hinzufügen" die beiden Ordner "config" und "data" an.

Wählt nun einzeln die beiden Ordner über "Ordner hinzufügen" aus und ordnet sie den folgenden Mount-Pfaden zu:

Nach dem Drücken des Button "Weiter" werden alle Daten für den Container nochmal zusammengefasst. Durch Betätigen von "Fertig" wird der Container nun gestartet.

Sollte irgendetwas nicht funktionieren (weil man etwas vergessen oder falsch geschrieben hat) ist das kein Problem. Geht auf den Menüpunkt "Container", wählt den gerade erstellten Container aus und drückt im Menüpunkt "Aktion" auf "Stop". Der Container wird nun gestoppt und Ihr könnt über  den Menüpunkt "Bearbeiten" erneut die Einstellungen für den Container aufrufen.

Unter dem Reiter Port-Einstellungen findet Ihr die Angaben zu den Ports, unter Volume-Einstellungen Angaben zu den Mount-Pfaden und unter dem Button "Erweiterte Einstellungen" die Angaben zu den Umgebungsvariabeln. Speichert anschließend die Änderungen und startet über "Aktion" und "Start" den Container neu.

InfluxDB aufrufen

Über die IP-Adresse des NAS (Docker Host) gefolgt von dem Port sollte nun InfluxDB erreichbar sein (z.B. 192.168.178.135:8086). Nach Eingabe des Benuternamens und des Passworts, die oben bei den Umgebungsvariabeln angelegt wurden kommt man auf die schicke und nützliche neue InfluxDB Oberfläche.

Im nächsten Teil werden Node-Red und Grafana installiert sowie Daten gesammelt und ausgewertet.