Nach der Einführung der neuen HMIP-Zentrale HCU (Home Control Unit) hat eQ-3 eine API veröffentlicht, mit der man eigene Plugins erstellen und auf die HMIP-Daten zugreifen kann. Im Herbst 2025 wurde angekündigt, dass die auch von mir genutzte CCU3 vom eQ-3 nicht weiterentwickelt, sondern in dem freien Modell OpenCCU (ehemals Raspberrymatic) durch die Community weitergepflegt werden soll.

Ich habe auf der CCU3 viel programmiert und mit Node-RED auf die CCU3-Geräte zugegriffen. Jetzt will ich prüfen, wie gut man die HCU in Node-RED einbinden kann, um langfristig von der CCU auf die HCU zu wechseln.

Im ersten Schritt möchte ich eine Verbindung zwischen Node-RED und der HCU aufbauen und erste Daten von HMIP-Geräten empfangen. Ich nehme vorweg, das Ganze funktioniert einfacher als erwartet. In den folgenden Kapiteln beschreibe ich dazu detailliert die Vorgehensweise. Das wesenliche Dokument für alle folgenden Schritte ist dabei die Homematic IP Connect API Dokumentation.

HCU Entwicklermodus freischalten

Damit die HCU API-Zugriffe akzeptiert, muss der Entwickler-Modus aktiviert werden. In diesem Modus kann man eigene Plugins direkt auf der HCU laden. Oder man kann mit Plugins auf anderen Systemen (z. B. Node-RED) über eine Websocket-Verbindung kommunizieren.

Die Vorgehensweise zur Freischaltung ist gut in der API-Dokumentation beschrieben, so dass ich nur auf folgendes hinweise:

1. Aktiviere den Entwicklermodus und gebe sofort die Websockets frei (Häkchen setzen)
2. Warte mit der Erstellung des Aktivierungsschlüssels bis zum nächsten Schritt!

Authentication Token vereinbaren

Jedes Plugin braucht für die Kommunikation eine eindeutige ID.  eQ-3 empfiehlt zur Namensfindung die "Reverse Domain Name Notation". Ich habe diesen Namen für die folgenden Tests benutzt:

de.spike.grass.plugin.example1

Damit die Kommunikation zwischen der HCU und einem anderen Gerät sicher, aber einfach ist, brauche ich außerdem ein Token. Dieser Authentication Token ist wie ein Passwort. Zur Erstellung des Tokens muss man mit der HCU über API-Requests kommunizieren.

Ich empfehle das Tool Postman zu verwenden, da es einfach zu bedienen ist.

Ich verweise hier auch auf die Anleitung in Kapitel 2.4 (Step 2) und ergänze noch ein paar Hinweise::

• Wähle in Postman die Methode "POST" aus. Trage dahinter als Adresse https://hcu1-XXXX.local:6969/hmip/auth/requestConnectApiAuthToken ein (Setze anstelle von hcu1-XXXX den lokalen Netzwerknamen ein)
• Ergänze unter dem Tab "Headers" das Feld "VERSION" mit dem Wert "12"
• Gehe nun zuerst zurück in den Entwicklermodus der HCU und generiere einen Aktivierungsschlüssel (dieser ist nur kurzzeitig gültig)
• Kopiere in den Tab "body" den body-example Code aus Kapitel 2.4 Step 2
• Tausche den Aktivierungsschlüssel gegen den soeben generierten Schlüssel aus
• Tausche die plugin_id gegen die von dir gewählte ID aus (siehe oben)

Drücke auf Send und man sollte ein solches Feedback erhalten (Wert für spätere Verwendung speichern):

Nun muss der Erhalt dieses Schlüssels noch bestätigt werden. Gehe dazu wie folgt in Postman vor:

• Drücke oben in der Tabzeile auf "New Request"
• Ergänze unter dem Tab "Headers" das Feld "VERSION" mit dem Wert "12"
• Wähle in Postman die Methode "POST" aus. Trage dahinter als Adresse https://hcu1-XXXX.local:6969/hmip/auth/confirmConnectApiAuthToken (Setze anstelle von hcu1-XXXX den lokalen Netzwerknamen ein)
• Kopiere in den Tab "body" den body-example Code aus Kapitel 2.4 Step 3
• Tausche den Aktivierungsschlüssel gegen den eben generierten aus
• Tausche den authToken gegen den im vorigen Schritt erhaltenen authToken aus.

Drücke auf Send und du solltest eine client_id in der folgenden Form erhalten (Wert für spätere Verwendung speichern):

Websocket Verbindung testen

Nun kann getestet werden, ob eine Websocket-Verbindung zur HCU mit den gerade erzeugten Daten aufgebaut werden kann. Ich empfehle hierzu auch wieder das Tool Postman zu verwenden.

Hier gibt es allerdings mit der freien und unregistrierten Version eine Einschränkung: In dieser Version kann man keine Self-Signed-Socket Verbindungen aufbauen, die wir aber für die Kommunikation mit der HCU benötigen.

Man löst das Ganze, indem man sich einen (kostenlosen) Postman-Account erstellt und sich dann mit dem Account in der App anmeldet. Anschließend ist die Kommunikation mit den Self- Signed- Zertifikaten möglich.

Folgende Schritte sind anschließend in Postman durchzuführen:

• In der Adressleiste wird folgende Adresse eingetragen: wss://hcu1-XXXX.local:9001 (Setze anstelle von hcu1-XXXX den lokalen Netzwerknamen ein)
• Auf das Plus-Zeichen links oben im Workspace drücken und "Websocket" auswählen.
• Unter Headers wird ein neuer Key "authtoken" mit dem eben generierten Wert eingetragen.
• Unter Headers wird ein weiterer neuer Key "plugin-id" mit der generierten Plugin-ID eingetragen.

Nach Betätigen von Connect sollte die Meldung "connected to .local:9001" erscheinen.

Und in der HCU im Plugins Menü sollte die Verbindung ebenfalls auftauchen!

Mit Node-RED HCU-Daten abfragen

Jetzt kann eine Websocket Verbindung zur HCU aus Node-RED aufgebaut werden. Die Sockets-Nodes in Node-RED unterstützen allerdings keine Self-Signed Zertifikate. Stattdessen verwende ich die Palette node-red-contrib-dynamic-websocket, die ich in Node-RED installiert habe. Darin befindet sich ein Websocket-Node, der viel mehr Möglichkeiten als die Standard-Nodes bietet.

In Node-RED wird nun der Dynamic-Websocket-Node eingefügt und in den Eigenschaften folgende Daten eingetragen:

• Default-Url "wss://"
• "Allow Self Signed Certificates"-Häkchen setzen

Unter Custom Headers wird anschließend folgender JSON-Eintrag ergänzt:

Im Code wird die eigene Plugin-ID sowie das eigene Authentication Token eingetragen. Mit der Zeile "hmip-system-events":"true" wird die HCU so eingestellt, dass alle Änderungen an HMIP-Zuständen (Basisstation, Geräte, Gruppen, etc.=) sofort an Node-Red übermittelt werden (siehe auch API-Dokumentation).

Alle Websocket-Nachrichten können durch einen Debug-Node am ersten Ausgang des Websocket-Nodes im Debug-Fenster ausgegeben werden. Nach dem deployen des Flows sollte das Ergebnis wie folgt aussehen. In den Objekten sind bereits alle Informationen zu den HMIP-Geräte enthalten.

Weitere Funktionen ergänzen

Ich erweitere den Flow jetzt noch um Funktionen, die bei den weiteren Tests hilfreich sind. Hierzu gehört auch, dass die HCU zwischenzeitlich abfragt, ob mein Plugin einsatzbnereit ist. Hierzu sendet die HCU an Node-Red unter payload.type einen "PLUGIN_STATE_REQUEST". Sobald ich diesen erhalte schicke ich eine PLUGIN_STATE_RESPOND Message zurück. Die Nodes, die ich ergänze sind in folgender Tabelle aufgeführt.

Der Flow sieht anschließend wie folgt aus und bietet jetzt eine solide Basis für die Kommunikation mit der HCU.

