↓ Zum Hauptinhalt springen
fricklr
fricklr
Smarthome 16 min

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

Wege, um Logik in das Smarthome zu bringen, gibt es viele. Doch welcher ist der richtige? Ein Vergleich zwischen den nativen Home Assistant Automationen, dem visuellen Node-RED und der programmatischen Lösung via PyScript – und warum die “YAML-Hölle” heute ihren Schrecken verloren hat.

Home-Assistant Node-Red Pyscript Yaml
Die Qual der Wahl: Home Assistant Automationen, Node-RED oder PyScript?
Inhaltsverzeichnis

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 YAMLDatenformat (YAML Ain’t Markup Language). Wird in Home Assistant für Konfigurationen, Automationen und Szenen verwendet. Leicht lesbar aber fehleranfällig bei falschen Einrückungen -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.

Home Assistant Empfehlungen
Oszilloskop & Multimeter (3-in-1)

Oszilloskop & Multimeter (3-in-1)

  • 【2-Kanal-Oszilloskop】50 MHz Bandbreite, 250 MSa/s Abtastrate, 1 kpts Aufzeichnungstiefe, automatische Messfunktion, max. Spannung 400 V, vertikale Empfindlichkeit 10 mV/div bis 10 V/div, unterstützt das Speichern und Exportieren von Wellenformbildern.
  • 【4,5-stelliges Multimeter mit 19999 Counts】Wechselspannung: 0–750 V, Gleichspannung: 0–999,9 V, Gleich-/Wechselstrom: 0–9,999 A, Widerstand: 0–19,99 MΩ, Kapazität: 0–99,99 mF, Durchgangsprüfung. Multifunktionsmessgerät für Profis, Schulen und Hobbyisten.
105,00 €
Ansehen
−15%
Deal
Automatischer Feuerlöscher für Schaltschränke und Server

Automatischer Feuerlöscher für Schaltschränke und Server

  • ✔ SOFORTIGE BRANDUNTERDRÜCKUNG BEI 170ºC ±10ºC – Der Ferosticker F03 aktiviert sich automatisch bei 170ºC ±10ºC und setzt ein Aerosol frei, das den Brand sofort löscht, indem es die Verbrennung unterbricht. Er bietet schnellen, automatischen Brandschutz in geschlossenen Räumen mit einem Schutzvolumen von 0,3 m³. Speziell für kleine, enge Bereiche entwickelt.
  • ✔ KEIN STROM, KEIN DRUCK, KEINE VERKABELUNG ERFORDERLICH – Im Gegensatz zu herkömmlichen Feuerlöschern funktioniert der Ferosticker ganz ohne Strom, Batterien oder Kabel. Sein selbstaktivierendes System sorgt für sorgenfreien Brandschutz ohne Wartung. Vielseitiger Schutz: wirksam gegen Brände der Klassen A, B, C, E und F – deckt ein breites Spektrum an Brandrisiken ab.
50,09 €
Ansehen
−9%
Deal
SONOFF SWV-ZFE Hydro ONE Zigbee Bewässerungscomputer Home Assistant Ready

SONOFF SWV-ZFE Hydro ONE Zigbee Bewässerungscomputer

  • Durable Brass Inlet: Dieser water timer verfügt über einen robusten Messinganschluss für zuverlässige Leistung, sorgt für stabilen Betrieb in Ihrem bewässerungssystem garten oder bewässerungssystem, ideal für den langfristigen Einsatz.
  • Flexible Zeitpläne & Mengensteuerung: Erstellen Sie bis zu sechs Pläne für zeit- oder mengenbasierte Bewässerung. Wetter- und saisonale Anpassungen optimieren Ihr bewässerungssystem garten und sparen Wasser – ein intelligenter sprinkler-timer.
Ansehen
SONOFF NSPanel Pro Gen2 Smart Home Bedienfeld Home Assistant Ready

SONOFF NSPanel Pro Gen2 Smart Home Bedienfeld

  • Multi-App Unterstützung & Home Assistant-Integration: 2GB RAM + 32GB Speicher für flüssige Nutzung mehrerer Drittanbieter-Apps – kein Root erforderlich, einfach über F-Droid als Home Assistant Steuerzentrale nutzbar. All-in-One Smart Panel ersetzt zusätzliche Tablets.
  • Matter Bridge für universelle Kompatibilität: Integriertes Matter Gateway verbindet Zigbee‑ & Wi‑Fi‑Geräte mit Apple Home, Google Home, Alexa & Home Assistant. Vereinheitlicht alle Marken und Protokolle für ein nahtloses Smart Home Erlebnis.
