Node-RED vs Home Assistant Automations (2026)

Werbung / Affiliate-Links: Mit * markierte Links sind Affiliate-Links. Beim Kauf über diese Links erhalten wir eine kleine Provision — für dich ändert sich am Preis nichts. Als Amazon-Partner verdienen wir an qualifizierten Verkäufen.

Home Assistant hat zwei Wege für Automationen: die eingebauten Automations (YAML oder UI) und Node-RED als visuellen Flow-Editor. Beide haben ihre Fans, beide ihre Berechtigung. Welcher passt besser zu deinem Setup und deinem Arbeitsstil?

In diesem Vergleich schauen wir uns beide Ansätze praxisnah an — mit konkreten Beispielen, Stärken, Schwächen und einer klaren Empfehlung.

So haben wir verglichen: Grundlage sind die offizielle Home-Assistant-Dokumentation, die Doku der Node-RED-App und des Node-RED-Projekts sowie Erfahrungsberichte aus der Home-Assistant-Community. Kriterien waren Einrichtung, Lernkurve, Debugging, Wartbarkeit und Ressourcenbedarf. Eigene Benchmarks haben wir nicht durchgeführt — Zahlen zu RAM oder Startzeit sind Richtwerte, keine eigenen Messungen.

Auf einen Blick

Home Assistant Automations — die eingebaute Lösung

Was ist das?

Das native Automationssystem von Home Assistant. Du erstellst Automationen entweder über den visuellen UI-Editor oder als YAML-Konfiguration. Seit den letzten großen Updates (Trace, Blueprints, Labels) ist das System deutlich mächtiger geworden.

Stärken

• Kein Extra-Setup: Sofort verfügbar, keine App nötig, kein zusätzlicher Ressourcenverbrauch
• UI-Editor: Trigger, Bedingungen und Aktionen per Klick zusammenstellen — kein Code nötig
• Blueprints: Fertige Automations-Vorlagen aus der Community importieren. Hunderte verfügbar auf der HA-Community-Seite
• Trace: Seit HA 2021.4 gibt es detailliertes Debugging — du siehst genau welcher Schritt wann ausgeführt wurde, welche Daten geflossen sind, und warum eine Condition fehlgeschlagen hat
• Im HA-Ökosystem: Alles an einem Ort, ein Backup, eine Oberfläche
• Labels & Kategorien: Automationen organisieren, gruppieren und filtern
• Script-Support: Wiederverwendbare Skripte, die von mehreren Automationen aufgerufen werden können

Schwächen

• Komplexe Logik wird unübersichtlich: Verschachtelte if/else, Schleifen, dynamische Entscheidungen — das wird in YAML schnell zu einem unlesbaren Monster
• Kein visueller Datenfluss: Du siehst nicht, wie Daten von A nach B fließen. Alles ist textbasiert, auch mit dem UI-Editor
• Templates sind mächtig aber kryptisch: Jinja2-Templates können alles — aber {{ states('sensor.wohnzimmer_temperatur') | float(0) > 25 and is_state('binary_sensor.fenster', 'off') }} ist nicht gerade leserlich
• Kein globaler State zwischen Automationen: Jede Automation ist isoliert. Für geteilten State brauchst du input_*-Helfer
• Choose/If-Then-Else: Seit 2022 verfügbar, aber die YAML-Syntax dafür ist… gewöhnungsbedürftig

Praxisbeispiel: Licht bei Bewegung (einfach)

Über den UI-Editor:

1. Neue Automation → Trigger: Zustandsänderung → Bewegungssensor → „on”
2. Bedingung: Sonne → nach Sonnenuntergang
3. Aktion: Licht einschalten → Warten, bis der Sensor 3 Minuten lang keine Bewegung meldet → Licht ausschalten

Als YAML:

automation:
  - alias: "Flur Licht bei Bewegung"
    triggers:
      - trigger: state
        entity_id: binary_sensor.flur_bewegung
        to: "on"
    conditions:
      - condition: sun
        after: sunset
    actions:
      - action: light.turn_on
        entity_id: light.flur
        data:
          brightness_pct: 80
      - wait_for_trigger:
          - trigger: state
            entity_id: binary_sensor.flur_bewegung
            to: "off"
            for: "00:03:00"
      - action: light.turn_off
        entity_id: light.flur

Einfach, klar, funktioniert. Für solche Standard-Automationen brauchst du definitiv kein Node-RED.

Praxisbeispiel: Adaptive Beleuchtung (mittel)