Im nächsten Beitrag werde ich mir die Nachrichtenformate der HCU näher anschauen und entscheiden, wie ich diese am besten auswerte. Anregungen und Ergänzungen sind herzlich willkommen.

Viele Wechselrichter oder Messsteckdosen liefern Momentanwerte der Leistung, beispielsweise 350 W. Ich benötige jedoch häufig nur die kumulierten Werte in Form von Zählerständen, d. h. die kumulierte Energie über einen bestimmten Zeitraum in Kilowattstunden.

Dazu braucht man im Prinzip nur die Leistungswerte mit einem Zeitstempel.

Im folgenden Artikel beschreibe ich, wie ich das mit Node-Red gelöst habe. Das Prinzip ist auf viele andere Geräte übertragbar, die keine Zählerstände liefern.

Grundprinzip

Ein Zendure-Hyper-2000-Wechselrichter liefert über die Cloud nur die erzeugte Leistung per MQTT zu einem bestimmten Zeitpunkt, nicht aber einen Zählerstand, anhand dessen ich die erzeugte Energie beispielsweise an einem Tag ablesen könnte.

Dabei lassen sich Energie und Zählerstand recht einfach aus der Leistung berechnen. Die dazu benötigten Werte lassen sich physikalisch wie folgt beschreiben (vereinfacht):

• Leistung (Watt) = Spannung * Stromstärke (z.B. in Watt)
• Energie (kWh) = Leistung * Zeit in einem Zeitintervall (z.B. in Kilowattstunden)
• Zählerstand =  Summe der Energiewerte in Zeitintervallen (z.B. in Kilowattstunden)

Eine Lampe, die eine Stunde lang eingeschaltet ist und 500 Watt benötigt, verbraucht somit eine Energie von 0,5 kWh. Wäre die Lampe dimmbar und würde sie nach einer halben Stunde auf 250 Watt gedimmt werden, würde sie in der ersten halben Stunde 0,25 kWh und in der zweiten halben Stunde 0,125 kWh, also insgesamt 0,375 kWh, verbrauchen.

Ein Wechselrichter produziert in relativ kurzen Zeitabständen unterschiedliche Leistungen, sodass ich die Energie für viele kleine Zeitintervalle berechnen und aufsummieren muss. Mathematisch entspricht dies einer Integralfunktion über ein Rechteck. Da jeder übermittelte Leistungswert einen Zeitstempel besitzt, können die erforderlichen Daten schnell ermittelt werden.

Voraussetzungen

Ich realisiere die Berechnung in Node-Red und speichere die Zählerstände in eine InfluxDB-Datenbank. Grundsätzlich speichere ich nur die resultierenden Zählerstände in der Datenbank ab, indem ich die Energie des letzten Zeitraums hinzufüge.

Im Programm benutze ich einige Flow-Variablen, das heißt, diese speichern Werte zwischen, die beim nächsten Programmdurchlauf verwendet werden, wenn ein neuer Leistungswert geliefert wird. Diese Variablen sind:

Flowbeschreibung

Die Verarbeitung und Speicherung der Daten erfolgt durch einen Flow, dessen Struktur wie folgt ist:

Von meinem Wechselrichter erhalte ich per MQTT-Abfrage eine Vielzahl von Werten als Input. Aus diesen extrahiere ich im nächsten Function-Node zuerst die aktuelle Leistung.

In der Funktion „Energie berechnen” ermittele ich die Energie im letzten Zeitintervall. Mit dem anschließenden Switch-Node teste ich, ob die Variable „f_Zaehlerstand” vorhanden ist (Bedingung für Ausgang 1: „ist nicht Null”, für Ausgang 2: „ansonsten”). Warum mache ich das?

Für die Zählerstandsermittlung hole ich mir initial immer den Zählerstand aus der Datenbank und rechne dann mit Flow-Variablen in Node-Red weiter. Dadurch spare ich mir bei jedem Durchlauf die Datenbankabfrage des letzten Zählerstandes, die nur Zeit kostet. Allerdings muss ich am Anfang (nach einem Neustart von Node-Red) den Zählerstand einmal in die Variable laden. Dies stelle ich mit dem Switch-Node fest, der einfach prüft, ob die Variable „f_Zaehlerstand” einen Wert größer 0 liefert. Falls nicht, führe ich eine Abfrage der InfluxDB-Datenbank mit dem „influxdb in“-Node „Letzten Zählerstand auslesen“ und dem Function Node „Letzten Zählerstand zwischenspeichern“ aus. In diesem speichere ich den letzten Zählerstand aus der Datenbankabfrage in der Variablen „f_Zaehlerstand”.

Liefert der Switch-Node das Ergebnis „>0”, wurde eine korrekte Energieberechnung durchgeführt. Im nächsten Funktionsknoten „Zähler hochsetzen” addiere ich die beiden Variablen „f_letzterZaehlerstand” und „f_energiekWh” und erhalte somit den neuen Zählerstand, den ich im anschließenden „InfluxDB Out”-Knoten in die Datenbank schreibe.

Berechnung

Im Folgenden ist die Vorgehensweise bei der Berechnung in dem Function-Node "Energie berechnen" kurz beschrieben:

1. Zunächst wird die Leistung ausgelesen und ein Zeitstempel erzeugt.
2. Anschließend werden die Flow-Variablen ausgelesen und zwischengespeichert.
3. Nun erhalten die Flow-Variablen die aktuelle Leistung und den aktuellen Zeitstempel.
4. Danach wird geprüft, ob es sich um die erste Messung handelt. Dies kann mittler der Variablen f_Zaehlerstand erfolgen, die bei der ersten Messung noch nicht ermittelt ist (z. B. nach einem Neustart von Node-Red). Falls ja, wird die Funktion abgebrochen (die
5. Erläuterung erfolgt weiter hinten).
6. Anschließend wird die Zeitdifferenz zwischen dem letzten und dem aktuellen Zeitwert berechnet (auch in Stunden).
7. Schließlich kann die Energie in Wattstunden berechnet werden.
8. Das Ergebnis wird von der Funktion zurückgeliefert.

Der gesamte Ablauf kann selbstverständlich noch vereinfacht werden. Ebenso sind Erweiterungen denkbar. So habe ich beispielsweise eine kleine Absicherung eingebaut, falls die Datenbank nicht beschrieben werden kann (z. B. aufgrund eines Connection-Errors). In diesem Fall werden die Energiewerte zwischengespeichert, bis ein erneutes Schreiben möglich ist.

Neben den großen Batteriespeichern für fertige PV-Anlagen setzen sich zunehmend modulare Hybridsysteme mit AC/DC- und DC/AC-Wandlern durch. Diese ermöglichen das Laden mit Gleichstrom aus den Solarpanels sowie das Laden mit überschüssigem Wechselstrom aus dem Hausnetz. Damit kann der Strom aus alten Solaranlagen, die aus der Förderung fallen, ebenso wie der Strom aus Balkonkraftwerken, der sonst meist kostenlos ins Netz geht, einfach für den Eigenverbrauch genutzt werden.

Ein großer und seit Jahren aktiver Hersteller ist die Firma Zendure aus dem Silicon Valley.

Für viele Speichermodelle bietet Zendure eine API an, mit der über die Hersteller-Cloud auf Daten des Speichers zugegriffen werden kann. Nach Aussagen des Herstellers funktioniert das für die folgenden Speichertypen

• SuperBase V (6400, 4600)
• Satellite Battery (6400, 4600) und
• SolarFlow (800, 800 Pro, 2400 AC, Hyper 2000) und
• SuperBase V (6400, 4600).

Wer möchte, kann die Cloud auch komplett aussperren. Dies ist beispielsweise in folgendem Beitrag von Tobias Schulz beschrieben. Dann hat man jedoch keinen Zugang zur gut gemachten App sowie zur KI-basierten Speicherverwaltung. In diesem Beitrag zeige ich wie ich einen Zendure Hyper 2000 mit Speicher über die Hersteller Cloud mit Node-RED abfrage. Zendure stellt hierzu eine kleine Dokumentation unter github zur Verfügung.

