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:

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)

Neulich bin ich wieder auf die die Ulanzi TC001 Pixelclock gestoßen und beschreibe im folgenden Beitrag, wie sich mit dem Display eigene Werte über Node-Red von beliebigen Smart Home Systemen darstellen lassen.

Ich habe die Pixelclock direkt bei Ulanzi bestellt. Innerhalb kurzer Zeit wurde sie geliefert. Sie besitzt ein Matrixdisplay aus 256 LEDs und versprüht damit einen gewissen Retro Charme. Sie ist mit einem Akku ausgestattet und über einen USB-C Anschluss kann man das Gerät aufladen oder auch mit einem Netzteil betreiben. Ich verwende dazu ein Netzteil, welches ich normalerweise für einen Raspberry PI benutze (5V, 1A).

Auf der Oberseite befinden sich neben einem Lichtsensor drei Tasten, die zur Bedienung der internen Einstellungen dienen. Die Pixelclock zeigt bereits fünf eigene Apps an, zu denen ein Kalender oder die Akkuanzeige gehören.

Neue Firmware aufspielen

Um eigene Werte auf der Pixelclock anzeigen zu können, muss eine andere Firmware aufgespielt werden. Diese wird der blueforcer AWTRIX LIGHT Gruppe gepflegt und über diese Webseite mit einem Online-Flasher bereitgstellt. Nach dem Anschluss des Gerätes über das mitgelieferte USB-C-Kabel kann das Gerät über die Webseite geflasht werden.  Während dieses Vorgangs piept das Gerät kontinuierlich.

ACHTUNG: Der Online Flasher funktioniert lt. Hersteller nur mit Google Chrome und Microsoft Edge. Bei mir hat nur Google Chrome unter OSX funktioniert.

Nach erfolgreicher Installation meldet sich die Pixelclock mit einer bunten Anzeige, auf der "AWTRIX sowie die Versionsnummer der Firmware und "AP MODE" angezeigt werden. Dies bedeutet, dass die Pixelclock noch keine Verbindung ins WLAN hat. Da sie in diesem Modus ein eigene WLAN aufspannt kann man sich mit einem beliebigen Gerät mit diesem WLAN verbinden (Name i.d.R. "awtrix....").

Nach Eingabe der SSID und der Passwortes startet das System neu und sollte nun nach dem Versionsschriftzug eine IP-Adresse anzeigen. Unter dieser IP-Adresse ist das AWTRIX-Webinterface ab sofort erreichbar.

TIPP: Wer später eine aktuellere Firmware aufspielen möchte kann diese unter folgendem Link herunterladen und auf dem Webinterface der Pixelclock über den Menüpunkt "Update" installieren.

AWTRIX konfigurieren

Zur Anzeige eigener Werte ist ein MQTT-Broker erforderlich. In meinem Beitrag MQTT-Broker Mosquitto als Docker Image auf einem NAS installieren ist beschrieben, wie man diesen installieren kann.

Ich empfehle, folgende Einstellungen vorzunehmen:

• Unter "MQTT" die IP-Adresse des MQTT-Brokers (der Port kann i.d.R. auf 1883 bleiben, wenn man den nicht geändert hat)
• Unter "Prefix" den Namen, unter dem Daten für das Gerät zu finden sein sollen. In meinem Beispiel verwende ich "awtrix_test"
• (optional) Unter "Auth" einen Usernamen und ein Passwort für den Zugriff auf das Webinterface.

Nach Änderungen ist es sinnvoll, diese zu sichern.  Das kann man über den Menüpunkt "Backup" erledigen und kann somit später Konfigurationen einfach wiederherstellen.

Auf dem Gerät sollte man darüber hinaus alle Applikationen deaktivieren, die man nicht braucht. Bei mir ist nur der Kalender übrig geblieben. Dazu drückt man etwas länger die mittlere Taste und wählt über die links- oder rechts-Taste das Menü "APPS"  aus. Ein erneutes Drücken der mittleren Taste bietet anschließend die Möglichkeit, mit den Pfeiltasten die vorinstallierten Apps anzuwählen. Diese können über die mittlere Taste auf "ON" oder "OFF" gestellt werden.  Das jeweilige Untermenü verlässt man über das längere Drücken der mittleren Taste.

