I just moved from deCONZ to ZHA with the ConBeeII stickk I’ve used for years. After the move, almost everything (well, most lights at least) is extremely slow. When toggling them from the UI, ZigBee remote, or motion sensors, it can take several seconds to respond. Quite a few lights simply do not respond at all (though they appear in ZHA config).
I do have an AP in the same room, but using 2.4 GHz channel 1, and another AP on another floor on channel 7, while the ConBeeII stick is set to ZigBee Channel 25 (set in deCONZ ; since I can’t see option to change this in ZHA, I’m assuming that this has not changed?).
The usual tricks (for the occasional drop in deCONS) such as restarting control software or power cycling lights does not work for my ZHA install.
Any suggestions to avoid going back (and having to re-pair 60+ devices, and figure out which generic name is what device… again)?
EDIT: I see that the hatebin link had cut off the last 85% of the logs. I’ve made a new one only with the level >= warning. hatebin. The crossed out one has a lot of entries with level = DEBUG, but all the WARNING ones were in the part that was too long, I guess.
Hey mate, of the 60+ devices do you have a number of powered ones as well to act as repeaters/routers? I was having the same issue recently with ZHA/Conbee II, and a remote switch that was a fair distance from the Conbee II. I purchased a Philips Hue globe yesterday to act as a repeater, and now the remote switch is turning lights on and off instantly…
That would include lightbulbs, right? If so, I have a few dozen.
And the exact same physical setup worked for years with deCONZ, which is why I thought it so weird. I literally did not move a single device or the ConBeeII stick between the deCONZ and ZHA approaches. I just passed the stick to the VM, it’s even physically connected to the same server that ran deCONZ in docker…
I still have some devices (only battery powered, as far as I remember) that I didn’t bother to add yet, in case I’m going to have to go back to deCONZ and re-pair them all back again. But so far:
However, it’s mostly the lights that are a problem. And there’s no obvious correlation with ones far not working, while those close do. But it is mostly certain lights, that don’t work well (or at all, in some cases).
And I do get all those warnings in the logs that I’m not really sure what mean.
EDIT: I see that the hatebin link had cut off the last 85% of the logs. I’ve made a new one only with the level >= warning. hatebin
Note that most Zigbee coordinators and especially ConBee/Raspbee are known for being very susceptible to signal interference, so other than updating the ConBee firmware, be sure to take actions to avoid radio frequency interference and electromagnetic interference by using suggested long USB extension cable to a USB 2.0 port (or use it via a USB 2.0 hub) and add electromagnetic shielding to computer, peripherals, and appliances, as well consider getting better shielded cables/wires. Read:
I have gone through pretty much all the “best practices” for my old deCONZ network, which worked pretty well for a few years. Updating the ConBeeII firmware has improved things, however. Somewhat.
So unless there is some underlying difference between deCONZ and ZHA that can explain, it would seem to me that the issue is most likely that ZHA is using a ZigBee channel that overlaps with WiFi (because any two APs with non-overlapping 2.4 GHz channels would somewhat overlap with ZigBee channel 15, right? At leas the sideband lobes), and deCONZ was not?
Luckily I live in Europe, so we also have WiFi channels 12 and 13 available; I’ve set the AP close to the ConBeeII to channel 13, and the other one to channel 8. I’ll test a bit and see if it helps.
I would still have preferred just staying with ZigBee channel 25, and have no overlap with any WiFi, but just the sound of
after just having done that gives more than a few grey hairs.
Is it a technical limitation in ZHA that you cannot change the channel without having to re-pair everything?
One idea. Not sure it is correct. I have a Conbee2/ZHA network with 60+ devices, and it is solid and fast.
You mention you have some devices that you have not included in the network again. As the coordinator is the same, and might be using the same network key, they will actually connect again. They will then be part of the zigbee network, however not known HA/ZHA, they might create problem? Im not sure.
One other idea, that I experienced early in my HA setup. The DECONZ supervisor should not be installed. Only ZHA. It created strange behavior when I had both installed.
Thanks for the advice, I’ll try re-pairing the last few devices (hope I can remember all!).
Nothing deCONZ has ever been included in this current Home Assistant install. This is hassOS in VM that I’m in the process of migrating to from my old setup, which was just HA Core running in Docker (now stopped). That’s the install where deCONZ was used.
ZHA does support “source routing” for Silicon Labs and Texas Instruments Zigbee Coordinators but those are using different radio libraries for zigpy, and not sure if zigpy-deconz radio library support it?
Without having “source routing” enabled it will be much more limited with amount of Zigbee 3.0 devices that you can add to a Zigbee Coordinator as its Zigbee Routers is not off-loading size if routing tables.
Off-topic but FYI, ZHA/zigpy developers are working on a tool that will allow you to backup Zigbee network from ConBee or RaspBee and restore to other brand Zigbee Coordinator with more resourses:
I am not saying that ConBee or RaspBee are bad as Zigbee Coordinators but it is a fact that they use a MCU chip that has less RAM and flash storage and will therefore be much more limited in the amount of Zigbee 3.0 devices compared to Silicon Labs EFR32MG21 and Texas Instruments CC2652 chips.
I am not actually sure, it might be a limitation in zigpy or in Zigbee specifications. Suggest you ask here:
Thanks for all the info. A bit to go through, but I think that as soon as there’s an easy way to backup/restore from a ConBeeII stick, maybe it is time for an upgrade.
Any recommendations? If using a Ethernet connected version (recently noticed this was an option, e.g. Tube’s PoE version), I could move it far away from any APs. Are there any real disadvantages of using those instead of simple USB connections?
Exactly why I really liked my old (deCONZ days) setup using WiFi channels 1, and 7 (no channel 11 in use), and ZigBee Channel 25. As soon as I also used an extension USB, I hardly had any issues for 2+ years.
Of course, as soon as I tried WiFi channels 8 and 13, some of my ESP devices (e.g. openEVSE) started having issues, and I found that ESP devices don’t necessarily play nice with channels > 11 (though I haven’t done very thorough testing of this myself). So maybe that’s not the way to go…
Texas Instruments CC2652P and Silicon Labs EFR32MG21 or EFR32MG24 are the most powerful and have the most RAM so can control more Zigbee 3.0 devices which security schemes used a lot of RAM.
I personally recommend CC2652P as the first choice today because both Home Assistant’s native ZHA integration and Zigbee2MQTT have great support for Texas Instruments CC2652 adapters (with latest Z-Stack Zigbee Coordinator NCP firmware), as the only reason for not recommending Silicon Labs EFR32MG2x (Silabs EFR32MG21 or later) as the first choice today is that while those work great in Home Assistant’s native ZHA integration they currently only have experimental support in Zigbee2MQTT (due to Zigbee2MQTT developers are few and they primarily use Texas Instruments CC2652 based adapters themselves), but that might of course change in the future.
The ZHA (and zigpy) developers have proven that Silicon Labs EFR32MG2x based adapter hardware and firmware are certainly at least as good as Texas Instruments CC2652 adapters as long as there are developers that actively use those themselves and fix any issues that arise via bug-reports, etc…
Also note that there are disadvantages of using a network-attached Zigbee coordinator instead of just a long USB extension cable because the serial protocol they need is not robust so need a stable connection, which is the reason why using a Zigbee coordinator over Wi-Fi is especially warned against, see ex:
Btw, testers testing backup mentioned pull request confirmed that patches to backup ConBee to the new Open ZigBee Coordinator Backup Format required to restore backups to different stacks/solutions:
Great, the CC2652 is also what’s in more of the ones I’ve been looking at.
I’d never use WiFi for this, but is the “serial protocol robustness” also an issue for a reliable hardwired connection? I couldn’t see any claims of this? If using e.g. the PoE CC2652P2 coordinator I mentioned, I could then place it away from the server room (which does probably have one of the highest level of RF interference in the house).
Alternately, I’d probably just add another “Remote Home Assistant” on an RPi with an USB ZigBee controller and pass ZigBee entities. But that would still ultimately be an ethernet connected ZigBee controller, so it seems to me like the RPi and additional HA instance to manage should be redundant?
That would be a much more stable solution because not tunnel Zigbee serial protocols over a network. Such a solution cannot be compared with serial connection to a “network-attached” Zigbee Coordinator. If you link a second Home Assistant instance with a “direct-attached” Zigbee Coordinator USB adapter then that would convert the serial protocol to MQTT or other protocol meant for network communication.
There should not be any serious issues in practice if have a wired Ethernet “network-attached” Zigbee Coordinator connection over a local LAN. Many people in this community use wired Ethernet connected network-attached Zigbee Coordinator adapters like Tube’s Zigbee Gateway and ZigStar LAN Gateway without any problems at all. You can read many reports from their users in the HA community here:
Also, note that based on the fact that there are fewer reports about it in the communities, Texas Instruments ZNP serial protocol is generally believed to have slightly more robust than the Silicon Labs EZSP (EmberZNet Serial Protocol) in the way that Silicon Labs based “WiFi-attached” Zigbee Coordinator connection is infamously known to be notoriously unstable when connected over a Wi-Fi network that is not extremely stable. Though to be fair there are today a lot more Silicon Labs WiFi-attached Zigbee Coordinator products on the market that has been hacked for use with ZHA and Zigbee2MQTT than there are Texas Instruments based WiFi-attached Zigbee Coordinator products).
I think that in practice the only common scenario that causes issues for even Texas Instruments based wired Ethernet “network-attached” Zigbee Coordinators is when the LAN/switch does down for whatever reason (like a locally blown fuse) and your ZHA/Z2M instance is still up, then it would be like pulling out the adapter during operation. That would be to the effect same as in a scenario where you would pull out a Zigbee Coordinator USB adapter without stopping ZHA/Z2M. In that case and the wired Ethernet “network-attached” Zigbee Coordinator comes back then you might need to restart your ZHA/Z2M instance afterwards if the serial protocol the Zigbee stack uses is not robust enough to recover.
To workaround that issue you could as a suggestion make sure that both your computer running ZHA/Z2M and the wired Ethernet “network-attached” Zigbee Coordinator are both powered by the same PoE (Power over Ethernet) switch as that way if one dies due to power loss then other also dies too.
I’m following your trail as I have pretty much the same story. Conbee II started loosing it after the end of december update. I have +60 devices, using 3 ikea wifi range extenders, in a mix of ikea, xiomi and others. I sometimes wake up and 30% of the devices became offline during the night. Look at the image. The repeaters are sitting there, doing nothing (they were reactivated some 5 hours ago).
Problem is I’m not “that” techical. So eager to read the outcome of your discussions.
Well, my initial thoughts is that it’s an RF interference issue for me.
I’m basing this on the fact that
(1) It happened when I changed from deCONZ to ZHA, and didn’t change anything else, but this apparently results in an automatic change to ZigBee channel 15 (if you set up the integration from UI at least, there’s a workaround if you use yaml, and specify channel when setting up),
(2) my old setup with ZigBee channel 25 (well away from any WiFi interference from me or any neighbors) worked quite well, and
(3) I found a chance to disable the WiFi AP near the ConBeeII stick for a few days while I was home alone (for testing), and I saw a significant improvement in the ZigBee network; almost every device responds near-instantaneously, just like with the deCONZ setup. Only problem is that I still can’t pair a few sensors and a single light “in place”, but have to move them close to the coordinator for it to work (which is not recommended).
So not sure if this is any help to you. If it happened after a Hass update, then it’s probably not the same issue…
Hi, thanks for the answer - I’m about to try something but I’m not sure of the consequences… My setup is still fullly with Deconz. You’re saying I could try to change to channel 25 here? Ands I get a warning… is it “everything might collapse” or some devices might need re-pairing? Thanks
I have changed my Conbee II channel to 25 too with 60+ devices without any issues.
The only thing that could happen (happened to a friend of mine) is that your endpoints (like door/window sensors) need to send a state to the coordinator. Simply open/close the window/door and it binds again.
