Why Does Node-RED Stop Processing Flows When Zigbee2MQTT Reconnects? [Fixed]

Introduction: When Your Smart Home Suddenly Goes Silent

You’ve spent hours — maybe even days — carefully building your Node-RED automations. Your lights respond to motion sensors. Your thermostat adjusts based on door contacts. Everything works like a well-oiled machine. Then, out of nowhere, everything stops.

You check your dashboard. Node-RED is running. Zigbee2MQTT is running. The MQTT broker is running. But nothing is happening. No messages flowing. No automations firing. Your smart home has essentially become a collection of expensive, unresponsive devices sitting on your walls and shelves.

If this sounds painfully familiar, you’re not alone. I’ve been there myself — staring at a Node-RED debug panel showing absolutely nothing while Zigbee2MQTT happily reports it just reconnected to the broker. The frustrating part? The reconnection itself is what broke everything.

In this comprehensive guide, I’ll explain exactly why this happens, what’s going on under the hood, and — most importantly — how to fix it permanently so your automations survive every reconnection without missing a beat.

[📷 Image Placeholder: Screenshot showing Node-RED flow with disconnected MQTT nodes displaying “disconnected” status after Zigbee2MQTT reconnects]
Alt text: “Node-RED MQTT nodes showing disconnected status after Zigbee2MQTT reconnection event”

Understanding the Core Problem: What Actually Happens During Reconnection

How MQTT Subscriptions Work in Node-RED

Before diving into the fix, let’s understand the mechanics. When Node-RED connects to an MQTT broker, it does two critical things:

Establishes a TCP connection to the broker (typically on port 1883 or 8883 for TLS)
Subscribes to specific topics like zigbee2mqtt/+ or zigbee2mqtt/living_room_sensor

These subscriptions are session-based. This means they exist only as long as the connection — or the session — remains active on the broker side. Here’s where the trouble begins.

The Zigbee2MQTT Reconnection Cascade

When Zigbee2MQTT reconnects to your MQTT broker (Mosquitto, for example), a chain reaction occurs:

Zigbee2MQTT loses its connection (due to a crash, restart, network hiccup, or configuration change)
Zigbee2MQTT reconnects to the broker with the same client ID
The broker may terminate the previous session associated with that client ID
If Node-RED shares broker-level session dependencies, its subscriptions can get silently dropped
Node-RED thinks it’s still connected, but the broker is no longer routing messages to it

The result? Node-RED sits there, fully “connected,” but receiving absolutely nothing. It’s like having a phone that shows full signal bars but can’t actually receive calls.

[📷 Image Placeholder: Diagram showing the MQTT connection flow between Zigbee2MQTT, Mosquitto Broker, and Node-RED, highlighting the point where subscriptions break]
Alt text: “Architecture diagram showing MQTT message flow breakdown between Zigbee2MQTT, Mosquitto broker, and Node-RED during reconnection”

The Real Culprits: 5 Reasons This Happens

1. MQTT Client ID Conflicts

This is the number one cause I’ve encountered in real-world setups. If Node-RED and Zigbee2MQTT use the same MQTT client ID (or if you have multiple Node-RED instances with the same ID), the broker will disconnect the older client when the new one connects.

How to check: Look at your Zigbee2MQTT configuration.yaml:

YAMLmqtt:
  base_topic: zigbee2mqtt
  server: mqtt://localhost:1883
  client_id: my_mqtt_client

Then check your Node-RED MQTT broker configuration node. If both use similar or identical client IDs — that’s your problem.

2. Clean Session Settings Misconfigured

MQTT has a concept called Clean Session (MQTT v3.1.1) or Clean Start (MQTT v5). When set to true, the broker discards any previous session data — including subscriptions — every time the client connects.

Here’s the catch: this doesn’t just affect the reconnecting client. In some broker configurations, particularly when client IDs collide or when the broker’s session management has bugs, a clean session from one client can interfere with another.

3. Mosquitto Broker Overwhelmed During Reconnection

When Zigbee2MQTT reconnects, it often does several things simultaneously:

Re-subscribes to all its topics
Publishes availability messages for all devices
Sends a burst of retained messages

If your Mosquitto broker is running on limited hardware (like a Raspberry Pi 3), this flood of messages can cause the broker to temporarily drop connections with other clients, including Node-RED.

4. Node-RED MQTT Node Doesn’t Auto-Resubscribe Properly

In some versions of Node-RED (particularly older ones), the MQTT nodes have a known behavior where they don’t properly resubscribe after a broker-side disconnection that Node-RED didn’t detect. The TCP connection might stay open, but the MQTT session is effectively dead.

