Z-Wave.me UZB dongle not fully recognized

[jires]

Describe the issue you are experiencing

After updating to 11.1, my usb dongle for Z-Wave became unresponsive and integration z-wave js ui hangs or won't start from time to time.
When I turn on the monitor connected to Intel NUC, I can se that dongle generates some errors when connected to usb port.

It's saying "device descriptor read/64, error -32

It's like missing driver or something. Issue persist in 11.2 version. Right now, I had to move my z-wave network to Aeotec Z-Stick 7.

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

6.1.63-haos - Home Assistant OS 11.2

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

1. start the system up
2. Plug an USB dongle ZMEEUZB from Z-Wave.Me into usb port

...

Anything in the Supervisor logs that might be useful for us?

Not really

Anything in the Host logs that might be useful for us?

Not Really

System information

System Information

version	core-2023.10.3
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.11.5
os_name	Linux
os_version	6.1.63-haos
arch	x86_64
timezone	Europe/Copenhagen
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.33.0
Stage	running
Available Repositories	1353
Downloaded Repositories	22

Home Assistant Cloud

logged_in	true
subscription_expiration	September 7, 2024 at 02:00
relayer_connected	true
relayer_region	eu-central-1
remote_enabled	true
remote_connected	true
alexa_enabled	false
google_enabled	true
remote_server	eu-central-1-11.ui.nabu.casa
certificate_status	ready
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 11.2
update_channel	stable
supervisor_version	supervisor-2023.11.6
agent_version	1.6.0
docker_version	24.0.7
disk_total	916.2 GB
disk_used	64.5 GB
healthy	true
supported	true
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	Advanced SSH & Web Terminal (16.0.1), InfluxDB (4.8.0), Grafana (9.1.1), Node-RED (16.0.2), File editor (5.7.0), Studio Code Server (5.14.2), Mosquitto broker (6.4.0), Home Assistant Google Drive Backup (0.112.1), Network UPS Tools (0.12.2), ESPHome (2023.11.6), Samba share (12.2.0), Filebrowser (2.23.0_7), Portainer (2.19.3), Log Viewer (0.16.0), Glances (0.20.0), Frigate (Full Access) (0.12.1), Z-Wave JS UI (3.0.2), Zigbee2MQTT (1.34.0-1)

Dashboards

dashboards	7
resources	5
views	41
mode	storage

Recorder

oldest_recorder_run	March 17, 2023 at 20:34
current_recorder_run	December 7, 2023 at 19:12
estimated_db_size	17118.81 MiB
database_engine	sqlite
database_version	3.41.2

Additional information

No response

[mcolyer]

I'm having a similar issue, after upgrading to 11.2 my usb Zwave hub is no longer recognized.

[sblogoshs]

In my case, it is the SkyConnect stick that stops working after a few hours and the problem can only be solved by unplugging it and plugging it in again. A downgrade to 11.1 solved the problem for me.

[mcolyer]

Can confirm that downgrading to 11.1 and then unplugging and replugging in the dongle (Aeotec z-stick Gen 5) fixes the issue.

[ohessel]

On my RPI 3b+ downgrading to 11.1 (ha os update --version 11.1) directly fixed the issue with Z-Wave USB Stick (ZMEEUZB1).

[bnounours]

Same as all, I upgraded to OS 11.2 Zwave stop working as the stick was no more detected. I downgraded to OS 11.1, stick is back online.

[GHGiampy]

Also related #2977

[sairon]

We suspect it could be caused by some regression in the stable kernel, because at the same time similar issues started to appear on RPi and x86 platforms. There is bunch of changes in the USB subsystem in the newer stable releases which are currently in the development branch. If there's someone willing to switch to the dev channel and test it, it will help a lot (but make sure you have backups, since it switches all the components to dev and things can go south much more often).

ha supervisor options --channel=dev
ha supervisor reload
ha supervisor update
ha os update

Otherwise there should be another beta release soon, we will appreciate early feedback after the release too.

[sairon]

Since OS 11.3.rc1 is out for a while already, has anyone been able to check if the problem persists there?

[sblogoshs]

