My Zigbee network used to run fine for many months (using ZHA). Last week, I’ve upgraded my OS from 13.1 to 13.2. Immediately after booting, HA crashed. The last entry in the homeassistant.log file is:
ERROR (bellows.thread_0) [ bellows.uart] Lost serial connection: SerialException('device reports readiness to read but returned no data (device disconnected or multiple access on port?)')
Even after rolling back to version 13.1 of the OS, the issue is not resolved. I’ve ruled out an issue with the Sonoff Zigbee stick itself by connecting it to spare RPI4 with HA. That just worked fine.
I’ve tried different USB ports, but without luck. Sometimes the Zigbee network is up for a few minutes untill HA crashes again with the above log entry in the logfile.
I am not sure anymore what to do next.
I found out that I have to boot my Home Assistant without the Sonoff zigbee stick connected. When I boot it with the Zigbee dongle inserted, it looks like it is somehow conflicting with my DSMR integration (usb connection to the utility meter). Only when Home Assistant is up and running, I can put the Zigbee Dongle in the Intel NUC USB port and the Zigbee network will get online.
Restarting Home Assistant is not an issue, but rebooting the device will generate the error in the log and causes Home Assistant to crash entirely.
I have a clue. It’s almost certainly caused by the fact that your USB devices are configured by their USB path (eg. /dev/ttyUSB0) instead of /dev/serial/by-id.
ZHA definitely accepts a serial by ID and it is actually recommended to use this in the docs. Not sure whether the DSMR integration also supports it since I do not use it, but technically, it should. (Search around for this before changing the DSMR config).
Basically the USB path is not tied to a particular device. When you reboot (such as after an update), your USB devices will get assigned a path at random if you define them using a path.
Given you have 2 USB devices, the DSMR dongle is being assigned the path which was previously being used by your Zigbee dongle. When ZHA loads, it tries to read from that path but instead of the coordinator, it finds the DSMR dongle.
I suspect the opposite is happening with your DSMR integration - it’s trying to read a Zigbee dongle and throws a fit.
Both scenarios could lead to your instance crashing if the system gets swamped with errors, and honestly you’re lucky this didn’t happen earlier.
I am sorry for the delayed response. You are right. I have reconfigured ZHA to not use the USB path anymore. Doing this for DSMR was a bit more challenging. Had to change it in /config/.storage/core.config_entries
Anyways, I can now reboot without the need of having to remove the Zigbee stick during the boot process.
Thanks @ShadowFist !
Hi Marcel and ShadowFirst im interested in how you changed the configuration in ZHA im totally new to HA and just setting up but seems like im having a similar problem HA hangs up whenever i try to connect devices to ZHA ive checked my USB Path and it is /dev/ttyUSB0 how and where do i change this to /dev/serial/by-id
many thanks in advance
Two years after installing all my Hue bulbs on ZHA I decided to go through the laborious task of pairing them with a Hue bridge, waiting several hours for firmware update and then resetting them and re-adding them to Home Assistant. This worked quite well.
Yesterday I started on the hue sensors and remotes. When adding these battery Zigbee devices back into HA, the interview process would normally show ‘starting interview’ and then the ‘complete’ message. However, sometimes the interview would start and never complete. After happening a few times, the whole HA system crashes and I have to do a PoE cycle to reboot (HA Yellow)
The hardware is a HA Yellow with a second Zigbee antenna (Sonoff) that is used for matter over thread