Foro Homepage

Hello Leslie, Thank you for getting an answer from the teams, and for opening the bug ticket on the route record. That is good news. 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. 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. 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 happ

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

Hello Leslie, 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. 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… 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. Best, Antoine This reply was modified 1 hour, 17 minutes ago by Bertin Antoine .

maybe we’re close… they’re in the app now… Images: You must be logged in to view attached files.

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

Thanks Antoine for the capture. The teams are currently taking a look at it Have a good day, Leslie – Community Manager

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!

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

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/ — 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 — 6 of 6, against 488 of 488 correctly appended by non-Legrand routers. The

Hello Leslie, thank you for getting an answer from the developers. 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. So the practical question is: what options do we have to get it back? 1. Is there any EU firmware or SKU of the K4003C, K4027C or K4411C that includes MTOR support? 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. 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

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

Hello, The teams need more information to investigate. Can you : explain the exact need send me a backup of the F461 on this email address to check the configuration Have a good day, Leslie – Community Manager