I also noticed that with OS 11.3.rc1 but for me it just took longer until the error reappeared, it just depends on how long there is no restart.

[llroelj]

We suspect it could be caused by some regression in the stable kernel, because at the same time similar issues started to appear on RPi and x86 platforms. There is bunch of changes in the USB subsystem in the newer stable releases which are currently in the development branch. If there's someone willing to switch to the dev channel and test it, it will help a lot (but make sure you have backups, since it switches all the components to dev and things can go south much more often).

ha supervisor options --channel=dev
ha supervisor reload
ha supervisor update
ha os update

Otherwise there should be another beta release soon, we will appreciate early feedback after the release too.

I will try this tomorrow morning and will keep you posted if it works.

[agners]

@mcolyer @sblogoshs @ohessel @bnounours @llroelj do you see the same device descriptor read errors as the original poster?

@bnounours which stick are you using?

[llroelj]

@mcolyer @sblogoshs @ohessel @bnounours @llroelj do you see the same device descriptor read errors as the original poster?

@bnounours which stick are you using?

After going through the above mentioned steps I am having the same error as mentioned above and the one I had before downgrading to 11.1

usb 1-1.1.2: device descriptor read/64, error -32

I see in the Z-Wave JS addon also the same error popping up: " Driver: Failed to open the serial port: Error: No such file or directory, cannot open /dev/serial/by-id/usb-0658_0200-if00 (ZW0100)"

Currently I am running the following versions:

Core: 2023.12.3
Supervisor: 2024.01.0.dev0201
Operating System: 11.4.dev20231226
Frontend: 20231208.2

[agners]

@llroelj so you are saying you had the device descriptor read with 11.2 as well as the OS version from the dev channel?

What (exact) hardware are you running HAOS on?

[llroelj]

@llroelj so you are saying you had the device descriptor read with 11.2 as well as the OS version from the dev channel?

What (exact) hardware are you running HAOS on?

Indeed I had the same message in 11.2 and now the dev channel. With both the zwave stick cannot be found by the system itself (no serial folder).
If needed I can share my dmesg log with all information.

I am running HAOS on a RPi3 B+ 1GB memory installed on a SanDisk Ultra 32GB microSDHC card
The Zwave USB stick is a Z-Wave.me Stick (ZMEEUZB1)

[mnorrsken]

My problems with USB is solved now after upgrading to HAOS 11.3. I had problems with ConbeeII zigbee dongle not being detected. This is possibly another issue but worth trying 11.3 as I see a couple of kernel USB fixes.

[sblogoshs]

With the final version OS 11.3 the error seems to be fixed, but due to various updates I haven't had 24 hours without a restart yet, I hope that it will still work.

[jires]

I can tell that upgrade to OS 11.3 DID NOT FIXED (? or did?) the issue with Z-Wave.me UZB. Descriptor error is still coming, however it's looks like that dongle is working as expected
Log output from host, after plugin dongle in the usb port, when system reboted with dongle plugged in, there is no errors in the log:

Jan 07 12:04:09 homeassistanttest kernel: usb 1-1.3: new full-speed USB device number 6 using xhci_hcd
Jan 07 12:04:09 homeassistanttest kernel: usb 1-1.3: device descriptor read/64, error -32
Jan 07 12:04:09 homeassistanttest kernel: usb 1-1.3: device descriptor read/64, error -32
Jan 07 12:04:10 homeassistanttest kernel: usb 1-1.3: new full-speed USB device number 7 using xhci_hcd
Jan 07 12:04:10 homeassistanttest kernel: usb 1-1.3: device descriptor read/64, error -32
Jan 07 12:04:10 homeassistanttest kernel: usb 1-1.3: device descriptor read/64, error -32
Jan 07 12:04:10 homeassistanttest kernel: usb 1-1-port3: attempt power cycle
Jan 07 12:04:11 homeassistanttest kernel: usb 1-1.3: new full-speed USB device number 8 using xhci_hcd
Jan 07 12:04:11 homeassistanttest kernel: usb 1-1.3: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
Jan 07 12:04:11 homeassistanttest kernel: usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jan 07 12:04:11 homeassistanttest kernel: cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

