Curious, if you do this firmware update to the Sonoff Zigbee coordinator do you lose your network and have to rebuilld it? Thx!
No, you keep the network. You can however backup everything before hand:
You can even restore the backup on a different hub, or EZSP stick (Nortek GoControl HUSBZB-1 / Elelabs ELU013) or even TI stick and migrate your network seamlessly.
Good to know, thanks for the info and link!
Now, that is a real option 
--i-understand-i-can-update-eui64-only-once-and-i-still-want-to-do-it
Thanks, I noticed new firmware but it was “release candidate”, I see now that readme suggest 6.7.8 as preffered firmware. Will update.
What is the difference between current networking and source routing? What will change?
When I download only zigbee firmware, tasmota reports error (file signature error or something like that), I have done OTA update and I can only guess that along with tasmota part, zigbee was updated as well.
I have moved to source routing and used your ezsp_config data and after some reseting and rejoining my bulbs seem to work fully ok now. I will test this a little bit more in the coming days but currently I have 100% of desired functionality which is great!
Now when I look at my zigbee network some bulbs are connected to other bulbs and they are connected to the bridge (which is what I wanted to achieve), which basically means that either when I hit 32 zigbee devices on sonoff bridge I hit a limit of some kind OR that change to source routing meant something (I have read some articles about source routing but franky could not figure out difference between default and source routing (in zigbee network)).
I have not managed to create card for cheching all zigbee devices in one spot, but I will likely do that in next few days (or at least try).
I will report back in a day or two to confirm that my setup still works as expected.
Thank you!
Can I kindly ask for someone to explain what ‘source routing’ is? I have already attempted to search for this info but have come up short. thanks in advance.
That is some super news! Nothing better to do that ‘I’m bad’ dance in front of the significant other, after she was giving you the ‘eye’ as the lights flashed on and off 
Do you attribute the improvements to the Sonoff Zigbee bridge firmware upgrade or to setting the source routing at the ZHA level, or both or ¯_(ツ)_/¯ ?
Congrats, tech that works, what a concept!
Maybe this write up might help. I am still learning, but as I understand it Zigbee networks allow for several different routing methods for the network and it’s devices to decide on how to get a packet from the source node to the destination node (or nodes). Some of the methods are old and deprecated, I think there is a tree routing one that is for the books.
AODV = Ad-hoc On-demand Distance Vector
If I have to guess, I would say that change of routing parameters solved the problem.
I am not entirely sure that I have upgraded ezsp firmware (I do not know how to check that, firmware version is not reported in HA, maybe there is some console command for tasmota to get that info, will check).
p.s. One other conclusion from two days of playing with lights is that they perform much better if lights are grouped on ZHA level vs. home assistant group level.
Thanks for the link. I sorta understand it but not 100%.
What I could not glean from the link is if it’s ‘better’ to have source routing on?
My ZHA network with approx 30 devices is very stable so not sure that I want to tempt fate by turning source routing on unless there is a specific advantage.
thanks
Your conclusion that control at the ZHA level of commanding groups of zigbee devices makes sense. I think this was/is one of the big selling points of zigbee for pro lighting, low latency and devices moving in unison.
Here is something you can try to get version, but be careful! I am not sure how cool it is to execute zha bellows commands within HA while HA is running it’s own bellows instance, I have received a python timeout error a couple times but HA and ZHA seem to recover and continue. This shows that I am running 6.7.6.0 firmware in my Sonoff Zigbee Tasmota’ed hub. I am running HA in a docker container, so I can basically ssh into it via docker command line command or portainer gui as shown. The version is also dumped in the log if you turn the right debug on, shown below:
# https://github.com/zigpy/bellows
export EZSP_DEVICE=socket://192.168.2.190:8888
bellows info
[60:a4:23:ff:fe:00:00:00]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=cc:cc:cc:cc:e3:ab:00:00, panId=0x3498, radioTxPower=20, radioChannel=11, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.64|32|HAVE_TRUST_CENTER_LINK_KEY|8|GLOBAL_LINK_KEY: 124>, trustCenterLongAddress=60:a4:23:ff:fe:00:00:00)]
Manufacturer:
Board name:
EmberZNet version: 6.7.6.0 build 327
2021-01-25 09:03:59 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer:
2021-01-25 09:03:59 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name:
2021-01-25 09:03:59 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.6.0 build 327
You ask a good question. My first thought is don’t mess with something that is working! But keep the source routing and some of the other possible option in quiver as your network expands. In @mrakar 's case for reasons TBD source routing seems to be a must have. Is it the devices and their quirks? Is it how the network was ‘built out’? Much to learn! Good hunting!
Yes, thanks. Lots to learn!
This is a good 
&|:wine_glass: read (pdf):
https://www.silabs.com/documents/public/user-guides/ug103-02-fundamentals-zigbee.pdf
This paragraph:
By nature Zigbee devices are RAM-constrained, but often Zigbee networks are dense. This means that each router is within radio rangeof a large number of other routers. In such cases, the number of neighbors can exceed the maximum number of entries in a device’sneighbor table. In such cases, the wrong choice of which neighbors to keep can lead to routing inefficiencies or worse — a disconnec-ted network.
Might explain my situation from yesterday, all devices (36 of them) were visible to each other (with various signal levels, but still visible) and this might have created my problem. If my devices were further apart so that devices on the edge can not see each other, than my network might have worked. Instead, it might be that source routing (as suggested) is actually a better fit for my particular space in which my devices operate. Interesting (and so very different from wifi).
Interesting yes. However, I am struggling a bit to buy in to the idea that you are the first person in the Zigbee universe to have 36 bulbs in one area. If so, I hope they give you a tee shirt or something. One of the draws is that zigbee has been around for a long time (in tech years anyway), in reading the change log for the chip set in the in Sonoff Zigbee bridge, sure seems to be quite a bit of churn occurring.
I don’t see how you can guarantee how devices ‘see’ each other. Sure seems like they should be able to figure this out without you running around wrapping bulbs in aluminum foil
Wifi, and specifically WiFi mesh, a whole other animal I think. But with ‘fangs’ as well.
Hoping for a ‘stable mesh’ not a ‘stable mess’ for you!
Agree (fully).
But, according to other posts, some concentrators such as CC2531 have hard limit on how many direct connections they can handle and this number is approx. 30. Maybe, there is similar limit for EZSP as well? It would be interesting to know.
When I would look at the network diagram, I would, for example, see E27 bulb which was disconnected (status: unknown), but last seen just minutes or seconds ago.
I will check later today to see if the lights after 24 hours of communicating among themselves still work as desired. I also have to see if there is some advantages if I configure my network in functional clusters (lights, switches, sensors).
24 hours after config change this is visualization of my zigbee network, quite different from the first one and all nodes are connected (except for xiaomi buttons which report only ocassionaly so it is ok that they appear disconnected).
here are also all of my changes in configuration.yaml:
zha:
zigpy_config:
source_routing: true
ota:
ikea_provider: true # Auto update Trådfri devices
network:
channel: 11
ezsp_config:
CONFIG_MAX_END_DEVICE_CHILDREN: 16
CONFIG_SOURCE_ROUTE_TABLE_SIZE: 24
p.s. network channel is configured as this is the least populated frequency, so I guess the best one for zigbee
4 Likes
Nice find and a good read for bedtime 
Actually I was looking for documentation on what kind of configurations are available to be set in configuration.xml? Seems not easy to find 
, just the basics are there. For example this source_routing was never mentioned in any documentation, also the last two configurations you have there that are to limit the routes and children.
I am on ZNP but I would assume config would be somewhat similar.
FYI still quite new to all this, moved from SmartThings which I out grew quickly. I have like 81 devices on my mesh, its okay, but I do lost connection to some of my switches from time to time, I have to hit them a few times for them to wake up. Not sure if this might just be a switch thing as it is an end device.