If you go to the integrations and download the diagnostics for ZHA, you’ll see something like this in the json file.
"ezsp": {
"manufacturer": "HubZ ZigBee",
"board": "HUSBZB-1",
"version": "5.4.1.0 build 962",
"stack_version": 4,
"can_write_custom_eui64": true
}
Fairly sure the version is the firmware on the controller.
I’m fairly confident this only affects users using a HUSBZB-1 controller which is not supported by z2m.
Something changed with the built in zha integration that makes it unreliable now.
Mine is exactly as you show there:
"ezsp": {
"manufacturer": "HubZ ZigBee",
"board": "HUSBZB-1",
"version": "5.4.1.0 build 962",
"stack_version": 4,
"can_write_custom_eui64": true
}
Interesting. I would be curious ro see what others are. Especially those that are working again.
I’m on 6.7.8.0 and ZHA has been stable for me on 2023.5.4, though I only have two Aqara devices (TVOC air monitors).
"ezsp": {
"manufacturer": "HubZ ZigBee",
"board": "HUSBZB-1",
"version": "6.7.8.0 build 373",
"stack_version": 8,
"can_write_custom_eui64": true
}
You might want to consider upgrading the firmware as per one of the links that was posted earlier.
Two devices is an exceptionally small sample size to say that the code is error-free. I have dozens of Aqara devices, and the issue does not affect all of them. Further, the issue did not exist prior to 5.0, and there were ZERO listings about breaking changes.
Devs need to find a solution for this.
I haven’t even had a chance to see if any of the updates got my Phiilips devices working again.
Once they broke and I had to spend an hour restoring the backup to control my lights again, I put off updates for a while…
Maybe I’ll try 7.3+ when that comes out.
I am struggling heavily with Sonoff zigbee dongle. After HA update none of my zigbee sensors are available. At some point all I had to do was reload the integration, but even that doesn’t help anymore. They’re all gone.
I struggled REALLY bad with that dongle. Ended up trashing it.
Some people claim it’s fine, but there are two versions of it. I think maybe I (and you?) chose poorly…
Are you running Z2M or ZHA? If you already have the dongle and trying to use it with ZHA, I would strongly recommend dumping ZHA, and running Z2M instead. I use the Sonoff as both coordinator and router, and found it flawless with Z2M.
And with Z2M, you don’t have to change code everything HA updates, or crash and restart the zigbee network when HA restarts. It’s just a much better platform than ZHA, at least today.
I run ZHA. You mean MQTT? I’ve been thinking whether I should try that. It’s just when I started playing around with HA, for some reason I couldn’t get MQTT work. So I went with ZHA and it has worked well until the latest HA updates. Actually today I spent some time investigating the issues and it seems all my zigbee devices have reverted back to their default names. A bit strange I would say…
I’ll spend some time to get familiar with MQTT and how much work that would be to migrate to that. Anyways there’s quite much work ahead renaming all zigbee devices again and updating the sensors etc. accordingly…
Kari, I meant using zigbee2mqtt (commonly referred to as Z2M). The integration with HA via MQTT is VERY good, and it’s more capable in terms of device support, can run on a different PI or other host than HA itself, and isn’t slaved to the update cycle of HA the way ZHA is. Architecturally, it’s clearly superior to ZHA.
Those things may or may not all be accurate, but the fact remains that regardless the accuracy of those statements, it doesn’t absolve the devs of their responsibility for breaking a core piece of functionality and not even having the courtesy of listing it as a breaking change. Complete nonsense.
Watched a couple of Youtube videos on ZHA vs. MQTT and for now I am continuing with ZHA if my remaining issue is just the devices need to be paired again and renamed. So far the devices I went through yesterday seem to stay online.
If I changed to MQTT now I’d need to redo all automations and configurations from scratch.
In the future let’s see. If this kind of issues still continue then I might either set all my HA stuff into hell of a big bonfire or finally migrate to MQTT.
That’s a great point - about the automations. With dozens of zigbee devices on my network, it would take me HOURS of effort to redo all the automations and dashboards and everything else. Switching is NOT a viable solution.
It is possible to change the name of the sensor etc… so it’s consistent with the ZHA sensor etc… used in existing automations. I did a bit of this when I was transitioning from deconz.
In any case, hopefully new folks looking at this choice will avoid ZHA and use Z2M instead, even if it’s too painful for large existing installed bases to shift.
Look, we get it - you’re a z2m fan. This thread is about how the devs broke zha. Your comments are not contributing to getting zha fixed. Respectfully, please start your own thread.
Be sure to people that not all hardware is supported, too.
Thank you.
I still have all my zigbee devices dropping off network. Getting completely fed up with this. I thought this was fixed by re-pairing and renaming all devices. It worked a couple of days, but now all sensors are unavailable again. Seems I have no other choice but revert back to some earlier HA version or change to mqtt. Winter is coming and I need my heating related automations to work… I just can’t understand why HA is doing nothing to fix this. It was one of the latest Releases that broke the zigbee for many of us.
99.9999% of the time, it’s issues with your controller (Your sonoff zigbee dongle). I have Tubes controller and I don’t see any of these issues you see.
I’m not saying that switching to this controller may be better. But there are other ways to ensure you have less issues with your controller. Like using a USB extension cable. Ensuring that the stick is not near other devices to cause interference. Ensuring that you have a solid mesh (No devices really far away from another device). Ensuring that you have repeaters when needed. Etc.
strong echo of this, I was able to resolve 100% of my drops by much more deliberately placing the nodes and most especially the powered nodes that are being used as repeaters.
Also not having the controller located near a bunch of other stuff blasting 2.4ghz seemed to help as well since it had been placed near multiple esp8266 based sensors, but I kind of did all of that at the same time so it is kind of hard to determine which specific thing was the primary thing that resolved the drops, but I kind of needed to do all of those things regardless.