HINWEIS: Man kann auf dem Gerät nur die vorinstallierten Apps aktivieren oder deaktivieren. Eigene Apps werden hier nicht angezeigt, sondern werden nur über die MQTT-Nachrichten gesteuert. 

Icons installieren

Eigene Daten kann man mit vorangestellten Icons anzeigen lassen. Hierzu gibt es bereits eine riesige Auswahl auf der Seite Lametric. Wunderschön sind insbesondere die animierten Icons z.B. für Stromverbrauch oder Stromerzeugung. Wer hier nichts findet, kann sogar selber eigene Icons erstellen. Ich wähle für mein Beispiel das Icon mit der Nummer 21256 aus.

Nach dem Wechsel in das AWRTIX-Webinterface kann man unter dem Menüpunkt "Icons" durch die Angabe der Icon-Nummer von der Lametric-Seite ein oder mehrere Icons auf die Pixelclock laden.

Eigene Werte anzeigen lassen

Ich möchte auf der Pixelclock den aktuellen Stromverbrauch meines Smartmeters anzeigen lassen. Wie man diesen ausliest, habe ich in dem Beitrag SmartMeter mit Tasmota auslesen beschrieben.

In Node-Red baue ich dazu einen Flow, der aus folgenden Komponenten besteht:

Von einer CCU hole ich mir die Variable, in der der aktuelle Stromverbrauch gespeichert ist (das könnte natürlich auch der Wert von einem MQTT-Broker sein). Diesem Wert übermittle ich an einen Change-Node, in der die Nachricht zusammengestellt wird, die an einen MQTT-out-Node weitergegeben wird. Die Nachricht wird als json-String in einer Payload zusammengesetzt und besteht aus folgenden Bestandteilen:

In Node-Red sieht der Change-Node wie folgt aus:

TIPP: Es gibt eine große Zahl von Konfigurationsmöglichkeiten für eine Anzeige. Diese sind in der sehr guten Dokumentation unter folgendem Link zu finden.

Diese Informationen leite ich anschließend an den MQTT-out-Node weiter. Hier ist darauf zu achten, dass das Topic richtig eingetragen wird. Dieses besteht aus dem in AWTRIX festgelegten Topic (hier "awtrix_test"), gefolgt von dem Text "/custom" sowie einer eigenen Applikationsbezeichnung. In meinem Beispiel lautet das topic "awtrix_test/custom/stromverbrauch". Der letzte Name kann frei gewählt werden ist aber wichtig, damit man die verschiedenen Werte, die man an die Uhr übermittelt, eindeutig unterscheiden kann.

Sobald man den Flow in Node-Red deployed hat, sollte nach kurzer Zeit auf der Pixelclock der definierte Wert angezeigt und ständig aktualisiert werden. Es kann am Anfang ein paar Sekunden dauern, bis die Nachrichten vom Broker empfangen wurden.

Senken des Stromverbrauchs

Bei Messungen habe ich festgestellt, dass die Pixelclock bis zu 8 Watt im Betrieb braucht. Das erschien mir ziemlich viel, so dass ich zwei Maßnahmen empfehle, wie der Verbrauch gesenkt werden kann.

Zuerst sollte die Helligkeit des Displays heruntergestellt werden. Dazu wählt man im Menü der Pixelclock (langes Drücken auf die mittlere Taste) den Menüpunkt "BRIGHTNESS". Nach Drücken der mittleren Taste kann man hier einen eigenen Wert einstellen. Bei mir sind aktuell 10% eingestellt, was auch bei Tageslicht vollkommen ausreicht. Dadurch sank mein Stromverbrauch bereits auf weniger als 5 Watt.

Zusätzlich stelle ich ich die Anzeige z.B. nachts aus. Hierzu wird der Pixelclock einfach ein Befehl geschickt, der diese für eine bestimmte Zeit schlafen legt (Deep Sleep Modus des ESP).

Dazu wird in einem Change-Node die Eigenschaft "sleep" auf die Sekundenzahl gesetzt, die das Gerät im Schlafmodus verbringen soll. In meinem Beispiel sind das 12 Stunden oder 43.200 Sekunden:

Diese Information wird anschließend als Push-Nachricht über einen mqtt-out-Node an den MQTT-Server gesendet, wobei das Topic wie folgt lautet "awtrix_test/sleep".

