I am still fairly new to HA; I searched the archives on this issue but I’ve had some difficulty interpreting the shorthand. Thanks in advance for your tolerance!
I am running Arch linux on a KAMRUI E1 Mini PC, using Docker to launch HA. All of my setup is via the UI; nothing fancy except one automation uses YAML to respond to specific events. I have a 23 device zigbee network using ZHA.
Earlier this week one device (no automations, but published to voice assistants) went “unavailable.” This morning I removed it, expecting to factory reset and re-add it. However, things went pretty wonky, and now ZHA won’t initialize. I’ve tried restarting HA, rebooting the system, removing and re-adding the Zigbee antenna, and finally restoring from backup, but no joy.
There are no “ZHA” entries in the logs. I do see a handful of errors:
Failed to disconnect from radio
1:07:22 PM – (WARNING) /usr/local/lib/python3.13/site-packages/zigpy/application.py - message first occurred at 1:07:22 PM and shows up 2 times
Attempted to use a closed event loop
1:07:22 PM – (WARNING) components/zha/__init__.py - message first occurred at 1:07:22 PM and shows up 4 times
Login attempt or request with invalid authentication from 192.168.4.122 (192.168.4.122). Requested URL: '/auth/token'. (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.2 Safari/605.1.15)
12:39:18 PM – (WARNING) HTTP - message first occurred at 12:39:16 PM and shows up 3 times
Ended unfinished session (id=12 from 2026-03-06 23:52:35.962603)
12:39:11 PM – (WARNING) Recorder
The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly
12:39:11 PM – (WARNING) Recorder
I assume at least the “radio” issues are related, but I suspect the “invalid authentication” issue has been around for a while. The AIs seem to think that I should be deleting some specific files in my configuration, but I don’t trust them enough to start doing that. Any suggestions?
Which has possibly corrupted you database according to the warning.
Are you shutting down cleanly, or just driving along the freeway at 60mph and putting the gear into PARK? Bolts tend to be forcibly ejected from the exhaust pipe!
Your backups may be corrupted too.
Is your system in the middle of an update, and if so, could letting it finish before you delete things help?
Ok, that was a useful note. Per this article, it looks like we should all bump the docker shutdown timeout to give things time to clean up. Since I’m using docker compose and a yaml config file, that looks like this for me:
Then to recover the database, I followed the steps described here, which boil down to this line: sqlite3 home-assistant_v2.db ".recover" | sqlite3 home-assistant_v2.db.fixed - to work around permissions issues, I ended up doing that in four steps (all issued from the //homeassistant/config/ directory):
Bouncing my HA docker container and no message about corrupt database, and the data all looks like it’s there. But the ZHA still doesn’t initialize. I have one remaining error message:
/usr/local/lib/python3.13/asyncio/base_events.py:750: RuntimeWarning: coroutine 'SerialProtocol.disconnect' was never awaited self._ready.clear()
Ok so I turned on ZHA debug logging, and digging through the logs it looks like my core problem is that I’ve lost the ability to communicate with my Sonoff zigbee radio:
2026-04-05 11:57:16.287 DEBUG (bellows.thread_0) [zigpy.serial] Opening a serial connection to '/dev/ttyUSB0' (baudrate=115200, xonxoff=True, rtscts=False)
2026-04-05 11:57:20.825 INFO (bellows.thread_0) [serialx.descriptor_transport] <serialx.platforms.serial_posix.PosixSerialTransport object at 0x7f1ede637290> was closed by peer
2026-04-05 11:57:20.825 DEBUG (bellows.thread_0) [serialx.descriptor_transport] Backgrounding a close request: None
2026-04-05 11:57:20.826 DEBUG (bellows.thread_0) [serialx.descriptor_transport] Closing connection: None
2026-04-05 11:57:20.826 DEBUG (bellows.thread_0) [serialx.descriptor_transport] Closing file descriptor 34
2026-04-05 11:57:20.826 DEBUG (bellows.thread_0) [serialx.descriptor_transport] Calling protocol `connection_lost` with exc=None
2026-04-05 11:57:20.826 DEBUG (bellows.thread_0) [zigpy.serial] Connection lost: None
2026-04-05 11:57:20.826 DEBUG (bellows.thread_0) [bellows.uart] Connection lost: None
2026-04-05 11:57:20.827 DEBUG (MainThread) [zigpy.application] Connection to the radio has been lost: None
2026-04-05 11:57:20.827 DEBUG (MainThread) [bellows.ezsp] EZSP startup/reset failed, retrying (2/3): ConnectionResetError('Remote server closed connection')
So - as I should have suspected from the beginning - the problem is the radio. It turns out I added a zWave antenna a few weeks ago, and (sigh) I specified the USB port directly in my docker-compose.yaml file:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0
I saw all the warnings about using the tty directly rather than ``/dev/serial/by-id/’ but when I was installing that hadn’t appeared to work so I went directly with the USB port. More fool me, clearly.
