↓ Skip to main content
fricklr
fricklr
Smarthome 10 mins

The Dilemma: Home Assistant Automations, Node-RED or PyScript?

There are many ways to bring logic into the smart home. But which is the right one? A comparison between native Home Assistant automations, the visual Node-RED, and the programmatic solution via PyScript – and why the “YAML hell” has lost its horror today.

Home-Assistant Node-Red Pyscript Yaml
The Dilemma: Home Assistant Automations, Node-RED or PyScript?
Table of Contents

Those who have been around in the Home Assistant universe for a while may still remember with a slight shudder the early days. Back then, creating automations was a pure text task in YAML YAMLData format (YAML Ain’t Markup Language). Used in Home Assistant for configurations, automations and scenes. Easy to read but error-prone with incorrect indentation files. And by that, I don’t mean relaxed configuring, but the daily battle against the invisible final boss: the space character.

Welcome to YAML Indentation Hell.

One space too few? Configuration error. One space too many? The system won’t boot. A tab instead of two spaces? Catastrophe! You often felt like a bomb disposal expert, trying with trembling hands to slide the entity_id exactly two spaces below the action block. You stared at the screen for hours, doubted your sanity, only to discover in the end that line 42 was a millimeter too far to the left.

⚠ [affiliate] Keine Produkte mit Cache für home-assistant. Bitte affiliate-sync --lang en ausführen.

Those who – like me – came from systems like IP-Symcon had it particularly hard. I used to be an absolute “PHP Guy.” In the Symcon world, it was easy for me to just program through even the most complex automations because I spoke the language.

In Home Assistant, on the other hand, you initially felt lost in the text desert, painfully missed a real scripting language, and needed Zen-Buddhist patience just to turn on the hallway light via motion sensor when dark. More extensive automations were only feasible directly in YAML.

Fortunately, Home Assistant has massively evolved. The graphical editor for automations has become powerful and takes away this Sisyphean task. In parallel, Node-RED Node-REDVisual programming environment for flows. Often used as a Home Assistant add-on to create complex automations graphically via drag & dropRead more → has established itself as a quasi-standard for complex processes, and for coders, there’s PyScript PyScriptEnables writing Home Assistant automations in Python instead of YAML. Provides more flexibility for complex logic with loops and conditionsRead more → , a powerful Python integration.

But when do you use which tool? I’ve looked at the three most common methods and present their pros and cons.

The Scenario: Light On When Motion Detected

To make the approaches comparable, we use an absolutely classic example found in almost every household: A motion detector in the hallway should turn on a lamp, but only when it’s dark enough (brightness < 20 lux). When no more motion is detected, the light should turn off again.

1. Native Home Assistant Automations

The integrated engine has matured enormously in recent years. What used to be said tedious YAML hacking can now be clicked together almost entirely via the user interface ( UI UIUser Interface – the visible surface of software (windows, menus, buttons). In HA: the dashboard (Lovelace), settings and the add-on store ). Home Assistant still writes the YAML in the background, but you no longer have to look at it – and above all, no longer manually indent it.

The flow is linear: Trigger TriggerTrigger of a Home Assistant automation – the event that starts the flow (e.g. sunset, sensor value, time). First building block of every automation (motion detected) -> Condition (only when dark) -> Action (light on) -> Trigger no motion for 5 min -> Action light off.

Even though you mostly click today, it’s worth looking at the code that’s created in the background to understand the structure:

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

alias: "Hallway Light: Motion and Brightness"
mode: restart
triggers:
  - trigger: state
    entity_id: binary_sensor.hallway_motion_occupancy
    from: "off"
    to: "on"
    id: "motion_detected"
  - trigger: state
    entity_id: binary_sensor.hallway_motion_occupancy
    to: "off"
    for:
      minutes: 5
    id: "no_more_motion"
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "motion_detected"
          - condition: numeric_state
            entity_id: sensor.hallway_motion_illuminance
            below: 20
        sequence:
          - action: light.turn_on
            target:
              entity_id: light.hallway_ceiling
            data:
              brightness_pct: 100
              transition: 1
      - conditions:
          - condition: trigger
            id: "no_more_motion"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.hallway_ceiling
            data:
              transition: 2

This is solid, readable, but even with this simple logic, you can see why it can become confusing with more complex nesting.

A huge advantage of native automations is the trace function. You can visually and interactively track why an automation triggered – or why it didn’t. Especially during troubleshooting, this is worth its weight in gold and, in my opinion, is now better solved than debugging in many other tools.

