Node-RED vs Home Assistant Automations: Which to Use, and How to Run Both on One MQTT Broker

Node-RED vs Home Assistant is a common debate for anyone automating a home, a lab or a small building, and the honest answer is that they solve overlapping but different problems. This guide compares how each one builds automations, how they handle MQTT, and where each shines, then shows how to run both side by side on one MQTT broker so you do not have to choose.

Two Different Tools That Overlap

Home Assistant is a home automation platform. Its core idea is the entity: a light, a sensor, a switch or a climate device with a state and attributes. Hundreds of integrations turn vendor devices and cloud services into entities, and the dashboard, history, energy views and voice assistants all work on those entities. Automations are one feature among many.

Node-RED is a general-purpose, flow-based programming tool from the OpenJS Foundation. It has no concept of a home, a room or an entity. It has messages flowing between nodes: MQTT, HTTP, databases, files, serial ports, industrial protocols and thousands of community nodes. Automation is what it does, and it does it for factories and cloud integrations as readily as for living rooms.

So the comparison is less "which is better" and more "which mental model fits this particular automation".

Node-RED vs Home Assistant at a Glance

How Each Approach Builds an Automation

Take one simple rule: when the greenhouse temperature goes above 30 degrees, turn on the fan.

In Home Assistant

First, the MQTT sensor and fan become entities. With the MQTT integration configured, you can declare them in configuration.yaml:

mqtt:
  sensor:
    - name: "Greenhouse temperature"
      unique_id: greenhouse_temperature
      state_topic: "connectmq/demo/ha5k2m/greenhouse/temperature"
      unit_of_measurement: "°C"
      device_class: temperature
  switch:
    - name: "Greenhouse fan"
      unique_id: greenhouse_fan
      command_topic: "connectmq/demo/ha5k2m/greenhouse/fan/set"
      state_topic: "connectmq/demo/ha5k2m/greenhouse/fan/state"
      payload_on: "ON"
      payload_off: "OFF"

Then the automation works on entities, not topics:

automation:
  - alias: "Greenhouse fan on when hot"
    triggers:
      - trigger: numeric_state
        entity_id: sensor.greenhouse_temperature
        above: 30
        for: "00:02:00"
    actions:
      - action: switch.turn_on
        target:
          entity_id: switch.greenhouse_fan

The for clause, the history graph of the sensor and the trace of each automation run come for free. You can build the same thing in the visual editor without touching YAML.

In Node-RED

Node-RED works directly on topics and messages. An mqtt in node subscribes to the temperature topic, a function node applies the rule, and an mqtt out node publishes the command:

// Turn the fan on above 30, off below 27, only on change
const t = Number(msg.payload);
if (isNaN(t)) return null;

const fanOn = context.get("fanOn") || false;
if (!fanOn && t > 30) {
    context.set("fanOn", true);
    return { topic: "connectmq/demo/ha5k2m/greenhouse/fan/set", payload: "ON" };
}
if (fanOn && t < 27) {
    context.set("fanOn", false);
    return { topic: "connectmq/demo/ha5k2m/greenhouse/fan/set", payload: "OFF" };
}
return null;

There is no entity registry, no history and no dashboard unless you add them. In exchange, you get full control: hysteresis in three lines, easy access to any protocol, and transformations that would be awkward in YAML templates.

Where Home Assistant Wins

• Consumer devices. If a product has a Home Assistant integration, you get its entities, states and controls with almost no work.
• A home-oriented user interface. Dashboards, mobile app, presence detection, energy views and voice control are built in.
• Readable automations for simple rules. Trigger, condition and action is easy for other people in the household to understand and edit.
• Automation traces. Seeing why a rule did or did not fire is excellent for debugging everyday automations.

Where Node-RED Wins

• Complex logic and data shaping. State machines, aggregation, rate limiting and JSON transforms are natural in function nodes.
• Protocols and systems beyond the home. Modbus, OPC UA, databases, HTTP APIs and email are a palette install away. See our guides on Node-RED with MySQL and Node-RED HTTP endpoints.
• Raw MQTT work. Any topic structure, wildcard subscriptions, retained messages and MQTT 5 properties, without first modelling every device as an entity.
• Reuse outside the house. The same skills apply to a workshop, a farm or a factory line.

Running Both on One MQTT Broker

You do not have to pick one. Many setups run Home Assistant for devices and the user interface, and Node-RED for heavier logic and integrations. MQTT is the cleanest glue between them, because both are ordinary MQTT clients of the same broker.

