ZHA errors every few days

I’m currently running HA 84.6 on a RPi3b+ in venv and a husbzb-1. I have 10 sengled bulbs, 1 osram plug and 1 smartthings plug. Every 2 or 3 days I get the following error flooding the log and none of the zigbee entities will work until I restart HA.

[homeassistant.components.sensor] Updating zha sensor took longer than the scheduled update interval 0:00:30

I did find this issue in github for zigpy but I wasn’t sure if my problem was related or not so I thought I would post here and ask if anyone had any ideas to what the problem might be.

I hate to say this…but…

I came to HA after 4 years of using SmartThings. Most of my stuff was z-wave, but I had about 4 devices that were the things that came with my SmartThings ‘kit’. I also use the HUSBZB-1 stick.

I was never able to get a stable zigbee system going. Just like you, every few days, the zigbee devices (or a subet) would stop working. The only way to get it back was a restart of HA. Since I had so few deices I replaced mine with z-wave (where I have 50+ devices already) and just stopped using zigbee.

I think there’s been some work lately on the zigbee system in HA, but it’s way less robust than the z-wave one.

There are people here who use a lot of zigbee stuff, so maybe mine was a result of my (very old) SmartThings devices not being modern enough

I thought about just replacing the zigbee stuff for z-wave, but 10 bulb is a lot to swallow with the slim z-wave bulb pickings.

Have any recommendations for z-wave bulbs?

Unfortunately, no… I replaced all of my wall switches withe z-wave switches rather than the bulbs (also way less confusing for others).

With that many bulbs I would spend some time trying to figure out the zigbee stuff. Here’s what I would do:

remove the smartthings plug from your system (i.e., do a zha.remove) and see how it goes for a few days, if it still happens, remove the other plug, then repeat. until you find the problem child. I suspect the SmartThings plug, only because the my troubles were with all smartthings devices as well.

I’m not sure what else I can tell you… it sucks. There’s a thread on here for zha working devices, maybe ask there?

Thanks, I’ll check out that thread.

I did recently add the smartthings plug because I needed a zigbee repeater. I just don’t remember if the problem appeared after the ST plug or if I had it prior.

Maybe I will look for a different zigbee repeater and remove it. It’s the only newest zigbee device that was added recently. The other osram plug and sengled bulbs have been there for as long as I’ve been using HA. So I don’t think they are the problem.

I just wanted to add that I’m having the same issue as you and looking for a resolution. Sometimes the Zigbee network will stop responding several times a day. I created an automation that restarts HA whenever a zigbee device state changes to offline, but it takes too long before the devices register as offline. My zigbee devices are mostly door sensors to trigger automatons and my alarm when away. I really don’t want to switch back to the Iris hub as it lacks a lot of automation, specifically the ability to cancel an alarm from non-Iris devices.

I ended up adding an automation that calls homeassistant.restart every 6 hours because eventually zha (using xbee) gets into some state where it stops being able to function until reboot.

My log is just fill of this:

ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy_xbee/zigbee/application.py", line 81, in request
    v = await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

I’ve had the same issue. Been periodically restarting, but now I’m losing zha components after only hours rather than days. Is there no idea what’s causing this?

My problems were resolved with the recent 0.89 release. I’m using an XBee S2C with ZHA.