Die Qual der Wahl: Home Assistant Automationen, Node-RED oder PyScript?

Wer schon länger im Home Assistant Universum unterwegs ist, erinnert sich vielleicht noch mit einem leichten Schaudern an die Anfangszeiten. Damals war die Erstellung von Automationen eine reine Textaufgabe in YAML-Dateien. Und damit ist nicht entspanntes Konfigurieren gemeint, sondern der tägliche Kampf gegen den unsichtbaren Endgegner: das Leerzeichen.

Willkommen in der YAML-Einrückungs-Hölle.

#

Ein Leerzeichen zu wenig? Konfigurationsfehler. Ein Leerzeichen zu viel? Das System fährt nicht hoch. Ein Tabulator statt zwei Leertasten? Katastrophe! Man fühlte sich oft wie ein Bombenentschärfer, der mit zitternden Händen versucht, die entity_id exakt zwei Spaces unter den action-Block zu schieben. Man starrte stundenlang auf den Bildschirm, zweifelte an seiner Zurechnungsfähigkeit, nur um am Ende festzustellen, dass Zeile 42 einen Millimeter zu weit links stand.

Wer – wie ich – von Systemen wie IP-Symcon kam, hatte es da besonders schwer. Ich war früher ein absoluter “PHP-Guy”. Daher fiel es mir in der Symcon-Welt leicht, selbst komplexeste Automationen einfach herunterzuprogrammieren, weil ich die Sprache sprach.

In Home Assistant hingegen fühlte man sich anfangs in der Textwüste verloren, vermisste schmerzlich eine echte Skriptsprache und brauchte eine Zen-buddhistische Geduld, nur um das Licht im Flur per Bewegungsmelder bei Dunkelheit einzuschalten. Umfangreichere Automationen waren nur direkt in YAML machbar.

Zum Glück hat sich Home Assistant massiv weiterentwickelt. Der grafische Editor für Automationen ist mächtig geworden und nimmt einem diese Sisyphusarbeit ab. Parallel dazu hat sich Node-RED als Quasi-Standard für komplexe Abläufe etabliert und für die Coder gibt es mit PyScript eine mächtige Python-Integration.

Doch wann setzt man welches Werkzeug ein? Ich habe mir die drei gängigsten Methoden angesehen und stelle Vor- und Nachteile gegenüber.

Das Szenario: Licht an bei Bewegung

#

Um die Ansätze vergleichbar zu machen, nutzen wir ein absolut klassisches Beispiel, das in fast jedem Haushalt vorkommt: Ein Bewegungsmelder im Flur soll eine Lampe einschalten, aber nur, wenn es dunkel genug ist (Helligkeit < 20 Lux). Wenn keine Bewegung mehr erkannt wird, soll das Licht wieder ausgehen.

1. Native Home Assistant Automationen

#

Die integrierte Engine ist in den letzten Jahren enorm gereift. Was früher besagtes mühsames YAML-Hacken war, lässt sich heute fast vollständig über die Benutzeroberfläche (UI) zusammenklicken. Home Assistant schreibt das YAML im Hintergrund zwar immer noch, aber man muss es sich nicht mehr ansehen – und vor allem nicht mehr manuell einrücken.

Der Ablauf ist dabei linear: Auslöser (Bewegung erkannt) -> Bedingung (nur wenn dunkel) -> Aktion (Licht an) -> Trigger (Bewegung) keine Bewegung mehr erkannt -> Delay 5 Minuten warten -> Aktion Licht aus

Auch wenn man heute meist klickt, lohnt sich ein Blick auf den Code, der dabei im Hintergrund entsteht, um die Struktur zu verstehen:

alias: "Flurlicht: Bewegung und Helligkeit"
mode: restart
triggers:
  # Trigger 1: Bewegung erkannt
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_flur_occupancy
    from: "off"
    to: "on"
    id: "bewegung_erkannt"

  # Trigger 2: Keine Bewegung für 5 Minuten
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_flur_occupancy
    to: "off"
    for:
      minutes: 5
    id: "keine_bewegung_mehr"