Weinor Markisen sind seit vielen Jahrzehnten im Einsatz und gelten als sehr zuverlässig. Nach dem Kauf einer neuen Weinor-Markise wollte ich diese mittels Node-Red einbinden und über Taster von Homematic-IP schalten.

Dabei habe ich festgestellt, dass die verbauten Somfy Motoren nur noch das io-Homecontrol Protokoll unterstützen. Für dieses habe ich leider keine funktionsfähigen Bibliotheken für Node-Red gefunden, die den Zugriff auf die Somfy Produkte ermöglichen. Daher habe ich mich damit beschäftigt, wie man das Thema auch ohne fremde Bibiotheken lösen kann und zeige in den folgenden Absätzen wie das trotzdem geht.  Ich verwende dazu Node-RED, über das ich auch die Schalter von Homematic-IP nutzen kann.

Wenige Grundlagen

Schon seit langem werden Weinor Markisen mit Somfy Motoren ausgestattet. Somfy unterscheidet hier zwei selbst entwickelte Technologien:

• RTS (Radio Technology Somfy): Dise unidirektionale Technologie gibt einfach nur Befehle an den Motor weitere.
• io-Homecontrol: Dies ist eine biderektionale Funktechnologie, die auch den Status von Aktoren abfragen kann. Diese wird mittlerweile auch standardmäßig in Weinor Produkten eingebaut.

Für das RTS-Prokololl gibt es eine Vielzahl von Lösungsmöglichkeiten u.a. über einen nano-CUL Stick an, der auf dem Frequenzbank 433 MHz kommuniziert. Eine Anleitung hierzu ist  u.a unter folgendem Link zu finden: https://www.byteride.com/iobroker-somfy/

Für io-Homecontrol sieht das Ganze schon deutlich schwieriger aaus, das Somfy dieses Protkoll erst seit wenigen Jahren als neues Protokoll in seinen Geräten verbaut.

Um die von mir vorgestellte Lösung nutzen zu können, braucht man einen Tahoma Switch, von Somfy, der eine Basisstation für alle Somfy-Produkte ist. Ein Somfy Connectivity Kit ist nicht geeignet. Die angelernten Geräte sich sich dann auch über eine Somfy-App sehr komfortabel einrichten und steuern.  In diesem Tahoma Switch hat Somfy eine lokale API installiert, die man für eigene Zwecke sehr schön nutzen kann, und über die die Steuerung aller Parameter eines am Tahoma-Siwtch angeschlossenen Gerätes inkl. von der Weinor-Markisen gelingt. Die vorgestellte Lösung kann somit für beliebige Somfy-Geräte verwendet werden, die an dem lokalen Tahoma-Switch angeschlossen werden.

Welche Technologie unterstützt meine Markise

Welche Technologie der Markisenmotor unterstützt ist fast immer anhand der Bezeichnung der Fernbedienung abzulesen, auf der z.B. ein kleines "io" zu finden ist, wenn die aktuelle Technologie verbaut wurde.

Alternativ  kann man sich den Aufdruck auf dem Markisenmotor anschauen, was meist etwas unpraktisch ist. Kennt man aber die Bezeichnung entweder vom Motor oder von der Fernbedienung kann man die Funktechnologien, die diese Geräte unterstützen,  auch direkt auf der Somfy-Webseite nachschauen.

Developer Mode aktivieren

Somfy hat in 2022 die Möglichkeiten zum Steuern von IOT-Devices komplett auf eine neue API umgestellt, die auf der lokalen Tahoma Basisstation aktiviert werden muss und anders angesprochen wird, als die alten APIs. Hierzu muss auf der Tahoma Basisstation der sogenannte "Developer Mode" aktiviert werden.

Man installiert den Switch wie in der Anleitung beschrieben und registriert sich bei Somfy (ohne geht es nicht, da für die Nutzung der API Daten mit Somfy ausgetauscht werden müssen).

Loggt man sich anschließend in seinen Account ein, sollte die Box unter "Produkte" erscheinen und aktiv sein (sonst bitte nochmal die Installationsschritte prüfen).

Unter dem Link "Tahoma/Connexoon bedienen" findet man nun die Möglichkeit den Developermode zu aktivieren. Sobald dieser aktiviert wurde sollte das Ergebnis wie folgt aussehen:

