Legrand/BTicino Zigbee routers do not participate in many-to-one routing
<p>Setup: 34 Legrand/BTicino routers (22x K4003C light switches, 7x K4027C shutter modules, 4x 067797 dimmers), firmware 0x004745ff and 0x002945ff obtained through your OTA, on a Zigbee 3.0 network of about 70 devices with an EmberZNet 8.0.2 coordinator (Sonoff Dongle Plus MG24) running Zigbee2MQTT. The coordinator is configured as a high-RAM concentrator and broadcasts a many-to-one route request (MTORR) about every 60 seconds.</p><p> </p><p>Observation from the coordinator logs (36 hours): every non-Legrand router (Sonoff, NodOn, Gledopto, Philips Hue, Tuya) sent route records as expected, hundreds each, and their end-device children were carried in route records too. None of the 34 Legrand devices sent a single route record, and none of the 9 end devices parented by a Legrand router had one generated on its behalf. Legrand devices do relay normally as parents and as hops in table routes, but they never appear in any route record.</p><p> </p><p>Sniffer capture (ESP32-H2, channel 11, decrypted, 10 min next to the coordinator plus 70 min at the far end of the house): the coordinator sent 40 and 56 many-to-one route requests respectively. Every non-Legrand router in range rebroadcast them, 19 to 54 times each. All 29 Legrand routers in range rebroadcast them zero times, while each of them sent link status every 16 seconds with correct two-way costs and answered plain (unicast) route requests with route replies. The Legrand firmware therefore receives the MTORR and drops it instead of relaying it. </p><p> </p><p>Consequence: no Legrand device and no end device parented by one ever has a many-to-one route or sends a route record, so the coordinator cannot source-route to any of them and instead runs a full AODV route discovery per Legrand destination – 16 discoveries in 10 minutes, each flooded by about 38 routers, roughly a quarter of all network-layer frames on the air. Multi-hop Legrand devices then produce ROUTE_ERROR_NON_TREE_LINK_FAILURE on about 15 % of the coordinator’s messages to them as table routes go stale (in bursts where it is every message for an hour), and occasionally a lost command. The non-Legrand devices on the same paths produced no route errors in the same period.</p><p> </p><p>Questions: is many-to-one route request handling intentionally disabled in the Legrand Zigbee 3.0 firmware? If not, is it a known defect with a planned fix? I can provide the coordinator logs and the decrypted sniffer captures (pcap) on request.</p><p> </p>
Hello,
Please write me on this email address by providing the ZigBee captures. I’ll then forward it to the teams
Have a good day,
Leslie – Community Manager
<p>Hello Leslie,</p><p> </p><p>thank you. I have sent the captures to the address you indicated (ww-sm-contact-workswithlegrand@legrand.com): a zip with the two raw sniffer captures, the decoded routing commands of both as text and CSV, per-capture summaries, a device map, 67 hours of coordinator route-error logs and a README with the setup, firmware builds and the filters to reproduce the finding.</p><p> </p><p>Please also check the spam folder in case the attachment triggered a filter. If the mailbox does not accept attachments of that size (about 2 MB), let me know and I will provide a download link instead.</p><p> </p><p>I am happy to run further captures or test firmware on this network.</p><p> </p><p>Best.</p><p> </p>
Hi again,
Well received :). I forwarded it to our Zigbee developers, I’ll tell you once I know more
Have a good day,
Leslie – Community Manager
Hi again,
Here is the feedback from the developers :
We had to disable the MTOR feature on the majority of our devices. When we added it, we measured an increase in flash size. And for most products, that wouldn’t fit. So, we added it only for US products – where there was enough space and a proven need
Have a good day,
Leslie – Community Manager
<p>Hello Leslie,</p><p> </p><p>thank you for getting an answer from the developers.</p><p> </p><p>I have to say the answer is worrying from a user’s point of view. Relaying the many-to-one route request and sending route records is the behaviour every mainstream coordinator expects from a router: Silicon Labs, TI and NXP stacks, as used by Home Assistant, Zigbee2MQTT, Hue, SmartThings, Amazon and others, run the coordinator as a concentrator and rely on it. A router that does not take part in it behaves, from the coordinator’s point of view, like a device that cannot be reached by a stable route. On my network that means 33 Legrand/BTicino devices that can never be source-routed, a full route discovery per Legrand destination for ordinary traffic (about 280 route requests per hour, a quarter of all network-layer frames on the channel), and route errors and occasional lost commands on the multi-hop ones. Other brands on the same network do not have this problem.</p><p> </p><p>So the practical question is: what options do we have to get it back?</p><p>1. Is there any EU firmware or SKU of the K4003C, K4027C or K4411C that includes MTOR support?</p><p>2. Could a build with MTOR be provided for these products, even at the cost of another optional feature, given that the handling itself is small? I am happy to test such a build on this network and report back with captures.</p><p>3. Failing that, is there a coordinator configuration Legrand recommends for networks with many of your routers, so that the discovery load and the route errors are at least reduced?</p><p> </p><p>Best regards</p><p> </p>
Hello,
Confirmed independently here, on a different coordinator. Adding what the missing MTOR support costs in practice, and one defect that has not been reported.
Setup
107 devices, 35 Legrand (20 routers, 15 wireless switches). SMLIGHT SLZB-06M (EFR32MG21, EmberZNet 8.0.2 build 397, EZSP v14), Zigbee2MQTT 2.14.1, channel 11. Sniffer: CC2531 with whsniff, captures decrypted with the network key.
Every Legrand device runs the latest firmware you publish, checked model by model against: https://developer.legrand.com/production-firmware-download/
Models: 067776A, 067771, 067773, 067774, 199182.
MTORR
Route requests split on the many-to-one subfield:
| Capture | MTORR (many-to-one set) | Plain route requests |
|---|---|---|
| 606 s | 562 frames, Legrand rebroadcast 0 | 868 frames, Legrand rebroadcast 112 |
| 120 s | 426 frames, Legrand rebroadcast 0 | 425 frames, Legrand rebroadcast 57 |
Zero of 988. The same routers relayed 169 ordinary route requests, sent link status, and answered unicast route requests with route replies. Only the many-to-one path is missing.
In the 606 s capture: 17 Legrand routers sent 67 unicasts to the coordinator and 0 route records; 25 non-Legrand routers sent 622 unicasts and 641 route records.
Unreported defect: truncated relay list
Legrand routers forward route records that originate elsewhere without adding themselves to the relay list. This occurred in 6 out of 6 cases, compared to 488 out of 488 correctly appended by non-Legrand routers.
The coordinator therefore stores a path shorter than the real one, with the Legrand hop deleted, and acts on it as valid. Five non-Legrand devices behind a Legrand hop had their source routes corrupted this way in ten minutes. A missing feature yields no route record; truncating another device’s route record is worse.
Effect on end devices
A sleepy end device’s route record is generated by its parent, so a wireless switch parented by a Legrand router is never advertised. In one capture, the four switches on compliant parents had 11, 10, 9 and 3 route records; the one on a Legrand parent had 0.
One press then toggles the light two to four times.
The coordinator has no valid route to the switch, so its APS acknowledgement goes to a router that no longer holds the device as a child. The acknowledgement never arrives, the switch retransmits three times as the standard requires, and the controller actuates the light on each copy. Retries land at approximately 1.8 s, 3.4 s and 6.2 s, so the light turns on and then off again seconds after the press.
Frames per command over 12 hours (1.00 = acknowledged first time):
| Switch | Frames per command |
|---|---|
| 067774 kitchen, endpoint 2 | 2.83 |
| 067774 kitchen, endpoint 1 | 2.33 |
| 067773 living room | 2.32 |
| 067773 dining room | 1.94 |
Same physical switch, split by the parent it happened to be using, which isolates the cause:
| Switch | Via Legrand parent | Via non-Legrand parent |
|---|---|---|
| 067774 kitchen | 2.55 (n=33) | 1.60 (n=5) |
| 067773 dining room | 2.46 (n=13) | 1.00 (n=4) |
Over 132 minutes the coordinator logged 154 ROUTE_ERROR_SOURCE_ROUTE_FAILURE, 1.17/min, all for devices at or behind a Legrand router. Non-Legrand devices on the same paths: none.
Cost
- Wireless switches toggle lights repeatedly on a single press. This is what users notice, and it is undiagnosable without a sniffer. Nothing in the logs points at routing.
- Three wasted retransmissions of battery power per affected press.
- No Legrand device can be source-routed, so ordinary traffic to them needs a full route discovery, flooded by every router on the network.
- Route errors and occasional lost commands on multi-hop Legrand devices.
- Non-Legrand devices behind a Legrand hop are affected as well, via the truncated relay list.
Request
- Is there any EU firmware or SKU with MTOR for the 067776A, 067771, 067773, 067774 or 199182?
- Would you consider a build with MTOR enabled, if necessary at the cost of another optional feature? I will test it here and report back with decrypted captures.
- Separately from MTOR: can the relay-list handling be fixed, so a Legrand router forwarding another device’s route record either appends itself or does not forward it? That is not a feature. It corrupts routing for other manufacturers’ devices and should be far smaller than full MTOR support.
Captures, coordinator logs and the display filters to reproduce all of this are available on request.
Best regard.
Hello Antoine,
I also forwarded your message to the teams. They are interested in getting your zigbee capture. Can you please send it to me at this email address ?
I’ll tell you when I have an answer for both of your questions 🙂
Have a good day,
Leslie – Community Manager
<p>Thank you Leslie, the email has been sent. Looking forward for a positive outcome on this issue that has been plaguing my home automation for a while!</p>
Thanks Antoine for the capture. The teams are currently taking a look at it
Have a good day,
Leslie – Community Manager
Thanks for keeping this thread alive. I can confirm Antoine’s second finding on my network too.
In a 24 h sniffer capture: 32 route records were relayed by a Legrand router, all 32 with an empty relay list. The 4376 records relayed by Sonoff, NodOn, Gledopto, Tuya and Signify routers all appended correctly. No Legrand address appears in any relay list, on any day.
What makes it worth reporting is where the effect lands: on non-Legrand devices. A smart plug of another brand sends its route records through three Legrand routers and then one Sonoff router. Because none of the Legrand routers adds itself, the coordinator concludes the plug sits one hop behind that Sonoff router, which cannot reach it and answers ROUTE_ERROR_SOURCE_ROUTE_FAILURE. 216 of the 294 route errors in five days of coordinator logs are exactly that, for that one plug, plus 18 for the battery sensor parented by it. Truncated records against errors, per day: 70 -> 81, 153 -> 180, 6 -> 17.
I would separate this from the MTOR discussion. Not implementing many-to-one routing is a product decision with a reason I understand. Relaying a route record without appending the own address looks more like an oversight in the same code path, and it leaves the coordinator with a route that does not exist.
The reason I went this far is that nothing else surfaces it. The logs look clean, every device reports online with good link quality, and what you actually notice is a switch reacting late, a report going missing, a plug whose state lags. It took an 802.15.4 sniffer and a week of decrypted traffic to see what was happening.
That is also the part I would ask you to pass on internally. Everyone with these products in their walls lives with those small glitches, but only a handful of users can ever connect them to a cause. For everyone else it stays a home that is “mostly fine” for no visible reason, and the usual conclusion is that their hub or their setup is at fault. The workaround of adding non-Legrand routers on the affected paths is not realistic for someone with thirty Legrand modules installed.
So from a customer’s point of view: the relay list behaviour looks like a small fix compared to MTOR support, and it would help every mixed installation. And while I understand there is no EU firmware with MTOR today, it is something we are hoping to see eventually.
<p dir=”ltr”>Hello Leslie,</p><p dir=”ltr”>I can’t stress enough how much this issue has hurt Legrand’s reputation in the home automation community. While researching my own problems, I kept finding other users in the same situation, stuck with no fix and concluding that Legrand hardware is simply unreliable.</p><p dir=”ltr”>Tracking it down took network captures, which needs the right hardware, some technical expertise and a lot of personal time. That rare combination is probably why the issue went unnoticed for so long. It took me a year to come around and commit to investigate deeply, not even knowing what I would find. Before that, I tried many things like isolating some devices on a separate zigbee network thinking they were the problem…</p><p dir=”ltr”>Could you share an update on the issues reported here, including what we can expect and a rough timeline? I’d be glad to test beta firmware if that helps the team. I’m keen to finally see this resolved.</p><p dir=”ltr”>Best,<br />Antoine</p>
Hello Antoine,
Some feedback from the teams :
Concerning the MTORR, it will not be technically possible to activate it on all devices (and they don’t know if it’s something they want). I doubt there will be any evolution on that point
Concerning the route record, they indeed noticed the problem you mention. An internal bug ticket is opened for this. But it hasn’t been prioritized in the backlog yet, so I can’t tell you when it will be resolved
Have a good day,
Leslie – Community Manager
<p>Hello Leslie,</p><p> </p><p>Thank you for getting an answer from the teams, and for opening the bug ticket on the route record. That is good news.</p><p> </p><p>On MTORR: I understand it cannot fit on every device, but having it on some products would already make a real difference. A mesh does not need every router to take part in many-to-one routing. Every Legrand router that does is one more path the coordinator can use, and one less route discovery flooding the network. So I would kindly ask the teams to enable it wherever there is room, on new products and in firmware updates for existing ones that can take it, rather than closing the topic.</p><p> </p><p>On the route record, I would really ask for it to get priority. It is not a cosmetic issue. The installations I look after mix Legrand switches with devices from other brands, which is exactly what Zigbee 3.0 is meant to support. The devices that fail are the other brands’ ones, because a Legrand router sits on their path. My clients see a sensor or plug that reacts late, and sometimes a device that stops receiving commands until it is re-paired. Nobody sees the Zigbee routing behind this. What they see is a Legrand installation that is not reliable, and they are asking me for a fix I cannot give them.</p><p> </p><p>The fix itself should be small: the router appends its own address when it relays a route record. If there is anything I can do to help move it up the backlog, like testing a beta firmware, sending more captures, or reproducing it on a specific product, I am happy to do it.</p><p> </p><p>Thanks again for following this up.</p><p> </p>
You must be logged in to reply to this topic.
13 replies 
3 participants