conditions: []

actions:
  - choose:
      # Szenario A: Licht einschalten (nur wenn dunkel)
      - conditions:
          - condition: trigger
            id: "bewegung_erkannt"
          - condition: numeric_state
            entity_id: sensor.bewegungsmelder_flur_illuminance
            below: 20
        sequence:
          - action: light.turn_on
            target:
              entity_id: light.flur_decke # DEINE LAMPE
            data:
              brightness_pct: 100 # Helligkeit festlegen
              transition: 1       # Sanftes Einblenden

      # Szenario B: Licht ausschalten
      - conditions:
          - condition: trigger
            id: "keine_bewegung_mehr"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.flur_decke # DEINE LAMPE
            data:
              transition: 2       # Sanftes Ausblenden

Das ist solide, lesbar, aber schon bei dieser simplen Logik sieht man, warum es bei komplexeren Verschachtelungen unübersichtlich werden kann und hier haben wir noch nicht die “aus” Automation nach z. B. 5 Minuten definiert, die auch einen Reboot von Home Assistant überleben würde - also kein einfaches Delay.

Ein riesiger Vorteil der nativen Automationen ist die Trace-Funktion. Man kann visuell und interaktiv nachverfolgen, warum eine Automation ausgelöst hat – oder warum eben nicht. Gerade bei der Fehlersuche ist das Gold wert und mittlerweile meiner Meinung nach besser gelöst als das Debugging in vielen anderen Tools.

Vorteile:

• Tief integriert: Keine Zusatzsoftware nötig, Updates von Home Assistant decken alles ab.
• Performance: Da es direkt im Core läuft, ist die Latenz minimal.
• Debugging: Die Trace-Timeline ist hervorragend zur Fehleranalyse.
• Blueprints: Man kann fertige Vorlagen aus der Community nutzen, ohne das Rad neu erfinden zu müssen.

Nachteile:

• Komplexität bei Verzweigungen: Sobald man verschachtelte “Wenn-Dann”-Logiken oder Schleifen benötigt, wird die UI schnell unübersichtlich.
• YAML-Kenntnisse: Für sehr spezifische Dinge (Templates) landet man am Ende doch wieder im Code-Editor – aber zumindest meist nur als Einzeiler.

2. Node-RED

#

Node-RED ist für viele der heilige Gral der Hausautomatisierung. Es handelt sich um ein visuelles Programmierwerkzeug, bei dem man “Nodes” (Knoten) mit Leitungen verbindet. Es läuft meist als Add-on parallel zu Home Assistant.

Für visuelle Typen ist das ein Segen. Man sieht den Fluss der Daten förmlich vor sich. Unser Beispiel wäre hier eine Kette aus: Event State Node (Bewegung) -> Switch Node (Prüfung Helligkeit) -> Call Service Node (Licht an).

Node-RED spielt seine Stärke aus, wenn die Logik komplex wird. Wenn Daten von einer API geholt, umformatiert, gefiltert und dann an drei verschiedene Dienste geschickt werden müssen, ist das in Node-RED oft in wenigen Minuten zusammengeklickt. In YAML wäre das ein Albtraum, aus dem man schweißgebadet aufwacht.

Ein perfektes Beispiel dafür ist mein Projekt, bei dem ich unsere Türkamera schlauer gemacht habe . Hier musste beim Klingeln der Fernseher eingeschaltet, auf den richtigen HDMI-Eingang gewechselt und das Kamerabild angezeigt werden. Solche Verkettungen von unterschiedlichen Protokollen (HDMI-CEC, MQTT, Kamerastreams) sind die Paradedisziplin von Node-RED.

