Zha.core.channels.base, async_initialize: all attempts have failed

Hi everyone,

I also faced the EXACT same problem after the last update. The same error message in home assistant as the op and lso Conbee II
I tried the suggestion of holding the pair button but that not only did not fix the problem but also made the working devices stop working! lol
The search did not find any device at all.

Before removing everything I tried reconfiguring zigbee devices from the UI. That passed for some devices that worked fine but failed for others that also worked fine and of course for those that experience the problem…

At the end I bit the bullet and removed all my 22 Zigbee devices :-< or better said I tried my best to remove everything related to ZHA

I thought maybe I give other solutions a try but neither deconz nor zigbee2mqtt worked. They both timed out when trying to communicate with the device ( or something similar to that ) I thought maybe the problem is hardware related but when I tried to set up ZHA again ( all 22 devices smh.) it works fine. at least for now.

I learned a painful lesson to not update home assistant without first making a FULL snapshot. As others have said the snapshot it automatically makes before update is more for decoration than actually fixing problem later.

edit: Sorry this wasn’t meant as a reply to francisp but a general reply to the topic X_X

I see these errors too, but does not seem have any impact. My Zigbee devices are working fine.
Also HA on NUC with Proxmox (Debian 11 VM). My ConBee II is running on RPi2 connected using usbip to HA.

Not sure if its much help, but all I tried was a ‘rediscover’ and then after ~20 minutes everything started working again.

The frequency of my devices dropping has increased a bit, it’s no longer around a HA release or a restart. Now each morning I’m finding HA has a device or two off-line (this is new, used to be stable and just HA updates would mess it up).

While I used to use the ZHA integration “Add device” to pair again, I’m finding I just need to press the device’s pair button for 5 seconds, get the LED flash (not doing anything in HA but watch the device entities) and then in HA it switches from unavailable to working fine. These are mains powered devices, shouldn’t need to be waken up like this.

Oddly, I’ve also noticed the Zigbee Coordinator (Sonos bridge) marked as offline and a RSSI of “unknown”, but yet all the devices are reporting in just fine and the “Last Seen” timestamps are increasing. How are they reporting in if the Coordinator is offline?

BTW - The “zha-network-card” has been very helpful giving me at a glance view of all Zigbee devices, state and a “Last Seen” timestamp.

1 Like

I find it odd no one can figure out the issue that so many are having. Best way I candescrive it is some entities like those that show open close stop working but battery and temp on the same device keep working.

It seems like once ZHA gets a CRC error for a device it is simply unable to communicate with that device again until ZHA is restarted. It does not appear that ZHA can be restarted independently of HA. I was having CRC errors using a Sonoff WiFi Coordinator which is pretty much listed as not recommended to use any more.

As @francisp pointed out, having the Zigbee network decoupled from HA is nice. I decided to redesign my Zigbee network from scratch:

  • I switched to a LAN based Coordinator with decent antenna
  • Switched to a higher Zigbee Channel which seems to have less interference (based on my Ubiquity access point scans)
  • Converted everything over to Zigbee2MQTT and just uninstalled ZHA a few hours ago
  • Made use of Zigbee groups (super easy in Zigbee2MQTT) which now uses a single Zigbee command to work with many lights, (HA light groups send instructions to each light individually).

Yeah, its was a few days of work to get it up and running and move devices over, and fix my dashboards and automations to work with new entity names.

This was stable enough that I was able to migrate over my last reminding items connected to SmartThings Hub and finally turn that off and I’ll be working on migrating my Hue lights off that hub and turn that off as well.

All helps to reduce Zigbee traffic. I’m at 26 devices now. Monitoring to see how things go.

If anyone is tempted to look at Zigbee2MQTT instead, be sure to use the latest dev version not the December stable version. They are doing a lot of work on the HA integration and automatic entity creation via MQTT Discovery. Rename a device in Zigbee2MQTT and it will rename all the related entities in HA to match. The latest dev build fixed issues I had with some sensors not getting created.

It was also interesting to see the same sensors report different attributes now. For example I had no idea all the Aqara contact sensors that I have already include a temperature sensor, My ZHA installation did not expose it, but it is under Zigbee2MQTT.

