#Zigbee insanity after replacing zwave USB stick

1 messages · Page 1 of 1 (latest)

cold skiff
#

Hi, I originally had a zigbee/zwave combo stick. The zigbee started misbehaving so I got a better zigbee dongle and let the combo stick just handle zwave duties. This fixed the problem but eventually the zwave got flakey as well so I also got a better zwave stick. So now the original stick is gone. For some reason even tho it has not been using the combo stick for zigbee in a while, this completely broke zigbee. I tried reconfiguring the zigbee integration via migrate radio but I kept getting "Unknown error occurred" at various steps in the process. Logs attached. Running in docker on ubuntu 24.04. thanks

📎 homeassistant_logs1.txt
cold skiff
#

bleh. i was getting an error that my database was out of date or something so i updated home assistant core and that went away. then it said my firmware was corrupted so i reflashed the USB stick and tried to "migrate" it to itself. this complained it oculdn't find ttyUSB2 even though its now ttyUSB0 in my bindings so i changed it back to ttyUSB2 and now its not working with no errors at all 🙃

#

if i try to just reinitialize it i get this

image.png
#

and if i migrate to a new radio

image.png
#

this is my compose file

version: '3'
services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /home/gradyn/hass:/config
      - /etc/localtime:/etc/localtime:ro
    devices:
      # remember not to point a different USB device at the same ttyUSB ID so that home assistant doesnt think something is something else
      - /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_d44386df256bef11b49899adc169b110-if00-port0:/dev/ttyUSB2
      - /dev/serial/by-id/usb-Zooz_800_Z-Wave_Stick_533D004242-if00:/dev/ttyUSB1
    restart: unless-stopped
    network_mode: host

I have been trying to fix this all day and i am about ready to SCREAM so if anyone has any pointers please.. lol

#

Surely I can get more verbose logging or something so I have somewhere to start

cold skiff
serene scarab
#

hey, it's frustrating trying to get help with zigbee issues here. I've tried it before with little response... I'm not sure I can help you very much, but a few things come to mind skimming through your original logs. Especially this line:
{% elif states('sensor.rice_cooker_current') | float > 1 %}

Am I right that this comes from an automation, script or similar you have? In that case I would try to disable all your zigbee-related automations before trying the radio migration again. In fact, if possible extract them from YAML and remove them entirely while upgrading. I have no idea whether this will help you, but based on the above, I think it's worth a shot.

cold skiff
#

ill disable that

#

I was able to get debug logging working and I got this

# 
2025-04-04 16:35:31.415 DEBUG (MainThread) [homeassistant.components.zha] Failed to set up ZHA
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 156, in async_setup_entry
    await zha_gateway.async_initialize()
  File "/usr/local/lib/python3.13/site-packages/zha/application/gateway.py", line 271, in async_initialize
    await self._async_initialize()
  File "/usr/local/lib/python3.13/site-packages/zha/application/gateway.py", line 254, in _async_initialize
    await self.application_controller.startup(auto_form=True)
  File "/usr/local/lib/python3.13/site-packages/zigpy/application.py", line 220, in startup
    await self.connect()
  File "/usr/local/lib/python3.13/site-packages/zigpy_znp/zigbee/application.py", line 82, in connect
    await znp.connect()
  File "/usr/local/lib/python3.13/site-packages/zigpy_znp/api.py", line 737, in connect
    self._uart = await uart.connect(self._config[conf.CONF_DEVICE], self)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/zigpy_znp/uart.py", line 148, in connect
    _, protocol = await zigpy.serial.create_serial_connection(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zigpy/serial.py", line 137, in create_serial_connection
    raise exc.__context__ from None
  File "/usr/local/lib/python3.13/site-packages/serial/serialposix.py", line 385, in _reconfigure_port
    fcntl.flock(self.fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
BlockingIOError: [Errno 11] Resource temporarily unavailable
cold skiff
#

why is EVERY zigbee zha error like this lol

image.png
cold skiff
#

i think ill make a github issue and if that doesnt go anywhere ill have to get a homey hub or something because zigbee is non-negotiable and i have nowhere to go from here

serene scarab
#

I totally get that. I would however recommend you to just try out Z2M. I migrated everything to that not long ago and have been super happy with it. It's more stable and mature.

My experience with ZHA mirrors yours in a way. When it worked, it just worked, but when it failed I felt utterly helpless.

#

The error you posted is however really interesting. To me this looks like something else on your system has taken a hold on the serial interface, and home-assistant is unable to create its own lock on it. I have never run Hass on docker, but my gut says that there is something here to look at.

#

You could try (as root) to check if any processes are using it:

lsof /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_d44386df256bef11b49899adc169b110-if00-port0:/dev/ttyUSB2```
cold skiff
#

thanks. there are alot of processes using it in the container but none outside. what is Z2M?

#

oh zwave 2 mqtt probably

serene scarab
#

Zigbee, but yes

cold skiff
#

figured it out, it was a usb mapping issue

#

/solved