automation:
  - alias: "Adaptive Beleuchtung Wohnzimmer"
    triggers:
      - trigger: state
        entity_id: binary_sensor.wohnzimmer_bewegung
        to: "on"
    conditions:
      - condition: state
        entity_id: person.philipp
        state: "home"
    actions:
      - choose:
          - conditions:
              - condition: time
                before: "06:00:00"
            sequence:
              - action: light.turn_on
                target:
                  entity_id: light.wohnzimmer
                data:
                  brightness_pct: 10
                  color_temp_kelvin: 2700
          - conditions:
              - condition: sun
                before: sunset
            sequence:
              - action: light.turn_on
                target:
                  entity_id: light.wohnzimmer
                data:
                  brightness_pct: 100
                  color_temp_kelvin: 4500
        default:
          - action: light.turn_on
            target:
              entity_id: light.wohnzimmer
            data:
              brightness_pct: 70
              color_temp_kelvin: 3000

Das funktioniert. Aber du siehst: bei drei Zeitfenstern wird der YAML schon lang. Bei fünf oder zehn wird’s unmanageable.

Node-RED — der visuelle Power-Editor

Was ist Node-RED?

Ein visueller Flow-Editor, ursprünglich von IBM für IoT-Anwendungen entwickelt. Läuft als App in Home Assistant und kommuniziert über die Home Assistant Nodes direkt mit HA. Die Logik wird als „Flows” modelliert — Nachrichten fließen von Node zu Node.

Installation

1. Einstellungen → Apps → App Store
2. Suche nach Node-RED
3. Installieren → Starten
4. „In der Seitenleiste anzeigen” aktivieren
5. Web-UI öffnen → Editor erscheint

Die Home Assistant Nodes (Events, Services, States, etc.) sind vorinstalliert. Du kannst sofort loslegen.

Stärken

• Visuelles Debugging: Du siehst in Echtzeit welche Nachrichten durch welche Nodes fließen — mit Payload, Timestamp und allem. Das ist unschlagbar beim Troubleshooting
• Komplexe Logik leicht gemacht: Switch-Nodes, Function-Nodes, Delays, Loops, Rate-Limiting — alles visuell verständlich. Was in YAML 50 Zeilen braucht, ist in Node-RED ein übersichtlicher Graph
• JavaScript-Power: In Function-Nodes kannst du beliebigen JavaScript-Code ausführen. Arrays sortieren, HTTP-Requests machen, Daten transformieren — keine Einschränkung
• Subflows: Wiederverwendbare Logikblöcke. Einmal bauen, überall einsetzen
• Plattformübergreifend: Node-RED kann auch mit MQTT, HTTP APIs, Datenbanken, E-Mail, Telegram — nicht nur HA
• Riesiges Node-Ökosystem: Tausende zusätzliche Nodes via npm: Datenbank-Anbindung, Machine Learning, Bildverarbeitung, was du willst
• Flow-Organisation: Tabs für verschiedene Bereiche (Beleuchtung, Heizung, Sicherheit), Kommentare, Gruppierung

Schwächen

• Extra App: Separater Node.js-Prozess mit eigenem RAM-Bedarf (Nutzer berichten meist von einigen hundert MB, abhängig von Flows und installierten Nodes), zusätzliche Daten im Backup. Auf einem Raspberry Pi mit 2GB kann das eng werden
• Zwei Orte für Automationen: Manche in HA, manche in Node-RED — das wird schnell unübersichtlich. Wo war nochmal die Waschmaschinen-Automation?
• Backup nur mit App-Auswahl: Die Node-RED-Flows liegen im Konfigurationsordner der App und landen nur im HA-Backup, wenn die Node-RED-App in der Backup-Auswahl enthalten ist (bei „Alle Apps” automatisch). Siehe unseren Backup-Guide
• Overkill für einfache Automationen: „Bewegung → Licht an” braucht in Node-RED drei Nodes + Konfiguration. In HA ist das ein 3-Klick-Job
• Lernkurve: Das Konzept von Flows und Messages muss man erstmal verstehen. Nicht schwer, aber auch nicht sofort intuitiv

Praxisbeispiel: Intelligente Heizungssteuerung (komplex)

In Node-RED als visueller Flow — mit einem Aqara Temperatur- und Feuchtigkeitssensor^* und einem tado Smartes Heizkörperthermostat X Starter Kit^* wird das Ganze praktisch:

[Temperatur-Sensor] → [Switch: < 19°C?]
                          ↓ Ja
                    [HA: Fenster offen?] → [Ja: Heizung aus + Notify]
                          ↓ Nein
                    [HA: Jemand zuhause?] → [Nein: Auf 17°C absenken]
                          ↓ Ja
                    [Switch: Tageszeit?]
                       ↓ Morgens    ↓ Tagsüber    ↓ Abends    ↓ Nachts
                      22°C         20°C           21°C        18°C
                          ↓
                    [HA: set_temperature]

Das ist in Node-RED ein übersichtliches Diagramm auf einem Bildschirm. In HA-YAML wäre das 80+ Zeilen verschachtelter choose-Blöcke — und beim Debugging müsstest du dich durch den Trace klicken statt einfach den Flow zu beobachten.

Praxisbeispiel: Waschmaschinen-State-Machine