Den PIN-Code, der angezeigt wird kopiert man, da dieser später noch benötigt wird. Wird die Möglichkeit zum Aktivieren des Entwicklermodus nicht angezeigt, dann ist ein Gerät nicht für die folgenden Schritte geeignet (z.B. Connexoon-Box, Connectivity Kit). Mit Aktivierung des Developer Modes wird der Zugriff auf die API freigeschaltet.

Session ID erzeugen

Alle Schritte für das Generieren und das Ansprechen der Befehle sind von den Entwicklern in der Doku Somfy Tahoma Developer Mode beschrieben. Da dies aber für den Laien echt kryptisch klingt, erkläre ich die wichtigen Schritte detailliert in den folgenden Absätzen.

Für die nächsten Schritte empfehle ich, das Tool Postman zu verwenden, da die Kommunikation auch über POST-Befehle erfolgt und ein normaler Browser diese nicht unterstützt. Natürlich kann man das Ganze auch über curl machen, aber ich finde Postman einfacher. Im Prinzip braucht man nur die freie Version vom Postman zu installieren, d.h. eine Registrierung ist nicht erforderlich.

Zuerst muss eine Session ID erzeugt werden, die die aktive Kommunikation mit der Somfy API authentifiziert.

Hierzu wählt man in Postman in der oberen Zeile den Befehl "POST" aus (das kann man leicht vergessen und dann gibt es schnell einen Fehler, wenn da noch GET drinsteht) und gibt im nachfolgenden Feld die folgende Adresse ein:

https://ha101-1.overkiz.com/enduser-mobile-web/enduserAPI/login

Nun müssen noch die folgenden Parameter in den Reitern unterhalb der Adresszeile ergänzt werden:

Nach dem Drücken auf "Send" sollte als Ergebnis folgendes erscheinen:

Wichtig ist dass irgendwo "sucess: true" steht und im Bereiche Cookies ein Cookie Code verfügbar ist. Diese Session ID ist erforderlich, um im nächsten Schritt einen dauerhaften Token anzulegen, mit dem man zukünftig alle Befehle authentifizieren kann. Der Vorteil von Postman ist, dass er diesen Cookie mit der Session ID "behält" und automatisch für die folgenden Befehle verwendet.

Token erzeugen

Die Kommunikation mit der API erfordert grundsätzlich eine Authentifizierung. Dazu muss ein Token generiert werden, der zukünftig bei jedem Befehl an die Tahoma Box mitgesendet wird. Auch hierzu braucht man nun Postman.

Dazu wird zuerst GET Befehl mit der folgenden Syntax benötigt:

https://ha101-1.overkiz.com/enduser-mobile-web/enduserAPI/config//local/tokens/generate

ist dabei die PIN des Gateways, die man wie oben beschreiben unter den Geräteinformation des Tahoma Switch findet. Der Befehl lautet dann beispielsweise:

https://ha101-1.overkiz.com/enduser-mobile-web/enduserAPI/config/2031-1587-1994/local/tokens/generate

Auch hier gibt man nun in Postman folgende Parameter an:

Weitere Angaben müssen nicht gemacht werden, da die Authentifizierung über die im vorigen Abschnitt generierte Session ID erfolgt. Nun kann der Befehl wieder per "Send" ausgeführt werden.

Tipp: Wenn der Fehler "" erscheint, dann ist aus irgendeinem Grund die SessionID abgelaufen. Hier hilft es, einfach den Befehl aus dem vorigen Abschnitt nochmal aufzurufen (einfach in Postman den Reiter wechseln und wieder auf SEND drücken) und schon sollte es wieder funktionen. D.h. die Befehle zur Erzeugung der Session ID sowie des Tokens sollten zeitlich nicht zu weit auseinander liegen.

Als Ergebnis sollte man einen 20-stelligen alphanumerischen Tokenwert erhalten, den man zur weiteren Verwendung kopiert (siehe Bild).

Token aktivieren

Um den Token nutzen zu können, muss er noch aktiviert werden. Dies wird wieder durch einen POST Befehl im folgenden Format erreicht:

https://ha101-1.overkiz.com/enduser-mobile-web/enduserAPI/config//local/tokens

ist dabei wieder die PIN des Gateways, der Befehl lautet dann beispielsweise:

