Homee mit Node RED erweitern

Der Homee ist eine Smart Home Zentrale, welche den Vorteil hat, dass sich Geräte von verschiedenen Herstellern einbinden lassen und die Automatisierung über „Homeegramme“ sehr einfach funktioniert.

Es gibt jedoch auch Anforderungen, welche sich mit dem Homee nicht erfüllen lassen, da keine echte Programmierung möglich wird. Zwar gibt es ein inoffizielles API – dies kann sich jedoch jederzeit ändern und ist nicht ausreichend dokumentiert.

Aus diesem Grund habe ich mich entschieden, die Funktionalität des Homee über einen RaspberryPi zu erweitern. Die Auswahl der Platform viel dabei auf NodeRED, da Abläufe sich über das UI einfach erstellen lassen, aber dennoch „echte“ Programmierung über JavaScript möglich ist.

Ein Anwendungsfall ist die Lichtsteuerung im Treppenhaus. Alle Lampen dort werden über einen Fibaro Switch geschalten. Das Gerät ist über Z-Wave mit dem Homee verbunden, so dass dieser auch die Schaltvorgänge mitbekommt. Die Anforderung besteht darin, das Licht nach einer definierten Zeit (hier drei Minuten) automatisch auszuschalten. Dies lässt sich zunächst einmal auch mit einem Homeegram umsetzen, indem nach dem Einschalt-Event zeit-verzögert das Ausschalten erfolgt. Dieses Vorgehen hat jedoch den Nachteil, dass es zu Irritationen kommen kann wenn zwei Bewohner im Abstand von knapp drei Minuten das Licht benutzen.

Einrichtung des RaspberryPi

Auf dem Raspberry wurde ein standard „Raspbian mit Desktop und empfohlener Software“ installiert. Zu dieser empfohlenen Software gehört auch NodeRED. Damit dies auch beim Booten started, muss der Service aktiviert werden:

sudo systemctl enable nodered.service

Kommunikation zwischen Homee und Node RED

Um mit externen Systemen zu kommunizieren, können im Homee WebHooks verwendet werden. Dabei können WebHooks andere Systeme über ein Event informieren oder es werden eingehende Requests verwendet, um eine Aktion auszulösen.

Um Node RED zunächst über Schaltvorgänge zu informieren wurden zwei Homeegramme erstellt. Eines wird beim Einschalten ausgelöst – das andere beim Ausschalten. Bei der Definition eines WebHooks sind 4 Angaben erforderlich: Die URL, die Methode, der Content Type und ein Body.

Die URL setzt sich aus der Adresse des Homee, einem Port und dem Endpunkt zusammen, auf dem NodeRED eingehende Nachrichten erwartet. In meinem Netzwerk ist NodeRED unter dem Namen nodered.local zu erreichen. Scheinbar gibt es jedoch Probleme mit der Namensauflösung über mDNS beim Homee. Aus diesem Grund wurde eine fest IP (über den Router) vergeben und diese in der URL verwendet.

Standardmäßig lauscht Node RED auf Port 1880. Als Endpunkt wurde „/staircase“ verwendet. Die URL setzt sich also wie folgt zusammen: http://<ip>:1880/staircase

Als Methode wurde POST verwendet und der Content Type ist „application/json“. Um den Endpunkt „/staircase“ für verschiedene Events zu verwenden wurde zudem ein Body definiert, dem die location und das event genauer spezifiziert werden.

Entsprechende Bodies wurden auch für die Schaltung im Erdgeschoss („staircase_groundfloor“) und für das Ausschalten („event“:“light_off“) erstellt.

Ablauf über Node RED erstellen

Die Basis der Programmierung in NodeRED bilden Nodes, welche man als graphische Elemente auf den Canvas ziehen kann. Verschiedene Nodes können dann zu einem Flow verbunden werden.

Eine Gruppe von Nodes die untereinander verbunden sind, werden inoffiziell als „Flow“ bezeichnet. Tatsächlich wird als Flow aber der gesamte Reiter bezeichnet, also auch Nodes die keinerlei Verbindung haben.

Flow

A Flow is represented as a tab within the editor workspace and is the main way to organise nodes.

The term “flow” is also used to informally describe a single set of connected nodes. So a flow (tab) can contain multiple flows (sets of connected nodes).

https://nodered.org/docs/user-guide/concepts

Ich bleibe hier bei der Bezeichnung Flow für eine Gruppe von verbunden Nodes.