Allerdings führt Node-RED eine weitere Komplexitätsebene ein. Es ist ein eigenständiges System, das gewartet werden muss. Fällt das Add-on aus, bleibt das Licht aus, auch wenn Home Assistant noch läuft. Zudem verleitet es dazu, riesige “Spaghetti-Monster” zu bauen – unübersichtliche Kabelwirrwarr-Flows, die man nach drei Monaten selbst nicht mehr versteht. Außerdem kann man sich in der riesigen Auswahl an Custom-Nodes verlieren und oft ist es schon eine Herausforderung, die richtige Node zu finden.

Vorteile:

• Visueller Überblick: Datenflüsse sind intuitiv erfassbar.
• Mächtig: Enorme Bibliothek an “Palettes” (Erweiterungen) für fast jeden Anwendungsfall.
• Flexibilität: Ideal für komplexe Logiken und Datenmanipulation.

Nachteile:

• Zusätzliche Wartung: Ein weiteres System, das gepflegt werden muss.
• Overhead: Für simple “Licht an/aus” Geschichten oft wie mit Kanonen auf Spatzen geschossen.
• Trennung: Die Logik liegt außerhalb der eigentlichen Home Assistant Konfiguration (Backup-Strategie beachten!).

Ein paar Node-Empfehlungen für NodeRed habe ich trotzdem für euch. Die ersten 3 machen viele komplexe Aufgaben viel einfacher:

node-red-contrib-bigtimerMächtige Timer-Funktionen. Kann Sonnenaufgang/Untergang (mit Offset), Feiertage, manuelle Overrides und sogar MQTT-Texte ausgeben. Perfekt für Rolladen- und Lichtsteuerung.node-red-contrib-cron-plusUnterstützt CRON-Syntax und dynamische Erstellung von Zeitplänen zur Laufzeit.node-red-contrib-boolean-logic-ultimateErspart riesige “Switch”-Kaskaden oder komplexe If/Else-Blöcke in Function-Nodes.Bietet AND, OR, XOR Gates. Beispiel: “Licht nur an, WENN (Bewegung erkannt) UND (Nacht ist) UND (NICHT Fernseher läuft)”. Es speichert auch Zustände persistent über Neustarts hinweg.node-red-contrib-looptimer-advancedUm Dinge blinken zu lassen oder Benachrichtigungen zu wiederholen (“Garage ist noch offen!”), bis einer reagiert.node-red-contrib-influxdbDirekt in InfluxDB schreibennode-red-contrib-zigbee2mqttAuf zigbee2mqtt zugreifen
node-red-contrib-huemagicSehr mächtige Palette für Philips Hue. Bietet mehr Optionen (z.B. dynamische Szenen, “Color Loop”) als die Standard-HA-Entitäten.

3. PyScript (Python) – Der AppDaemon-Killer?

#

Lange Zeit war AppDaemon der unangefochtene Platzhirsch für alle, die mehr Power wollten, als YAML bieten konnte. Versteht mich nicht falsch, AppDaemon ist mächtig und hat seine Daseinsberechtigung (vor allem für komplexe Dashboards) – aber es ist auch ein “eigenes Biest”. Es läuft als separate Instanz neben Home Assistant, muss extra konfiguriert werden, benötigt eine eigene Verbindungskonfiguration und fühlt sich oft unnötig kompliziert an, wenn man “nur mal schnell” ein intelligentes Skript braucht.

Hier kommt PyScript ins Spiel, und es ist für mich die deutlich schlankere und charmantere Alternative. PyScript läuft nicht neben, sondern quasi in Home Assistant. Man spart sich den Overhead einer separaten Anwendung. Man hat direkten Zugriff auf alle Entitäten, als wären es native Python-Variablen.

PyScript wird über HACS installiert und man speichert die Scripte im /config/pyscript/ Ordner.

Nun war ich immer im Bereich der C-artigen Programmiersprachen tätig, also PHP, C, C++, JS oder C# unterwegs. Hier werden Strukturen mit geschweiften Klammern gebildet und Einrückungen sind zwar für die Lesbarkeit sinnvoll, ändern aber nichts an der Funktion. Meine Umgewöhnung hinsichtlich Python war hier schon recht groß. Allerdings belohnt Python mit erzwungen gut lesbarem und sehr elegantem Code, den jeder technikaffine und lernwillige Home Assistant Fan lernen kann.

