Node-RED vs Home Assistant Automations: When the Visual Flow Wins
Node-RED vs Home Assistant automations comes down to readability under pressure: I run roughly 90% of my rules as native HA automations (trigger, condition, action) living in version-controlled YAML, and reach for Node-RED only for the gnarly stateful, multi-branch flows where the YAML stops being readable. Both talk to the same entities, so they coexist on my hub without conflict.
That is the short version, and after years of running Home Assistant automations on a dedicated Intel N100 hub, I have stopped treating this as a religious war. It is a tooling choice, and the right answer is “both, for different jobs.” Below I walk through what each one actually is, where each earns its keep, how they behave on restart, what debugging looks like at 11pm, and why performance is almost never the thing that decides it.
What native Home Assistant automations actually are
Native HA automations are the trigger/condition/action rules built into Home Assistant itself. A trigger fires (a sensor changes, a time hits, an event arrives on the MQTT bus), optional conditions gate it, and actions run. They live in your config as YAML, which means they are diffable, version-controllable, and survive a reinstall.
That last part is why native automations are my default. In my setup, every automation is text. I keep the config in a git repo, so when I change the way a presence routine is wired I can see the diff, roll it back, and know exactly what changed. The visual automation editor in the HA frontend writes the same YAML underneath, so beginners are not locked out, but the source of truth is plain text I can grep.
The grammar is small on purpose. Triggers are things like state, numeric_state, time, mqtt, template, and the newer trigger-based template sensors I lean on. Conditions are the same building blocks I cover in my automation conditions guide, and actions call services on entities. Most of my house, including everything in my automation examples, is exactly this: short, linear rules. Motion plus low lux turns on a scene. A contact sensor opens, a notification fires. A power clamp drops below a threshold, the washing-machine-done routine runs. None of that needs a flow editor.
What Node-RED is and how it talks to HA
Node-RED is a separate visual flow editor, usually run as a Home Assistant add-on, that talks to HA over the WebSocket API. You wire nodes together on a canvas: an event node listens for a state change, a switch node branches, a delay node waits, a call-service node acts. It is a general automation engine that happens to have excellent HA integration, not a part of HA core.
Because it speaks to HA over the WebSocket, Node-RED sees the same entities, the same state machine, and the same services my native automations do. It is not a parallel universe; it is another client of my hub. That matters: a Node-RED flow and a native automation can read the same mmWave presence sensor and call the same light scene without stepping on each other, as long as I do not have two rules fighting over one entity.
The appeal is visual reasoning. When a rule has five branches, three timers, and a state machine that has to remember “is the away-mode countdown running,” a flow diagram is genuinely easier to read than the equivalent nested YAML. You see the paths. You see the dead ends. For a certain class of logic, that picture is worth more than any amount of indentation discipline. Node-RED also overlaps conceptually with the trigger/action thinking behind reusable blueprints — both are about packaging logic — but blueprints stay inside HA and stay as YAML.
My real stance: native for 90%, Node-RED for the gnarly 10%
My stance after years of this: native HA automations for about 90% of rules, Node-RED for the stateful, heavily-branching 10% where YAML turns into an unreadable pyramid. The deciding question is never “which is faster,” it is “which one will I still understand in six months.”
The 90% is everything linear. One trigger, maybe a condition or two, one or two actions. Lights, scenes, notifications, the routine I run to drop the radiator TRVs at night, the leak-sensor-shuts-the-valve rule. These read fine as YAML, they version-control cleanly, and they sit right next to my template sensors and helpers in the same config. Wrapping that in a flow editor would be ceremony for no benefit.
The 10% is the stuff that makes me wince in YAML. Multi-stage morning routines that branch on who is home, the day of week, and whether the away countdown already cancelled itself. Anything with a real state machine. Anything where I am tempted to write a choose block nested inside another choose block with three repeat loops. The moment I cannot read my own automation aloud, that is the signal it should be a Node-RED flow. The visual layout makes the branching legible in a way the YAML never will.
Node-RED vs Home Assistant automations: the comparison
Here is how the two stack up across the dimensions that actually decide it for me. Notice that performance is not the headline — readability, restart safety, and how each handles version control matter far more in a real self-hosted setup.
| Dimension | Native HA automations | Node-RED |
|---|---|---|
| Readability / learning curve | Easy for linear rules; gets ugly with deep nesting | Steeper start; far clearer for branching, stateful logic |
| Restart safety | Reloads with HA; timers and delays can be lost on restart unless designed around it | Runs as a separate add-on; flow state can persist across an HA restart but not always a Node-RED restart |
| Version control in YAML | Native — automations are YAML, diff and roll back in git | Flows are JSON; technically diffable but the JSON is noisy and not human-friendly |
| Performance / latency | In-process, very low overhead | Extra WebSocket hop; overhead is real but tiny — rarely the deciding factor |
| Debugging | Trace view shows the path a single run took; logbook and templates help | Live debug nodes and node-by-node message inspection; excellent for watching a flow execute |
| Where it lives | Inside HA core, in your config | Separate add-on / container, talks to HA over WebSocket |
The table makes the split obvious. For a one-line rule, native wins on every axis that matters to me: it is in my git repo, it is in-process, and there is nothing extra to keep running. For a ten-branch flow, Node-RED wins on the one axis that actually hurts — being able to read it.
Restart behaviour, and why it bites people
Restart behaviour is the difference that surprises people. Native automations reload with Home Assistant, and any in-flight delay or wait inside an automation is generally lost when HA restarts. Node-RED runs as its own add-on, so an HA restart does not necessarily kill a running flow’s timers — but a Node-RED restart will.
This matters because half my house depends on timers. A “turn the bathroom fan off after fifteen minutes” rule, an away-mode countdown, a porch light that holds for two minutes after the last motion. If HA restarts mid-delay, a naively written native automation simply forgets the timer existed, and the fan stays on or the light never turns off. The robust pattern is to not rely on an in-memory delay at all: store the deadline in a helper or an input_datetime, and let a separate time-trigger automation check it. This is closely related to the broader problem I cover in automations firing on restart — restart is a state change like any other, and you have to design for it.
Node-RED is not magically immune. Its persistence depends on how the flow is built and how its context store is configured. A delay node mid-flow can survive an HA core restart because Node-RED is a separate process, but it will not survive Node-RED itself restarting unless you have persisted the context. So neither tool lets you ignore the problem. Both reward designing your stateful logic so that the source of truth is a persisted entity, not an in-memory timer that evaporates the moment a process bounces.
Debugging at 11pm
The honest test of any automation tool is what debugging feels like at 11pm when a routine misfires and you want to be asleep. Here the two diverge in style: native HA gives you a trace of the single run that happened, Node-RED lets you watch messages flow node by node in real time.
HA’s automation trace is excellent for “why did this one automation do that.” It shows you the exact path: which trigger fired, which conditions passed or failed, which action ran, with the actual values at each step. For a linear rule, that trace usually tells me the answer in ten seconds. The logbook fills in the surrounding context, and a quick template in the developer tools confirms what an entity’s state really was.
Node-RED’s strength is watching a flow live. Drop a debug node on a wire and you see every message passing through it, with its full payload. For a branching flow where I am not sure which path a message is taking, that live view is far better than reading a static trace. The trade is that you are debugging in the canvas, not in your config and not in your git history. For the gnarly 10% that is fine, because those flows are the ones I most need to watch execute. For everything else, the native trace plus the logbook is faster, and it is all the more reason I keep scenes, scripts, and automations native where I can.
Performance is rarely the deciding factor
Performance almost never decides this for me. Yes, native automations run in-process and Node-RED adds a WebSocket hop, so native has lower overhead. But on a dedicated N100 hub, the latency difference between a native rule and a Node-RED flow firing a light is well under the threshold you would ever notice in a room.
The numbers people worry about are not the numbers that matter. A native automation and a Node-RED flow both react to the same state change pushed over the same event bus; the extra hop is the WebSocket round-trip inside the same machine, which is trivial on local hardware. If your automations feel laggy, the cause is almost always elsewhere: a slow Zigbee mesh with a weak repeater, a cloud integration introducing round-trips you did not want, or presence detection that is genuinely slow to settle. Move that integration local, fix the mesh, and the lag goes away regardless of which tool wrote the rule.
So I do not pick Node-RED to go faster, and I do not avoid it to save milliseconds. I pick the tool that makes the logic readable and the failure modes survivable. Performance is a tie-breaker that almost never gets to break the tie.
They coexist fine — and that is the point
The best part is that this is not an either/or decision. Native automations and Node-RED both connect to the same Home Assistant, the same entities, the same services. On my hub they run side by side: the linear 90% as YAML in my git repo, the branching 10% as flows in the add-on, and nothing fights as long as I do not have two rules controlling one entity in opposite directions.
That coexistence is what lets me be pragmatic. I do not have to commit to a philosophy. A new rule starts life as a native automation because that is the lowest-ceremony path and it lands in version control for free. If it grows a state machine and three branches and starts hurting to read, I move it into Node-RED and leave the rest of my config exactly as it was. The hub does not care. The entities do not care. Only my future self, reading the logic at 11pm, cares — and that future self is the one this whole decision is really for.
Frequently asked questions
Is Node-RED better than Home Assistant automations?
Neither is strictly better. Native HA automations win for linear rules because they are YAML, version-controllable, and in-process. Node-RED wins for branching, stateful logic where YAML becomes unreadable. Most setups should use both for different jobs.
Do I need Node-RED if I use Home Assistant?
No. Native HA automations handle roughly 90% of rules perfectly well. Only add Node-RED when you hit genuinely gnarly multi-branch, stateful flows where the equivalent YAML turns into an unreadable nested pyramid that you cannot read aloud.
Does Node-RED run faster than native automations?
No. Native automations run in-process with the lowest overhead, while Node-RED adds a WebSocket hop. On local hardware like an N100 hub the difference is well under what you would ever notice, so performance rarely decides the choice.
Can Node-RED and Home Assistant automations run at the same time?
Yes. Node-RED talks to HA over the WebSocket and shares the same entities and services as native automations. They coexist fine as long as you do not have two separate rules controlling one entity in opposite directions.
What happens to Node-RED flows when Home Assistant restarts?
A running Node-RED flow can survive an HA core restart because Node-RED is a separate add-on, but in-flight timers will not survive a Node-RED restart unless context is persisted. Native automation delays are generally lost on an HA restart.
Are Node-RED flows version-controllable like YAML automations?
Technically yes, but poorly. Flows are stored as JSON that is diffable yet noisy and not human-friendly. Native HA automations are clean YAML you can diff and roll back in git, which is why I keep most logic native.