Ansehen
Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Preis inkl. MwSt., zzgl. Versandkosten.

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 Node-REDVisuelle Programmierumgebung für Flows. In Home Assistant oft als Add-On genutzt, um komplexe Automationen grafisch per Drag & Drop zu erstellenMehr dazu → als Quasi-Standard für komplexe Abläufe etabliert und für die Coder gibt es mit PyScript PyScriptErmöglicht das Schreiben von Home Assistant Automationen in Python statt YAML. Bietet mehr Flexibilität für komplexe Logik mit Schleifen und BedingungenMehr dazu → eine mächtige Python- Integration IntegrationIn Home Assistant: die Anbindung eines Geräts oder Dienstes über ‚Geräte & Dienste’. Jede Integration stellt Entitäten bereit (z.B. Shelly, Zigbee, MCP). Nicht zu verwechseln mit dem allgemeinen IT-BegriffMehr dazu → .

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 UIUser Interface – die sichtbare Oberfläche einer Software (Fenster, Menüs, Buttons). In HA: das Dashboard (Lovelace), Einstellungen und der Add-On-Store ) 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 TriggerAuslöser einer Home-Assistant-Automation – das Ereignis, das den Ablauf startet (z.B. Sonnenuntergang, Sensorwert, Zeit). Erster Baustein jeder Automation (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:

yaml 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

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 AutomationRegelbasierte Ablaufsteuerung in Home Assistant: Auslöser (Trigger), Bedingungen und Aktionen führen automatisch einen Ablauf aus (z.B. Licht bei Sonnenuntergang einschalten) 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 Add-OnZusätzliches Softwarepaket für Home Assistant OS/Supervised, installiert über den Add-On-Store (heißt in neueren HA-Versionen „Apps“). Läuft als eigener Container neben dem Core – z.B. das SSH-Add-OnMehr dazu → 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 APIApplication Programming Interface – definierte Schnittstelle, über die Programme kommunizieren. Home Assistant bietet eine REST- und eine WebSocket-API (z.B. für MCP) 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 MQTTLeichtes Publish/Subscribe-Nachrichtenprotokoll. Wird in Smart Homes verwendet, um Sensordaten und Steuerbefehle zwischen Geräten auszutauschenMehr dazu → , 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 BackupUnabhängige Sicherung zur Wiederherstellung des gesamten Systems oder wichtiger Daten. Ein Home-Assistant-Backup ergänzt Git und ersetzt die Versionshistorie nichtMehr dazu → -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-bigtimer – Mä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-plus – Unterstützt CRON-Syntax und dynamische Erstellung von Zeitplänen zur Laufzeit.
  • node-red-contrib-boolean-logic-ultimate – Erspart 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-advanced – Um Dinge blinken zu lassen oder Benachrichtigungen zu wiederholen (“Garage ist noch offen!”), bis einer reagiert.
  • node-red-contrib-influxdb – Direkt in InfluxDB schreiben.
  • node-red-contrib-zigbee2mqtt – Auf zigbee2mqtt zugreifen.
  • node-red-contrib-huemagic – Sehr 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 HACSHome Assistant Community Store – Inoffizieller Marktplatz für Integrationen, Add-Ons und benutzerdefinierte Dashboards aus der CommunityMehr dazu → 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

python 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# 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:

python 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

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 LLMLarge Language Model – KI-Modell, das auf riesigen Textmengen trainiert wurde und natürliche Sprache verstehen und generieren kann. Beispiele: GPT-4, Claude, Gemini, DeepSeek. Grundlage für Chatbots wie ChatGPT und GitHub Copilot 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 HelperVirtuelle Entitäten in Home Assistant zur Datenverarbeitung und Steuerung (z.B. Umschalter, Schieberegler, Zeitplan). Angelegt über Einstellungen → Geräte & Dienste → Helfer -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 ClaudeKI-Assistent von Anthropic (Modelle Sonnet, Opus, Haiku). Nutzt MCP nativ – Claude Desktop war einer der ersten MCP-Clients und kann direkt auf deinen HA-Server zugreifen 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

Feature Native Automation Node-RED PyScript
Einstiegshürde Niedrig Mittel Hoch (Python-Kenntnisse)
Visualisierung UI / Traces Flow-Chart Keine (Code)
Debugging Exzellent (Traces) Gut (Debug Node) Log-Files
Wartungsaufwand Minimal Mittel (Add-on) Minimal (Textfiles)
Komplexität Wird schnell unübersichtlich Gut strukturierbar Perfekt für AI & komplexe Logik
Architektur Native Core Separater Container Integriert (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.

Hallo! Ich bin Markus – der Fricklr. ⚡ Elektrotechniker, 🎵 Musiker (Bass, Gitarre, Keyboard) und seit über 30 Jahren beruflich „irgendwas mit Internet“ 🌐 – inzwischen auch mit KI 🤖 – ein 55-jähriger Generalist aus Bayern.

Dein Feedback hilft mir, noch interessantere Beiträge zu schreiben. Bei „Ja“ findest du danach eine kleine Option, meine Arbeit zu unterstützen.

Verwandte Themen entdecken

Inhaltskarte →
Verbindungen als Liste anzeigen
💡 Ziehen, hover & klicken zum Entdecken
Größere Punkte sind relevanter
Alle Smarthome →

Was sagst du dazu? Kommentiere jetzt!

Teile deine Gedanken, Fragen oder Erfahrungen mit der Community.

Mit diesem Symbol gekennzeichnete Links sind Affiliate-Links (Werbung). Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Für dich entstehen keine Mehrkosten.