Schauen wir uns unser Licht-Szenario in PyScript an. So sieht dieselbe Logik aus, wenn man sie programmiert:

Python

# Hier deine echten Entitäts-IDs eintragen
MOTION_SENSOR = "binary_sensor.bewegungsmelder_flur_occupancy"
LIGHT_ENTITY  = "light.flur_decke"
LUX_SENSOR    = "sensor.bewegungsmelder_flur_illuminance"

LUX_SCHWELLE  = 20
TIMEOUT_SEK   = 300 # 5 Minuten in Sekunden

# --- FUNKTION 1: EINSCHALTEN ---
# Triggert, wenn der Bewegungsmelder auf 'on' springt
@state_trigger(f"{MOTION_SENSOR} == 'on'")
def flur_licht_an():
    # Wir holen den aktuellen Helligkeitswert
    # WICHTIG: In HA sind States immer Strings,
    #daher float() zur Umwandlung
    try:
        aktuelle_lux = float(state.get(LUX_SENSOR))
    except (ValueError, TypeError):
        # Fallback, falls Sensor
        #'unavailable' ist -> Licht sicherheitshalber an
        #aktuelle_lux = 0

    # Bedingung prüfen
    if aktuelle_lux < LUX_SCHWELLE:
        light.turn_on(entity_id=LIGHT_ENTITY, brightness_pct=100, transition=1)
        log.info(f"PyScript: Flurlicht an (Lux: {aktuelle_lux})")

# --- FUNKTION 2: AUSSCHALTEN ---
# Triggert NUR, wenn der Sensor für 300 Sekunden DURCHGEHEND 'off' war
@state_trigger(f"{MOTION_SENSOR} == 'off'", state_hold=TIMEOUT_SEK)
def flur_licht_aus():
    # Prüfen, ob Licht überhaupt an ist (spart Funkverkehr)
    if state.get(LIGHT_ENTITY) == "on":
        light.turn_off(entity_id=LIGHT_ENTITY, transition=2)
        log.info("PyScript: Flurlicht aus nach Timeout")

Oder ganz ohne Kommentare:

MOTION_SENSOR = "binary_sensor.bewegungsmelder_flur_occupancy"
LIGHT_ENTITY  = "light.flur_decke"
LUX_SENSOR    = "sensor.bewegungsmelder_flur_illuminance"

LUX_SCHWELLE  = 20
TIMEOUT_SEK   = 300

@state_trigger(f"{MOTION_SENSOR} == 'on'")
def flur_licht_an():

    try:
        aktuelle_lux = float(state.get(LUX_SENSOR))
    except (ValueError, TypeError):
        aktuelle_lux = 0

    if aktuelle_lux < LUX_SCHWELLE:
        light.turn_on(entity_id=LIGHT_ENTITY, brightness_pct=100, transition=1)

@state_trigger(f"{MOTION_SENSOR} == 'off'", state_hold=TIMEOUT_SEK)
def flur_licht_aus():
    if state.get(LIGHT_ENTITY) == "on":
        light.turn_off(entity_id=LIGHT_ENTITY, transition=2)

Das ist extrem sauber, kurz und lesbar – vorausgesetzt, man beherrscht Python. Durch die Variablen zu Beginn, kann man den Code sehr einfach wiederverwenden, indem man einfach die Enitäten austauscht. Besonders spannend wird PyScript bei zwei Themen, die immer wichtiger werden:

