Smart Home mit Shelly, JSON und Node Red: Leitfaden zur Installation und Programmierung

Smart Home ist ein so interessantes Thema, und gerade mit den diversen Geräten von Shelly, NOUS oder Homematic IP ist es einfach, seine Wohnung oder das Haus smart zu machen. Ich nutze aktuell hauptsächlich die Produkte von Shelly. Mit der zweiten oder dritten Generation hat sich das einfache MQTT-Protokoll stark verändert. Einfache Kommandos gehören der Vergangenheit an. Mittlerweile verwenden die Shellys das JSON-Format für ihre Nachrichten.

In meinem Smart-Home habe ich selbst erstellte Smart-Touch-Displays, mit denen ich den Status einsehen und ändern kann. Das JSON-Format unterstützt meine Programmierung aber nicht, sondern nur einfache Topics. Damit ich keinen großen Programmieraufwand habe, aber dennoch die neueren Generationen der Shellys verwenden kann, nutze ich Node Red. Was Node Red ist, was es kann und wie ich wieder einfache MQTT-Topics zum Steuern neuerer Shellys verwende, möchte ich dir in diesem Blogpost zeigen.

Mein Name ist Jörn, ich bin leidenschaftlicher Maker und bin viel in Linux, Arduino, ESP32 und IoT unterwegs. Meine Erfahrung und Kenntnisse möchte ich dir weitervermitteln.

JSON und Node Red

Bevor ich in die Praxis einsteige, möchte ich einmal kurz erklären, worum es sich bei dem JSON-Format handelt und was Node Red ist. Beides ist wichtig, damit später die Programmierung von Node Red klar wird.

Das JSON-Format

Wer in der IT oder als Programmierer unterwegs ist, der wird das JSON-Format oder auch das XML-Format kennen. Beides sind Arten, um Daten leserlich dem User zu präsentieren, wobei auch das Programm oder System diese Daten einlesen oder bearbeiten kann. Das JSON-Format ist besonders interessant, weil man den vorhandenen JSON-Daten einfach weitere Daten hinzufügen oder sie manipulieren kann. Gerade in der Industrie habe ich es oft gesehen und verwendet, um einen schnellen Datenaustausch zu gewährleisten. Dabei können die JSON-Daten simpel, aber auch komplex aufgebaut werden.

Code 1 zeigt die Antwort auf den Status im JSON-Format bei einem Shelly der zweiten Generation.

{
  "id": 1,
  "src": "shellypro1-84cca87c1f90",
  "params": {
    "id": 0,
    "name": "name",
    "type": "switch",
    "enable": true,
    "invert": false
  }
}

Code 1: Antwort eines Shellys Gen 2 bei Abfrage des Status

Das Prinzip sollte bei diesem leicht leserlichen Format klar sein. Zunächst erhält man die ID und den SRC-Namen vom Gerät. Als Nächstes kommt ein weiteres Objekt mit dem Namen „params“, welches weitere Parameter mit einem Keyword und dem jeweiligen Datentyp aufweist. Das Objekt „params“ wird durch „: { }“ definiert, was wichtig beim korrekten Einlesen der Daten ist. Ohne große Kenntnisse sollte es ein Leichtes für dich gewesen sein, die Daten aus Code 1 zu lesen und zu interpretieren. Einen Blick ist der entsprechende Wikipedia-Artikel wert, der das JSON-Format noch einmal super erklärt und auch Parallelen zu XML zieht.

Node Red

Kommen wir nun zu der Frage, was genau Node Red ist. Node Red ist ein von IBM entwickeltes grafisches Entwicklungswerkzeug, das besonders in der Heimautomation und Automatisierung beliebt ist, weil es durch seine visuelle Programmieroberfläche leicht zu bedienen ist. Es ermöglicht das Zusammensetzen von Funktionsbausteinen mit Verbindern im Baukastenprinzip, die wiederum die Anweisungen enthalten.

