ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE means that a unicast travelling towards a Zigbee concentrator encountered a broken link. In Zigbee2MQTT you may see it from the Ember driver on hardware such as a Sonoff ZBDongle-E, Home Assistant Connect radio or SMLIGHT SLZB-06M.
The message is useful, but it does not diagnose one universal Ember defect. A few errors during joining or startup can accompany normal route changes. Repeated failures from the same area, missed reports or devices becoming unavailable deserve investigation. Record what the devices are doing as well as how many messages appear.
The routing and troubleshooting here are local to your Zigbee network. Downloading a firmware update is a separate step; ordinary communication does not pass through a vendor cloud.
What ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE actually means
A concentrator, usually the coordinator in this setup, uses many-to-one route requests to establish paths back to itself. Routers store a next hop towards it. For traffic going back out, source routing can put the sequence of hops in the message header. Silicon Labs’ routing concepts explain how these mechanisms reduce routing-table demands near a central device.
The failure status concerns a unicast using a many-to-one route, not proof that the route-request broadcast failed to reach a device. The released herdsman EZSP callback documentation describes a broken link on the inbound route. It distinguishes this from SOURCE_ROUTE_FAILURE, which concerns an outbound source-routed unicast. Retries can produce several route-error notifications for one failed message.
Issue #22540 reported the many-to-one message on a ZBDongle-E with Zigbee2MQTT 1.37.0-1 and EmberZNet 7.4.3. It records a user’s symptoms; it is not the protocol definition or proof that every instance has the same cause.
This log spelling is associated with the Ember/EZSP path. Many-to-one routing itself is a Zigbee mechanism, not an Ember-only concept. Other stacks can encounter a many-to-one route failure and expose it differently; a different coordinator is not immune to broken radio paths.
Why Ember exposes this message
A change from the old ezsp driver to ember can make previously hidden events visible. In #22516, the Ember maintainer explains that the old driver did not surface these network/route errors in the same way. Seeing new messages after migration therefore does not, by itself, prove that migration created the routing problem.
The same discussion distinguishes occasional events from persistent failures, particularly those associated with one device or an area of the network. Router behavior and interference are possible contributors. Check current debug logs and device operation before attributing every error to the driver.
A later discussion, #29902, proposed that source routing and route discovery caused gradual network degradation. It is important to read its follow-up: the reporter found interference and a separate PAN-ID conflict, then closed the issue because there was insufficient evidence for a routing-specific cause. A firmware update to 8.2.2 initially improved that particular setup, but it was not a controlled test establishing a general fix.
The issue quotes a real code comment mentioning Silicon Labs BUGZID 12261 and the ENABLE_ROUTE_DISCOVERY option. The maintainer explains the tradeoff: disabling the option had caused devices to go offline in some networks, so it was retained. That comment does not establish that all many-to-one errors are an unresolved SDK bug, that every Ember coordinator is affected equally, or that Zigbee2MQTT maintainers can do nothing useful about network behavior.
| Hardware | Relevant evidence | Limit of the report |
|---|---|---|
| Sonoff ZBDongle-E | #22540 and #22516 contain route-error reports on 7.4.x firmware. | Historical versions and networks; not proof of a fault in every Dongle-E. |
| Home Assistant Connect ZBT-1 / ZBT-2 | SkyConnect/ZBT-1 users appear in #22516; #29902 discusses a ZBT-2 setup on 7.4.4. | The later ZBT-2 routing hypothesis was not established by the investigation. |
| SLZB-06M using ember | #22516 contains user reports after changing driver and on 7.4.1. | The radio stack and firmware matter; Ethernet transport alone neither causes nor fixes this route status. |
If you are comparing coordinator families, the ZBDongle-E versus ZBDongle-P guide covers the broader differences. Match current support and firmware to the exact adapter. One historical warning thread is not enough to rank the reliability of whole hardware families.
Is it dangerous, or is it just log noise
An isolated route error does not mean the network is about to collapse. Zigbee routes change as devices join, disappear or encounter interference. The maintainer’s guidance in #22516 is to pay attention to persistent errors during ordinary operation, especially from the same devices or area.
Check the practical effect: are commands delayed, reports missing or availability checks failing? Compare the error’s target with the device’s current short network address. Old logs can show that address as a decimal number, while the frontend may show hexadecimal. This is the short network address, not the permanent IEEE address, and it can change after rejoining. Do not identify a device from an old number alone.
A network map is supporting evidence, not a packet trace. Missing or unexpected map links do not prove which route a failing packet used. In #29902 the maintainer specifically warns that maps depend on the quality of information devices return. Correlate the log time and target with real failed operations before deciding what to change.
What actually helps
Start by checking the driver and firmware for your exact coordinator against the current Ember adapter documentation. For a supported Ember adapter the configuration uses adapter: ember; the port, baud rate and flow control must match the hardware and firmware.
serial: adapter: ember port: /dev/ttyUSB0
Use your adapter’s actual port. A stable /dev/serial/by-id/… path is usually preferable for USB; an Ethernet adapter needs its documented network endpoint instead. Merge the example into the existing block. An update does not normally “silently fall back” to another driver, so inspect the startup log rather than assuming that happened.
Then work through the affected part of the network. Check that expected routers are powered, improve coordinator placement, and keep a USB coordinator away from interference sources with a suitable extension cable. If errors cluster around one router, investigate that device and its connections. Change one thing at a time and compare missed operations as well as log frequency.
Clean up confirmed retired devices if you no longer want them in Zigbee2MQTT, but do not delete entries simply because their map links look odd. Database cleanup does not repair an over-the-air link or prove that many-to-one broadcasts were targeting each dead database entry. The ghost-device guide helps distinguish stale entries from devices that need recovery.
Home Assistant moved away from experimental simultaneous Zigbee/Thread operation on ZBT-1 because of reliability problems. ZBT-2 is designed to be dedicated to Zigbee or Thread, rather than run both simultaneously. Follow the instructions for the exact model; do not assume ZBT-2 uses the old ZBT-1 multiprotocol migration procedure. For Zigbee2MQTT, check that the radio is running its supported Zigbee NCP firmware.
Before a relevant firmware update, save a complete Zigbee2MQTT data backup and follow the adapter’s recovery instructions. Use a build intended for that exact board, serial settings and role. A newer firmware may fix specific bugs, but a version number alone is not evidence that this warning has a universal cure. Avoid changing expert stack options from an old issue as a general first step.
When the problem persists
There is no single repair implied by this status code. A persistent problem may involve an RF link, a particular router, device firmware, coordinator firmware or host-side handling. The appropriate fix follows the evidence in that installation. It is inaccurate to label every occurrence a known, unfixable Silicon Labs defect.
For a current report, include Zigbee2MQTT version, coordinator model, firmware, adapter configuration without secrets, target addresses, and a debug log covering the missed reports or failed commands. Note whether the problem follows a router, location or update. That gives maintainers something testable beyond the route-error name.
FAQ
Will this eventually break my network? The message alone cannot predict that. Occasional events with working devices are lower priority than repeated errors accompanied by missed operations.
Is many-to-one failure unique to Ember? No. Many-to-one routing is part of Zigbee. Ember’s logging makes this particular name visible; other stacks may expose comparable failures differently.
Does Zigbee-only firmware fix it? Supported single-protocol firmware avoids a separate source of instability, particularly with older ZBT-1 multiprotocol setups. It does not repair every broken route.
How many messages are too many? There is no universal count. Retries can produce several notifications for one failed message. Look at persistence, location and actual device behavior.
Is BUGZID 12261 proof I must wait for Silicon Labs? No. The quoted code comment concerns a route-discovery option and its tradeoffs. #29902 did not establish it as the cause of the reporter’s dropouts or of every error with this name.
Sources and limits
This guide uses the released herdsman callback semantics, Silicon Labs’ routing documentation and complete issue discussions, including #29902’s closing explanation. The firmware distinction comes from Home Assistant’s ZBT-1 guidance and ZBT-2 documentation. It is a source-based troubleshooting guide, not a reproduced hardware fault.
An Ethernet coordinator still relies on its Zigbee radio and mesh; the SLZB-06 guide provides related installation context. Confirm the variant before applying Ember-specific advice, because the SLZB-06 family includes different radios and the model name alone is not a driver setting.