1. KI und AI-Anwendungen: Python ist die Lingua Franca der künstlichen Intelligenz. Wer die API von OpenAI ansprechen, LangChain nutzen oder Daten an ein lokales LLM füttern will, um die Heizung wirklich intelligent zu steuern, ist hier richtig. In PyScript importiert man einfach die entsprechenden Libraries und ist startklar. In der oft isolierten Umgebung von AppDaemon ist das Einbinden externer Bibliotheken oft ein ziemliches Gefrickel. PyScript sitzt direkt an der Quelle.
2. Daten-Persistenz “light”: Manchmal will man Werte speichern, die einen Neustart überleben. Normalerweise müllt man sich die Home Assistant Instanz dafür mit unzähligen Helper-Entitäten (input_text, input_number, input_boolean) zu. Für jeden Wert, den man sich merken will, muss ein Helfer angelegt werden. Das bläht die Entitäten-Liste unnötig auf und macht das System träge.Mit PyScript spart man sich diese Materialschlacht. Man nutzt einfach die Standard-Python-Funktionen (open(), write()), um Daten in eine lokale Text- oder JSON-Datei im Config-Ordner zu schreiben.
3. Vibe-Coding : Hervorragende Coding-Unterstützung durch KI-Tools. ChatGPT, Gemini, Claude usw. “sprechen” Python am besten und können sofort lauffähige Vorschläge liefern oder helfen beim Debugging. Bei YAML versagen die Tools regelmäßig, sobald die Automationen komplexer werden. Zudem gibt es eine riesige Menge an Python-Bibliotheken, die man nutzen kann.

Vorteile:

• Simpler als AppDaemon: keine separate Instanz, kein Verbindungs-Overhead, kein Boilerplate Code
• AI-Ready: Perfekte Umgebung für die Einbindung moderner KI-Bibliotheken.
• Keine Helper-Flut: Daten werden in Dateien gespeichert, statt Dutzende Helfer-Entitäten anlegen zu müssen.
• Kompakt: Viel Logik auf wenig Raum.
• VSCode: Mit dem VSCode Editor als Addon , bekommt man viel Unterstützung beim Coding (und dem richtigen Einrücken).

Nachteile:

• Lernkurve: Ohne Python-Kenntnisse steht man vor einer Wand.
• Coding: Erfordert ein “Entwickler-Mindset”. Ohne jegliche Coding-Vorkenntnisse wird es schwierig.
• Keine UI: Code bleibt Code – hier gibt es nichts zu klicken.
• VSCode: … sollte man auch noch lernen

Der Vergleich im Überblick

#

FeatureNative AutomationNode-REDPyScriptEinstiegshürdeNiedrigMittelHoch (Python-Kenntnisse)VisualisierungUI / TracesFlow-ChartKeine (Code)DebuggingExzellent (Traces)Gut (Debug Node)Log-FilesWartungsaufwandMinimalMittel (Add-on)Minimal (Textfiles)KomplexitätWird schnell unübersichtlichGut strukturierbarPerfekt für AI & komplexe LogikArchitekturNative CoreSeparater ContainerIntegriert (einfacher als AppDaemon)

Realitäts-Check: Wo die Methoden an ihre Grenzen stoßen

#

Theorie ist gut, Praxis ist besser. Um zu verstehen, warum man alle drei Werkzeuge kennen (oder zumindest verstehen) sollte, schauen wir uns Beispiele an, bei denen der jeweils andere Weg scheitert oder einfach keinen Spaß macht.

1. Der Standardfall:: Bewegungsmelder & Licht

#

Hier gewinnt: Native Automation

Man könnte das in Node-RED bauen. Man könnte dafür ein Python-Skript schreiben (siehe oben). Aber warum?

Für eine simple “Bewegung an = Licht an”-Logik ist PyScript absoluter Overkill. Man holt nicht den großen Werkzeugkasten mit Programmiersprache, Datei-Handling und Importen raus, nur um einen Schalter umzulegen. Das ist mit Kanonen auf Spatzen geschossen.

Auch Node-RED ist hier eigentlich unnötig: Wenn der Node-RED-Container mal beim Update hängt, steht man im Dunkeln. Native Automationen sind hier robuster, schneller erstellt und benötigen null Wartung.