[kvandt]

I have the same on my HA Yellow. When upgrading to 11.2 or 11.3 my UZB Zwave stick cannot be found anymore. No usb device available. When downgrading to 11.1, everything works again. I have tried the upgrade three times, but no luck. I hope this can be fixed in next release.

[ohessel]

@agners I did not download the logs, and the journal of the error is rotated away already.
If it helps, I could update again (or better setup a clone, as I don't want to break my system) and see if those exact logs appear.

[afaucogney]

I'm in the same situation, with 2 different Zwave devices.
Now running 11.4OS

[ohessel]

@afaucogney So you're saying 11.4 has the same issue?

[afaucogney]

@ohessel Yes it seems the same issue.
I have reboot to be certain that everything is clear, but then I canot find my usb stick in the all_hardware list
And ZWaveJS is not able to talk to the controller. Should it work with that version ?

[kvandt]

@sairon can you please add the board/yellow label as well? I have this issue on the yellow (see earlier post).

[afaucogney]

Is there some activity on this topic, or do you need some information/log to help you ?

[FredrikFornstad]

I have been looking at the changelog for Debian 12.2 for "suspects". Found these commits in the Linux kernel that was introduced in Debian 12.2:
- USB: core: Unite old scheme and new scheme descriptor reads
- USB: core: Change usb_get_device_descriptor() API
- USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
- USB: core: Fix oversight in SuperSpeed initialization

My guess, but I might be wrong, is that the "Unite old scheme and new scheme descriptor reads is the cause why the UZB does no longer work. There is a fix for USB3 (SuperSpeed) that was found not to work after the schemes update.

Here you can read a bit about these patches and how they were introduced: https://lore.kernel.org/linux-usb

[sairon]

@FredrikFornstad Very interesting findings again, thanks! I've created a build with those four patches reverted for Raspberry Pi 3 (32-bit and 64-bit builds), could you test it? You can find the build here: https://github.com/home-assistant/operating-system/actions/runs/8141367477

Just ignore the failure, it's because the image of the target for testing wasn't built. Also note you must be logged in to download and the files are ZIP compressed when downloaded (it's a limitation of GH artifacts).

[sairon]

FWIW, these changes were introduced to Linux stable in 6.1.53 - which means that last version working should be HAOS 10.5 for x86 (and other non-RPi boards, with 11.0.rc1 being the breaking version, bumping 6.1.52 -> 6.1.53), and HAOS 11.1 for Raspberry Pi (breaking version 11.2.rc1, bumping 6.1.21 -> 6.1.58). This issue is a bit of a mixed bag of reports from both platforms without any further details, and while there's clear consensus about reverting to 11.1 fixing the issue, it's not clear if it's related to x86, or those all are about RPi (which should have been reported in #2977).

[FredrikFornstad]

Tested your special bild (64bit). Result: It works with UZB on rpi3b.

Dmesg reports Linux version 6.1.73-haos-raspi with build date today afternoon.

It is exactly as in haos 11.1: 2x2 error messages, and then directly after the "attempt powercycle" it find the UZB and do the handshake and then cdc_acm assigns it to ttyACM0

I have a broken internet connection today, so I only have my mobile. So I skip the 32bit for now. But I am sure it also will work successfully.

Next step? Report to the Linux usb team?

[sairon]

@FredrikFornstad Perfect, I have started a discussion in the linux-usb mailing list and reported the issue to the regressions list as well. Also, putting all the pieces together, I realized the "USB 2" port on my mini PC I used for the testing before, is in fact only black, but it's a SuperSpeed port anyway 🤦 That's why I wasn't able to reproduce it before (just like you, I got -71 errors instead and the driver recovers). And using RPi's USB 2 ports, I am reproducibly getting the USB enumeration error too 🎉

[kvandt]

The solution to put the UZB stick in a USB3 port is not a solution for the HA Yellow. This device only has USB2 ports (in USB-A format). I just tried again the update from 11.1 to 11.5 and 12.0, but the UZB stick is not found. I switched USB port (but are both USB2) and no effect as expected. After downgrading to 11.1 the UZB is recognised again.

I hope this can be solved upstreams and if not in a special build for HA Yellow devices.

@sairon can you also add the HA Yellow label to this topic?

[kvandt]

Thnx @sairon !

[FredrikFornstad]

@FredrikFornstad Perfect, I have started a discussion in the linux-usb mailing list and reported the issue to the regressions list as well. Also, putting all the pieces together, I realized the "USB 2" port on my mini PC I used for the testing before, is in fact only black, but it's a SuperSpeed port anyway 🤦 That's why I wasn't able to reproduce it before (just like you, I got -71 errors instead and the driver recovers). And using RPi's USB 2 ports, I am reproducibly getting the USB enumeration error too 🎉

@sairon, I saw Alan Stern asked for Windows Wireshark logs from UZB attachment. This is from my HP Pavilion laptop, running Windows 10 Home 22H2. The log starts exactly when I plug in the UZB, before I plugged it in it was 30 seconds of complete silence on the usb-bus. The UZB is plugged into "Port 2" which after windows has managed to start talking to it becomes destination 1.3.0. One notable difference (I think) is that Windows do 5 port resets, before it manage to start communication with the UZB. I guess the UZB "problem" can be timing related, and that Linux gives up too soon. Also, I tend to remember to have read somewhere that Windows uses the "new" scheme, just as Linux do since the "troublesome" patches that caused the problems with UZB, so maybe if Linux did a few more tries before giving up, it maybe works also with the new scheme. Anyway, maybe the attached log-file is of some help. Windows assign the UZB to COM3 in this particular case.

One thing that puzzles me is that with the Linux patches USB3 ports actually works, but USB2 ports do not, even though Alan says that the USB init is now sharing the code between the two... Leads me to think there has to be some difference in behaviour between USB2 and USB3 code.

usbPcap1_USB2-port.txt

[FredrikFornstad]

@sairon, I looked in detail at your usbmon traces and compared them side by side. I understand Alan already have looked at those in detail, and as an amateur I can probably not provide much more useful input/ideas. But I stick out my neck a little bit and offer my observations for what it may be worth:

1. With the "troublesome" patches reverted (the working example), the sequence executes faster. Assuming the timestamps (second column) is in usec, then the working example is 1871 usec faster up to the powercycle instruction than the non-working example after the start of the logs. Most of these come early in the logs at two places 800 usec + 1000 usec. I guess this could just be a coincidence caused by some CPU interrupt calls that has nothing to do with the usb bus. Repetive runs of usbmon would tell if this was just a coincidence or if the troublesome patches actually made the whole init procedure slower than before.
2. After approx 1.28 seconds(I guess) after the start of the logs comes an interupt input (I guess this is the power-cycle). In the working example this took approx 1700 usec longer than in the non-working example. Why does the "interupt input" come later (take longer time?) in the working example? This I guess could be significant for the troubleshooting.
   Non-working example:
   ffff9f9a29b3f300 298538893 C Co:1:002:0 0 0 ffff9f9a012cae40 298581342 C Ii:1:002:1 0:2048 1 = 04 (timestamp diff = 42499)
   Working example:
   ffff8fc4ee367240 368298823 C Co:1:002:0 0 0 ffff8fc4c0c5ac00 368343025 C Ii:1:002:1 0:2048 1 = 04 (timestamp diff = 44202)
3. After the interupt input then follows a control input submission and directly after that a control input callback where for the first time there is a difference in bit sequence. If this is where the init has been successful then the cause of the difference is before this point which indicates a potential timing issue, unless there are things going on that is not captured by usbmon. Below is the first difference I see in the sequence apart from timing:
   Non-working example: ffff9f9a29b3f300 298742459 C Ci:1:002:0 0 4 = 03011000
   Working example: ffff8fc4ee367240 368502372 C Ci:1:002:0 0 4 = 01011100

[henriklund]

Upgrade to v12.1 did not change the USB disconnect behaviour. Using it from USB3 improved stability (from disconnecting permanently every 2nd time to every 4-5 times ZWave JS was restarted).

[diablodale]

As a datapoint... my Z-Wave.Me UZB has none of these failures that I've seen. Looking now I also see nothing in various logs.

• It is on a RPI4 model B and plugged into a black USB 2 port on the top left.
• My UZB has firmware 5.26. This is the newest firmware possible on my specific UZB stick.

Note: There are many sub-types of UZB sticks and each has distinct firmware upgrade paths that DO NOT all reach the same numbers.

[MUN0X]

I updated my HA yellow from 11.1 to 12.1.
My uzb stick works unlike at 11.2-11.4.

Looking at dmesg output, I still get some errors while it attempts to read the descriptor, after a single power cycle it recognizes the stick.

[FredrikFornstad]

@sairon , I saw that you are thinking about contacting Z-Wave.Me team on possible correction of the UZB firmware. For your information, in case you are not aware, relevant information for them might be the combination of bootloader version and firmware version. The bootloader version is easily obtained using their Z-Way software using the Expert UI (no license needed for viewing the info or to upgrade bootloader and/or firmware).

I do not recall exactly what versions my UZB sticks had when I bought them many years ago. But at least one of them was on 5.04 or 5.05. The other one must have been 5.06 or earlier.

Today, both my UZB sticks are running bootloader 40196 and firmware 5.39 (after several steps of upgrading both bootloader and firmware). As @diablodale says, the bootloader/firmware upgrade paths are not straight forward. Actually, I think it is possible to upgrade his UZB to 5.39 also, but requires to filter on "all" upgrade paths and not only the "active" ones. However, I do not know why some paths (the non-active) are normally hidden, so maybe this is not recommended.

See here for the very complicated upgrade path map: [https://service.z-wave.me/expertui/uzb-stats/versions-graph.html?hw=277&with_hidden]

Given the amount of time that has pasted since 5.39 firmware was released, I somewhat doubt if the Z-Wave.Me team still have a possibility to make any adjustments (if it is technically possible).

[kvandt]

For the record: 12.1 fixed the issue for me. (on Home-Assistant Yellow)

[Taraman17]

For me as well, the ZWAVE stick was recognized with 12.1

[PoltoS]

Thank you @sairon for calling for me. I'm from Z-Wave.Me, the manufacturer of the UZB1.

Before we dive in deeper, just to test it, does an intermediate old-school USB hub helps? This might be an easy solution.

Based on the details analysis here and in the Linux Kernel thread I can deduce that UZB1 is setting up pull-ups too early. Even taking into account that this device is EOL and is not produced for more than 4 years, we still have the ability to make a new firmware. In theory ;) But I'll have to check with my colleagues if we have access to the USB part of the code as in old times Sigma Designs was not sharing sources of internal parts of the SDK, especially in the CDC-ACM driver implementation (in contrast, now we control everything except for the very low-level RF driver called RAIL).

I'll come back soon with more info from our R&D.

Please note that we have released new cool hardware to substitute UZB1. Modern and more professional.
Z-Station dual-protocol Z-Wave & Zigbee/Thread/BLE USB dongle
mPCI-E dual-protocol Z-Wave & Zigbee/Thread/BLE mini PCI-Express extension card
RaZberry 7 Pro Z-Wave extension card for Raspberry Pi and similar

All are using high-performant external antennas providing 3-4 times better range compared to UZB1. And with Long Range support (if you are in the US; soon in EU too)! Recently we published our test results and it went up to 1.9 km light-of-sight! And of course a simple backup & restore can help to migrate without any re-inclusion. So, if you thought about replacing the old 5th gen UZB1 with new hardware, it is the right time — to compensate the issue above we propose an offer of 20 EUR discount on any of the three hardware listed above with the coupon 2CPLD4DT.

[github-actions]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[MehdiTouns31]

Hello guys,

I have had the same problem as you for a few months on my Home Assistant installation on RPI 4B:

my ZMEEUZB Z wave USB drive (firmware version 5.37) is not read correctly by the Z wave JS add-on. Here are some logs from the add-on:

Here is the output of the dmesg command:

I'm embarrassed to no longer have any information coming back from my Zwave network... Any idea of ​​the problem I'm encountering?

i tested to downgrade to HAOS 10.5, but still the same issue... I don't understand...