Closed jires closed 3 weeks ago
Thnx @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 🎉
@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.
@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:
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)ffff9f9a29b3f300 298742459 C Ci:1:002:0 0 4 = 03011000
Working example: ffff8fc4ee367240 368502372 C Ci:1:002:0 0 4 = 01011100
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).
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.
Note: There are many sub-types of UZB sticks and each has distinct firmware upgrade paths that DO NOT all reach the same numbers.
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.
@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).
For the record: 12.1 fixed the issue for me. (on Home-Assistant Yellow)
For me as well, the ZWAVE stick was recognized with 12.1
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.
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.
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.![Inked2023-12-07 22 04 08](https://github.com/home-assistant/operating-system/assets/9952609/a770f050-98b6-44c1-b1fd-3763d15e498a)
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
...
Anything in the Supervisor logs that might be useful for us?
Anything in the Host logs that might be useful for us?
System information
System Information
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 | 22Home 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 | okHome 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 | storageRecorder
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.2Additional information
No response