2. Der “Webhook-Parser”: Daten von extern

#

Hier gewinnt: Node-RED

Stellt euch vor, es kommt von einem externen Dienst (z.B. einer nicht integrierten Solaranlage oder einem DIY-Sensor) ein komplexes JSON-Objekt via Webhook rein. Man muss dieses JSON zerlegen, drei Werte extrahieren, prüfen, ob Wert A größer als Wert B ist, und das Ergebnis dann per MQTT-Payload in getrennten Topics senden.

• Native Automation: Das endet in der “Jinja2-Template-Hölle”. Wer schon mal versucht hat, verschachteltes JSON in YAML-Templates zu parsen, weiß, wovon ich spreche. Es ist unlesbar und fehleranfällig.
• PyScript: Möglich, aber man muss den Webhook erst einmal in Python “fangen”.
• Node-RED: Ein Traum. Ein http-in Node, ein function Node (oder change Node), MQTT-Send-Node und fertig. Man sieht visuell, wo die Daten langfließen.

3. Der “Mathematiker”: Dynamische Heizkurven & Arrays

#

Hier gewinnt: PyScript

Das Ziel: Eine dynamische Heizungssteuerung bauen, die nicht nur die Außentemperatur nimmt, sondern eine Liste der letzten 24 Stunden-Werte durchgeht, den Durchschnitt berechnet, Ausreißer entfernt, das Ganze mit dem Sonnenstand verrechnet und diesen Wert in eine Datei schreibt, um ihn morgen als Referenz zu nutzen.

• Native Automation: Nahezu unmöglich oder ein Konstrukt aus 20 Helper-Entitäten und endlosen Template-Sensoren.
• Node-RED: Man landet am Ende bei einem function-Node, in dem man… JavaScript schreibt. Wenn man also eh coden muss, warum dann nicht gleich in einer richtigen Umgebung?
• PyScript: Hier spielt Python seine Stärke aus. Listen iterieren, Statistik-Funktionen nutzen, Datei schreiben – das sind 10 Zeilen sauberer, lesbarer Code ohne Helper-Chaos.

Fazit und Empfehlung

#

Es gibt kein “Besser” oder “Schlechter”, es gibt nur das richtige Werkzeug für den jeweiligen Job.

Ich persönlich habe mich über die Jahre gewandelt. Anfangs habe ich vieles extern ausgelagert, einfach um der YAML-Hölle zu entfliehen. Mittlerweile verfolge ich den Ansatz: So nativ wie möglich.

1. Standard-Automationen: Licht, Heizung, einfache Benachrichtigungen erledige ich zu 90 % mit den nativen Home Assistant Automationen. Die UI ist mittlerweile so gut und die Traces so hilfreich, dass es keinen Grund gibt, dafür eine externe Engine anzuwerfen.
2. Datenverarbeitung & APIs: Wenn JSON-Daten von einer Webseite geparst werden müssen oder komplexe Verknüpfungen nötig sind, die sich schwer in der UI abbilden lassen, ist Node-RED das Mittel der Wahl.
3. AI, Mathematik & Speicher: Wenn Berechnungen angestellt werden müssen, Daten schnell in eine Datei wegschreiben werden sollen (ohne Helper-Chaos) oder eine KI ins Smarthome integriert werden soll, ist PyScript der Königsweg. Es ist leichter als AppDaemon und fühlt sich “näher” am System an.

Mein Ratschlag: Mit den Bordmitteln anfangen. Erst wenn man dort an harte Grenzen stößt oder merkt, dass die Automation unlesbar wird, sollte man den Blick auf Node-RED richten. Und wer Python kann? Der sollte sich PyScript ansehen – es könnte eine neue Liebe werden. Und wer Python nicht kann? Der bekommt mit den Möglichkeiten und der Eleganz von PyScript vielleicht einen triftigen Grund, sich damit zu beschäftigen.