Eine echte State-Machine in Node-RED:

[Strom-Sensor]
     ↓
[Switch: Watt-Bereich?]
     ↓ >50W              ↓ 5-50W              ↓ <5W (3min)
[State: LÄUFT]      [State: SPÜLEN]     [State: FERTIG]
     ↓                    ↓                    ↓
[flow.set: running]  [flow.set: rinsing]  [Benachrichtigung!]
                                              ↓
                                         [flow.set: idle]

Mit flow-Variablen behält Node-RED den Zustand über die gesamte Lifetime. In HA brauchst du dafür input_select-Helfer und mehrere separate Automationen.

Feature-Vergleich im Detail

Debugging

Node-RED gewinnt beim Debugging klar. Aber HAs Trace (seit 2021.4) ist inzwischen ausgereift und reicht für 90% der Fälle.

Datenpersistenz

HA-Automationen haben hier einen Vorteil: input_boolean, input_number etc. überleben Neustarts. Node-REDs Flow-Variablen nicht (es sei denn, du nutzt context-Storage mit File-Backend).

Wartbarkeit

Performance-Vergleich

Die folgenden Angaben sind grobe Richtwerte aus Doku und Community-Berichten, keine eigenen Messungen. Der tatsächliche Bedarf hängt stark von Hardware, Anzahl der Flows und installierten Nodes ab.

Bei typischen Hausautomationen berichten Nutzer von keinem spürbaren Unterschied in der Reaktionszeit. Der RAM-Verbrauch ist auf einem Raspberry Pi mit 2GB relevant — auf einer Proxmox-VM mit 4GB+ irrelevant.

Können beide zusammen laufen?

Ja — und das ist oft die pragmatischste Lösung:

• Standard-Automationen in HA: Licht bei Sonnenuntergang, Bewegungsmelder, einfache Benachrichtigungen
• Komplexe Logik in Node-RED: Multi-Sensor-Entscheidungen, API-Integrationen, State-Machines

Aber: Dokumentiere, welche Automation wo liegt. Nichts ist frustrierender als „warum geht die Heizung nicht an?” und dann sucht man 20 Minuten, ob es eine HA-Automation oder ein Node-RED-Flow ist.

Best Practice für Koexistenz

1. Klare Trennung: Alle einfachen Automationen in HA, alle komplexen in Node-RED
2. Namenskonvention: Node-RED-Flows mit Prefix (z.B. „NR: Heizungssteuerung”)
3. Dokumentation: In Node-RED Kommentar-Nodes nutzen, in HA die Beschreibungsfelder
4. Kein Ping-Pong: Nicht aus einer HA-Automation einen Node-RED-Flow triggern, der wiederum eine HA-Automation auslöst

Migration

Es gibt kein automatisches Migrationstool — aber die Migration ist in beiden Richtungen machbar:

HA → Node-RED

1. Automation in HA identifizieren und deaktivieren (nicht löschen!)
2. In Node-RED als Flow nachbauen
3. Testen
4. Wenn alles läuft: HA-Automation löschen

Node-RED → HA

1. Flow-Logik in YAML oder UI-Editor übertragen
2. flow-Variablen durch input_*-Helfer ersetzen
3. JavaScript-Logik in Jinja2-Templates umschreiben (kann aufwändig sein)
4. Testen und Node-RED-Flow deaktivieren

Genereller Tipp: Laufen lassen was läuft. Migriere nur wenn du einen konkreten Grund hast (z.B. Ressourcen sparen, Komplexität reduzieren, ein System konsolidieren).

Fazit

Für die meisten Leute reichen die eingebauten HA-Automationen. Der UI-Editor ist in den letzten Versionen richtig gut geworden, Blueprints sparen Zeit, Trace macht Debugging einfach, und du hast alles an einem Ort.

Node-RED lohnt sich, wenn du regelmäßig komplexe Logik mit vielen Verzweigungen brauchst, visuelles Echtzeit-Debugging schätzt, oder sowieso schon mit JavaScript arbeitest.

Die schlechteste Option: beides halbherzig nutzen und nicht mehr wissen, wo welche Automation liegt. Entscheide dich für einen Hauptweg und nutze den anderen nur für begründete Ausnahmen.

Weiterführende Artikel

• Home Assistant Automationen für Anfänger — 10 Automationen zum Sofort-Umsetzen
• MQTT Broker einrichten — Basis für viele Automationen
• Benachrichtigungen einrichten — Telegram, Pushover & Companion App
• Dashboard gestalten — Die Ergebnisse deiner Automationen visualisieren

Autor

Philipp

Themen

Home Assistant, ESP32, Zigbee

Schreibt über Home Assistant, ESP32 und alles, was das Smart Home smarter macht.

Dieser Artikel wurde mit KI-Unterstützung erstellt; Angaben werden gegen offizielle Dokumentation und Herstellerangaben geprüft. Wie die Artikel entstehen