Forum

<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>