Advantages:

  • Deeply integrated: No additional software needed, Home Assistant updates cover everything.
  • Performance: Since it runs directly in the core, latency is minimal.
  • Debugging: The trace timeline is excellent for error analysis.
  • Blueprints: You can use ready-made templates from the community without reinventing the wheel.

Disadvantages:

  • Complexity with branching: As soon as you need nested “if-then” logic or loops, the UI quickly becomes confusing.
  • YAML knowledge: For very specific things (templates), you end up back in the code editor – but at least usually only as one-liners.

2. Node-RED

For many, Node-RED is the holy grail of home automation. It’s a visual programming tool where you connect “nodes” with wires. It usually runs as an add-on alongside Home Assistant.

For visual types, this is a blessing. You literally see the flow of data before you. Our example would be a chain of: Event State Node (motion) -> Switch Node (brightness check) -> Call Service Node (light on).

Node-RED plays to its strengths when logic becomes complex. When data needs to be fetched from an API APIApplication Programming Interface – defined interface through which programs communicate. Home Assistant offers a REST and a WebSocket API (e.g. for MCP) , reformatted, filtered, and then sent to three different services, that’s often clicked together in Node-RED in a few minutes. In YAML, that would be a nightmare from which you wake up drenched in sweat.

A perfect example is my project where I made our door camera smarter . When the doorbell rang, the TV had to turn on, switch to the right HDMI input, and display the camera image. Such chains of different protocols (HDMI-CEC, MQTT MQTTLightweight publish/subscribe messaging protocol. Used in smart homes to exchange sensor data and control commands between devices , camera streams) are Node-RED’s specialty.

However, Node-RED introduces another level of complexity. It’s an independent system that needs maintenance. If the add-on fails, the light stays off, even if Home Assistant is still running. It also tempts you to build huge “spaghetti monsters” – confusing cable chaos flows that you yourself no longer understand after three months.

Advantages:

  • Visual overview: Data flows are intuitively graspable.
  • Powerful: Enormous library of “palettes” (extensions) for almost every use case.
  • Flexibility: Ideal for complex logic and data manipulation.

Disadvantages:

  • Additional maintenance: Another system that needs care.
  • Overhead: For simple “light on/off” stories, often like using a sledgehammer to crack a nut.
  • Separation: The logic lies outside the actual Home Assistant configuration (mind your backup strategy!).

3. PyScript (Python) – The AppDaemon Killer?

For a long time, AppDaemon was the undisputed top dog for everyone who wanted more power than YAML could offer. AppDaemon is powerful and has its raison d’être – but it’s also a “beast of its own.” It runs as a separate instance next to Home Assistant, must be configured separately, and often feels unnecessarily complicated when you “just quickly” need an intelligent script.

This is where PyScript comes in, and for me, it’s the noticeably leaner and more charming alternative. PyScript doesn’t run next to, but virtually inside Home Assistant. You save the overhead of a separate application. You have direct access to all entities as if they were native Python variables.

PyScript is installed via HACS HACSHome Assistant Community Store – unofficial marketplace for integrations, add-ons and custom dashboards from the community , and you save the scripts in the /config/pyscript/ folder.

Let’s look at our light scenario in PyScript:

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

MOTION_SENSOR = "binary_sensor.hallway_motion_occupancy"
LIGHT_ENTITY  = "light.hallway_ceiling"
LUX_SENSOR    = "sensor.hallway_motion_illuminance"

LUX_THRESHOLD  = 20
TIMEOUT_SEC    = 300

@state_trigger(f"{MOTION_SENSOR} == 'on'")
def hallway_light_on():
    try:
        current_lux = float(state.get(LUX_SENSOR))
    except (ValueError, TypeError):
        current_lux = 0

    if current_lux < LUX_THRESHOLD:
        light.turn_on(entity_id=LIGHT_ENTITY, brightness_pct=100, transition=1)
        log.info(f"PyScript: Hallway light on (Lux: {current_lux})")

@state_trigger(f"{MOTION_SENSOR} == 'off'", state_hold=TIMEOUT_SEC)
def hallway_light_off():
    if state.get(LIGHT_ENTITY) == "on":
        light.turn_off(entity_id=LIGHT_ENTITY, transition=2)
        log.info("PyScript: Hallway light off after timeout")

This is extremely clean, short, and readable – provided you know Python. With variables at the beginning, you can reuse the code very easily by simply swapping the entities.