Als Programmiersprache wird JavaScript für die Funktionen verwendet und die Laufzeitumgebung mit Node.js. Die Daten werden, daher auch die Einführung zu JSON, im JSON-Format gespeichert. Was bei Node Red interessant ist, ist die Tatsache, dass es mittlerweile viele Plugins gibt, die die Kommunikation mit verschiedenen Geräten oder auch Datenbanken ermöglichen und weitere Funktionen bereitstellen.

Erfreulich ist, dass Node Red alle gängigen IoT-Protokolle, ggf. über separate Plugins, beherrscht und durch die starke Community und Entwickler schnell auf Änderungen bei einzelnen Plugins eingegangen wird. Das wurde zum Beispiel deutlich, als Shelly die neue API für die Gen2 und Gen3 der Shellys vorgestellt und dokumentiert hat. Kurz danach wurden neue Plugins für die neuesten Shelly-Generationen angeboten.

Node Red kann auf fast allen gängigen Betriebssystemen installiert werden (siehe Node Red Dokumentation). Besonders interessant, gerade wenn man ältere Blogs von mir liest, ist die Möglichkeit, Node Red über Docker laufen zu lassen, was mittlerweile mein bevorzugter Weg ist. Da Node Red auch für die ARM-Architektur angeboten wird, ist es kein Wunder, dass auch ein Docker-Image für ARM und somit für die Verwendung mit dem Raspberry Pi verfügbar ist. Wer mehr über Node Red erfahren möchte, kann sich gerne den entsprechenden Wikipedia-Artikel ansehen. Bei weiterem Interesse kann ich nur das Fachbuch eines bekannten Fachverlages für Bücher, E-Books und Videokurse zu IT-, Kreativ- und Marketingthemen mit Sitz in Bonn empfehlen.

Node Red Installation

Wie bereits erwähnt und in meinem Blogartikel zur Einführung zu Docker vermuten lässt, nutze ich natürlich bevorzugt die Installation via Docker über Portainer. Da ich auf Docker Hub und auch auf der Node Red Installationsseite mich eingelesen hatte, weiß ich, dass ein Mount zu dem Pfad /data vom Container benötigt wird. Dies realisiere ich nicht wie sonst mit einem Bind, sondern mit einem Volume, welches ich zunächst anlegen muss, siehe Abbildung 1.

Abbildung 1: Volume anlegen

Im nächsten Dialog muss ein Name für das Volume vergeben werden, und über den „Create the volume“-Button wird das Volume dann erstellt, siehe Abbildung 2.

Abbildung 2: Volume Namen geben und erstellen

Als Nächstes erstellen wir den Docker-Container mit allen nötigen Einstellungen. Dazu wird zunächst in die „Container“-Übersicht gewechselt und über den Button oben rechts ein neuer Container angelegt, siehe Abbildung 3.

Abbildung 3: Neuen Container erstellen

Im Folgenden, da in meinem Basis-Blog zu Docker schon ausführlich beschrieben, die Konfiguration für Node Red:

• Unter „Name“ einen Namen für den Container vergeben
• Bei Image ist nodered/node-red:latest einzutragen
• Einen neuen Netzwerkport anlegen
• Host: Port der bei euch frei ist, ich empfehle hier 1880
• Container: 1880, dies ist der Port der vom Container verwendet wird
• Unter Volumes eine neue Map erstellen
• Typ: Volume
• Container: /data (dieser Pfad ist fix!)
• Host: Das zuvor erstellte Volume

Danach kann der Container deployed werden, siehe Abbildung 4, wobei das dauern kann, da das Image zuvor heruntergeladen werden muss.

Abbildung 4: Alle Einstellungen vorgenommen, Container deployen

Sobald der Container gestartet wurde, kannst du Node Red im Webbrowser über die Adresse http://<IP-VOM-DEVICE>:1880 starten, siehe Abbildung 5.