It also provides OTA firmware updates to many bulbs. Finally got all my IKEA and Phillips bulbs updated to latest firmware.

3 Likes

Just to chime in a final update. I’ve not had a single device drop from the network and I’ve been able to add everything I wanted (35 devices). Everything is INSTANT, there is zero delay now.

I have an automation which increases a Sengled back door light from 10% to 100% when the door is opened. I used to open the door and look at the light and wonder if it was going to get brighter or not. Now the light reacts before the door is fully out of the door jam, its fascinating how fast everything reacts now.

Removing ZHA, Hue, and SmartThings integrations shaved off about 35 seconds of HA restart time (I restart in 5 to 8 seconds now). Everything is just one Zigbee network the way it should be.

I’m certainly not blaming anything on ZHA. You can’t blame the devs for your own bad choices in coordinators, overlapping channels with WiFi, multiple hubs, and not taking the time to understand a bit more than just the basics of Zigbee network. That said, I’m extremely happy with Zigbee2MQTT and its feature set that I don’t plan on switching back to ZHA to see if all the changes I made would make that environment equally enjoyable.

I mistakenly thought you just bought, paired and marvel at the technology. That only worked for a handful of devices.

2 Likes

I’m having the same issue and have been looking at Z2M for a while. Do you run both the mqtt add-on and Z2M in HA or do you have a separate VM for it/them?

I have Home Assistant, Z2M, Mosquitto MQTT (and others) all running under docker as separate containers.

2 Likes

Same issue here after the 2022.3.3 core update. Someone found a solution in the ZHA?

1 Like

This is a good alternative, SLAVA UKRAJINI!
https://www.ebay.com/itm/165178757770

@franciscorocha - that is the unit I’m using. :slight_smile:

ZHA also completely stopped working for me yesterday after upgrading to the latest HA version. All devices are coupled and I can see them in the topology view but I can not do any actions. E.g. let my covers down or pair new devices.

Same here - no updates, no restarts, yet my devices stopped responding after weeks of solid performance. ZHA visualization looks fine. After restarting and a hard reboot didn’t work, I updated to latest HA Core and OS. No relief. Super frustrating.

Anyone had any luck with this? I just updated to 2022.3.8 and all of my zha devices just stopped working. Same async error, they still show up in the visualization, but none of them respond, even after a full hard reboot. Anyone find anything?

Turns out my problem was due to my HUSZBZ being plugged into a USB 3.0 slot. I moved it to a 2.0 slot and everything returned. Just in case someone comes across this later!

Tip is to see/follow https://github.com/home-assistant/home-assistant.io/pull/18864

https://github.com/home-assistant/home-assistant.io/commit/970295a277e8f01d3ee39eeeaacf453625b988d3

and also

https://www.home-assistant.io/integrations/zha#best-practices-to-avoid-pairingconnection-difficulties

I am having these messages appear in my logs since updating to 2022.4.0. My network follows most of the best practices listed in @Hedda 's reply. Around 40 devices with ample amounts of routers for my ~900 sqft apartment.

Out of the blue the messages started to appear in my logs, continually spamming them. None of my Zigbee devices are available during this time, although 50-70% of them will start to come online over the next half hour, and then stop short of having my entire network back online.

Logger: homeassistant.components.zha.core.channels.base
Source: components/zha/core/channels/base.py:457
Integration: Zigbee Home Automation (documentation, issues)
First occurred: 6:44:02 PM (13 occurrences)
Last logged: 6:47:46 PM

