Faulty zigbee behaviour on Home Assistant Yellow with HUSBZB zwave&zigbee stick

Hardware
,
1

Hi all, just want to share some info on this.
I successfully migrated everything from old installation to yellow, this HASS Yellow migration - points to watch for (MQTT, Zigbee, restore) really helps.
Some points:

  • after the migration for zwave I’m still using HUSBZB
  • after the migration for zigbee I’m using the one comes with yellow

And after the migration everything seems ok, until a restart.
Today I restarted yellow for some non-zigbee/zwave related changes, and after that, yellow is trying to reach out to my HUSBZB stick for zigbee rather than the built-in one.

Error setting up entry HubZ Smart Home Controller - /dev/serial/by-id/usb-Silicon_Labs_HubZ_Smart_Home_Controller_xxxxxx-port0, s/n: xxxxx - Silicon Labs - xxx
2:09:17 PM – (ERROR) components/zha/core/gateway.py
Couldn't start EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis coordinator (attempt 1 of 3)
2:09:17 PM – (WARNING) Zigbee Home Automation - message first occurred at 2:09:01 PM and shows up 3 times

And obviously, zigbee automation was completely dead(since during the migration the HUSBZB was reset for zigbee part).
I deleted the zha integration and re-added it back by choosing the correct radio, and now it seems ok again.
But just wondering if anyone has seen this recently? It will be so annoying if I need to do this every time when need to restart home assistant. Thanks

2

Hi,
Glad the “stuff I got wrong” post helped you!
I’m running vanilla:

  • Zigbee Home Automation + Yellow Sil Labs (EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1)
  • Z-Wave JS Supervisor add-on + Z‐Stick Gen5 USB Controller

The HASSOS docker virtualisation makes it surprisingly difficult to workout the /dev/tty* device mapped through to the integration - I thought it was in the Download Diagnostics, or in the binding config, but couldn’t find it today.

From a web terminal, ls -la /dev/serial/by-id/usb-* only came back with one file - a symbolic link to ../../ttyACM0 which sounds like the Zigbee SilLabs device on my Yellow (there are several other /dev/tty* serial device files likely for Z-Wave, serial console, USB console, etc).

Is you ls -l the path mentioned in the first line of the HubZ Smart Home Controller error, what comes back?

That it apparently shows the s/n: REDACTED makes me wonder if the integration is connected to the hardware (e.g. NOT wrong port/device/moon phase), but there’s something deeper wrong.

My best suggestion is take a full backup, backup the adapter config from the integration, then at least you have a baseline configuration whatever you try next.

Given a chunk of Zigbee config is in adapter flash, I don’t know if deleting and reinstalling the integration will work? I guess it comes down to how many devices you might need to re-pair if a re-install fails.

Not great, sorry!

1 Like
3

hi here so this is the result for ls command:

image
image2340×144 38.1 KB

and this is from their official hardware diagram Hardware – Home Assistant Yellow
image
image1920×1192 211 KB

u can see that /dev/ttyAMA1 should be the onboard hardware.
I think it’s more likely the hassos just reached out to the wrong hardware…

4

and btw the redacted part in screenshot is same, I guess it’s just zwave and zigbee part of the stick. but not sure why yours only has one listed.

5

My concern is that there’s two entries - something I don’t see with a USB Z-Wave controller attached and working.

My guess is the second link is being used by ZHA, and /dev/ttyUSB1 is wrong. Which one matches the log error message?

Note the full paths, take a FULL backup, delete the second symlink, and re-create it pointing to ../../ttyUSB0 perhaps?

(the command would be something like cd /dev/serial/by-id; ln -s ../../ttyUSB0 /dev/serial-by-id/......)

Top Tip: press SHIFT and select in the web console to copy/ paste, then use code fences, rather than screen shots.

1 Like
6

I think there is something else going on, as none of those two path matches the log error message… anyway since re-adding integration currently works for me I’ll take it, and keep monitoring, if this is not an uncommon scenario, I believe there will be more topics in forum like this.

7

Using the usb symlink is fraught with danger as it can change on reboot.

Use the by-id port to point to your devices, this is mine for Zigbee2MQTT:

serial:
  port: >-
    /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_82aeeb91e0c9eb119f658b4f1d69213e-if00-port0
1 Like