Abbildung 5: Erster Start von Node Red mit Hinweisen

Damit ist die Installation abgeschlossen und sofern du alle Schritte befolgt hast, sollten bei einem Neustart von deinem Container alle Flows und Add-ons weiterhin vorhanden sein.

Die Vorarbeit und der Flow

Die Vorarbeit

Da Node Red nun läuft und MQTT schon in der Basis-Installation von Node Red enthalten ist, fehlt nur noch das Add-on, um mit den neueren Generationen von Shelly zu kommunizieren. Also muss zunächst unter dem Menüpunkt Palette, siehe Abbildung 6, ein Shelly Add-on nachinstalliert werden.

Abbildung 6: Palettenverwaltung öffnen

Unter dem Punkt Palette im Reiter Installation suchst du nach „Shelly“ und findest dort in den Suchergebnissen unter anderem das benötigte Add-on „node-red-contrib-shelly“, welches du über den Button Installieren installierst, siehe Abbildung 7.

Abbildung 7: Shelly Add-on installieren

Im Anschluss kommt noch einmal ein Dialog mit allen nötigen Informationen vor der Installation, siehe Abbildung 8.

Abbildung 8: Die Installation bestätigen

Der Flow (Code)

Jetzt kommt der Teil mit der „Programmierung“, die je nach Aufgabe in Node Red mal mehr mal weniger einfach ist. An dieser Stelle werde ich grob auf den Flow eingehen, damit verständlich ist, was da passiert. Später hänge ich den Code an und gebe Hinweise, wo Anpassungen vorgenommen werden müssen. Zunächst erst einmal der Flow, siehe Abbildung 9, beispielhaft von meinem Küchenlicht.

Abbildung 9: Der komplette Flow für die Küchenleuchte

Der obere Verlauf, beginnend mit dem blauen „Shelly Küche“, prüft in einem Intervall von einer Sekunde, ob sich etwas verändert hat. Gerade wenn der Node Red komplett neu gestartet wird, muss vorher eine Variable für den Flow, also das Arbeitsblatt, angelegt werden. An dieser Stelle können die grünen Kästchen ignoriert werden. Diese dienen zum Debuggen und geben die Raw-Daten in einer Debugkonsole aus. Das Prinzip hinter dem ersten Strang ist: Der aktuelle Status wird abgefragt und mit dem zuletzt gespeicherten verglichen. Sollte es einen Unterschied geben, wird zum einen die MQTT-Message mit dem neuen Status versendet und gleichzeitig auch der aktuelle Wert geändert.

Die zweite Reihe, rosa Kasten unterhalb vom blauen „Shelly Küche“, lauscht auf eingehende Topics, die für diese Funktion relevant sind. In diesem Fall ist es ein Kommando, den Status der Lampe zu verändern. Je nachdem, ob „on“ oder „off“ in dem Topic steht, wird eine entsprechende JSON-Nachricht generiert und mit dem neuen Kommando versehen. Anschließend wird dieser JSON-String dann an den Shelly übermittelt (blauer Kasten rechts unten). In der Theorie braucht es den zweiten Shelly-Baustein bei der unteren Reihe nicht. Der Übersicht und dem Verständnis halber habe ich ihn trotzdem eingebaut.

Was muss nun genau umkonfiguriert werden? Im Wesentlichen nur die Bausteine für den Shelly, einige Bausteine, welche globale Variablen lesen und schreiben, und die MQTT-Knoten.

Den Anfang sollen die Shelly-Bausteine machen, siehe Abbildung 10, bei dem die IP-Adresse sowie die Beschreibung geändert werden müssen. Sollte der Shelly mit einem Passwort geschützt sein, so ist dieses auch entsprechend einzutragen. Bei einem Shelly-Baustein ist der Modus auf Polling gestellt. Über „Zeit in ms“ kann das Abfrageintervall angepasst werden. In meinen Augen sind 1 Sekunde (1000 ms) ausreichend, kann aber auch niedriger gesetzt werden.