Cloud Verbindung herstellen

Für die Inbetriebnahme eines Geräts (Wechselrichter und Batteriespeicher) ist das Anlegen eines Accounts in der Cloud des Herstellers und die Registrierung der Geräte erforderlich (Link). Ebenso muss die Zendure-App installiert werden, um die Geräte anzumelden und notwendige Firmware-Updates auf Speicher und Wechselrichter einzuspielen. Darüber hinaus ermöglicht der Zugang über die App den Abruf sämtlicher Statusdaten und Statistiken der registrierten Geräte. Die App hat mittlerweile einen sehr guten Entwicklungsstand erreicht, der eine komfortable Steuerung und Auswertung der Leistungsdaten ermöglicht. Für weitere Informationen verweise ich auf die Webseite des Herstellers.

Nach der Registrierung und Inbetriebnahme des Hyper2000-Wechselrichters über die App kann durch Klicken auf das Zahnradsymbol oben rechts die Seriennummer des Geräts aufgerufen werden. Diese steht sowohl unter dem Gerätenamen als auch unter dem Menüpunkt „Gerätedaten“.

Grundsätzlich kommunizieren die Zendure Geräte über einen MQTT-Broker, der in meinem Fall in der Zendure-Cloud liegt. Für diesen brauche ich Zugangsdaten, damit ich Daten von meinen Geräten abfragen kann.  Mit der Seriennummer und dem Accountnamen kann nun ein Request an die Zendure-Cloud gesendet werden, um die Zugangsinformationen für eine sichere Abfrage aus Node-Red zu erhalten.

Die Abfrage kann beispielsweise mit einem cURL-Befehl durchgeführt werden. Ich verwende stattdessen eine Abfrage mit Node-RED.Hierzu benötige ich nur 3 Nodes.

Im inject-Node gebe ich als JSON-Objekt die Seriennummer sowie den Accountnamen wie folgt an:

Diesen Inhalt schicke ich nun an einen HTTP-Request-Node, und zwar als POST-Befehl an die Adresse https://app.zendure.tech/eu/developer/api/apply.
Für den Output verwende ich einen Debug-Node.

Nun erhälte ich im Node-RED Debug-Fenster einen String zurück, der wie folgt aussieht:

Hiervon sind folgende Teile wichtig:

• appKey: Der Accountname für die Anmeldung in der Cloud
• secret: Das Passwort für die Anmeldung  in der Cloud
• mqttUrl: Die URL des MQTT-Servers für die Datanabfrage

Nun sind alle Daten vorhanden, die man für eine weitere Abfrage benötigt.

von dem folgende Daten wichtig sind:

Daten abfragen

Um die Daten für das Gerät aus der Zendure-Cloud empfangen zu können, muss eine Abfrage beim MQTT-Server von Zendure erfolgen.

Dazu verwendet man einen MQTT-In-Node, für den man zunächst eine Verbindung mit den folgenden Daten einrichtet:

• Name: beliebig
• Server: mqtt-eu.zen-iot.com
• Port: 1883
• Connect automatically
• Protokoll: MQTT V3.1.1
• Bereinigte Sitzung verwenden

Unter dem Reiter „Sicherheit” werden folgende Daten angegeben:

