I Run a 933-Entity Smart Home With Zero Home Assistant Automations. Here’s Why.

Home Assistant is my hub. Node-RED is my brain. After years of tinkering and 145 devices, I still haven’t written a single native automation — and I’d do it all again.

Open my Home Assistant, go to Settings → Automations & Scenes, and you’ll find something that makes most people assume I just installed it yesterday:

• Automations: 0
• Scenes: 0
• Scripts: 1 — and it’s called “New Script.” I’ve never touched it.

Now look at the rest of the house. 933 entities. 145 devices. 15 areas. Shelly relays everywhere, SmartThings, Home Connect appliances, Reolink and Ring cameras, a SolaX solar inverter, a Securitas alarm, Matter locks, a UPS on NUT, my own ESPHome boards, BTHome sensors. This is not a fresh install. It’s a mature, slightly over-engineered home.

And the native automation engine is completely empty.

Not because I don’t automate — my house does plenty on its own. It’s because none of that logic lives in Home Assistant. It all lives in Node-RED. This is a deliberate architectural choice I made early and have never regretted, and I want to explain why, where it shines, and — honestly — where it bites.

The split: Home Assistant is the hub, Node-RED is the brain

The mental model is simple, and once it clicks it’s hard to unsee:

Home Assistant ownsNode-RED ownsIntegrations & device connectivityEvery if-this-then-thatState, history, the recorderEvery schedule and timerDashboards & the mobile appAll branching and conditionsVoice / Assist pipelineState machines and sequencesAuth, users, areasAnything touching external data

Home Assistant is spectacular at talking to hardware. Hundreds of integrations, a unified state model, a great UI. I would never give that up. But its automation engine — YAML, or the visual editor that generates YAML — is where I get off the bus. The moment logic gets interesting, YAML gets ugly.

So I let each tool do what it’s best at:

Events flow up from HA into Node-RED. Decisions flow back down as service calls. The two are joined by the node-red-contrib-home-assistant-websocket nodes, which give Node-RED a live, real-time view of every entity in the house.

The trick most “Node-RED vs HA” posts miss: writing back to HA

Here’s the part that makes this setup actually livable for a family, not just for me.

If you grep my entity list for things created by Node-RED, you find exactly five:

• switch.automation_rega_manha — morning garden irrigation
• switch.automation_rega_tarde — afternoon irrigation
• switch.button_close_covers — close every blind in the house
• one more covers button
• the Node-RED hub entity itself

Those aren’t toggles I built in HA. Node-RED created them. Using the entity/config nodes, a flow can publish its own switches, buttons, and sensors back into Home Assistant. So my irrigation logic lives entirely in a Node-RED flow — but my wife sees a clean Morning Irrigation switch on the dashboard. She can flip it off before a garden party without knowing Node-RED exists. The "close all covers" flow shows up as a button she can tap from the sofa or the HA app on her phone.

That’s the whole game: the power and readability of flow-based logic, wrapped in the polish of the Home Assistant UI. The brain does the thinking; it just reports back to the hub in a language the rest of the household already speaks.

Why Node-RED wins for the logic that actually matters

A motion-light automation? Fine, do it in YAML, I won’t judge you. But that’s not where the value of a smart home is. The value is in the messy logic — and that’s exactly where the visual, debuggable, stateful nature of Node-RED pulls ahead.

Irrigation. My Rega Manhã and Rega Tarde flows aren't just timers. They check the IPMA weather forecast, skip a cycle if rain is coming, adjust by season, and stagger valves so I don't drop pressure. Expressing "water at 7am unless it rained overnight or it's forecast to rain today and it's not winter" in a native automation is a template nightmare. As a flow it reads like a flowchart, because it is one.

Energy — the killer case. This is the one I’d never attempt in YAML. I live in Portugal, so I pull the OMIE Iberian spot price, combine it with Forecast.Solar production estimates and my SolaX battery state of charge, and decide when to run the dishwasher, heat water, or lean on the battery versus the grid. That’s a genuine decision tree with live external data on three axes. In Node-RED it’s a few function and switch nodes I can watch execute in real time with debug nodes inline. In a native automation it would be an unmaintainable wall of Jinja that I’d be terrified to ever touch again.

Debuggability. When something misfires, I drop a debug node on a wire and watch the messages flow. I can inject a test message to fire a branch on demand. I can see the exact payload that triggered the wrong path. Debugging a YAML automation, by comparison, is reading traces and guessing.

The honest trade-offs

This is not a free lunch, and I’d be lying if I pretended otherwise.

• It’s another moving part. If the Node-RED add-on is down, my house gets dumb — every bit of logic stops. Native automations run inside HA core, so they’re more resilient by default. I mitigate with monitoring and the fact that the add-on is genuinely stable, but the risk is real.
• Backups and version control take effort. Your logic now lives in flows.json, not in HA's config. I run Node-RED Projects backed by Git so I have history and can roll back, but you have to set that up deliberately — it's not automatic.
• The learning curve is real. Flow-based programming clicks for some people instantly and frustrates others for weeks. If you’ve never used it, your first complex flow will be spaghetti.
• It’s overkill for a small setup. If you have ten entities and three automations, installing Node-RED is bringing a forklift to carry a grocery bag. The payoff scales with complexity.

If you’re brand new to Home Assistant, don’t start here. Learn the native engine first. Feel where it hurts. Then the case for Node-RED will make itself.

When I still reach for native Home Assistant

I’m not a purist, and “zero automations” isn’t dogma — it’s just where the line landed for me. I still lean on HA for:

• Template sensors (a dozen of them) — deriving and reshaping state belongs close to the data.
• Helpers and switch_as_x — turning a switch into a light, input booleans, groups. Cheap, native, no reason to involve the brain.
• The Assist / voice pipeline and the whole UI layer.

The dividing line is clean once you internalize it: state representation stays in HA; behaviour goes to Node-RED. If I’m describing what something is, that’s a template or a helper. If I’m describing what should happen, when, and under which conditions, that’s a flow.

My rule of thumb

If it’s a value, a label, or a simple transform → Home Assistant helper or template. If it’s logic, timing, branching, or external data → Node-RED.

933 entities later, that single rule has kept my setup powerful where it needs to be and boring where it should be. The hub stays a hub. The brain stays a brain. And the automations page stays gloriously, deliberately empty.

If you want the nuts and bolts of any of these flows — the irrigation logic, the OMIE energy optimiser, or how to publish entities back into HA — let me know and I’ll write the deep-dive next.