Die Abbildung unten zeigt das Tab, welches für die Lichtsteuerung im Treppenhaus angelegt wurde.

Auf dem Tab gibt es einen Eingangs-Node vom Typ http. Dieser ist so konfiguriert, dass er auf eine POST-request auf dem Endpoint /staircase reagiert.

Der Inhalt des request wird als Payload mit der Message an den nächsten Knoten übergeben. Dieser nächste Knoten ist vom Typ Switch und unterscheidet den Ursprung des Events (anhand des Schlüsselwertes „location“, der vom Homee übergeben wird).

Der Flow wird hier in zwei Pfade gesplittet, welche die unterschiedlichen Orte im Treppenhaus repäsentierten.

Auch der nächste Block ist wieder vom Typ Switch und fragt das Event (ebenfalls ein key des payload Objektes) ab.

Nach den beiden Switch-Blöcken gibt es nun 4 Pfade im Flow. Entsprechend wurden hier vier Function-Blocks gesetzt, welche den aktuellen Zustand im in zwei Variablen speichern – ein Variable speichert den aktuellen Zustand des oberen Treppenhauses, die anderes den Zustand im Ergeschoss.

Über die Funktion flow.set(‚<Variablenname>‘,'<Wert>‘) kann eine Variable im Scope des Flows gesetzt werden. Diese lässt sich von jeder Stelle im aktuellen Reiter abfragen.

Wurde das Licht ausgeschalten erfolgt keine weitere Aktion. Nur beim Einschalt Event soll ein Timeout gestartet werden, welcher das automatische Abschalten einleitet.

Ein Timeout Node ist in den Standard-Nodes nicht enthalten, kann jedoch einfach über das Modul node-red-contrib-timeout hinzugefügt werden.

Der Timeout Node hat zwei Funktionen. Zum einen wartet er beim Auslösen einen definierten Zeitraum ab, bis er die Folgeaktion auslöst. Zum anderen setzt er den Countdown zurück, wenn der Trigger erneut ausgelöst wird. Für den Trigger müssen der „Safe state“ und der „Unsafe state“ definiert werden. Die Definition des Warning state ist nicht notwendig. Zwar soll beim Auslösen des „Safe state“ keine weitere Aktion erfolgen, es ist aber dennoch nötig diesen Status zu definieren (ansonsten Schaltet der Flow nur nach dem allerersten Schaltvorgang ab).

Da nur für den „Unsafe State“ geschaltet werden soll, folgt auf den Trigger ein weiterer Switch, welcher die Nachricht der Payload überprüft.

Um einen unnötigen HTTP Request zu vermeiden, wird vor dem Abschalten noch einmal geprüft, ob das Licht an entsprechender Stelle tatsächlich noch angeschaltet ist. Hierzu wird die zuvor gesetzte Variable (dem Flow) abgefragt.

Der Schaltvorgang an sich erfolgt wieder über den Homee. Hierzu wurde für beide Bereiche je ein weiteres Homeegramm angelegt. In diesem Fall ist ein WebHook der Auslöser für das Homeegramm. Beim Erstellen eines WebHook muss lediglich der Name angegeben werden. Der Homee gibt danach eine öffentliche URL aus, über welche sich dieses Event triggern lässt.

Statt der öffentlichen URL lässt sich aber auch die lokale Adresse des Homee verwenden. Dabei wird einfach der Teil ab „/api“ der lokalen Adresse des Homee (einschließlich Port 7681) hinzugefügt.

In NodeRED ruft ein Node vom Typ http request die Adresse über Methode GET auf.

Fazit

Fehlende Funktionalität im Homee lässt sich über NodeRED kompensieren. Dabei bietet NodeRED genau das, was dem Homee meines Erachtens fehlt: Die Möglichkeit über einen Low-Code Ansatz auch komplexere Vorgänge abzubilden. Dabei stell sich natürlich die Frage, wozu man den Homee dann überhaupt benötigt und nicht direkt einen Raspberry Pi als SmartHome Zentrale einsetzt. Grund für mich bleibt hier weiterhin die Möglichkeit Geräte von verschiedenen Herstellern sehr einfach einbinden zu können. Die Kommunikation über Webhooks ist dabei lediglich ein Workaround. Es wäre wünschenswert, wenn dem Homee eine echte (offizielle) API spendiert würde

"Raspberry Pi" Edge Devices Homee Node RED Remote Development VS Code