Zigbee2MQTT Many-to-One Route Failure: What It Means

If you’re running Zigbee2MQTT against an Ember/EZSP-based coordinator, a Home Assistant Connect ZBT-1 or ZBT-2, a Sonoff ZBDongle-E, an SLZB-06M running in Ember mode, and you’ve started seeing ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE show up in the log, you’re not looking at a misconfiguration you caused. It’s a documented mesh-routing behavior tied to the Ember/EmberZNet driver itself, reported against multiple pieces of hardware and multiple firmware builds for more than two years.

The confusing part is that the symptom doesn’t always match the warning. Some readers see the message once or twice a day with nothing else wrong. Others watch devices, sometimes devices sitting a few meters from the coordinator, drop offline while the log fills with the same route error on repeat. Both experiences trace back to the same underlying mechanism, just at different severities.

This stays entirely inside your local Zigbee mesh. No cloud service is involved and nothing here depends on an internet connection, which is also why a real fix, if one arrives, has to come from Silicon Labs’ EmberZNet SDK rather than anything Zigbee2MQTT’s own maintainers can patch on their own.

What ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE actually means

Zigbee coordinators periodically issue what’s called a many-to-one route request. It’s a broadcast that asks every router-capable device on the mesh to record a path back to the coordinator, so that whenever any of those devices needs to reach it (reporting a sensor value, for instance), the packet already has a known route to converge on. “Many-to-one” describes the traffic pattern: many devices, one destination.

ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE, per the original GitHub bug report that first documented it (issue #22540), is Zigbee2MQTT’s Ember/EZSP driver logging that one of these route requests failed to reach a device. The route table entry for that device either never got built or got dropped, and the log line is Z2M reporting that the housekeeping broadcast came back incomplete.

Why this is specifically an Ember/EZSP problem

The clearest root-cause writeup is a later, more technical GitHub thread (issue #29902), aimed at maintainers rather than end users, which is part of why no one had turned it into a plain-language explainer before this. What it describes is Ember’s source-routing behavior interacting badly with route discovery. Instead of routing evenly, some router devices end up absorbing a disproportionate share of child connections, while other devices, some of them physically close to the coordinator, get routed through distant multi-hop paths instead of connecting to the coordinator directly. Over time that lopsided load is what produces the gradual network degradation some readers describe.

Silicon Labs tracks the underlying issue internally as BUGZID 12261. That’s worth knowing because it tells you where responsibility for a real fix actually sits, with Silicon Labs’ EmberZNet SDK, not with the Zigbee2MQTT project. The reports span different Ember-based coordinators and multiple firmware versions, with the EmberZNet 7.4.4 GA build among those specifically cited, which rules out a bad unit or a bad batch as the explanation. This is a driver/SDK-level pattern, not a defect isolated to one specific SKU.

The sourced reports are consistently about Ember/EZSP hardware; the Z-Stack (CC2652) and deCONZ stacks don’t turn up in them for this specific route-failure pattern. That gap in the record is suggestive that this is an Ember-specific behavior, not proof it’s mechanically impossible elsewhere.

If you’re weighing an Ember-based coordinator against a Z-Stack one for a new build, our Sonoff ZBDongle-E vs ZBDongle-P comparison goes through that tradeoff in more depth. This route-error pattern is one more data point in that comparison, not the deciding factor on its own. Ember/EZSP is still Zigbee2MQTT’s recommended modern driver for the hardware it supports.

Is it dangerous, or is it just log noise

This is the question that matters most, and the honest answer depends on frequency and what else is happening. A handful of these warnings scattered through a log with no devices actually dropping is closer to background noise than a real problem. A steady stream of them, especially paired with devices going unavailable, including ones that shouldn’t have any reason to be out of range, matches the network-degradation pattern the root-cause thread describes.

A related report (GitHub issue #22516) documents general Ember driver warnings appearing after a user switched to an Ember-based coordinator from something else. That’s useful context if you’re trying to work out whether what you’re seeing is this specific route error or a broader side effect of the Ember migration itself. If the warnings you’re seeing don’t match the ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE text specifically, you may be looking at a different, unrelated issue.

The Home Assistant Community thread on this exact error stops short of a deep explanation, but its practical advice is worth taking seriously as a first step. Confirm your adapter is genuinely running the ember driver rather than having silently fallen back to something else after an update.

What actually helps

None of this is a fix for the underlying SDK behavior. These are mitigations that reduce how often you hit it, sourced from the same community thread and issue trackers above.

Confirm the driver setting first.

serial:
  adapter: ember
  port: /dev/ttyUSB0

A Zigbee2MQTT update can occasionally leave this set differently than you expect. Check it explicitly rather than assuming it hasn’t changed.

Prune devices you don’t actually use anymore. Route requests still target devices that are permanently powered off or otherwise abandoned on the network, and each one that fails to respond is another opportunity for this warning to fire. Removing dead entries is one of the few mitigations readers report actually helping.

What’s still unfixed

This is the part worth being direct about, since it’s easy to read a troubleshooting list and assume every step resolves the problem. It doesn’t. Confirming the driver, pruning dead devices, and dropping multiprotocol firmware all reduce the conditions that trigger this warning. None of them touch the underlying source-routing behavior Silicon Labs tracks as BUGZID 12261, and there’s no public timeline for a fix at the SDK level.

I think that’s a rough position for Zigbee2MQTT to be in, given how strongly the project has pushed Ember/EZSP as its modern recommended driver for exactly the hardware this affects. Being upfront that this is a known, unresolved upstream limitation, rather than something a config tweak fully solves, is the honest framing.

FAQ

Is ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE dangerous, or will it eventually break my network?
Occasional instances without other symptoms are closer to noise than danger. Frequent warnings combined with devices going unavailable, including ones close to the coordinator, match the network-degradation pattern described in the root-cause GitHub thread.

Why does this only seem to happen with Ember-based coordinators like SkyConnect, ZBT-1/ZBT-2, or Dongle-E?
Because the root cause is in how Ember’s source-routing behavior interacts with route discovery specifically, tracked upstream as Silicon Labs BUGZID 12261. Z-Stack (CC2652) and deCONZ-based coordinators use different stacks and aren’t among the sourced reports.

Does switching from multiprotocol to Zigbee-only firmware fix it?
It removes one contributing variable rather than fixing the underlying issue. Home Assistant’s own guidance recommends Zigbee-only firmware for ZBT-1/ZBT-2 regardless, since multiprotocol firmware has separately been linked to stability problems.

How many of these warnings in the log is normal versus a sign of a real problem?
There’s no official threshold. Treat occasional isolated instances as low-priority, and treat a steady, repeating stream, especially alongside devices dropping offline, as worth actively pruning dead devices and double-checking your adapter’s driver setting over.

Is there an actual fix coming, or is this permanent?
Unclear. It’s tracked upstream at Silicon Labs as BUGZID 12261, not as a Zigbee2MQTT-side bug, and there’s no public timeline for a resolution as of this writing.

What this covers, and what’s still open

This piece is built from the original GitHub bug report (issue #22540), the more detailed maintainer-level root-cause thread (issue #29902) that traces the behavior to Ember’s source-routing design and Silicon Labs’ BUGZID 12261, a related report of general Ember driver warnings (issue #22516), a Home Assistant Community thread’s practical troubleshooting advice, and Home Assistant’s own Connect ZBT-1/ZBT-2 firmware guidance. No coordinator here was reproduced on a test bench for this article. The facts about the mechanism and the affected hardware are sourced directly from those threads, not from hands-on reproduction.

What stays local is everything covered above. The mesh, the routing, and every mitigation here run entirely inside your own network with no cloud round-trip. What depends on a vendor fix is the underlying source-routing behavior itself, which sits inside Silicon Labs’ EmberZNet SDK rather than Zigbee2MQTT’s own codebase. If you’re hitting this now, check your driver setting, prune anything you’re not actually using, and keep an eye on our Zigbee2MQTT ghost device troubleshooting guide if devices start disappearing outright rather than just logging route errors. It’s also worth watching whether the frequency changes after a firmware update to your adapter — including an Ethernet coordinator like the SLZB-06 — since BUGZID 12261 could plausibly be addressed in a future EmberZNet release without either vendor announcing it.