[0x03AC:1:0x0300]: async_initialize: all attempts have failed: [DeliveryError('[0x03ac:1:0x0300]: Message send failure'), DeliveryError('[0x03ac:1:0x0300]: Message send failure'), DeliveryError('[0x03ac:1:0x0300]: Message send failure'), DeliveryError('[0x03ac:1:0x0300]: Message send failure')]
[0x9117:1:0x0006]: async_initialize: all attempts have failed: [DeliveryError('[0x9117:1:0x0006]: Message send failure'), DeliveryError('[0x9117:1:0x0006]: Message send failure'), DeliveryError('[0x9117:1:0x0006]: Message send failure'), DeliveryError('[0x9117:1:0x0006]: Message send failure')]
[0x03AC:1:0x0006]: async_initialize: all attempts have failed: [DeliveryError('[0x03ac:1:0x0006]: Message send failure'), DeliveryError('[0x03ac:1:0x0006]: Message send failure'), DeliveryError('[0x03ac:1:0x0006]: Message send failure'), DeliveryError('[0x03ac:1:0x0006]: Message send failure')]
[0x9117:1:0x0702]: async_initialize: all attempts have failed: [DeliveryError('[0x9117:1:0x0702]: Message send failure'), DeliveryError('[0x9117:1:0x0702]: Message send failure'), DeliveryError('[0x9117:1:0x0702]: Message send failure'), DeliveryError('[0x9117:1:0x0702]: Message send failure')]
[0x03AC:1:0x0702]: async_initialize: all attempts have failed: [DeliveryError('[0x03ac:1:0x0702]: Message send failure'), DeliveryError('[0x03ac:1:0x0702]: Message send failure'), DeliveryError('[0x03ac:1:0x0702]: Message send failure'), DeliveryError('[0x03ac:1:0x0702]: Message send failure')]

I have attempted to upgrade to 2022.4.1 without success. I have attempted to delete my “deps” folder. I have attempted rolling back to my full backups from weeks ago where there were no issues. I attempted to switch my ConBee 2 from USB 2.0 to USB 3.0 and back again. No luck.

When attempting to troubleshoot this, I have noticed that the Studio Code Server add-on as well as the Samba fileshare I had set up thru an additional add-on were not functional at this time.

Activating extension 'esbenp.prettier-vscode' failed: ENOENT: no such file or directory, uv_cwd.

This is a serious breaking issue for me that I can’t seem to resolve, and it appears as though I am far from being alone with ZHA issues recently. But this seems way deeper than that. Is there any suggestions to getting my HomeAssistant back to where it needs to be? Has anyone else been able to get this fixed?

FYI, release notes did not mention it but there was a huge update/change to ZHA dependencies (zigpy and zha-quirks/ zha-device-handlers Zigbee libraries) for Home Assistant 2022.4.x so I would just wait.

zigpy was updated to the very latest Zigbee Cluster Library specification, which should greatly improve interoperability in the long run, meaning that newer devices will need fewer quirks. But that was a large change so there is no real surprise that things broke.

Tip is not upgrade to the first revisions of any new releases if you want to avoid breakage for stability.

Regardless, did you update the firmware on Zigbee Coordinator dongle to the very latest version?

If computer only has USB 3.0 ports then the recommendation is to get a powered USB 2.0 hub for it.

https://www.google.com/search?q=powered+USB+2.0+hub

https://www.amazon.com/s?k=powered+USB+2.0+hub

Example:

https://www.amazon.com/AmazonBasics-Port-USB-Power-Adapter/dp/B00DQFGJR4/

Thank you for your thoughtful reply, boss.

Release notes not mentioning massive dependency updates doesn’t seem too helpful in HA’s quest to become mass-market adoptable. I generally agree with your sentiment of not updating to newest releases for compatibility, the fact that I can’t get my HA instance revived with backups is frustrating for me. I take frequent backups, validate them as working, and store on multiple remote locations following best practices to allow me to upgrade my Home Assistant version (working in information security has pounded into my head that you must keep everything up to date). However, none of my backups will roll-back the damage that this update has done to my network.

I did a clean install onto Home Assistant OS 8.0 RC1 yesterday and right out of the box, everything seemed to work fine. Then, I uploaded a full backup of my system from a 2022.3.6 release and was met without a working install yet again.

This morning I spent some time clearing out my Zigbee.db and ZHA.config files, then deleted/reinstalled ZHA. After adding about 6 devices (1/8th of my overall Zigbee network) I attempted to reboot and instantly my issues came right back. At this point, it seems like my best bet is to literally sit with a non-functioning Zigbee network in hopes that a dev fixes this… or completely start from ground zero on my Home Assistant install ie. reconfiguring remote access, mobile app companions, all my dashboards, node-red and HA automation flows, etc etc etc.