PyScript becomes especially exciting for two topics that are becoming increasingly important:

  1. AI and AI Applications: Python is the lingua franca of artificial intelligence. Those who want to use the OpenAI API, LangChain, or feed data to a local LLM LLMLarge Language Model – AI model trained on vast amounts of text that can understand and generate natural language. Examples: GPT-4, Claude, Gemini, DeepSeek. Foundation for chatbots like ChatGPT and GitHub Copilot to intelligently control the heating are in the right place. In PyScript, you simply import the corresponding libraries and are ready to go.
  2. Lightweight Data Persistence: Sometimes you want to store values that survive a restart. Normally, you clutter your Home Assistant instance with countless helper entities (input_text, input_number, input_boolean). With PyScript, you use standard Python functions (open(), write()) to write data to a local text or JSON file in the config folder.
  3. Vibe Coding: Excellent coding support through AI tools. ChatGPT, Gemini, Claude ClaudeAI assistant by Anthropic (Sonnet, Opus, Haiku models). Uses MCP natively – Claude Desktop was one of the first MCP clients and can access your HA server directly , etc. “speak” Python best and can deliver immediately runnable suggestions or help with debugging. With YAML, the tools regularly fail once automations become more complex.

Advantages:

  • Simpler than AppDaemon: No separate instance, no connection overhead, no boilerplate code
  • AI-Ready: Perfect environment for integrating modern AI libraries
  • No Helper HelperVirtual entities in Home Assistant for data processing and control (e.g. toggles, sliders, schedules). Created via Settings → Devices & Services → Helpers Flood: Data stored in files instead of creating dozens of helper entities
  • Compact: Lots of logic in little space

Disadvantages:

  • Learning curve: Without Python knowledge, you’re facing a wall.
  • Coding: Requires a “developer mindset”.
  • No UI: Code remains code – nothing to click here.

The Comparison at a Glance

Feature Native Automation AutomationRule-based workflow in Home Assistant: triggers, conditions and actions automatically execute a flow (e.g. turn on lights at sunset) Node-RED PyScript
Barrier to Entry Low Medium High (Python)
Visualization UI / Traces Flow Chart None (Code)
Debugging Excellent (Traces) Good (Debug Node) Log Files
Maintenance Minimal Medium ( Add-on Add-onAdditional software package for Home Assistant OS/Supervised, installed via the add-on store (renamed to ‘Apps’ in newer HA versions). Runs as its own container alongside core – e.g. the SSH add-on ) Minimal (Text files)
Complexity Quickly confusing Well structurable Perfect for AI & complex logic

Conclusion and Recommendation

There’s no “better” or “worse,” there’s only the right tool for the respective job.

Personally, I’ve transformed over the years. Initially, I outsourced a lot externally, just to escape YAML hell. Nowadays, I pursue the approach: As native as possible.

  1. Standard Automations: Light, heating, simple notifications – I handle 90% with native Home Assistant automations. The UI is now so good and the traces so helpful that there’s no reason to fire up an external engine for this.
  2. Data Processing & APIs: When JSON data from a website needs to be parsed or complex connections are needed that are hard to map in the UI, Node-RED is the tool of choice.
  3. AI, Mathematics & Storage: When calculations need to be made, data needs to be quickly written to a file (without helper chaos), or AI is to be integrated into the smart home, PyScript is the royal road. It’s easier than AppDaemon and feels “closer” to the system.

My advice: Start with the built-in tools. Only when you hit hard limits there or notice that the automation is becoming unreadable should you look at Node-RED. And if you know Python? Then you should take a look at PyScript – it could become a new love. And if you don’t know Python? The possibilities and elegance of PyScript might give you a compelling reason to get into it.

Hi! I'm Markus – the Fricklr. ⚡ Electrical engineer, 🎵 musician (bass, guitar, keys) and professionally 'something with the internet' 🌐 for over 30 years – nowadays with AI too 🤖 – a 55-year-old generalist from Bavaria, Germany.

Your feedback helps me write even more interesting posts. After "Yes" there's also a small option to support my work.

Explore related topics

Content Map →
Show related content as a list
💡 Drag, hover & click to explore
Bigger dots are more relevant
Explore all Smarthome →

What do you think? Leave a comment!

Share your thoughts, questions or experiences with the community.

Links marked with this symbol are affiliate links. As an Amazon Associate I earn from qualifying purchases. There are no additional costs for you.