It only appears immediately after restarting Home Assistant (I’m running Home Assistant on an ODROID N2+) and has only started appearing today. I haven’t changed my Zigbee network, haven’t added devices, and haven’t changed my wireless network channel or configuration. That being said, I use Eero in bridge mode for my wireless AP and have not control over the channel it selects for any of it’s bands.
I ran a wifi analyzer on my phone and placed it near my Skyconnect and there was no detected signal at channel 15. The Eero network appears to be covering channels 1-7. I am not experiencing any dropouts or other issues with my Zigbee network…so I’m not sure if the error I’m receiving matters. It does seem odd that it’s started appearing with no change in my configuration.
Well there ya go! I figured I was off somehow. I can’t change the Eero…it works on PFM (Pure F*ing Magic) and is a black box. Unfortunately, it’s what we have invested a lot of money into (6 APs across our property with one UniFi P2P connection to out buildings). I guess I could replace the Eeros but it’s an expensive proposition to replace them with an equivalent product.
I assume the Eero network just decided to switch channels…and that’s what is causing this sudden issue.
I have read that one can change the channel on ZigBee…but that requires repairing all devices, correct?
How to run this test without waiting for message pop up in logs? Some service etc?
Valuable to check status after migrating channels on Zb/WiFi
Best, JR
I have a TP link Deco that has the same issue, cant change channels.
It will scan and optimize the network on demand though. I decided to beat it at its own game.
Router was on Channel 3, the worst for ZigBee channel 15 overlap. So, I set up an old router and put IT on channel 3 and placed it near the Deco. Ran the optimization and it decided that channel 3 was too congested and switched to channel 8. Zigbee performs much better now.
This is interesting! I have a few old routers laying around, I may give this a shot. The only issue is, I can’t even push the Eero to do an optimization…I have to call support to get that done
Thank you, I reviewed this information and have followed it previously. My ZigBee network works great, I am just seeing the message above in my logs now. Unfortunately, the Eero system appears to be the culprit. Since it does not offer manual channel selection of any kind, and it’s automatic channel selection has decided to blanket my ZigBee network with it’s love, I am researching an alternative mesh network for WiFi. Unfortunately, due to the size of our house and property, replacement of the Eero system will entail a considerable expense.
Additionally, since the devices on my ZigBee network are all functioning well, and are extensively integrated into automations throughout the house, I have decided to just let this ride instead of starting the ZigBee network from scratch on a new channel.
I really appreciate everyone helping me figure this out…I wish I could eliminate the log error…but it appears that it’s always been an issue and has not significantly affected the performance of my ZigBee network (I do have a lot of router devices closer together…so that’s probably why).
I have been monitoring for days with a spectrum analyzer and moving my devices off of that channel to a test zha ha system on channel 11. I can see with various energy plots that this warning is most likely (>95%) incorrect. FWIW. My 2.4G WiFi are way up in the upper bands.
Can someone point me to the actual code that computes this %? Would not mind looking into it a bit.
ZHA uses an open-source Python library implementing a hardware-independent Zigbee stack called zigpy. All coordinators compatible with zigpy can be used with ZHA.
Is there any reference information for how ZHA is coming up with the data for this message? I must say that is seems rather odd that HA’s ZHA system magically is able to come up with this data while running on multiple generic zigbee controller hardware devices. I have never seen any such information from much more dedicated zigbee focused for profit vendors running very specific zigbee hardware in over 5 years of working with zigbee.
zigpy-cli present the radio API from the main zigpy library that also acts as an partial hardware abstraction layer for some features which offer unified functions in a common manor via the zigpy library APIs and zigpy-cli command line interface → https://github.com/zigpy/zigpy and https://github.com/zigpy/zigpy-cli
Note that far from all available features and functions of all different Zigbee radios/ stacks have yet been implented in a uniformed way via zigpy radio API and zigpy-cli, so for many low-level features ZHA developers still have to implement in custom ways for each seperate zigpy radio library, and as an advanced end user you can also use zha-toolkit to access some of them → https://github.com/mdeweerd/zha-toolkit
The data can be extracted if developers want, but makers of commercial IoT black-box products often hide information that they do not think that the end user need to know as from thier point-of-view the product should just work. Read → Black box - Wikipedia
I believe that is one of the differenses that is to be highlighted between free and open source projects versus closed source for-profit products, as most companies will try to hide all their code as black-magic in order to keep all inovations and knowledge as intellectual property (patented or not), while most FOSS projects have an philosofy of trying to activly share both code inovations and knowledge, with focus on reusing core libraries between projects. Read → Free and open-source software - Wikipedia
PS: Off-topic but releated to this way of working you might be interested to read about the latest Google docuent leak in which a Google employee express thoughts about Google and other companies loosing the AI race to FOSS
Unfortunately, not in the posession of a Spectrum Analyzer, but seriousyl interested in this.
I observed these warning messages (as of 2023.6.x). In addition my Zigbee network has never been super stable (despite all precautions, extender cable, RF isolated from interference sources etc).
I started to use the ZHA Download diagnostics, and for several days monitored the “Energy scan”, sample below:
“energy_scan”: {
“11”: 15.32285793082191,
“12”: 19.00785284282869,
“13”: 73.50699819621309,
“14”: 95.69133648577223,
“15”: 98.21983128611214,
“16”: 98.43344238842926,
“17”: 97.39286236923465,
“18”: 96.19660508390695,
“19”: 96.19660508390695,
“20”: 55.9836862725909,
“21”: 65.26028270288712,
“22”: 12.244260188723507,
“23”: 23.33483723001185,
“24”: 19.00785284282869,
“25”: 15.32285793082191,
“26”: 95.69133648577223
},
This made me decide to go for a complete new fresh install, new network, on a different channel than the default 15. My regular scans showed that 20 and 25 were good options, all consistently “low”.
Spare you the hassle to re-install fresh network, but managed to move everything (with a new dongle…) to a new network, operating on channel-20. What I observe now is that channel-20 after my migration is also hitting the high mark of > 95%… I suspect that my full Zigbee network as it is migrated to channel-20 is also contributing to this “heat map”…
Good information, thx for doing the painful task lesson. I have been rather skeptical of this information since it has started to pop up more and more. As you state, only with a very expensive spectrum analyzer can you really ‘see’ what the various frequency utilization’s are. Even then, with mesh network systems the ‘fullness’ of a channel can often be less of the source of problems than a poor routing device can cause. The speed and robustness at which the network can reconfigure itself in the face of a device ‘coming and going’ as router can be a big contributor to the latency you see. Based on my fairly long playing around with this stuff, I think you would better served by a move to zigbee2mqtt. Good hunting!
I did something similar when this message first started appearing.
I was getting a warning that that I was at 95%+ utilisation, so as a test, a changed my coordinators channel to another very quiet channel and migrated ONE device across. Immediately, that channel also shot up from about (iirc) 15% to 90%, so I just stopped and returned everything back to the default channel 15.
I’ve noticed that (for me at least), the warning is very sporadic. This is my current energy scan:
I got same warning using ZHA on HA Yellow this week.
I’m using channel 15 but I only have about 40-50 devices (a few aqara sensors and about 40 inovelli blue switches) on the zigbee network. I have read a multiple places that the limit for zigbee itself is somewhere over 100. While I know that many times coordinators are the limitation, I’ve seen no documentation as to what the actual limit for sky Connect or HA yellow zigbee coordinator really is.
I’m keeping my zigbee network on 15 because I also have multiple hue hubs using channels 20 and 25 to support 100-150 hue bulbs and devices. I was trying to spread the pain across multiple zigbee networks instead of using one network. Of course I also have three 2.4 GHz and 5 GHz wireless access points running WiFi throughout the house as well.
Any big revelations or suggestions to solve this issue? Or is the consensus that it’s a false warning?
Poor taste joke by me I am sure, however, I think the day job of who ever added these messages to Home Assistant was writing MCAS messages for the 737MAX…
I still maintain, these message should have a prefix of "Chicken Little Sez : "
If someone could show me a graph of these number say ever 0.5 to 1 second over a useful period of time, say 24 hours. This would probably reduce my skepticism of this measure.
I’m pretty sure there are zigbee network with 1,000’s of nodes on them. From my amateur understanding, the actual bandwidth used by Zigbee packets for most meshes would measure in the 10’s to 100’ of packets per second. Pretty chump change, for a network running with a gigahertz carrier.
I’m not saying that your physical environment might not have something injecting ‘noise’ in the 2.4 GHz spectrum that could effect your Zigbee network. However, it you had zero other communications going on in this spectrum, your Zigbee networks would have no issue at the scale you have, even it they were all on the same Zigbee channel.
If you want to have a somewhat low cost and useful look at your Gigahertz spectrum, I recommend starting with this MacOS based software for 1 Jackson and then add on to it with their Pro software and Raspberry Pi based monitoring device for on the order of 3 to 5 Franklins. Links below.