• Benutzername: appkey (Der Accountname, den man von Zendure erhalten hat
• Passwort: secret (Das Passwort, was man von Zendure erhalten hat)

Im MQTT-IN Node werden folgende Eigenschaften eingetragen:

• Action: Subscribe to single topic
• Topic: appkey/#       (z.B. rtP7zHkq/#)
• QoS: 2
• Ausgang: Auto-Erkennung (parsed JSON Objekt, string oder buffer)

Nun sollte der Empfang funktionieren und die ersten Wert per payload-Objekt geliefert werden.

Daten auswerten

Beim Auswerten der empfangenen Daten stellt man schnell fest, dass immer nur Daten empfangen werden, die sich seit dem letzten Mal verändert haben. Damit enthält die payload immer eine unbestimmte Zahl von Einträgen mit jeweils unterschiedlichen Attributen.  Ebenso kann es durch die Cloudabfrage auch einen Zeitverzug ergeben (der für mich aber irrelevant ist). Ich habe festgestellt, dass für eine Hyper2000 neben der Seriennummer folgende Daten übertragen werden:

• remainOutTime ( Remaining discharge time in min = verbleibende Entladezeit)
• packInputPower (pack input power)
• electricLevel (Device battery percentage = Ladezustand der Batterie)
• solarPower1 (Solar1 Input Power in Watt = Leistung aus erstem Wechselrichter)
• solarPower2 (Solar2 Input Power in Watt = Leistung aus zweiten Wechselrichter)
• outputHomePower (output to home power in Watt = abgebene Leistung ins Hausnetz)
• hyperTmp (hyperTmp
• solarInputPower (solarInputPower = Leistung die gerade durch solarPanels in Speicher geladen wird)
• packState (packState = Gibt an, ob in Batterie gerade nichts passiert (0), geladen(1) oder entladen(2) wird)

Da es möglich ist, dass der Wert gar nicht geliefert wurde, muss man in einem anschließenden Switch-Node prüfen, ob das Ergebnis NULL ist. Anschließend kann der Wert weiterverarbeitet werden (z. B. in InfluxDB etc.)

Dies ist eine sehr einfache Lösung für die Auswertung, die natürlich durch eine effizientere Lösung mit weniger Redundanz ersetzt werden kann.

Interessant ist, dass Zendure keinen Zähler übergibt, der die Menge des von einer direkt angeschlossenen Photovoltaikanlage erzeugten Stroms in kWh misst. In der App ist ein solcher Zähler allerdings vorhanden. Zendure liefert stattdessen die jeweilige Leistung der PV-Module. In einem nächsten Beitrag zeige ich, wie sich aus der Leistung trotzdem Zählerstände berechnen lassen.

Seit vielen Jahren bietet Velux für seine Dachfensterlösungen die Nachrüstung von Rollläden an. Egal, ob man sich für Solarrollladen oder kabelgebundene Rollläden entscheidet, kann man diese in sein Smart Home einbinden. In vielen Fällen wird hierzu das KLF-200-Interface verwendet. Wer hingegen bereits eine Somfy-Basisstation (Tahoma Switch) besitzt, kann sich den Kauf des KLF 200 sparen. Im folgenden Artikel zeige ich, wie sich die Rollläden mit Somfy und Node-RED einfach in eine Smart-Home-Lösung integrieren lassen.

Rollladen anlernen

Zunächst wird der neue Velux-Rollladen über die Somfy-App angelernt. Hierzu ist keine Zusatzhardware von Velux oder Somfy erforderlich, sofern der Tahoma Switch vorhanden ist.

Dazu wählt man in der Somfy-App das Haussymbol und „Produkt hinzufügen“ aus. Anschließend wählt man „Fenster und Sonnenschutz“ und dann „Außensonnenschutz“ aus. Bei der Art des Außensonnenschutzes wird „Rollläden“ und bei der Fernbedienung „Wandsensor“ ausgewählt. Nun sollte der „Velux-Wandsensor“ erscheinen, den man anklickt.

Nun muss die SET-Taste des Velux-Wandsensors gedrückt werden. Am unteren Gehäuserand befinden sich zwei Öffnungen: Die linke ist mit einem Zahnrad versehen und stellt die SET-Taste dar, die rechte ist mit zwei übereinanderliegenden Fenstern versehen. Mit einem spitzen Gegenstand wird die linke Taste mit dem Zahnradsymbol so lange gedrückt, bis sich der Rollladen zu bewegen beginnt. Anschließend wird in der App auf „Weiter“ gedrückt. Die App sucht im Hintergrund nach dem VELUX-Empfänger und meldet nach kurzer Zeit, dass ein Rollladen gefunden wurde.

Der neue Rollladen ist jetzt in der Tahoma-App angelernt und kann darüber bedient werden. Die Option „Diskret“ reduziert das Geräusch der Rolladenbewegung durch langsameres Rollen. Ich empfehle dringend, dem Rollladen im folgenden Dialog noch einen sprechenden Namen zu geben, da wir diesen in Node-Red noch benötigen werden.

Ich nenne meinen Rollladen „DG Rollladen Mitte“.

Hinweis: In der Tahoma-App wird zwar der Name des Rollladen in der richtigen Länge angezeigt, bei der späteren Nutzung in Node-Red kann es aber sein, dass der Name nur gekürzt wiedergegeben wird.

Mit Node-RED Gerätedaten auslesen

Wie man den Tahoma Switch mit Node-Red ausliest, habe ich bereits im Beitrag Weinor Markisen mit NodeRed und Somfy API steuern beschrieben. Als Ergebnis des Beitrags erhalte ich neben der Adresse für den Switch auch den Token (Passwort), mit dem ich in den folgenden Schritten die Geräte abfragen kann.

Zunächst frage ich alle Geräte auf dem Tahoma Switch ab. Dazu muss ich den Befehl „Get Devices“ mit der Adresse der API des Tahoma Switches an die Zentrale schicken. Dies ist im oben genannten Artikel genau beschrieben. Ich habe mir diese Abfrage in Node-Red so eingerichtet, dass ich jederzeit alle Geräte abfragen kann. Nach dem Absetzen des GET-Befehls über einen „http-request“-Node erhalte ich im Debug-Fenster ein Objekt mit allen auf dem Tahoma Switch registrierten Geräten, deren Status und Befehlen. Bitte daran denken, den Bearer-Token immer neu einzugeben. Durch Aufklappen der Objektdetails kann ich nach meinem Rollladen „DG Rollladen Mitte“ suchen.

Da ich den Namen meines neuen Geräts kenne, fällt es mir nun leicht, es im Objektbaum zu finden. Kurz darunter steht die IO-Adresse, die ich zum Senden von Befehlen brauche. Im Array „Commands“ steht, dass ich die Befehle „up“, „close“ und „stop“ benutzen kann, um den Rollladen zu bewegen.

Nun habe ich alle erforderlichen Details, um das Gerät zu steuern.

Velux Rollladen steuern

Um einen Steuerbefehl absetzen zu können, muss ich Daten als POST-Request an die API-Funktion „exec” schicken.

Die Befehlszeile dazu sieht wie folgt aus:

Diese Befehlszeile, die ich mit einem HTTP-Request-Node absetze, benötigt als Input noch ein Datenobjekt, in dem ich angebe, welches Gerät ich mit welchem Befehl ansprechen möchte. Hier wird dann die IO-Adresse meines „DG Rollladen Mitte” verwendet.

Für das Runterfahren sieht das Datenobjekt wie folgt aus:

Dabei besteht die IO-Adresse immer aus der Adresse des Tahoma Switches, gefolgt von der siebenstelligen Geräteadresse des eigentlichen Geräts. Der Name des Gerätes ist für den Befehl nicht wichtig, da das Gerät eindeutig durch seine IO-Adresse bestimmt wird.

In Node-RED sieht das dann wie folgt aus:

Möchte man hingegen den Status abfragen, erhält man diesen mit einem Get-Befehl, der die API-Funktion /setup/devices/ aufruft. Bei der IO-Adresse muss man im Get- (oder Post-)Befehl daran denken, dass Sonderzeichen in HTML-UTF8-HEX-Zeichen umgewandelt werden müssen (d. h. aus :// wird %3A%2F%2F und aus / wird %2F).

Die Befehlszeile zur Abfrage des Status meines Rollladens lautet dann wie folgt:

Zurück erhalte ich ein Objekt, in dem sich ausschließlich die Daten meines Rollladens befinden. Mithilfe dieses Objekts kann ich beispielsweise feststellen, wie weit der Rollladen heruntergefahren wurde.

Nachtrag vom 14.5.25

Bestimmte Position anfahren

Für das Anfahren einer bestimmten Position findet man in der command-Liste des Gerätes den Befehl "setClosure". Als Parameter wird die Position in Prozent angegeben, wobei 0% eingefahren und 100% ausgefahren bedeutet. Das an den Befehl zu übergebende Datenobjekt sieht wie folgt aus:

Nicht erst seit Corona ist die Messung des CO2-Gehaltes in der Raumluft eine Möglichkeit festzustellen, ob genügend Frischluft (oder Sauerstoff) in einem Raum vorhanden ist. Ich war teilweise überrascht, wie teuer manche Sensorlösungen verkauft werden und habe mich daher entschlossen, einen eigenen Sensor zu bauen, der sich auch einfach in mein Smarthome integrieren lässt. Mit einer kleinen LED möchte ich anzeigen, ob ein vorgegebener Grenzwert überschritten wird. Die Daten des Sensors sollen zyklisch an mein Smarthome-System gesendet werden.

Benötigte Hardware

Als Sensor habe ich mich für einen CO2-Infrarotsensor MH-Z 19C entschieden. Der Sensor sendet seine Informationen über eine UART-Schnittstelle (Tx,Rx-Kanal), besitzt zusätzlich einen Temperatursensor und benötigt eine Versorgungsspannung von 5V. Mit diesen Anschlussmöglichkeiten eignet er sich hervorragend für den Anschluss an einen Wemos D1-Mini (8266 Chip), den ich schon in vielen meiner Projekte verwendet habe. Über diese kann ich dann auch alle Daten an einen MQTT-Broker senden und so die Daten einfach in meinem Smarthome-System weiterverarbeiten. Den Sensor gibt es in verschiedenen Ausführungen, wobei ich mich für die Version mit den Stiftleisten entschieden habe, um den Anschluss zu vereinfachen. 

Auf dem D1 Mini verwende ich die Tasmota Version 14.3.0. Um den CO2-Infrarotsensor MH-Z 19C an den D1 Mini anschließen und auslesen zu können, benötige ich die Tasmota Sensor Version (alternativ kann man den MH-Z19C auch einfach in der Standardversion aktivieren und spart dadurch viel Speicherplatz auf dem D1 Mini).

Ich erstelle meine Programme gerne mit der Skriptsprache von Tasmota. Da es diese Funktion in den vorkompilierten Versionen von Tasmota nicht gibt, kompiliere ich mir selbst eine Version und flashe den D1-Mini damit. Dies geht sehr einfach und ist im folgenden Artikel von mir beschrieben:Tasmota Scripting aktivieren

Ich empfehle, in der Konfiguration des D1-Mini neben dem WLAN auch direkt einen MQTT-Server anzugeben.

CO2-Sensor anschließen

Der Anschluss des CO2-Sensors ist recht einfach. Als Ergänzung habe ich noch eine rote LED hinzugefügt, die bei Überschreitung eines definierten Grenzwertes aufleuchten soll. Die gesamte Schaltung ist in der folgenden Abbildung dargestellt:

Nun muss der Sensor in Tasmota konfiguriert werden. Dies geschieht über die serielle Schnittstelle mit TX (Sendekanal) und RX (Empfangskanal).

Unter Configure / Configuration Module wähle ich als Module Type "Generic(18)" (steht meistens ganz unten in der Liste) und speichere das. Erst dann kann ich alle meine GPIOs sehen und konfigurieren.

• GPIO1 (TX) wird auf "MHZ Tx (60)" (Sendekanal) gesetzt.
• GPIO3 (RX) wird auf "MHZ Rx (61)" (Empfangskanal) gesetzt.

(Tipp: In der langen Liste stehen die beiden Werte im unteren Dritttel).

Um die LED einschalten zu können, wird noch ein Relay benötigt, dass wie folgt definiert werden muss:

• GPIO5 (D1) wird auf "Relay 1" gesetzt.

Nach dem Speichern und dem automatischen Neustart sollten Temperatur und CO2 Gehalt wie folgt auf der Tasmota Oberfläche erscheinen:

Hinweis: Aufgrund der Vorheizzeit kann es bis zu einer Minute dauern, bevor der Sensor Werte liefert!

Script für LED-Warnung erstellen

Natürlich möchte ich, dass eine rote Lampe aufleuchtet, wenn ein Grenzwert überschritten wird. Bezüglich möglicher Grenzwerte verweise ich auf den folgenden Artikel. Dazu muss ich den Sensorwert auslesen und in einem kleinen Programm das Relais immer dann einschalten, wenn der Grenzwert überschritten wird. Bei dieser Abfrage prüfe ich, ob die LED schon an ist, damit ich nicht ständig den Einschaltbefehl sende. Natürlich schalte ich die LED wieder aus, wenn der Grenzwert unterschritten wird.

Die Daten können nun vom MQTT-Broker "abgeholt"  und beispielsweise in InfluxDB gespeichert und ausgewertet werden. Wie das geht habe ich in folgenden Artikeln beschrieben

Möglicher Anpassungen

Ich versorge den Sensor über ein USB-Kabel mit Strom. Theoretisch könnte man dies auch mit einer Akkulösung realisieren. Dazu wird dann der Deepsleep-Modus verwendet (siehe hierzu Füllstandssensor (Zisterne) für HMIP selber bauen). Wichtig ist, dass der Sensor eine Vorlaufzeit zur Temperaturanpassung benötigt. Daher sollte der Sensor frühestens nach 1 Minute wieder in den DeepSleep-Modus gehen.

Anstelle einer LED könnte man auch eine mehrfarbige LED verwenden, die den jeweiligen Zustand anzeigt.

Inzwischen habe ich den Sensor auf eine Platine gelötet und mir mit dem Drucker ein passendes Gehäuse gedruckt.

Eine Bodenfeuchtemessung im Garten ist hilfreich, wenn man Pflanzen oder Rasen rechtzeitig und ausreichend bewässern möchte. Wenn man einen größeren Garten oder z.B. einen Schrebergarten hat, ist oft kein WLAN an allen Stellen verfügbar. Als Alternative bietet sich dann das Versenden der Sensordaten über LoRaWAN an. Die Vorteile habe ich bereits in meinem Beitrag LoRaWAN mit eigenem Gateway einrichten genannt.

ELV hat hierzu ein interessantes Produkt für einen überschaubaren Preis im Programm. Dazu braucht man das  LoRaWAN-Interfaces ELV-LW-INT1 und den  universellen Bodenfeuchtesensor SoMo1, I²C. Beide zusammen sind bei ELV für ca. 75 Euro zu erhalten.

Ich mit diesen Komponenten in einem größeren Garten die Bodenfeuchte und -temperatur gleichzeitig messen und halbstündlich an einen MQTT-Server übertragen. Ich habe dazu in der Nähe ein LoRaWAN-Gateway im TTN-Netz verfügbar.

Vor der Inbetriebnahme muss das System konfiguriert werden. Da die Konfiguration viele Möglichkeiten anbietet und für den Laien nicht trivial erscheint beschreibe ich, wie man den Sensor für diesen Zweck in Betrieb nehmen kann.

Installation der Hardware

Auch wenn die Platine als „Bausatz“ angeboten wird, sind keine Bestückungs- oder Lötarbeiten erforderlich. Das Interface besitzt neben 2 Mignon-Batterieslots vom Typ LR6 (AA) auch 2 Sensoranschlüsse mit UART- oder I²C-Schnittstelle. Obwohl insgesamt nur eine Spannungsversorgung über die Batterien (Akkus) von 3V zur Verfügung steht, können trotzdem 3,3 bzw. 5V an die Sensoren ausgegeben werden (über Transistoren). Dies ist wichtig, da die meisten Sensoren die etwas höhere Spannung für eine korrekte Messung benötigen. Die Platine besitzt keine externe Spannungsversorgung und kann daher nur durch Bestückung mit den 2 Mignonzellen in Betrieb genommen werden. Zur Befestigung liegen noch 2 Schrauben und eine Stiftleiste bei, über die ein Firmware-Update über einen USB-UART-Konverter UM2102N durchgeführt werden kann. Die richtige Firmware ist bereits installiert.

Der Feuchte- und Temperatursensor ist ebenfalls sofort einsatzbereit, kann Bodenfeuchte und -temperatur messen, besitzt einen AD/DA-Wandler und ist wasserdicht vergossen. Nach dem Einbau in eine Dose kann das Kabel des Sensors über die gekennzeichneten 4 Drähte an die Schnittstelle wie folgt angeschlossen werden:

• (braun) an +UB2
  
• (schwarz) an GND
• (blau) an SDA
• (weiß) an SCL

Weitere Detailinformationen finden sich z.B. in folgendem ELV-Journalartikel.

Wer kein LoRaWAN-Gateway in der nähe hat findet im Artikel LoRaWAN mit eigenem Gateway einrichten weitere Hinweise zum TTN-Netzwerk oder der Gateway-Einrichtung.

Ich empfehle, die Batterien erst wie im nächsten Kapitel beschrieben einzulegen.

Device und Applikation in TTN Netzwerk ergänzen

Nach dem Einloggen in das TTN-Netzwerk geht man auf den Reiter „Applications“. Als erstes erstelle ich eine Application und gebe hier einen aussagekräftigen Namen „Loris-Bodenfeuchte1“ ein.

Anschließend erstelle ich ein neues Device, indem ich auf „New Device“ klicke.

Bei „End device type“ kann man das Device direkt im Repository suchen (Option 1). Dazu wählt man ELV aus und findet dann schon das LoRaWAN Interface 1. Als Frequency Plan wird SF9 gewählt und nach Eingabe der JoinEUI (liegt dem Interface als kleiner Aufkleber bei) kann man auf Confirm tippen. Danach werden noch die DevEUI und der AppKey ergänzt. Die End-Device ID wird automatisch generiert und man kann nun „Register end device“ drücken. (Update Juli 2025: Die End-Device ID wird mittlerweile nicht mehr automatisch generiert. Hier kann man beispielsweise auch die DevEUI in der Notation "eui...." eintragen). 

Nach dem Einlegen der Batterien oder Akkus blinkt das Board kurz rot/gelb und wechselt dann auf grün.

Jetzt kann man unter „Live data“ beobachten, wie das Gerät Kontakt zum Netzwerk aufnimmt und Nutzdaten sendet. Zum Dekodieren der Daten benötigt man einen Payload Parser (ein kleiner Codeblock, der die vom Gerät empfangenen hexadezimalen Bytewerte übersetzt). Wenn man das Gerät wie beschrieben aus dem Repository ausgewählt hat, wird der Payload-Parser automatisch mitgeliefert. Dieser befindet sich unter dem Device im Reiter "Payload Formatter" "Uplink". Hier sollte "Use device Repository formatters" stehen. Den Code von eQ3  kann man sehen (und editieren), wenn man die Device aufruft und im Menü (OBEN!) den Reiter "Payload-formatters" aufruft.

Alternativ kann man diesen Code auch auf der ELV-Seite unter Downloads unter dem Link „ELV-LW-INT1 Payload-Parser“ herunterladen.

Sensor konfigurieren

Wer die Installation bis hierhin erfolgreich durchgeführt hat, wird feststellen, dass nur Statusdaten der Schnittstelle gesendet werden, aber keine Sensorwerte für Bodenfeuchte und Temperatur. Dies liegt daran, dass die Messung und Übertragung der Werte von den Sensoren erst aktiviert werden muss. Das Interface hingegen ist so vorkonfiguriert, dass es alle 30 Minuten eine Statusmeldung sendet.

Grundlagen zur Sensorkonfiguration

Die Befehle und Grundlagen für die Konfiguration der Sensoren und des Interfaces findet man in folgenden Dokumenten:

• Excel-Tabelle auf zum Interface mit allen Details zu Befehlen, Parametern, etc.
• Bau- und Bedienungsanleitung des Interfaces
• ELV-Journal 2/2024 unter Bausätze

Grundsätzlich tauscht man Informationen mit dem Interface und den Sensoren über eine Payload (eine Bytefolge von hexadezimalen Werten) aus. Befehle werden als Payload über einen Downlink-Kanal an ein Gerät gesendet, Daten werden über einen Uplink-Kanal empfangen. Kommandos werden als "frame-type" bezeichnet. In einem "frame-type" werden Daten wie z.B. Kanal und Parameter übertragen.

Für die zu übertragenden Codes (Bytes) müssen Werte berechnet werden, wobei teilweise zwischen dezimalen, hexadezimalen und binären Zahlenformaten gewechselt wird. ELV empfiehlt hierfür den folgenden einfachen Konverter.

In den folgenden Kapiteln werden einzelne Werte auch durch das Setzen von Bits ermittelt. Dabei gilt, dass die Bits in einem Byte von 0 bis 7 gezählt werden und rechts begonnen wird!

Sensoren über Kanäle ansprechen

Um die Sensoren und das Interface eindeutig anzusprechen benötigt man die Angabe einer Kanalnummer. Das Interface besitzt eine eigene Kanalnummer und neben dem gemeinsam verbauten Bodenfeuchte- und Temperatursensor wird auch ein Ultraschall-Disstanzsensor DUS1 unterstützt.

Folgende Kanalnummern stehen zur Verfügung:

Anzeige von Statusdaten

Theoretisch kann jeder Sensor eigene Statusdaten senden. Standardmäßig sendet das Interface jede halbe Stunde eine Statusnachricht und zusätzlich kann ich mir die Statusinformation des Feuchtesensors und des Temperatursensors jeweils in einem eigenen Zeitintervall senden lassen. Ich möchte aber insbesondere die Feuchte- und Temperaturinformationen immer zusammen erhalten und am liebsten noch zusammen mit den Statusinformationen des Interfaces (also insgesamt nur eine Nachricht mit allen Informationen jede halbe Stunde).

Dies kann ich erreichen, indem ich Statusgruppen verwende, in denen ich die Statusinformationen zusammenfasse und diese zusammengefassten Statusinformationen dann in eine Statusmeldung einfüge. In meinem Fall werden die Statusinformationen des Feuchtesensors und des Temperatursensors der Statusgruppe 1 zugeordnet. Ich werde für diese Sensoren nicht separat das Übermitteln von Statusinformationen aktivieren sondern werden das Interface so konfigurieren, dass es bei seiner halbstündlichen Statusinformation einfach die Gruppe 1 inkludieren soll. Damit wird die Statusmeldung auch die Informationen der Sensoren beinhalten.

Befehl zur Konfiguration der Sensoren

Zur Konfiguration verwende ich den "set single parameters" Befehl, dem ich beliebig viele Parameter übergeben kann. Mit diesem Befehl werden alle Parameteränderungen beginnen.

Feuchtesensor konfigurieren

Hierfür gelten folgende Punkte:

• Messungen müssen aktiviert werden, sonst kann der Feuchtesensor keine Daten senden.
• Man kann gleichzeitig auch das Messen der Temperatur aktivieren, so dass beide Werte synchron ermittelt werden!
• Der Bodenfeuchtesensor liefert immer sogenannte Rohwerte im Bereich von 3000 bis 4000 zurück. Diese kann man selber in Prozentwerte umrechnen oder vom Sensor direkt umrechnen lassen. Dazu ist das Ablesen der Sensorwerte im trockenen Zustand sowie in nassem Zustand erforderlich. Die beiden Rohwerte werden dann dem Sensor als Untegrenze für 0% und Obergrenze für 100% mitgeteilt.

Mit folgender Bytefolge konfiguriere ich den Feuchtesensor:

Temperaturmessung konfigurieren

Hierfür gelten folgende Punkte:

• Die Temperaturmessung wurde bereits über die Bodenfeuchtemessung aktiviert, so dass die Messzyklen für die Feuchtemessung automatisch gelten. Weitere Einstellungen zur Messwerterfassung sind bei diesem Ansatz nicht erforderlich.

Mit folgender Bytefolge konfiguriere ich den Temperatursensor:

Interface konfigurieren

Hierfür gelten die folgenden Punkte:

• Standardmäßig sendet das Interface alle 30 Minuten eine Statusmeldung, so dass dies nicht gesondert eingestellt werden muss.
• Zusätzlich zu den eigenen Statusinformation sollen die Statusinformation des Feuchte- und Temperatursensors übermittelt werden.

Mit folgender Bytefolge konfiguriere ich das Interface:

Konfigurationsänderung an das Gerät schicken

Dazu geht man im TTN-Webinterface unter "End devices" auf das SoMo1-INT1 Gert, wählt den Reiter "Messaging" und dort den Reiter "Downlink". Als "FPort" muss nun "10" eingestellt werden. Danach kann man die in den vorherigen Kapiteln erstellten drei Bytefolgen (Payload) jeweils in das Payload-Feld eintragen (bitte  ohne das führende 0x) und anschließend den Button "Schedule downlink" drücken. Das Kommando wird beim nächsten Verbindungsaufbau zum Gerät gesendet (durch kurzes Drücken des Buttons an der Schnittstelle kann die Zeit verkürzt werden).

Unter "Live data" kann man nun die Übertragung der Befehle beobachten. Wenn dort die "decode downlink data message" Meldung „No decoder defined for codec elv-lw-int1-codec“ erscheint, kann man diese ignorieren. Es gibt aktuell keinen Payload-Decoder, der in der Lage ist, die gesendete Bytefolge wieder in Klartext umzuwandeln.

Es kann einige Zeit dauern, bis die Einstellungen vorgenommen sind, da normalerweise die eingestellten Sendeintervalle abgewartet werden müssen (in diesem Beispiel bis zu 1 Stunde).

Um die Daten an einen MQTT-Server zu schicken verweise ich auf die Erläuterungen in folgendem Beitrag Füllstandsmessung mit LoRaWAN.

Wenn dann eine Statusinformation gesendet wird, sollte das Ergebnis wie folgt aussehen:

Die Daten können dann z.B. in Node-Red weiterverarbeitet und zur Steuerung von Bewässerungssensoren verwendet werden.

HINWEIS: Die Bodentemperatur wird als Zeichenkette (String) geliefert und nicht wie der Feuchtewert als Zahl (float-Typ). Vor der Speicherung in einer Datenbank sollte der Wert daher vorher umgewandelt werden, damit man ihn grafisch darstellen kann.

Optionale weitere Befehle

In der folgenden Tabelle sind einige weitere Befehle zur Konfiguration der Sensoren aufgelistet:

Mit einer Photovoltaikanlage wird vor allem in den warmen Monaten mehr Strom erzeugt als gespeichert oder verbraucht werden kann. Da es sich kaum lohnt, den Strom zu verkaufen, ist es besser, ihn zu verbrauchen. Was liegt da näher, als die Räume im Sommer mit Klimaanlagen kostenlos zu kühlen. Der folgende Beitrag zeigt, wie man mit einfachen Mitteln eine Split-Klimaanlage in das Smarthome-System Node-Red integrieren und den Stromüberschuss zum Kühlen nutzen kann.

Klimaanlage extern steuern

Die grundsätzliche Frage ist, wie eine Klimaanlage in ein Smarthome-System eingebunden werden kann. Sofern der Hersteller keine spezielle Schnittstelle zur Verfügung stellt (z.B. Modbus, etc.), ist die einfachste Möglichkeit, die Infrarotschnittstelle zur Fernbedienung des Klimagerätes zu nutzen. Die meisten Geräte verfügen über eine Infrarot-Fernbedienung, die bestimmte Infrarotsignale aussendet, um verschiedene Befehle an die Klimaanlage zu senden. Einige Fernbedienungen sind sogar bidirektional, d.h. sie können auch Statusinformationen von der Klimaanlage empfangen. In diesem Beispiel ist eine unidirektionale Fernbedienung ausreichend. Benötigt wird also ein Gerät, das  Signal der Klimaanlagen-Fernbedienung senden und über eine API von außen gesteuert werden kann. Mittlerweile gibt es eine Vielzahl von Geräten, die jedoch nicht mit allen Klimaanlagen funktionieren. Dazu habe ich einige Versuche unternommen.

1. Versuch

Als erstes Gerät habe ich den ELV Smart Home Bausatz IR-Sender ELV-SH-IRS8 getestet, da dieser direkt von einer HMIP-CCU angelernt werden kann. Leider stellte sich im Nachhinein heraus, dass meine Mitsubishi Heavy Industries Anlage nicht unterstützt wird. Außerdem muss man etwas Löterfahrung mitbringen, um das Gerät zusammenbauen zu können. Insgesamt ist die Auswahl der unterstützten Klimagerätehersteller überschaubar.

2. Versuch

Dann habe ich das BroadLink RM mini 3 getestet. Das Gerät heißt nicht nur so, sondern ist auch mini. Allerdings ist die Einrichtung ziemlich kompliziert. Um das WLAN einzurichten und die Klimaanlage anlernen zu können musste ich mehrere Apps benutzen, die teilweise nicht gut gepflegt waren. Die Anleitung selbst war nicht optimal und die blaue Status-LED am Gerät kaum erkennbar. Auch brach die WLAN-Verbindung zwischendurch immer wieder ab. Positiv war, dass eine große Anzahl von Klimaanlagen unterstützt wird. Allerdings habe ich keine brauchbare Node-Palette für Node-Red gefunden, mit der man das Gerät mit Node-Red steuern kann.

3. tado bietet die bisher beste Lösung

Schließlich bin ich bei tado gelandet. Diese bieten die Smarte Klimaanlagen Steuerung V3+ an. Um zu prüfen, ob mein Gerät überhaupt unterstützt wird, habe ich vor dem Kauf den Support (gelber Button unten rechts auf der Webseite) kontaktiert, da tado keine Kompatibilitätsliste veröffentlicht hat. Innerhalb kurzer Zeit hat jemand meine Angaben zur Fernbedienung und zum Hersteller der Klimaanlage aufgenommen und nach einem Tag hatte ich die Rückmeldung, dass meine Anlage unterstützt wird.  Die tado Lösung ist eine Cloud-Lösung, d.h. man muss auf jeden Fall einen Account anlegen und eine App installieren. Für Node-Red gibt es  zusätzliche Nodes, um dieses und andere Geräte steuern zu können.

tado legt großen Wert auf Design und einfache Bedienung, was man schon beim Auspacken merkt. Die Einrichtung ist komplett menügeführt und für den  Notfall gibt es auf der Webseite eine Anleitung. Folgende Tipps kann ich noch geben:

• Sowohl tado als auch broadlink wollen das Gerät mit dem 2,4 GHz WLAN verbinden. Wer sowohl ein 2,4 GHz als auch ein 5 GHz LAN mit dem gleichen Namen nutzt, dem empfehle ich das 5GHz LAN kurzzeitig zu deaktivieren, damit der Verbindungsaufbau fehlerfrei funktioniert.
• Bei tado wollte mein Gerät nach Aufbau der WLAN-Verbindung ein Update installieren. Dies funktionierte aber nicht, das Gerät blieb ständig im Installationsmodus. Nach mehreren Stunden kontaktierte ich erneut die tado-Hotline (gelber Button), die aus der Ferne die Installation starten konnte.

Danach konnte das Klimagerät mit einem einfachen Tastendruck auf der Fernbedienung identifiziert und automatisch eingerichtet werden. So sollte es sein!

Wer weitere einfach einzurichtende Verbindungen für Klimaanlage kennt, kann diese gerne hier posten!

Stromverbrauch auslesen

Um die Klimaanlage nur bei Stromüberschuss einschalten zu können benötige ich zunächst den jeweils aktuellen Stand meines  Saldos aus Stromverbrauch und Stromerzeugung am Zähler. Wie das geht, habe ich in dem folgenden Artikel beschrieben: SmartMeter mit Tasmota auslesen. Dieser Wert wird automatisch an den MQTT-Broker gesendet. Diesen rufe ich mit Node-Red bei jeder Änderung ab und speichere ihn zwischen. Wie man die Daten von einem MQTT-Server abruft habe ich im folgenden Beitrag Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 2/2) im Kapitel MQTT-Nachrichten mit Node-Red auslesen und in influxDB speichern beschrieben.

Der Code im Function-Node sieht wie folgt aus:

Ich extrahiere den relevanten Wert aus dem MQTT-Objekt und speichere ihn in einer Flow-Variablen. So kann ich auf diesen Wert zugreifen, ohne den MQTT-Broker erneut zu fragen. Das Ergebnis gebe ich zur Kontrolle mit einem Debug-Node im Debug-Fenster aus.

Anmelden bei tado

Um das tado-Gerät von Node-Red aus steuern zu können, installiere ich die Erweiterung node-red-contrib-tado-client. Ich rufe den neu installierten Tado-Node auf und gebe als erstes unter "Tado Config" meine Anmeldedaten für die Tado Cloud ein, da ich dort zuvor mein Gerät angelegt habe.

Wichtige Ergänzung (Juni 2025)

Tado hat mittlerweile die Authentifizierung geändert und nutzt nun das OAuth2-Verfahren, um einen Zugriff auf die Rest-API zu ermöglichen. Nähere Infos dazu findet man unter:

https://support.tado.com/en/articles/8565472-how-do-i-authenticate-to-access-the-rest-api

https://datatracker.ietf.org/doc/html/rfc6749#page-48

Wer die alte Version der Library noch installiert hat, muss mindestens auf die Version V1.1.4 updaten. Ich empfehle ebenfalls das Lesen der Library-Informationen bzgl. weiterer Neuerungen.

Zur Nutzung sollte der Beispielflow tado.json von der Library aus GitHub in NodeRed geladen werden, denn hier befinden sich auch weitere Erläuterungen zur Einrichtung.

Auf der Beispiel-Flow-Seite befinden sich nun drei Bereiche:  "Authentication Flow", "Persistent Auth" und "Testing".

Durch Drücken des „Inject“-Nodes im Authentication Flow wird ein Debug Output erzeugt. In diesem steht ein Link. Diesen ruft man in einen beliebigen Browser auf. Wenn man noch nicht bei tado angemeldet ist, dann gibt man zuerst seinen Login-Namen und sein Passwort an. Anschließend bestätigt man nur den angezeigten Code und tado meldet „Erfolgreich verbunden“. Nun steht im Debug-Fenster in NodeRed der "Refresh_Token", mit dem man die weiteren API-Aufrufe vornehmen kann (hierzu empfehle ich, das nächste Kapitel zu lesen).

Ein Refresh-Token ist allerdings maximal nur 300 Sekunden gültig, so dass man dann einen Neuen erzeugen müsste (dies wird z.B. auch durch einen Deploy in NodeRed ausgelöst, da der Token dann aus dem Speicher gelöscht wird.

Damit das nicht passiert und der Token erhalten bleibt bzw. automatisch erneuert wird hat der Autor der Library den Beispiel-Flow „Persistent Auth“ beigefügt.

Zur Nutzung werden die Nodes in dem Flow zuerst aktiviert. Anstelle des Nodes „unknown: tado-token“ wird der tado-Node eingetragen und verbunden. In diesem wird für die Eigenschaft "Tado-config" nur die Auswahl "Tado-config" getroffen. Für alle weiteren Abfragen verwende ich ab jetzt nur noch "Tado-config" und nicht mehr "Tado-Cloud" (die folgenden Bilder wurden noch mit der alten Authentifizierungsmethode erstellt).

Parallel dazu wird im NodeRed Data-Verzeichnis eine Datei /data/tado.json angelegt und dort im JSON-Format der letzte verwendete Refresh-Token eingetragen.

Anschließend sollte der Flow ohne Probleme laufen. Dieser erneuert nun automatsch den Refresh-Token. Laut Angaben des Autors der Library wird der Refresh-Token maximal innerhalb von 30 Tage automatisch erneuert, wenn man nicht auf die API zugreift, bevor man einmal manuell eine Erneuerung auslösen muss. Alternativ reicht es aus, dass innerhalb von 30 Tagen einmal ein API-Zugriff erfolgt. Ich vermute, dass dies auch eine Sicherheitseinstellung von tado ist.

tado Parameter auslesen

Für die weiteren API-Aufrufe benötige ich meine Home ID. Diese erhalte ich, wenn ich den API-Aufruf "Get the current user" auswähle und den resultierenden Aufruf mit einem Inject-Node vorne und einem Debug Node hinten ergänze und ausführe. Als Ergebnis erhalte ich im Debug-Fenster ein Datenobjekt, das wie folgt aussieht:

Hier brauche ich nun die Zahl, die unter "homes" im Array[0] hinter "id" steht. 2359335 ist meine Home-ID, die ich für die weiteren API-Aufrufe benötige (das Objekt lässt sich durch Klicken auf die Pfeile auf- und zuklappen).

Zusätzlich frage ich noch die Zone ab, in der sich mein Gerät im Tado-Universum befindet (zur Erklärung von Zonen sollte man sich bei tado informieren).

Dazu öffne ich einen neuen tado-Node, wähle diesmal die API-Funktion "Get all zones" und gebe die eben gefundene Home-ID an. Mit Inject und Debug-Node erhalte ich wieder ein Datenobjekt, indem ich durch Aufklappen der Datenstruktur irgendwo den Namen meiner Klimaanlage finde, den ich beim Setup angegeben habe. Die Nummer hinter dem Feldnamen id des Objekteintrags darüber ist die Nummer, die ich brauche.

Wenn ihr nur eine Klimaanlage eingerichtet habt, werdet ihr höchstwahrscheinlich die Nummer "1" als Ergebnis erhalten.

Jetzt habe ich alles zusammen, um die Klimaanlage mit Node-Red ein- und auszuschalten.

Klimaanlage mit Node-Red steuern

Um die Klimaanlage einzuschalten, ruft man wieder einen Tado-Node auf und wählt die Funktion "Set a Zone's Overlay". Mit den folgenden Parametern schalte ich die Klimaanlage bei mir ein:

Hinweis: Da ich keine bidirektional sendende Fernbedienung habe, kann Tado nicht erkennen, ob ich die Klimaanlage manuell ein- oder ausgeschaltet habe. Ich kann die von Tado eingeschaltete Anlage zwar mit der Fernbedienung ausschalten, Tado hat intern aber immer noch den Status "ein" gespeichert. Auch die "Auto-"Funktion beim AC-Mode funktioniert bei mi nicht.  Ich gehe ebenfalls davon aus, dass dazu eine bidirektionale Fernbedienung erforderlich ist, die auch Temperaturwerte übermittelt. 

Analog schalte ich die Klimaanlage aus, wenn ich in die Eigenschaft des Schalters "Heating On/Off" einfach auf "Off" stelle.

Nun kann ich ein einfaches "Programm" in Node-Red erstellen, das in der folgenden Grafik zu sehen ist:

Oben habe ich bereits beschrieben, dass ich den aktuellen Zählerstand immer vom MQTT-Server hole und in einer Variablen zwischenspeichere. Nun füge ich nur noch einen Inject-Node hinzu und stelle dort ein, dass dieser in der Zeit von 8:00 bis 20:00 Uhr an jedem Tage und zu jeder Viertelstunde ein Ereignis auslöst.

Dann prüfe ich im nächsten Switch-Knoten, ob mein aktueller Stromverbrauch (Saldo) einen Überschuss von 400 Watt und mehr aufweist oder darunter liegt. Im ersten Fall schalte ich die Klimaanlage mit dem Tado-Node ein oder mit dem anderen Tado-Node aus. Der Inhalt des switch-Knotens sieht wie folgt aus:

Dieses einfache Beispiel kann nun leicht erweitert werden, indem man weitere Klimaanlagen hinzufügt und z.B. die Temperatur vorher kontrolliert.

Mit dem kleinen Shelly Plus PM Mini wird eine günstige Möglichkeit geboten, eine Leistungsmessung durchzuführen. Das Gerät ist nur ca. 28 x 32 x 16 mm (HxBxT) groß und passt in viele UP-Dosen z.B. hinter einer Steckdose. Das Gerät unterstützt dabei eine Messung bis zu 16A Leistung (ist leider nicht bei allen Shelly Geräten so), so dass man mit dem Gerät theoretisch die Leistung eines Balkonkraftwerks, von Lichtschaltern oder Steckdosen messen kann.

Im folgenden Beitrag beschreibe ich, wie man das PM Mini auch ohne Shelly-App über WLAN und MQTT einbinden und die Daten in Node-Red weiterverarbeiten kann.

Grundsätzlich erfolgt hier der Hinweise, dass das Arbeiten an Elektroleitungen immer nur von Fachleuten (Elektrikern) durchgeführt werden und immer die fünf Sicherheitsregeln der Elektrotechnik berücksichtigt werden sollten.

Gerät ins Netzwerk einbinden

Ich möchte auf die Shelly Cloud sowie das Einrichten der Shelly App verzichten, sondern nur eine lokale Nutzung mittels WLAN umsetzen. Nach der Stomversorgung spannt das PM Mini ein eigenes Netz auf (Access Point), mit dem man sich verbinden muss. Das WLAN erkennt man an dem Namen, der mit "ShellyPMMini..." beginnt. Um anschließend in den Shelly-WebAdmin-Oberfläche zu kommen, gibt man im Browser die Adresse "192.168.33.1" ein und schon sollte die administrative Weboberfläche  erscheinen. Bitte berücksichtigt, dass auch die Shelly-Geräte nur das 2,4 GHz WLAN unterstützen. Die Optionen und Anzeigen  in der WebAdmin-Oberfläche sind unter diesem Link super erklärt.

Nun geht man auf "Configure Wifi-Setting", wählt "Enable Wifi-network" und gibt die SSID (Name des WLANs) sowie das Passwort für das WLAN an und speichert die Einstellungen. Theoretisch kann man das Gerät nun neu starten und es sollte dann unter einer eigenen IP-Adresse in der Netzwerkliste des Routers erscheinen.

Generelle Einstellungen

Da es bei älteren Shelly-Firmwareversionen zu Problemen mit der korrekten Leistungsmessung kam, sollte unbedingt die aktuelle Firmware für das PM Mini aufgespielt werden.  Dazu geht man auf "Settings" und "Firmware". Shelly prüft nun automatisch, ob eine neue Version verfügbar ist und bietet an, diese online zu installieren.

Nach dem Drücken von "Update" wird die Firmware aufgespielt und das Gerät neu gestartet. Nun sollten folgende Einstellungen vorgenommen werden:

MQTT-Settings

Für das erfolgreiche Senden von Nachrichten an einen MQTT-Broker müssen folgende Einstellungen vorgenommen werden:

Nach dem Speichern der Settings ist das Gerät vollständig konfiguriert und kann über "Settings" "Reboot-Device" neu gestartet werden. Anschließend kann man z.B. mit dem MQTT-Explorer prüfen, welche Informationen an den MQTT-Broker gesendet werden.

Tipp: Bei mir wurden zuerst keine Nachrichten gesendet. Erst als ich in den MQTT-Settings den Punkt „Generic Status update over MQTT“  enabled und dann wieder disabled habe, hat es funktioniert.

Daten in Node-Red weiterverarbeiten

Die Daten können jetzt in Node-Red weiterverarbeitet werden. In meinem Fall speichere ich diese direkt in einer InfluxDB ab.

Im mqtt-in-Node frage ich erst einmal das Topic vom MQTT-Server ab. Dieses findet man unter dem Namen, den man dem Shelly-Gerät  gegeben hat (siehe oben), gefolgt von einem "/pm1:0", also in meinem Fall heißt das Topic "EM-Licht/pm1:0". Als Ausgabe wird "Ein analysiertes (parsed) JSON-Objekt." gewählt.

Im Function-Node wird nun die Leistung aus dem JSON-Objekt extrahiert:

Der Code dazu lautet:

Das bedeutet, dass sich unter "aenergy.total" der benötigte Wert im payload-Objekt befindet.

Zuletzt speichere ich diesen Wert noch mit einem influxdb-out-Node in die Datenbank. Mit dieser Vorgehensweise kann man auch andere Shelly-Geräte ohne Shelly-App abfragen und deren Daten weiterverarbeiten.

Wie man Node-Red, MQTT und InfluxDB installiert und Daten austauscht steht unter anderem in meinen Beiträgen Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 1/2) und  Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 2/2)

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.