https://ha101-1.overkiz.com/enduser-mobile-web/enduserAPI/config/2031-1587-1994/local/tokens

Hier gibt man nun folgende Parameter an:

Nach dem Absenden des Befehls erhält man eine RequestID als Bestätigung, die angibt, dass der Befehl an die API erfolgreich versendet wurde (und gleich abgearbeitet wird).

Nun sind alle Voraussetzungen geschaffen, um die API zu nutzen.

Parameter zur Steuerung identifizieren

Welche Parameter (in diesem Fall eine Markise) ein Somfy Gerät besitzt und auf welche Befehle es reagiert, lässt sich nun einfach herausfinden. Dazu braucht man  nur die Devices im Tahoma Switch abzufragen (ähnliche wie bei einer CCU mit DevConfig) und sich die gelieferten Daten anzuschauen. Hierzu kann man wieder Postman verwenden oder die folgende interaktive Somfy Developer Webseite benutzen, die auf die lokale API zugreift:

https://somfy-developer.github.io/Somfy-TaHoma-Developer-Mode/#/Api/get_apiVersion

Dort trägt man oben als erstes die Geräte-PIN ein, der Port bleibt auf 8443 stehen. Durch Klicken auf den grünen "Auhorize-Button", kann man den vorhin generierten Token angeben.

Nun können die auf der Webseite dargestellten Funktionsaufrufe genutzt werden.

Unter der Rubrik "Setup" findet man den Befehl "GET /setup/devices". Dieser wird ausgeführt und als  Ergebnis erhält man eine riesige JSON-Datei mit allen Geräten, Paramatern, Befehlen und Namen der Devices, die über die Tahoma Box ansprechbar sind.

Aus der Datei habe ich die folgende Zeile heruasgesucht (sie enthält auch die bekannte Switch Adresse), die wie im folgenden Beispiel aussieht:

"deviceURL": "io://2031-1587-1994/4637294"

Dies ist die Adresse, unter der meine Markise intern angesprochen werden kann. Jeder Geräteblock in dieser Datei beginnt mit einer solchen deviceURL.

Tipp: Wer mehrere Geräte über eine Tahoma Box angeschlossen hat, sollte diesen Geräten über die Somfy App einen aussagekräftigen Namen geben, denn dieser Name taucht immer kurz nach der deiveURL auf. So kann man sicher sein, dass man das richtige Gerät erwischt hat.

Ebenso brauche ich den Namen des Geräte, der in einer weiteren Zeile zu finden ist:

"label": "Markise SUNEA"

Scrollt man weiter runter, findet man irgendwann auch eine Zeile, die mit "commands" beginnt. Hier sind nun alle Commands aufgeführt, auf das ein Somfy Gerät reagiert. In meinem Fall brauche ich nur den Befehlsnamen (CommandName) "open".

Markise über Postman steuern

Ich habe jetzt alle Parameter zusammen, um meine Markise über Postman mit einem Befehl an die Somfy API ausfahren zu lassen. Die Befehlssyntax hierzu lautet:

PUT https://gateway-.local:8443/enduser-mobile-web/1/enduserAPI/exec/apply

In meinem Fall lautet der Befehl wie folgt:

https://gateway-2031-1587-1994.local:8443/enduser-mobile-web/1/enduserAPI/exec/apply

Folgende Parameter werden angegeben:

Nach dem Absenden erhält man wieder eine "execID" und die Markise fährt aus.

Befehl über Node-RED ausführen

Den gleichen Befehl wie für Postman kann man auch über Node-RED ausführen lassen. Dort kann ich dann auch andere System einbinden und die Markise auf z.B. den Tastendruck eines Schalters reagieren lassen.

Ein einfacher Flow zum Ausfahren der Markise ist in folgendem Bild dargstellt:

Ich verwende in dem Beispiel einen Input Node. Dieser muss als JSON-Objekt konfiguriert werden, da er den RAW-Text für den Body des PUT Befehls erzeugt.

Der http Request Node wird wie folgt konfiguiert:

Wichtig hierbei ist, dass im Gegensatz zum Postman-Beispiel in der Zieladresse das ".local" weggelassen wird. Bei der TLS-Konfiguration gibt es nichts besonderes zu beachten.

