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

3. ...

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

[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](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[bot]]

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.