5. Network-Level Timeouts and Keep-Alive Mismatches

If the MQTT keep-alive interval in Node-RED doesn’t match your broker’s timeout settings, there can be a window during Zigbee2MQTT’s reconnection where the broker considers Node-RED’s connection stale but hasn’t yet notified Node-RED about it.

[📷 Image Placeholder: Screenshot of Mosquitto broker logs showing client disconnection and reconnection events with timestamps]
Alt text: “Mosquitto MQTT broker log entries showing client disconnection events during Zigbee2MQTT reconnection”

A Real Scenario: My Personal Experience With This Issue

Let me share what happened in my own setup last year. I was running:

Raspberry Pi 4 with Home Assistant OS
Zigbee2MQTT addon managing 47 Zigbee devices
Node-RED addon handling all my automations
Mosquitto addon as the MQTT broker

Everything worked great for weeks. Then I noticed a pattern: every Tuesday at 3 AM, my automations would stop working. No motion-triggered lights. No temperature-based HVAC control. Nothing.

After some detective work, I discovered that Zigbee2MQTT had an auto-update check that would occasionally trigger a soft restart. During that restart, it would reconnect to Mosquitto. And every time it did, my Node-RED MQTT subscriptions would silently die.

The Node-RED admin panel showed everything as “connected.” The flows looked normal. But the debug nodes showed zero incoming messages. The only fix was to manually restart Node-RED or redeploy all flows.

It took me three weeks to figure this out. I don’t want you to go through the same frustration.

Step-by-Step Fix: Making Your Flows Survive Reconnections

Step 1: Assign Unique MQTT Client IDs

This is the most critical step. Every MQTT client connecting to your broker must have a unique client ID.

In Node-RED:

Open your Node-RED editor
Double-click any MQTT node (input or output)
Click the pencil icon next to the broker configuration
Go to the Connection tab
Set the Client ID to something unique like nodered_main_client

In Zigbee2MQTT (configuration.yaml):

YAMLmqtt:
  client_id: zigbee2mqtt_main
  server: mqtt://localhost:1883

⚠️ Important: Never leave the Client ID field empty in Node-RED. When left empty, the library generates a random ID on each connection, which can sometimes collide with other random IDs.

[📷 Image Placeholder: Screenshot of Node-RED MQTT broker configuration dialog showing the Client ID field properly filled in]
Alt text: “Node-RED MQTT broker configuration node with unique client ID setting highlighted”

Step 2: Configure Clean Session Correctly

In your Node-RED MQTT broker configuration:

Open the broker config node
Find the “Use clean session” checkbox
Check it (set to true) for most use cases

Wait — shouldn’t we keep sessions persistent? In most smart home scenarios, clean sessions are actually safer because:

They force Node-RED to resubscribe on every connection
They prevent stale session data from causing issues
They ensure a fresh start every time

If you need persistent sessions (for QoS 1/2 message delivery guarantees), make absolutely sure your client IDs are unique and your broker has enough memory to manage all sessions.

textClean Session = true → Node-RED resubscribes every time → More reliable
Clean Session = false → Relies on broker session memory → Can break if sessions conflict

Step 3: Set Proper Keep-Alive Intervals

The keep-alive interval tells the broker “I’m still here” at regular intervals. Set it appropriately:

In Node-RED MQTT broker config:

Keep Alive: 60 seconds (recommended for local networks)

In Mosquitto (mosquitto.conf):

confmax_keepalive 120
persistent_client_expiration 1d

In Zigbee2MQTT (configuration.yaml):

YAMLmqtt:
  keepalive: 60
  version: 4

Step 4: Add a Reconnection Watchdog Flow in Node-RED

This is my secret weapon. Create a watchdog flow that detects when messages stop arriving and automatically triggers a resubscription:

JSON[
    {
        "id": "watchdog_inject",
        "type": "inject",
        "repeat": "120",
        "topic": "watchdog/check",
        "payload": "ping"
    },
    {
        "id": "watchdog_mqtt_out",
        "type": "mqtt out",
        "topic": "nodered/watchdog/ping"
    },
    {
        "id": "watchdog_mqtt_in",
        "type": "mqtt in",
        "topic": "nodered/watchdog/ping"
    },
    {
        "id": "watchdog_trigger",
        "type": "trigger",
        "op1": "",
        "op2": "reconnect_needed",
        "duration": "180",
        "units": "s"
    }
]

How this works:

Every 2 minutes, Node-RED publishes a message to nodered/watchdog/ping
It also subscribes to that same topic
If it doesn’t receive the ping back within 3 minutes, it means MQTT subscriptions are broken
The watchdog triggers an alert or an automatic flow restart

[📷 Image Placeholder: Screenshot of the watchdog flow in Node-RED editor showing the inject, MQTT out, MQTT in, and trigger nodes connected]
Alt text: “Node-RED watchdog flow design for detecting broken MQTT subscriptions after Zigbee2MQTT reconnection”

Step 5: Enable Automatic Reconnection in Node-RED MQTT Config

Make sure these settings are configured in your MQTT broker node:

Reconnect after disconnect: Enabled (this is usually the default)
Reconnect period: 5 seconds (don’t set this too low — it can overwhelm the broker)

Additionally, in newer versions of Node-RED, you can set:

Session Expiry: Set an appropriate interval if using MQTT v5
Auto-subscribe on reconnect: Ensure this behavior is enabled

Step 6: Update Mosquitto Broker Configuration

Add these lines to your mosquitto.conf to make the broker more resilient:

conf# Allow persistent sessions
persistence true
persistence_location /mosquitto/data/

# Set reasonable limits
max_inflight_messages 40
max_queued_messages 1000
max_queued_bytes 0

# Logging for debugging
log_type error
log_type warning
log_type notice
log_type subscribe
log_type unsubscribe

# Connection settings
allow_zero_length_clientid false
auto_id_prefix auto-

The critical line here is allow_zero_length_clientid false. This forces all clients to declare a client ID, preventing the random ID collision issue.

[📷 Image Placeholder: Screenshot of mosquitto.conf file with the recommended configuration settings highlighted]
Alt text: “Mosquitto MQTT broker configuration file with optimized settings for preventing Node-RED subscription loss”

Step 7: Upgrade Your Software Stack

Many of these issues have been fixed in recent versions:

Software	Minimum Recommended Version	Why
Node-RED	3.1+	Better MQTT reconnection handling
node-red-contrib-mqtt	Latest	Improved session management
Zigbee2MQTT	1.33+	Better MQTT client behavior
Mosquitto	2.0.15+	Fixed session handling bugs
Eclipse Paho (underlying MQTT library)	Latest	Connection stability improvements

Advanced Solution: Using MQTT v5 Features

If your entire stack supports MQTT v5, you get access to powerful features that solve this problem at the protocol level:

Session Expiry Interval

YAML# Zigbee2MQTT configuration.yaml
mqtt:
  version: 5
  session_expiry_interval: 3600

This tells the broker to keep session data for 1 hour even after disconnection, so subscriptions survive reconnections.

Subscription Identifiers

MQTT v5 introduces subscription identifiers that help the broker track which subscriptions belong to which client, even across reconnections. Node-RED’s MQTT nodes support this in recent versions.

Server-Side Disconnect Notifications

With MQTT v5, the broker sends a DISCONNECT packet with a reason code before dropping a connection. This allows Node-RED to properly handle the disconnection and resubscribe immediately.

Monitoring: How to Know When It Happens Again

Set Up Mosquitto Logging

Enable detailed logging to catch issues early:

conf# In mosquitto.conf
log_type all
log_dest file /mosquitto/log/mosquitto.log
connection_messages true

Then monitor the log for patterns like:

textClient nodered_main_client already connected, closing old connection.
Client zigbee2mqtt_main disconnected.
Client zigbee2mqtt_main connected.

If you see “already connected, closing old connection” for your Node-RED client, you have a client ID conflict.

Create a Node-RED Dashboard Monitor

Build a simple dashboard panel that shows:

Last message received timestamp
Messages per minute counter
Connection status indicator
Automatic alert when message rate drops to zero

[📷 Image Placeholder: Screenshot of a Node-RED dashboard showing MQTT connection health monitoring widgets with status indicators and message rate graphs]
Alt text: “Node-RED dashboard panel monitoring MQTT connection health with real-time message rate and connection status indicators”

Common Mistakes to Avoid

❌ Don’t: Restart Node-RED as a “Fix”

While restarting Node-RED does solve the immediate problem, it’s a band-aid, not a solution. Every restart:

Kills all in-progress flows
Resets all flow context variables
Disrupts any timing-based automations
Takes 10-30 seconds during which nothing works

❌ Don’t: Use Wildcard Topics Excessively

Subscribing to zigbee2mqtt/# captures everything, but it also means Node-RED processes every single message from Zigbee2MQTT, including bridge status, device announcements, and debug data. This increases the load during reconnection floods.