Dieses Beispiel kann nun beliebig erweitert werden. Ich frage hierüber bereits den Status der Markise ab, steuere diese über einen HMIP-Schalter und lasse sie einfahren, wenn es anfängt zu regnen oder der Wind zu stark ist.

Einbrüche und Diebstahl in und aus Gartenhäusern und Wohnmobilen sind ein großes Ärgernis. Die Überwachung mit Bewegungsmeldern wird dann problematisch, wenn eine Übertragungsstandard wie z.B. WLAN aufgrund der Entfernung nicht verfügbar ist. Daher stelle ich auf der Basis von LoRaWAN eine einfache Lösung vor, die kaum Strom braucht und geografisch sehr flexibel ist. Grundinformationen zu LoRaWAN habe ich bereits im Artikel LoRaWAN mit eigenem Gateway einrichten veröffentlicht.

Hardware

Um einen Bewegungsmelder mit LoRaWAN zu realisieren habe ich das von ELV angebotene  ELV-Modulsystem für LoRaWAN verwendet (Loris). Mit diesem System kann man sehr flexibel Komponenten für einen Sensor oder Aktor, der über LoRaWAN kommunizieren soll, zusammenstecken. Dies funktioniert i.d.R. sogar, ohne irgendeinen Lötkolben in die Hand nehmen zu müssen.

Als Basis ist immer eine LoRIS-Base ELV-BM-TRX1 erforderlich, über die die Kommunikation per LoRaWAN erfolgt. Die LoRIS-Base besitzt einen USB-C Anschluss zur Verbindung mit einem PC oder einer externen Spannungsversorgung.

Zusätzlich benötigt man das ELV-PIR1 Modul welches aus einem Bewegungsmelder und eine Helligkeitssensor besteht. Ebenso besitzt das Modul einen Opencollector-Ausgang, über den man mittels eines Relais auch andere Geräte schalten könnte. Ich benutze das in meinem Beispiel allerdings nicht.

Zur Stromversorgung verwende ich zusätzlich noch das ELV Powermodul LR03, in das man eine AAA-Micro Zelle einlegen kann. Bekanntermaßen braucht LoRaWAN zur Kommunikation unglaublich wenig Strom, so dass mit einer Batterie das Gerät bis zu mehrere Jahre laufen kann. Alternativ sind auch andere Module für die Stromversorgung mit mehr Kapazität verfügbar (inkl. Solarmodul, etc.).

Als Gehäuse kann man das ELV-MH0101a verwenden. In meiner Umsetzung habe ich ein eigenes Gehäuse entworfen und mit dem 3D-Drucker passgenau gedruckt.

Softwareinstallation

Die LoRIS-Base wird immer mit einer Standardfirmware ausgeliefert, die die Funktionen des Moduls wie z.B. einfache Schalter unterstützt. Um den Bewegungsmelder zu unterstützen, muss eine andere Firmware aufgespielt werden.

Auf der Produktseite des PIR1-Moduls im ELV-Shop befindet sich die Firmware, die man sich von dort runterlädt. Die Firmwaredatei hat eine .hex-Endung und befindet sich in einem ZIP-Archiv.

https://de.elv.com/elv-pir1-applikationsmodul-pir-bewegungsmelder-elv-am-pir1-158570?fs=185688875

Das Flashen erfolgt über das ELV-Base Flasher Tool. Dieses befindet sich in einem ZIP-Archiv im Downloadbereich der LoRIS-Base unter

https://de.elv.com/elv-lw-base-experimentierplattform-fuer-lorawan-elv-bm-trx1-156514

Vor der Benutzung empfehle ich, die PDF-Anleitung in diesem ZIP-Archiv zu lesen.

Die Installation des Flasher Tools erfolgt als Administrator. Anschließend wird das Tool aufgerufen.

Das eigentlichen Flashen mit dem Tool ist hervorragend in der beiliegenden PDF-Anleitung beschrieben. Als Firmwaredatei wird die soeben für das ELV-PIR1 heruntergeladene .hex-Datei angewählt.

Nachdem mit dem grünen Haken der erfolgreiche Flashvorgang bestätigt wurde kann das Tool beendet werden.

Hardware zusammenstecken.

Nun kann man die Module zusammenstecken.