Sensors / ESP32 / Zigbee2MQTT ──┐
                                ├──> MQTT broker <──> Home Assistant (entities, UI, simple automations)
Node-RED (logic, integrations) ─┘                <──> Node-RED (complex flows, databases, APIs)

A few rules keep this arrangement sane:

1. One owner per decision. Decide whether the greenhouse fan is controlled by Home Assistant or by Node-RED, never both. Two automations fighting over one command topic is the most common source of "the light keeps turning itself back on" bugs.
2. Separate topic branches. Devices publish state under .../<device>/state and accept commands under .../<device>/set. Node-RED publishes derived data under its own branch, such as .../computed/..., which Home Assistant can read as additional sensors.
3. Unique client IDs. Each Home Assistant instance, Node-RED instance and device needs its own client ID. Duplicate IDs make the broker disconnect the older session, which shows up as connections that flap every few seconds.
4. Retained state, non-retained commands. Retain state topics so a restarted Home Assistant sees current values; do not retain commands, or a fan may switch on again after every reconnect.
5. Count your connections. Home Assistant, Node-RED, Zigbee2MQTT and a dozen ESP32 boards add up. The free ConnectMQ Serverless plan allows up to 25 connections, which covers most homes; larger setups move to a paid plan.

You can also connect Node-RED to Home Assistant's own API with the node-red-contrib-home-assistant-websocket nodes, which is how the popular Node-RED add-on works. That gives Node-RED access to every Home Assistant entity, including non-MQTT ones. The MQTT approach is simpler to reason about when your devices are already MQTT, and it keeps both tools independent: either can be restarted or replaced without breaking the other.

Pointing both at the same broker

For experiments, both tools can use the public MQTT test broker at broker.connectmq.com on port 1883 with a unique prefix such as connectmq/demo/ha5k2m. For a real home, use private credentials over TLS. In Home Assistant, configure the MQTT integration under Settings → Devices and services, entering the broker host, port 8883, YOUR_USERNAME and YOUR_PASSWORD, and enabling TLS in the advanced options. In Node-RED, set the same host and port on the mqtt-broker config node with TLS enabled and a different client ID. The Node-RED MQTT tutorial covers the config node, and the Node-RED vs n8n comparison is worth reading if you are also weighing a workflow tool for cloud services.

Why Use a Cloud Broker Instead of the Add-on Broker?

Home Assistant OS offers a local Mosquitto add-on, and for a single house with everything on one network, that is perfectly reasonable. A cloud MQTT broker becomes attractive when devices live in several places (a holiday home, a greenhouse on another plot, a relative's flat), when you want to restart or rebuild the Home Assistant box without taking the messaging layer down, or when you would rather not open ports on your router. A managed broker such as ConnectMQ is reachable from anywhere over TLS, and its portal includes a live topic explorer and threshold alert rules, which are handy for checking what Home Assistant and Node-RED are actually publishing. Our guide on how to choose an IoT MQTT broker walks through the trade-offs.

Recommendation

• Start with Home Assistant if your goal is a smart home with mostly consumer devices, a family-friendly interface and straightforward rules.
• Start with Node-RED if your automations involve heavy logic, unusual protocols, databases or non-home equipment.
• Use both, connected through one MQTT broker, once your Home Assistant automations start to need templates inside templates. Let each tool own the decisions it is best at.

Connect Home Assistant and Node-RED to ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required, copy the generated username, password and client ID, and point both Home Assistant and Node-RED at it over TLS on port 8883. Give each tool its own credentials or client ID, and you have one shared message backbone that does not depend on any single box in your house.

Frequently Asked Questions

Is Node-RED better than Home Assistant automations?

Neither is strictly better. Home Assistant automations are easier for simple, entity-based rules and come with traces and history, while Node-RED handles complex logic, data transformation and non-home protocols more comfortably.

Can Home Assistant and Node-RED use the same MQTT broker?

Yes. Both are standard MQTT clients. Give each a unique client ID, agree on topic branches for state and commands, and make sure only one of them controls each device.

Do I need the Node-RED add-on to use Node-RED with Home Assistant?

No. The add-on is convenient on Home Assistant OS, but Node-RED can run anywhere and talk to Home Assistant through a shared MQTT broker or the Home Assistant websocket nodes.

How many MQTT connections does a typical smart home need?

One per device or gateway plus one each for Home Assistant, Node-RED and any bridges such as Zigbee2MQTT. Many homes fit within the 25 connections of the free ConnectMQ Serverless plan.