!Serverschrank mit Netzwerktechnik

Es gibt in jedem Home-Assistant-Forum einen Punkt, an dem die Empfehlung fällt: Nimm doch Node-RED. Meistens dann, wenn jemand an einer Automation scheitert, die mehrere Bedingungen, Wartezeiten und Verzweigungen kombiniert.

Der Rat ist nicht falsch. Er wird nur zu oft als Grundsatzentscheidung verstanden, und das ist er nicht.

Was Node-RED ist

Node-RED ist eine Entwicklung von IBM für das Internet der Dinge und die Hausautomation. Automationen entstehen darin nicht als Text, sondern als Ablaufdiagramm: Man zieht Knoten auf eine Fläche und verbindet sie mit Linien. Kein YAML, keine Programmiersprache.

In Home Assistant läuft es als Add-on beziehungsweise als eigener Container daneben. Über eine Verbindung zu Home Assistant greift es auf dieselben Entitäten zu und kann sie sowohl auslesen als auch schalten.

Der Reiz liegt auf der Hand, sobald eine Automation verzweigt. Was in YAML eine verschachtelte Abfolge von choose und conditions ist, wird als Diagramm sichtbar: Hier teilt sich der Weg, dort läuft er wieder zusammen.

Die ehrliche Aufteilung

Aus den Erfahrungsberichten der letzten Jahre hat sich eine Empfehlung herauskristallisiert, die sich in einem Satz sagen lässt: native Automationen für die linearen neunzig Prozent, Node-RED-Flows für die verzweigten zehn.

Der eingebaute Automations-Editor von Home Assistant funktioniert für einfache Abläufe gut. Wenn ein Bewegungsmelder das Licht einschaltet und ein Timer es wieder ausschaltet, braucht es kein zweites System. Node-RED spielt seine Stärke erst aus, wenn Verzweigungen, Schleifen oder Aufrufe an fremde Schnittstellen dazukommen.

Der Grund für diese Aufteilung ist nicht Geschmack, sondern Betriebssicherheit, und dazu gleich mehr.

Wo Node-RED tatsächlich gewinnt

Verzweigte Logik. Sobald eine Automation mehr als zwei Wenn-Dann-Ebenen hat, wird YAML unübersichtlich, während das Diagramm sie sichtbar macht. Fehlersuche. Node-RED zeigt beim Durchlauf, welchen Weg eine Nachricht genommen hat, und man kann an jeder Stelle einen Debug-Knoten einhängen. Das ist komfortabler als die Fehlersuche in YAML. Allerdings ist die Trace-Ansicht von Home Assistant seit einigen Jahren deutlich besser geworden und reicht für die meisten Fälle inzwischen aus. Fremde Schnittstellen. Node-RED bringt eine sehr große Zahl von Community-Knoten für APIs, Protokolle und Dienste mit, die es als Home-Assistant-Integration nicht gibt. Wenn etwas an einen Webdienst angebunden werden soll, für den keine Integration existiert, ist das oft der kürzeste Weg. Zeitliche Abläufe. Wartezeiten, Verzögerungen und Ablaufsteuerungen über längere Zeiträume lassen sich als Diagramm leichter überblicken als in YAML.

Das Argument, das gegen Node-RED spricht

Und jetzt der Punkt, den die Begeisterung regelmäßig überspringt: Node-RED ist ein zusätzliches System, das ausfallen kann.

Wenn der Node-RED-Container während eines Updates abstürzt oder nach einem Neustart nicht sauber hochkommt, stehen alle Automationen still, die dort liegen. Home Assistant läuft weiter und merkt davon nichts.

Daraus folgt eine klare Regel: Sicherheitsrelevante und kritische Funktionen gehören in native Automationen. Rauchmelder-Reaktionen, Wasserleck-Abschaltungen, Alarmanlagenlogik, Türschlösser. Alles, wovon abhängt, dass es funktioniert, auch wenn gerade jemand am System schraubt.

Node-RED bekommt dagegen das, was komfortabel ist und dessen Ausfall man verkraftet: Beleuchtungsszenarien, Benachrichtigungen, Auswertungen, Anbindungen an Dienste.

Das ist keine theoretische Vorsichtsmaßnahme. Es ist genau der Fall, der bei einem Update eintritt, und Updates macht man regelmäßig.

Was gegen einen Vollumzug spricht

Manche ziehen ihre gesamte Automationslogik nach Node-RED. Davon ist abzuraten, und zwar aus einem Grund, der über die Ausfallsicherheit hinausgeht.

Home Assistant ist tief in seine eigenen Automationen integriert. Blueprints, die Trace-Zeitleiste, die Verknüpfung mit Geräten und Bereichen, das Nachvollziehen im Logbuch: All das funktioniert für native Automationen und nicht für Node-RED-Flows. Wer alles auslagert, verliert diese Werkzeuge und tauscht sie gegen eine zweite Oberfläche, die er separat sichern und aktualisieren muss.

Dazu kommt die Datensicherung. Node-RED-Flows liegen nicht in der Home-Assistant-Konfiguration. Ein Snapshot sichert sie nur mit, wenn das Add-on im Backup enthalten ist, und bei einer Container-Installation gar nicht. Wer ein Jahr Automationsarbeit dort liegen hat, sollte das prüfen, bevor er den Server umzieht. Was beim Sichern sonst zu beachten ist, steht im Artikel über die Backup-Strategie.

Wenn es doch eine dritte Möglichkeit sein soll

Zwischen YAML und Node-RED gibt es einen Weg, der in der Diskussion oft untergeht: Skripte in Python über PyScript oder die eingebauten Vorlagen.

Für Leute, die programmieren können, ist das häufig der direktere Weg als ein Diagramm. Eine Schleife über zwanzig Entitäten ist in fünf Zeilen Python geschrieben und in Node-RED ein Geflecht aus Knoten. Umgekehrt gilt für alle, die nicht programmieren, genau das Gegenteil, und das ist der eigentliche Grund für die Existenz von Node-RED.

Die Wahl hängt also weniger an der Aufgabe als an der Person, die sie später warten muss. Das ist ein brauchbares Kriterium: Wer in einem halben Jahr nicht mehr versteht, was er gebaut hat, hat das falsche Werkzeug gewählt, unabhängig davon, welches es war.

Eine brauchbare Reihenfolge

Für alle, die überlegen, ob sie anfangen sollen:

Erstens prüfen, ob die Automation wirklich nicht nativ geht. Seit einigen Versionen können die eingebauten Automationen deutlich mehr als früher, unter anderem mehrere Auslöser mit Kennzeichnung, Auswahlblöcke und Wiederholungen. Vieles, wofür früher Node-RED nötig war, geht inzwischen ohne.

Zweitens, wenn es doch Node-RED wird: klein anfangen, mit genau einer Automation, und die kritischen Funktionen dort lassen, wo sie sind.

Drittens von Anfang an die Sicherung klären, nicht später.

Und viertens eine Entscheidung dokumentieren, die man in einem Jahr sonst nicht mehr nachvollzieht: Warum liegt diese Automation dort und nicht hier. Bei zwei Systemen ist das der Unterschied zwischen einem Aufbau, den man pflegen kann, und einem, der nach und nach zum Rätsel wird.

Quellen: Vergleichsdarstellungen von Node-RED und nativen Home-Assistant-Automationen bei hausbit.de, mostlychris.com und technikkram.net · Diskussionsstrang "NodeRed vs native automation" in der Home Assistant Community · Einordnung zu PyScript und Vorlagen bei fricklr.com · Einrichtungsbeschreibung des Node-RED-Add-ons bei raspberry.tips