Abbildung 10: Den Shelly-Baustein umkonfigurieren

Jetzt geht es weiter mit den drei MQTT-Knoten. Da ein MQTT-Broker verwendet wird, muss dieser entsprechend korrekt eingestellt werden. Um die IP und ggf. Anmeldedaten für MQTT zu ändern, muss z.B. der Baustein unten rechts geöffnet werden und über den Stift neben dem hinterlegten Server der Dialog zum Broker geöffnet werden, siehe Abbildung 11.

Abbildung 11: Öffne MQTT-Server Einstellungen

Im nachfolgenden Dialog kannst du nun die IP-Adresse und den Port (roter Rahmen) anpassen sowie Anmeldedaten für die Verbindung korrigieren (gelber Rahmen). Natürlich ist es dir überlassen, welche weiteren Einstellungen du in Verbindung mit dem Broker anpassen möchtest, siehe Abbildung 12.

Abbildung 12: Die MQTT-Broker-Einstellungen anpassen

Da dieser MQTT-Broker global für alle Knoten gilt, muss dies auch nur einmal mit dem Button „Aktualisieren“ geändert werden. Nachfolgend nutzen alle MQTT-Bausteine die neuen Broker-Einstellungen. Als Nächstes müssen noch die Topics für Empfangen und Senden angepasst werden. Bei beiden MQTT-Nodes gibt es ein Feld mit „Topic“, siehe Abbildung 11, das besagt, auf welchen Topic der Baustein hören oder senden soll. Der MQTT-Baustein unten links ist für den Empfang eines Kommandos zuständig und fragt den Status „on“ oder „off“ im weiteren Verlauf ab. Hier muss also das Topic für den neuen Status von einem MQTT-Gerät via MQTT-Broker eingetragen werden!

Bei dem MQTT-Knoten rechts oben muss hingegen das Topic mit dem aktuellen Status eingetragen werden. Damit wissen im MQTT-Netz alle interessierten MQTT-Clients den neuen Status und können darauf reagieren. Der letzte Teil befasst sich mit der Anpassung der für den kompletten Flow zugänglichen Variablen, welche sich in drei Change-Bausteinen, siehe Abbildung 13, befinden.

Abbildung 13: Die Bausteine der Flow-Variable

In allen drei Bausteinen gibt es ein Teil, das mit „flow.“ beginnt, siehe Abbildung 14. Diese Variable muss für dein Projekt oder bei mehreren Flows angepasst werden. Wichtig an dieser Stelle ist, dass in allen drei Bausteinen derselbe Variablenname verwendet wird, siehe Abbildung 14.

Abbildung 14: Die Variable umbenennen

Damit ist der Flow vollständig, und du kannst über die Schaltfläche „Übernehmen“, siehe Abbildung 11 oben rechts, deinen Flow starten. Damit kann der Shelly ab der zweiten Generation nun wieder über ein einfaches Statuskommando eingestellt und auch ausgelesen werden.

Zusammenfassung

Der Einbau der Shellys ist nicht kompliziert. Das habe ich schon in einem anderen Blogbeitrag geschrieben, siehe Blogbeitrag. Da es zu lange dauern würde, den Flow nachzubauen, habe ich im Berrybase-Repo NodeRedShelly angelegt, damit der Nachbau über den Import einfacher ist. Für den ganzen Aufbau sind Docker mit Node Red und MQTT nötig. Danach kann über jeden MQTT-Client mittels einfachem Statuskommando der Shelly geschaltet werden. Mittels einer Heimautomationsoberfläche, wie OpenHAB, die mit dem MQTT-Broker kommuniziert, kann die Heimautomation weiter erweitert werden.

An dieser Stelle sei gesagt: Ich bin kein Experte mit JavaScript und Node Red, daher ist wahrscheinlich noch Luft nach oben bei der Programmierung.