Instead, subscribe to specific topics:

textzigbee2mqtt/living_room_motion
zigbee2mqtt/front_door_contact
zigbee2mqtt/thermostat_bedroom

❌ Don’t: Ignore Retained Messages

Retained messages can cause unexpected behavior during reconnections. When Zigbee2MQTT reconnects and publishes retained availability messages, Node-RED might process stale data. Use a filter:

JavaScript// In a Function node after MQTT-in
if (msg.retain) {
    // This is a retained message — handle with caution
    node.warn("Received retained message on: " + msg.topic);
    return null; // Drop retained messages if not needed
}
return msg;

External Resources and References

For deeper understanding of the underlying technologies, check these authoritative resources:

MQTT v5 Specification — OASIS Standard — Official MQTT protocol documentation
Node-RED MQTT Configuration Guide — Official Node-RED MQTT documentation
Zigbee2MQTT MQTT Configuration — Zigbee2MQTT MQTT settings reference
Eclipse Mosquitto Documentation — Mosquitto broker configuration options
Node-RED GitHub Issues — MQTT Reconnection — Community discussions about MQTT reconnection bugs

Frequently Asked Questions (FAQ)

Why does Node-RED show “connected” but no messages are flowing?

This happens because the TCP connection between Node-RED and the MQTT broker is still alive, but the MQTT subscriptions have been silently dropped by the broker. The connection is technically active, but Node-RED is no longer registered to receive messages on any topics. This typically occurs after a client ID conflict during Zigbee2MQTT reconnection.

Will redeploying flows in Node-RED fix the problem?

Yes, redeploying flows forces Node-RED to resubscribe to all MQTT topics, which restores message flow. However, this is not a permanent solution. The issue will recur the next time Zigbee2MQTT reconnects. Implement the client ID and session configuration fixes described above for a permanent solution.

Can this problem damage my Zigbee devices or network?

No, this issue is entirely at the software/MQTT layer. Your Zigbee devices, coordinator, and mesh network are completely unaffected. The devices continue operating normally — they just can’t communicate with Node-RED through the broken MQTT subscription chain.

Does this issue affect Home Assistant automations too?

It can, but Home Assistant typically handles MQTT reconnections more gracefully because it uses its own MQTT integration with built-in reconnection and resubscription logic. If you’re running both Home Assistant and Node-RED, you might notice that HA automations keep working while Node-RED ones stop — this confirms the issue is with Node-RED’s MQTT session handling.

How often does Zigbee2MQTT typically reconnect?

Under normal conditions, Zigbee2MQTT maintains a stable connection and rarely reconnects. Common triggers for reconnection include:

Software updates or restarts
Mosquitto broker restarts
Network connectivity issues
System resource exhaustion (out of memory)
Configuration changes in Zigbee2MQTT
Scheduled backups that temporarily overload the system

Should I use QoS 0, 1, or 2 for my MQTT messages?

For most smart home automations, QoS 1 is the best balance between reliability and performance. QoS 0 (“fire and forget”) can lose messages during reconnections. QoS 2 (exactly once delivery) adds significant overhead. QoS 1 ensures the message is delivered at least once and works well with clean session configurations.

Is there a way to get notified when this happens?

Yes. Implement the watchdog flow described in Step 4 above, and connect it to a notification service. You can use the node-red-contrib-telegrambot or node-red-node-email nodes to send yourself an alert when MQTT subscriptions appear to be broken. Some users also monitor the $SYS/# broker topics for connection events.

Conclusion: Build Resilient Automations That Survive Anything

The issue of Node-RED stopping flow processing when Zigbee2MQTT reconnects is frustrating, but it’s completely solvable. The root cause almost always comes down to one of these factors: client ID conflicts, clean session misconfiguration, or insufficient reconnection handling.

By following the steps in this guide — assigning unique client IDs, configuring clean sessions properly, setting appropriate keep-alive intervals, and implementing a watchdog flow — you can build a smart home automation system that survives broker restarts, Zigbee2MQTT reconnections, and network hiccups without missing a single message.

Your smart home should work for you, not the other way around. Take 30 minutes today to implement these fixes, and you’ll save yourself countless hours of troubleshooting in the future.

[📷 Image Placeholder: Screenshot showing a healthy Node-RED flow with all MQTT nodes displaying “connected” status and debug panel showing active message flow]
Alt text: “Healthy Node-RED flow with properly configured MQTT nodes showing active connected status and flowing messages after implementing reconnection fixes”