No, but I was considering reducing its rx and tx gains to see if it helps. Sounds backwards but it is like with wifi where blasting the highest wifi signal you can is counterproductive given the client needs to be able to reach your AP using its tiny little poor gain antenna so the best setup is usually with more APs using less power. In the case of Zigbee the APs would be the routers.
Thatâs why I asked: for a lot of people itâs counterintuitive that decreasing gain can actually result in a better network, especially with lower power devices.
FWIW, I moved from deCONZ to z2m last week, and from Conbee II to Sonoff, and so far so good. I have about 60 devices. I did have to re-pair some Aqara devices after the mesh settled, because they werenât using the best router, but now that Iâve run it for about a week it looks like the mesh is in much better shape than it was with deCONZ (perhaps because z2m uses source routing which I hadnât turned on in deCONZ).
I will have to give it a tryâŚ
What is that? And do all coordinators have that feature?
Not at all. I donât know how the zigbee routing algorithms work, but the coordinatorâs default +9db may be making it look stronger to the device and therefor preferred.
From what I understand, with source routing the coordinator maintains a âbest route to nodeâ list so it can send targeted messages to each node in the network, instead of using an adhoc hop-by-hop routing mechanism thatâs used by default. Source routing limits the number of messages that need to be sent, which will help with the stability of larger networks.
I think most modern coordinators are able to support source routing, as itâs mostly limited RAM that may prevent it from being used (I believe thereâs a source-routing-enabled firmware for CC253X devices, but because of their memory constraints it will limit the number of directly connected devices from an already low 20/25-ish to about 5).
z2m enables it by default on modern coordinators, deCONZ has the option to turn it on but AFAIK itâs off by default.
1 Like
I donât see you stating the version of firmware you are using in your Sonoff dongle, nor the type or version of coordinator system you are using. These variables are critical to any analysis. From some of your later posts, it appears you maybe using more current firmware and zigbee2mqtt coordinator versions. I and perhap others have found some degradation in operation with the newer firmwares and zigbee2mqtt coordinator versions. I tried the 20220219 firmware and version 1.25.0 production of zigbee2mqtt and found my test network very unstable. I have cc25xx devices as routers on this network, and these routers quit acting as routers after a period of an hour or so. I also had zigbee2mqtt crash with error shown below several times. I rolled the test network back to the version 1.24.0 zigbee2mqtt and 20211217 firmware and the network is back to stable. I needed to power cycle routers when changing coordinator firmware. Additionally, there are two â2022â firmwares floating around for the CC26xx devices, which you get, 20220219 or 20220115, depends on where you find the download link.
As you or others have stated, the changing of power levels in the coordinator firmware maybe contributing to some of the problems. As you and/or others state, futzing around with these values only on one side of the communications does not seem to be a good idea.
I am bit concerned that zigbee2mqtt work is being overloaded by the number of dimensions that it is expanding, both the number of firmwares and the amount of device configurations seems have grown vastly in last months. Tough to stay on top of this I think.
firmware for cc26xx
20220219
20220115
20211217
Error: SREQ '--> ZDO - extRouteDisc - {"dstAddr":24409,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)')
at Object.func (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:322:27)
at Queue.executeNext (/app/node_modules/zigbee-herdsman/src/utils/queue.ts:32:32)
``This is what Iâm running now:
Zigbee2MQTT version 1.25.0
Coordinator type zStack3x0
Coordinator revision 20220219
This was a totally clean install for me, not an update. I donât have any CC25XX devices in my network.
Error: SREQ ââ> ZDO - extRouteDisc - {âdstAddrâ:24409,âoptionsâ:0,âradiusâ:30}â failed with status â(0xc7: NWK_TABLE_FULL)â (expected â(0x00: SUCCESS)â)
Have you seen this? NWK_TABLE_FULL errors ¡ Issue #4964 ¡ Koenkk/zigbee2mqtt ¡ GitHub
Itâs being referred to in the z2m FAQ
I am using a Sonoff Zigbee 3.0 USB Dongle Plus and flashed the latest Koenikk firmware on it that I found on gihub:
The version is 20220219. The chipset of the Sonoff coordinator is TI CC2652P + CP2102N. This coordinator has an output gain of +20dBm which I think may be contributing to the issues. I will try to lower it a bit if only I can find the ZHA configuration template for configuration.yaml - I know I saw it but I just canât find it nowâŚ
I am using the default ZHA integration in HA as I did not want to further complicate things with MQTT. For zwave I do use, and prefer, the ZwaveJS2MQTT but I have the latter turned off.
I believe there are more current github issues related to this error message/crash and the 1.25.0 production code with cc26xx coordinators. This issue was âclosedâ by author by moving to development 1.25.0 code. Also the FAQ you reference is for cc25xx coordinators, another dimension.
Are you sure you do not have any cc25xx devices on your network? These are the most prevalent chipset I believe, real or clone. I am not sure my router problems were due to me having cc25xx devices as routers in my porior post, it was just that these were the only devices routing on this test network.
If you continue to have issues, you might want to try and roll back to the 20211217 firmware. I believe this version was the last released before the author upgraded to some of the newer TI code base (which I believe made some significant changes to type and ways of routing) and also was last version of firmware that does not offer any changes to power levels in cc26xx devices.
1 Like
Not sure how you conclude that, the original issue on Github was started by someone with a CC1352P-2 adapter and the issue refers to zStack3x0 which AFAIK isnât available for CC25XX coordinators.
Well, not entirely, but most of my network consists of IKEA, Aqara and (rebranded) Tuya and those donât use the CC25XXâs (IKEA and Tuya use EFR32, Aqara uses NXP). There are perhaps two or three devices Iâm not sure of, but given that the CC25XX series is rather old I donât think theyâll be used.
I understand your interest in minimizing the âmoving partsâ. That said, I have found that by abstracting many of my integrations via MQTT has contributed to the stability of my setups. In this particular case, the combo of running zigbee2mqtt in a docker container and communicating to Home Assistant (in a docker container) via MQTT (again running in a docker container) allows moving forward and backward in zigbee2mqtt versions and to run both a production and test zigbee2mqtt at same time. Allowing changes to things abastracted via MQTT without touching my Home Assistant instance. With the growing of number of zigbee devices, this has been very helpful. Good hunting!
2 Likes
Food for thought! Good points!
yes, it does appear this error has popped up several time. Below is the issue I was referencing, only 7,000 issues later 
:
I am over a week into having re-setup my zigbee network on my new coordinator and am getting really frustrated with sensors and sometimes wired devices dropping offline. I have reset, without deleting them from HA, and added back both letting it pick how or trying to pick a reasonably close wired router. More or less the same devices keep dropping and I canât figure out why.
I also noticed that several models of zigbee routers tend to establish âgreenâ connections (looking at visualization) anywhere they are installed, and others just have tons of yellow and red as well. I added a couple new in-wall zigbee outlets in two opposite sides of the house where the devices seem to drop more frequently but for now it doesnât seem to have helped.
I have 90 devices and quite a few are routers and well distributed. Any ideas or suggestions on how to stop this? Before re-setting up the network, it seemed rock solid or I never realized stuff dropping off (I was not really looking at status all the time).
1 Like
Just a thought with this many devices. I have 70+. Maybe you have forgot some, and they make some noice.
Setting up a new coordinator without resetting ZHA means that the network key and panid are the same. Hence all old devices âon the network beforeâ will still be on the zigbee network, however they will be in a panic mode as they can not find their coordinator. How they will influence the zigbee network I do not know, the design is that all devices with same panid should share coordinator. They might show up as online in ZHA overview, however not there/working.
Just a thought. With this many devices, some might have been used less often or only as test. At least I sometime forget some of themđ
2 Likes
I removed ZHA and added it back as it was the only way I found for me to configure the new USB address (or whatever it is called). I am using Proxmox and after I replaced the coordinator, I ended up with both the Zwave and Zigbee sticks sharing the same USB ID as they both have the CP2104 USB to UART chip which required me to switch to sharing the actual port to the VM instead of passing through the device regardless of what port it is plugged into. Anyway⌠digressing⌠if removing ZHA and adding it back is enough to reset it, then I did.
I am quite sure I did not forget any devices as the count is the same, less a couple that I removed and did not add back (both battery operated). I did add a couple in-wall zigbee outlets just to add repeaters in the two areas where I am having most trouble.
I am getting a sense that devices are not actually doing anything to find better routes or the process is way slower than I thought. Looking at my mesh it does seem to be a bit better (more green) and things appear to be working a bit better. I have reset a few wired devices (thus repeaters) in the general area where I am having trouble assuming that one or more of them were not working well and just causing trouble on the mesh. Early to say but it seems to have helped a bit.
Several of the battery devices in the outskirts of the mesh are the ones causing issues. They now have a red line connecting them to repeaters and the few I checked I believe it was me to point them to those specific repeaters as the closer ones were not working (device was failing to be discovered, or it would drop off the network, or not finish configuration). The most common zigbee devices acting as repeaters are in-wall Jasco outlets so if the issue lies with how them, then that might explain why I seem to be going in circles.
Have you tried to get a 2-3m long usb extender cable and move the dongle far away from you setup. Also far away from any wifi?
Regarding reset of ZHA, Iâm not sure how much is reset by deleting it. However, this should not make a difference if you know you manually re-paired all devices. If some of them re-entered into the mesh again, without you re-pairing on the device, then it might be a problem.
I am quite sure that all devices were re-paired and functional right after doing so⌠but they donât all want to continue working. Last night I figured out how to turn on source routing and this morning the mesh was more yellow and red than before, but it appears to slowly moving to green.
The Sonoff Zigbee 3.0 USB Dongle Plus is sitting on top of the network rack via an extender with a magnetic mount. There is a picture a few posts up. The closest AP is one room over, and there are 2 more possibly a tiny bit further away. Anyhow I turned down power on the 2.4GHz band with no visible benefit.
Im out of ideas, except for trying to move the coordinator several meter away from anything. However, not sure it will make any difference. Have to say you have tried a lot and all the obvious. Im out of ideas. Hope you find a solution. Good luck
1 Like