Unten befindet sich die Loris-Base, darauf wird das Powermodul mit der Batterie gesteckt und oben wird das PIR-Modul aufgesteckt. Alles zusammen schiebe ich anschließend in ein Gehäuse. Hat man das ELV-Gehäuse gekauft, dann muss mit einem Stufenbohrer eine ca. 13mm große Öffnung gebohrt werden, so dass der obere Teil des Sensors aus dem Gehäuse herausragt. Ich habe mit das Gehäuse allerdings passend mit einer Öffnung sowie einer Öse (zum Befestigen mit einer Schraube) passend gedruckt.

Payload decodieren

Der Sensor wird nun als neue Applikation im TTN-Netz eingerichtet. Ich verweise hierzu auf meine Artikel Füllstandsmessung mit LoRaWAN, in dem die Einrichtung erklärt wird.

Anschließend kann man den Payload Parser von der ELV-Seite Seite des PIR Moduls im Downloadbereich kopiereren und im Application Modul unter „Payload Formatters/Uplink“ eingefügen.

Die Daten werden dann korrekt interpretiert. Diese kann man sich über den Menüpunkt Livedata anschauen. Damit man diese versteht gebe ich folgende Hinweise:

Die Payload unterscheidet grundsätzlich zwei Zustände, die in der TX_Reason ausgegeben werden. In Abhängigkeit davon werden auch unterschiedliche Bytezahlen zurückgegeben.

D.h. wenn der Input Event als Active ausgegeben wird, wurde eine Bewegung erkannt und man kann reagiren.

Konfigurationswerte ändern

Der Sensor hat eine Vielzahl von Konfigurationswerten, die in der Anleitung zum Sensor beschrieben sind. Hierzu wird ein Bytefolge aus insgesamt 8 Bytes gebildet, die immer komplett an das Gerät geschickt werden müssen.

Da ich möglichst viel Strom sparen möchte, schalte ich den Lichtsensor aus und lasse mir maximal einmal pro Stunde eine Nachricht schicken (wenn keine Bewegung erkannt wurde). Hierzu verwende ich folgende Bytefolge:

Hieraus ergibt sich die Bytefolge

0C 3C 19 22 10 02 85 85

Wer alles wieder zurücksetzen möchte kann die folgende Bytefolge verwenden:

0C 05 19 22 18 02 85 85

Die Bytefolge gibt man in "Applications /End Device / Messaging / Downlink" ein. Im Feld FPort wird Kanal 10 als Kommunikationskanal eingetragen und in "Payload" die Bytefolge.

Zur Bestätigung kann noch das Confirm-Häkchen gesetzt werden.

WICHTIG: Damit die Befehle vom TRX1 empfangen werden muss auf der Platine (am Rand) unbedingt der "User-Button" kurz gedrückt werden. Erst dann wird die Konfiguration durchgeführt.

Abfragen der Daten in Node-Red

Auch hierzu verweise ich  auf meine Anleitung Füllstandsmessung mit LoRaWAN insbesondere die Kapitel "Daten an MQTT-Server senden" sowie "Daten mit NodeRed verarbeiten". Zu diesem Zweck wird unter "Integrations/MQTT" für die Application ein neuer Nutzer angelegt sowie ein neuer API-Key vergeben. Dies sind die Accountdaten, um nachher in Node-Red die Werte abzufragen.

Mit dem MQTT-Explorer kann man diese Daten vorab auch auf dem MQTT-Server von TTN selber kontrollieren.

ACHTUNG: Wenn man in Node-Red bereits einen LoRaWAN-Sensor eingerichtet hat, dann muss man für diesen Sensor wieder eine neuen Server im MQTT-In Node einrichten, da man ja neue Accountdaten für diesen Sensor angelegt hat.

Unter Node-Red werden die Daten dann über folgende Funktion vom MQTT-Server ausgelesen und weiterverarbeitet.

Die Daten kann man nun für Alarmmeldungen z.B. über Nachrichtendienste verwerten.

Die mechanischen Zeitschaltuhren mit ihrem Drehrad waren lange Jahre das einzige Mittel, zuhause Lampen zeitgesteuert einzuschalten. Damit wurde dann in Abwesenheit vorgetäuscht, dass das Haus bewohnt ist. Mit Smarthome wird diese Funktion bereits mit vielen fertigen App-Lösungen angeboten. Für mich stellt sich die Frage, wie man so etwas übergeordnet und damit unabhängig von den meisten Smarthome-Zentralen und ihren App-Lösungen realisieren  und damit beliebige Geräte steuern kann.

