Smart Gemeindehaus II – Verbindungen schaffen

Nachdem Mosquitto, NodeRed und Zigbee2mqtt nun auf dem Raspberry Pi installiert sind, müssen die drei nun zusammenarbeiten. Das ist dank guter Vorarbeit gar nicht so schwer. Trotzdem lohnt es sich, sich ein wenig in die Arbeitsweise der Tools, vor allem NodeRed, einzuarbeiten. Ich habe das mit dem Sonderheft NodeRed von der Make gemacht. Aber es gibt auch viele gute YouTube-Videos und Blogartikel dazu.

Die groben Basics setze ich einfach mal voraus, ansonsten würde das den Rahmen sprengen. Ebenso ist die Voraussetzung, dass ihr Zugriff auf die Weboberflächen von NodeRed (http://deine-Adresse: 1880) und Zigbee2mqtt (http://deine_IP-Adresse: 8080) habt. Jetzt aber zum Thema. Ich beginne in der physischen Welt und gehe immer weiter Richtung Software und Programmierung.

Zigbee-Geräte in Zigbee2mqtt einbinden

Zu Beginn legst du dir deine Zigbee-Geräte (Sensoren, Thermostate, Steckdosen, Lampen, etc. Eine kleine Kaufberatung am Ende des Artikels) zurecht und überlegst dir, wo was hin soll. Hierbei ist zu beachten, dass Zigbee nicht die reichweitenstärkste Funktechnologie ist. Aber durch geschickten Einsatz von Routern (in der Regel Zigbee-Steckdosen und -Lampen, mit Wlan-Routern hat das nichts zu tun) kann dieses Manko ausgeglichen werden. Durch die Mesh-Archtektur und ihre Router können weitere Strecken und komplexere Räumlichkeiten mit Zigbee versorgt werden. Ebenfalls hilfreich ist eine gute Dokumentation von Anfang an, den ansonsten fragt man sich später welcher Sensor wo liegt, oder welches Thermostat eigentlich gerade neue Batterien braucht. In meinem Kirchgebäude und auch zu Hause habe ich einen Teil des Problems mit per wasserfestem Stift angebrachten Zahlen auf und im Gehäuse der einzelnen Geräte und der entsprechenden Benennung in Zigbee2mqtt gelöst. Zu Hause kommt dann noch eine Zuordnung zu den Räumen dazu: Mein Themperatursensor im Bad heißt temp1 das Themostat dort heißt thermostat 1, der Fenstersensor fenster1. In der Küche dann entsprechend temp2, thermostat2, fenster2. Das funktioniert aber in großen Räumen in Kirchgebäuden nicht. Im Kirchraum möchte man mit Sicherheit einen Temperatursensor in Sitznähe, aber auch einen an oder in der Orgel haben, in einem Saal wird es weit mehr al eine Heizung mit Thermostat geben u.s.w. Hier bietet sich dann entweder ein Grundriss oder eben eine gut geführte Liste mit genauen Ortsangaben an. Beim Überblick (zumindest innerhalb von Zigbee2mqtt) hilft auch eine optionale Beschreibung, die ihr mit der blauen Schaltfläche hinzufügen könnt. Diese Beschreibung taucht dann unter dem vergebenen Gerätenamen (s.u.) in grau auf.

Um die Geräte mit Zigbee2mqtt zu verbinden, muss man zuerst das „Anlernen aktivieren“ und im Zeitraum der nächsten Minuten eine Verbindung herstellen. Wie genau ihr die einzelnen Geräte in den Pairingmodus versetzt, sagt euch entweder die Anleitung oder die Gerätedatenbank auf zigbee2mqtt.io. Bei manchen ist es ein Resetknopf oder ein Loch für eine aufgebogene Büroklammer, bei anderen ein Menüpunkt, und bei wieder anderen (bspw. IKEA-Lampen) das mehrmalige Ein- und Ausschalten in einem bestimmten Rhytmus.

Habt ihr den Pairingmodus aktiviert sollte Zigbee2mqtt euer Gerät erkennen und versuchen ein Interview zu führen. Bei einigen Geräten habe ich zwei Versuche gebraucht, bis das Interview erfolgreich war. Danach taucht das Gerät mit ein paar Informatinen in eurer Zigbee2mqtt-Weboberfläche auf. Der Name ist allerdings nur die UUID des Gerätes, den du in einen Friedlyname bzw. Gerätenamen mit der blauen Bearbeiten-Schaltfläche entsprechend deinen Wünschen und deinem Ordnungssystem umbenennen kannst und solltest. Den Gerätenamen brauchen wir nämlich gleich, wenn es an die Verbindung zu NodeRed geht.

Es kann immer mal wieder passieren, dass Geräte schon in der Zigbee2mqtt-Gerätedatenbank auftauchen, aber auf eurer Installation nicht erkannt werden. Auch aus diesem Grund ist ein Update hin und wieder nicht verkehrt. Das lässt sich auf der Kommandozeile recht einfach bewerkstelligen:

sudo systemctl stop zigbee2mqtt
cd /opt/zigbee2mqtt
cp -r data/ data.sicherung
./update.sh
# ggfs. danach noch ein: rm -r data && mv data.sicherung data
sudo systemctl start zigbee2mqtt

Wenn du nun deine Geräte alle in Zigbee2mqtt eingebunden hast und eigentlich alles per Hand steuern möchtest, dann bist du hier fertig und hättest dir Nodered sparen können. Im Dashboard hast du eine gute Übersicht über deine Geräte und deren Werte und kannst Aktoren auch entsprechend steuern. Aber: Wir haben eine Kirche oder ein Gemeindehaus vor uns und damit recht komplexe Situationen zu bewältigen und wir hätten kaum etwas gewonnen. Und für komplexe Situationen ist Nodered genau das richtige (wenn auch mit steiler Lernkurve).

Nodered startklar machen

Jetzt geht es ans Eingemachte. Nodered ist so etwas wie eine kleine Programmierumgebung, bei der man aber sehr wenig programmieren können muss. Das Meiste ist in vorgefertigten Blöcken (Nodes) da, die man nur konfigurieren und entsprechend des Ablaufs verbinden muss. Manche der Nodes muss man sich erst aus dem Fundus der Community herunterladen, andere sind standardmäßig installiert. Theoretisch kommen wir schon sehr weit mit der Grundinstallation, aber um uns einige Arbeit zu ersparen empfiehlt es sich, ein paar Erweiterungen einzubauen.
Um die sogenannte Palette zu erweitern öffnest du sie im Menü (rechte Seite oben) und klickst auf den Reiter „Installation“. Dort kann man direkt nach erfolgter Suche die gewünschten Nodes (bzw. Node-Pakete) installieren. Meine Empfehlung fürs Erste: node-red-contrib-zigbee2mqtt (eine einfache Verbindung zu den meisten zigbeee2mqtt-Geräten). Wenn ihr wie ich keine Außensensoren habt, könnt ihr euch mit node-red-contrib-dwd-local-weather an OpenData über den Deutschen Wetterdienst erfreuen. Bei der Arbeit mit der Palette und mit Paket-Namen aus Anleitungen muss man übrigens peinlich genau auf die Namen und Schreibweisen achten, denn es gibt Node-Pakete mit sehr ähnlichen Namen, die einen sehr anderen Funktionsumfang haben oder noch in den Kinderschuhen stecken.

Jetzt bauen wir mit unserem ersten Flow. Damit es übersichtlich bleibt, bietet Nodered oben eine Leiste mit Reitern von Flows an, die man beliebig erweitern und umbenennen kann. Da man die Flows mit den Nodes Link in und Link out verbinden kann, muss man sich keine Gedanken machen, ob dieser oder jener Node in diesem oder vielleicht doch einem anderen Flow auftauchen muss. Versucht es einfach auf Dauer übersichtlich zu halten. Für das allererste Erfolgserlebnis „programmieren“ wir uns zwei Nodes zusammen, mit denen wir einen Zeitstempel erzeugen und ihn in die Debug-Nachrichten senden. Debug = Fehler suchen/beseitigen. Wir ziehen einen Inject-Node auf unsere Arbeitsfläche und einen Debug-Node. Der Injekt-Node ändert seine Benennung in Timestamp, weil das seine Standard-Konfiguration ist. Wenn wir nun auf einen der Verbindungspunkte klicken und die gedrückte Maus ziehen und auf dem anderen Verbindungspunkt loslassen (er färbt sich orange, wenn man richtig ist), dann verbinden sich die beiden Nodes zu einem Flow. Herzlichen Glückwunsch. Allerdings ist bis jetzt noch nichts gespeichert und aktiv. Dazu muss noch der jetzt rot gewordene Deploy-Button betätigt werden. Um zu kontrollieren, ob alles richtig ist, öffne nun die rechte Seitenleiste (irgendwo in der Mitte ist ein Anfasser) und wähle oben den kleinen Käfer (Bug) aus. Wenn du jetzt auf den Button am linken Rand des Inject/Timestamp-Nodes klickst, sollte in den Debug-Nachrichten ein Zeitstempel (nach Unix-Art) auftauchen.

Erklärung: Du schickst mit den Klick also eine Nachricht (hier einen Zeitstempel) auf die Reise durch den Flow. Diese Nachricht (Message oder msg) enthält erst einmal nur den sogenannten Payload (~ die Nutzlast, Ladung). Dieser Payload wird über den Verbinder an einen anderen Node weitergeleitet (ggfs. verändert, gestoppt, verzögert,…) und kommt in unseren Fall bei einem anderen Node an, der den Payload in die Debug-Nachrichten schiebt. Mit einem Doppelklick auf den Inject/Timestamp-Node solltest du dir seine Konfiguration näher anschauen und ein bisschen rumspielen. Hier siehst du, dass nicht nur einen Zeitstempel verschickt werden kann, sondern auch verschiedene Datentypen und Variablen. Außerdem siehst du hier, dass eine Nachricht nicht nur aus dem Payload (msg.payload) besteht, sondern auch ein Topic (Thema, Gegenstand) haben kann, das sich dann msg.topic nennt. Gibst du der Nachricht ein Topic, dann taucht auch dieses in der Debug-Nachricht auf. Wie gesagt, hier jetzt erst einmal rumzuspielen, um die generelle Funktionsweise zu verstehen lohnt sich.

Natürlich müssen Nachrichten nicht immer von dir per Knopfdruck auf die Reise geschickt werden. In den allermeisten Fällen läuft das automatisch ab. Zum Beispiel sendet ein Temperatursensor seine Daten (an zigbee2mqtt, zigbee2mqtt sendet sie an den mqtt-Broker Mosquitto und dieser sendet sie dann weiter an alle, die diese Nachrichten abonniert haben, z.B. Nodered. Aber dazu gleich mehr) und diese Daten werden dann in Nodered empfangen und in eine Nachricht gepackt (msg.payload sind die Daten die empfangen wurden und msg.topic ist der Name des mqtt-Topics),

Nodered mit Zigbee2mqtt und mit mqtt und mit… verbinden

Die Grundvoraussetzungen für die Kommunikation zwischen Mosquitto (und damit mit Zigbee2mqtt) und Nodered haben wir schon erledigt, allerdings bleibt uns ein wenig Konfigurationsarbeit nicht erspart – und das leider doppelt. Also los: Zieh einen zigbee2mqtt-in Node auf die Arbeitsfläche von Nodered. Ein Doppelklick darauf zeigt dir, dass du noch keinen Server angegeben hast. Durch einen Klick auf den Stift daneben kannst du deine Mosquitto-Zugangsdaten eintragen. Dein Host dürfte localhost bzw. 127.0.0.1 sein, wenn du nichts in der Anleitung aus meinem letzten Post verändert hast ist das Basetopic zigbee2mqtt und der Port 1883. Wenn du die Zugangsbeschränkung gewählt hast, dann trage hier auch deine Zugangsdaten ein. Nun kannst du speichern und kommst zurück auf die Node-Konfiguration des zigbee2mqtt-in Nodes. Die schließt du bitte unverrichteter Dinge und klickst den Deploy-Button. Dadurch lädt sich Nodered die verfügbaren Sensoren und Aktoren aus Zigbee2mqtt und mit einem erneuten Doppelklick auf den Node findest du nun unter Devices deine Geräte. Diese Liste und der nachfolgende Punkt Payload-Output sind das Schöne an dieser Art der Kommunitkation mit Zigbee2mqtt, wir müssen uns um fast nichts kümmern. Willst du nur eine Temperatur von einem Sensor haben, wählst du einfach bei Payload-Output nur Temperature,°C aus und schon besteht deine Message nur noch aus msg.topic = zigbee2mqtt/sensorXY und msg.payload = 21 (oder eben eine andere Zahl). Wenn du hier keine Auswahl triffst, dann bekommst du alles was der Sensor liefert in strukturierter Form, z.B.:

{"battery":97,
"humidity":70,
"last_seen":"2021-12-30T23:45:44.777Z",
"linkquality":54,
"power_outage_count":24,
"pressure":992.8,
"temperature":21,
"voltage":2995}

Um das zu erhalten oder einen Wert händisch auszuwählen können wir auch einen ganz anderen Weg gehen, der uns in Spezialfällen etwas mehr Flexibilität lässt (und bei noch nicht von dem zigbee2mqtt Node unterstützten Geräten zwingend erforderlich ist). Hierzu bemühen wir den Node mqtt-in. Auch hier tragen wir erst wieder einen Server ein, bevor wir weiter machen. Mit diesem Node haben wir jetzt zwar keine Geräteauswahl mehr, aber dafür können wir alle Nachrichten vom Mosquitto empfangen (und mit dem mqtt-out Node auch senden). Dazu müssen wir das mqtt-Topic der gesuchten Nachrichten herausfinden, was allerdings ganz einfach ist: Für Zigbee2mqtt ist das schlicht: zigbee2mqtt/friendly_name Was genau du von den einzelnen Sensoren auslesen kannst und welche Befehle geben kannst, erfährst du wieder in der Gerätedatenbank auf zigbee2mqtt.io. Mit dem mqtt-out kannst du zum Beispiel einen msg.payload {"open_window": "ON"} an das mqtt-Topic zigbee2mqtt/thermostat1/set senden, um die Fensterfunktion des Thermostats zu schalten. Oder du kannst auf einem gänzlich anderen Topic (das nichts mit zigbee2mqtt zu tun hat) über mqtt mit einem Mikrocontroller per Wlan kommunizieren, der dir eine LED einschaltet, wenn ein Raum zu feucht wird. oder oder oder…

Ähnlich funktioniert dann auch ein Node wie der vom Deutschen Wetterdienst. Du suchst dir die Nummer der Wetterstation raus, deren Daten du verarbeiten möchtest, trägst sie in den Node ein und wertest dann das aus, was abgerufen wird. Um einen Abruf anzustoßen könntest du etwa einen Inject-Node so konfigurieren, dass er beim Start von Nodered einmal einen Zeitstempel losschickt (der Haken bei Einmal injizieren nach 0.1 Sekunden, danach). Danach kann der dwd-Node selbstständig eine Wiederholung der Anfrage ausführen. Alternativ kannst du auch die Wiederholung direkt im Inject-Node einstellen.

Und jetzt das große Aber! Sowohl beim DWD, wie auch bei mqtt-in kommen die Daten in Massen. Wir wollen aber oft nur einzelne Daten. Solange die Daten strukturiert ankommen, ist das kein Problem. Wir setzen einen Change-Node ein, verbinden dessen Eingangspunkt mit den Ausgangspunkt des mqtt-in oder dwd-nodes und öffenen den Chance-node mit einem Doppelklick. Nun können wir den Payload und vieles andere manipulieren. Am besten ihr habt euch schon mal den kompletten Payload vorher in den Debugnachrichten angeguckt. Er besteht aus einer „Tabelle“, die durchaus auch mal verschachtelt sein kann. Im Fall des Temperatursensors weiter oben kann man wunderbar Zeilenweise lesen. Und genau so Zeilenweise kann man die Daten auch auslesen, bzw. verändern. Im Fall des dwd-Nodes muss ich nur erkennen, dass die aktuelle Temperatur mit tempc bezeichnet wird. Damit bekomme ich nur diesen Wert angezeigt, wenn ich msg.payload in msg.payload.tempc ändere (wie im Bild). Damit weiß Nodered, dass es nur diesen Teil der Nachricht als neuen msg.payload weiterleiten soll. Wenn die Ausgabe verschachtelt ist (sozusagen ein Wert, in einem Ordner in einem Ordner), dann kann die msg.payload auch mal aus so einem Teil geändert werden: msg.payload.object1.values.humidity.

Kleine Erfahrungsbericht zu Sensoren und Aktoren

Keine echte Kaufberatung, kein Affiliate-Links, keine bezahlte Werbung, einfach nur Erfahrungen mit der Bitte, eure Erfahrungen auch zu teilen: Ich habe Erfahrungen mit den Zigbee-Komponenten von Sonoff und Aquara gemacht. Beide Marken werden gut von Zigbee2mqtt unterstützt und sind dabei relativ günstig. Gerade die SonOff-Sensoren kann man gerade sogar für unter 10€ bei Berrybase.de bestellen (Stand 1/2024) Allerdings habe ich bei SonOff Fenstersensoren schon den ein oder anderen merkwürdigen Ausfall gehabt und beim Bewegungssensor keine Nachricht der zur Neige gehenden Batterie. Aquara ist etwas teurer. Der Vorteil speziell beim Aquara-Temperatursensor ist die zusätzliche Messung des Luftdrucks. Wenn euch wichtig ist, dass ihr in Zukunft nur eine Art von Batterien austauschen möchtet, dann bleibt möglichst bei einem Hersteller. Aquara benutzt meiner Erfahrung nach fast ausschließlich die gängigen 2032 Knopfzellen, Sonoff gerne die etwas größeren 2450er. Dazu kommen fast immer noch AA oder AAA für die Thermostate dazu. Als Thermostate nutze ich gerne die TuYa TV02, die auch als Avatto TRV06 oder AWOW B091CVG78J verkauft werden, weil sie zumindest für den Privatgebrauch den riesigen Vorteil haben, dass sie auch intern einen Steuerkalender und eine Fenster-offen-Funktion haben. Insgesamt haben die Dinger tatsächlich bei dem momentan günstigsten Preis den größten Funktionsumfang. Im Gemeindehauskontext brauche ich beides nicht, da dort die Steuerung ja eh über den Kalender geregelt werden soll. Bei mir zu Hause habe ich diverse andere Zigbee-fähige Modelle im Einsatz. Die meisten unterschieden sich für den Gemeindehauseinsatz kaum voneinander. Wichtiges Merkmal für mich sind allerdings eine aus der Ferne schaltbare Kindersicherung… aus Gründen… Als Schalter habe ich gerne die kleinen von Ikea, die momentan zusammen mit den Steckdosen verkauft werden. Die haben als einzige (die ich kenne) einen Magneten eingebaut. Erwähnte Ikea-Steckdosen haben allerdings gleich zwei Nachteile: Sie sind klobig und sie haben keinen physischen Schalter. Die kleinsten und besten Steckdosen, die ich in der Hand hatte, sind die Zigbee-Steckdosen von FDTEK, denn die haben gleich eine Funktion zur Strommessung mit dabei. Die Sonoff-Steckdose ist zwar eleganter geschnitten als die Ikea-Steckdosen, aber genau so groß und hat ebenfalls keine Messfunktion. Sehr gut für Zu Hause gefällt mir auch die einzeln schaltbare Vierfachsteckdose mit 2x 2.4A USB-Steckdosen UseeLink ZigBee Smart Power Strip 4 AC. Zum Zigbee-Stick und der Raspberry Pi Hardware hatte ich ja schon im letzten Artikel ertwas geschrieben. (Bei allem, wo Tuya draufsteht bitte genau nachschauen, die habenwie auch Sonoff sowohl Zigbee als auch Wlan im Sortiment und die Wlan-Geräte teilen sich in alte mit einem flashbaren Chip[esp8266] und der neuen Variante, die man nicht mehr softwaremäßig aus deren Cloud herausbekommt, sondern nur mit etwas instabilen Umwegen.)

Um es nocheinmal klar zu machen, für alle, die das System noch nicht ganz durchschaut haben: Ihr braucht keine Zigbee-Zentrale, keinen Homepod, kein Dirigera-Hub. All diese zentralen Komponenten eines Zigbeenetzwerks haben wir durch die wesentlich mächtigere und flexiblere (aber auch komplexere) Zentrallösung mit dem Stick und den Softwarekomponenten ersetzt.

SmartGemeindehaus Artikel:
I-Installation | II-Verbindungen schaffen (und Hardware) | III-Erste Automatisierung |
IV – Speichern + Visualisieren

erLoest