I’ve noticed a new Source Routing firmware available.
What is the Source Routing firmware do that the default firmware does not?
And when/why would I use it?
Or is it used to address certain issues that cropped up?
Just curious, as I’ve not seen much mentioned about it.
Many thanks.
I came upon some info that helped me understand better.
https://www.digi.com/resources/documentation/Digidocs/90001942-13/concepts/c_source_routing.htm
And
Following up on this, from this note it looks like I’m at the point where I should be considering switching from “normal” to “source routing” firmware. I’m assuming that if I do that, I’ll need to re-pair all my devices, starting obviously with the routers?
I do not think you will. Going by this info.
Which I read, but the fact that it only supports 5 direct children made me wonder. What if the first 5 are all end devices? Is there any prioritisation to ensure that routers get priority?
Or is it all a case of “try and see” 
Any update on this?
Did you actually have to re-pair all your devices?
I haven’t tried yet, I’m not yet at 40 devices, so I’ve held off.
From the look of my map however, I’m pretty hopeful.
For anyone else looking at this thread: I did not have to re-pair when switching from default to source routing firmware.
Hi ppls I’m in a position to start setting up a few new zigbee networks up and I’m using CC2530 connected to RPi4’s GPIO. I like the fact I can hide the adapter inside the case of the RPi. I’m trying to decide which is the best firmware to use for these new installations and so I thought I’d try the routing fw on my existing network as I’m currently using standard to pretty much a reliable point with 33 devices. I have a few issues with devices not showing after the pi being powered off occasionally but that’s usually sorted with restarting zigbee2mqtt. And I think I need to upgrade some of my Ikea devices fw once the OTA is sorted out.
So I tried a new adapter with the routing fw and initially I could operate about 75% devices OK. Things started to get worse as time went on though and one point I couldn’t operate 50%. I noticed the Ikea remote e1574 had a red light which was flickering rapidly which I’ve never seen. So I rebooted all the bulbs on one floor which didn’t go down well. I think it crashed the CC2530 as everything became unresponsive and even rebooting the Pi didn’t sort it. In fact Z2M wouldn’t start at all as the adpater was still unavailable, I’m guessing it was either being blocked by network traffic or I had to physically power it off instead of just the system reboot. At that point I went back to the old adapter and everything is OK again.
So my question is should the network start working OK after x amount of time and do I have to do anything to help this? I turned on joining devices when I started the new adapter as I read this helped. Is routing firmware less stable for a new network? If I pair devices in location A and then move them to location B is this going take a while for everything to work out its routes, or longer than it would with non routing fw? My perception is if I have a lot of bulbs acting as routers, routing fw will enable my cc2530 to support more devices as long as they’re not flooding the system with messages. So I probably need to go with this for my existing network at least. I just hope I can get it working without repairing everything.
EDIT: I’ve just tried that adapter with routing fw again and still won’t start up. Is it bricked?? This is the log:
Zigbee2MQTT:info 2020-10-24 11:55:11: Logging to console and directory: '/app/data/log/2020-10-24.11-55-11' filename: log.txt
Zigbee2MQTT:info 2020-10-24 11:55:12: Starting Zigbee2MQTT version 1.15.0 (commit #1bccc5d)
Zigbee2MQTT:info 2020-10-24 11:55:12: Starting zigbee-herdsman...
Zigbee2MQTT:error 2020-10-24 11:55:19: Failed to call 'OnEvent' 'stop' (TypeError: Cannot read property 'getEntries' of null
at Function.loadFromDatabaseIfNecessary (/app/node_modules/zigbee-herdsman/dist/controller/model/device.js:214:55)
at Function.all (/app/node_modules/zigbee-herdsman/dist/controller/model/device.js:234:16)
at Controller.getDevices (/app/node_modules/zigbee-herdsman/dist/controller/controller.js:252:31)
at Zigbee.getClients (/app/lib/zigbee.js:132:30)
at OnEvent.stop (/app/lib/extension/onEvent.js:23:42)
at Controller.callExtensionMethod (/app/lib/controller.js:371:44)
at async Controller.stop (/app/lib/controller.js:192:9))
Zigbee2MQTT:error 2020-10-24 11:55:19: Not connected to MQTT server!
Zigbee2MQTT:error 2020-10-24 11:55:19: Cannot send message: topic: 'zigbee2mqtt/bridge/state', payload: 'offline
Zigbee2MQTT:info 2020-10-24 11:55:19: Disconnecting from MQTT server
(node:16) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'end' of undefined
at MQTT.disconnect (/app/lib/mqtt.js:86:21)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async Controller.stop (/app/lib/controller.js:196:9)
(node:16) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:16) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.