Als Plattform habe ich Node-Red gewählt.

Zufallszahlen erzeugen

Für meine Umsetzung tue ich so, als ob ich nur eine Lampe schalten möchte. Die folgenden Werte dienen zur Demonstration und können natürlich frei verändert werden. Ich benötige folgende zufällig erzeugten Werte in einem vorgegebenen Intervall [min;max]):

1. Dauer: Wie lange soll das Licht anbleiben (ich gebe den Bereich von 1 bis 30 Minuten vor (Intervall [1;60])
2. Startdauer: Um wieviel Minuten ab jetzt verzögert soll ein Licht erst angehen. (auch hier soll der Start von 1 bis 15 Minuten in der Zukunft liegen, (Intervall [1;60])

Um diese Zufallswerte zu erzeugen braucht man einen Zufallsgenerator. Unter Node-Red wird dies mit der Math.random()-Funktion erreicht, die eine zufällige rationale Zahl von 0 bis kleiner 1 erzeugt.

Um hieraus eine Zahl für das gewünschte Intervall zu erzeugen, verwendet man folgende Formel:

(Math.random() * (max - min + 1)) + min

Damit wird gewährleistet, dass die Zufallszahl immer beim min-Wert beginnt und auch den max-Wert berücksichtigt.
Als Ergebnis kommt eine rationale Zahl heraus, die ich aber noch in eine ganze Zahl umwandeln muss.
Hierzu verweise ich auf den Artikel in selfhtml, in dem verdeutlicht wird, warum zum Runden die Math.floor()-Funktion besser geeignet ist, als die Math.round()-Funktion.

Daraus ergibt sich die Formel

Zufallswert = Math.floor((Math.random() * (max - min + 1)) + min)

und somit die Berechnungsformeln für die zwei Werte oben.

Flow Variablen verwenden

Die oben ermittelten Zufallswerte muss man in Node-Red Variabeln zwischenspeichern, um auf sie zurückgreifen zu können. Ich benötige daher sogenannte Flow-Variabeln, die ich aus jeden Knoten in dem Flow abrufen kann. Mit dem Befehl

var vara=flow.get('f_vara') || 0;

wird der Wert der flow-Variabel 'f_count' der lokalen Variabel 'vara' zugewiesen. Sollte 'f_count' nicht existieren, dann wird automatisch der Wert 0 (Null) der lokalen Variabeln 'vara' zugewiesen.

Mit dem Befehl

flow.set('f_vara',vara);

wird der Flow-Variabeln 'f_vara' wieder der Wert der lokalen Variabeln 'vara' zugewiesen. Über diesen Weg lassen sich alle Variebeln für den Flow sauber initialisieren.

Für den Node-Red Flow verwende ich folgende Flow Variabeln:

• f_startzeit (hierin steht die Startzeit zu der das Licht angehen soll)
• f_stopzeit (dies ist die Stopzeit, zu der das Licht wieder ausgehen soll)
• f_dauer (dies ist die Zeitspanne, die das Licht anbleiben soll in Minuten)
• f_verzoegerung (dies ist die Zeitspanne, bevor das Licht eingeschaltet werden soll in Minuten)

Node-Red Flow

Ich verzichte explizit auf eine Timer Funktion, da dann wieder eine Bibliothek eingebunden werden müsste. In dem Beispiel habe ich nur angedeutet, wo eigene Aktoren eingebunden werden können, wenn man das Beispiel verwenden möchte.

Aus den ganzen Überlegungen ist der folgende Flow entstanden:

Der Code hierzu lautet wie folgt:

Flow Erläuterungen

Die Inhalte der Nodes erfüllen folgende Aufgaben:

Abschluss

Ich habe an einigen Stellen natürlich mehr Code als notwendig ergänzt, da das Ganze dann auch für den Laien lesbarer ist.

Der Flow kann beliebig erweitert und umgebaut werden.

Denkbar ist z.B. die Einschränkung auf den Zeitbereich zwischen Sonnenunter- und Sonnenaufgang. Darüber hinaus würde ich die Schaltung zufällig n-Mal wiederholen. Ebenso könnte man das Ganze für mehrere Lampen anpassen und diese abhängig voneinander schalten lassen.