Open RicArch97 opened 3 years ago
Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (usb
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
usb documentation usb source (message by IssueLinks)
Can you turn on debug logging for homeassistant.components.usb
and paste the Discovered USB Device
line?
I tested with a Zooz Z-Wave Plus S2 USB Stick ZST10
. It doesn't have a description
field to match on, but it does have a serial number. I ordered two more to see if they are all similar. We could limit it down to that for this device.
The serial number is often different and meant to identify unique devices. The following is not the Zooz stick.
sudo lsusb -v -d 10c4:ea60
Bus 005 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x10c4 Silicon Labs
idProduct 0xea60 CP210x UART Bridge
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 CP2104 USB to UART Bridge Controller
iSerial 3 016788AA
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 2 CP2104 USB to UART Bridge Controller
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Note that without sudo the fields
iManufacturer 1 Silicon Labs
iProduct 2 CP2104 USB to UART Bridge Controller
iSerial 3 016788AA
will not be shown. That does not mean that they can not be queried though...
python3 -m serial.tools.list_ports -v -n 1
/dev/ttyUSB0
desc: CP2104 USB to UART Bridge Controller - CP2104 USB to UART Bridge Controller
hwid: USB VID:PID=10C4:EA60 SER=016788AA LOCATION=5-2
1 ports found
To know for sure you can't get more info, you'll have to check what's available in /sys/bus
etc.
If there truly is no additional information, even that might be communicated to the user.
The serial number is often different and meant to identify unique devices. The following is not the Zooz stick.
Right, I'm hoping they are sequential or identifiable in some way
Still worth it to run sudo lsusb -v -d 10c4:ea60
for the Zooz stick as well.
Can you turn on debug logging for
homeassistant.components.usb
and paste theDiscovered USB Device
line?
As already shown by @mrquincle , this is the exact line that you asked for, which shows similar (generic) information. We both have same type of stick. As you can see, the serial numbers are different so this is indeed not a good identifier.
2021-09-02 16:16:22 DEBUG (MainThread) [homeassistant.components.usb] Discovered USB Device: USBDevice(device='/dev/ttyUSB0', vid='10C4', pid='EA60', serial_number='01678887', manufacturer='Silicon Labs', description='CP2104 USB to UART Bridge Controller - CP2104 USB to UART Bridge Controller')
I’m assuming these are the same class devices since the serial number all start with 01678*, and none of these are the Zooz zwave stick?
Sent from my iPhone
On Sep 2, 2021, at 9:23 AM, Ricardo Steijn @.***> wrote:
Can you turn on debug logging for homeassistant.components.usb and paste the Discovered USB Device line?
As already shown by @mrquincle , this is the exact line that you asked for, which shows similar (generic) information. We both have same type of stick. As you can see, the serial numbers are different so this is indeed not a good identifier.
2021-09-02 16:16:22 DEBUG (MainThread) [homeassistant.components.usb] Discovered USB Device: USBDevice(device='/dev/ttyUSB0', vid='10C4', pid='EA60', serial_number='01678887', manufacturer='Silicon Labs', description='CP2104 USB to UART Bridge Controller - CP2104 USB to UART Bridge Controller') — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
I’m assuming these are the same class devices since the serial number all start with 01678*, and none of these are the Zooz zwave stick?
Yes same class device. This one to be exact https://shop.crownstone.rocks/products/crownstone-usb-dongle
I narrowed what I had enough data to do in https://github.com/home-assistant/core/pull/55613
I'll work on the specific vid:pid combination you mentioned as soon as the Zooz devices show up
Still waiting for the Zooz devices to show. I'm pretty sure USPS lost them, and I'm going to have to re-order.
If they don't show up soon, I'll work on a PR to prioritize matching so that more exact matches will win but we probably need to figure out a way to extract more from the usb descriptor.
I'm a bit confused though as the one above with 01678887
is shown differently in
https://github.com/home-assistant/core/pull/50677#discussion_r706114899
What there a firmware change to show Crownstone dongle
?
Python 3.9.7 (default, Aug 31 2021, 13:28:12)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial.tools.list_ports
>>> ports = [(port.device, port.description, port.product) for port in serial.tools.list_ports.comports()]
>>> ports
[('/dev/ttyUSB0', 'Crownstone dongle - Crownstone dongle', 'Crownstone dongle')]
$ lsusb -v -d 10C4:EA60
Bus 003 Device 006: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x10c4 Silicon Labs
idProduct 0xea60 CP210x UART Bridge
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 Crownstone dongle
iSerial 3 01678887
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 2 Crownstone dongle
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
What there a firmware change to show
Crownstone dongle
?
The product string (name) was changed using this tool, as a test
We will likely do this to all dongles that are getting shipped from now on, so it's easier to identify in general, and of course when setting up the Crownstone integration in Home Assistant. But of course not very useful for the users that already have a dongle.
I've reached out to Zooz
and Aeotec
to see if they can update their future dongles to provide more information in the usb descriptor.
We will remove the generic matcher based on how much time they need to get the changes into their supply chain (assuming they are willing to make the changes).
In the mean time, I'll work on a change to make a more descriptive matcher win discovery.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
@bdraco Do you know describe the devices with VID:10C4 and PID:EA60 as a general dongle with a generic cp210x chipset by Silicon labs? It doesn't say anything about zwave, etc.
I think the problem is well understood, we are just waiting for vendors to provide identifiers at this point.
Ah, so you addressed it in https://github.com/home-assistant/core/pull/54986 and have this one open until the vendors respond?
Then, if we would add this Bluetooth stick, would it still lead to the above pop-up? Or does it somehow inform the user that it doesn't need to be a Z-Wave stick?
Then, if we would add this Bluetooth stick, would it still lead to the above pop-up? Or does it somehow inform the user that it doesn't need to be a Z-Wave stick?
If you add a more descriptive matcher, it will prefer that and z-wave won't be discovered.
Then, if we would add this Bluetooth stick, would it still lead to the above pop-up? Or does it somehow inform the user that it doesn't need to be a Z-Wave stick?
If you add a more descriptive matcher, it will prefer that and z-wave won't be discovered.
I flashed sonoff latest firmware and not it appears as itead_sonoff_zigbee(...), but it still is recognized as Z-Wave JS. What am I doing wrong?
I flashed sonoff latest firmware and not it appears as itead_sonoff_zigbee(...), but it still is recognized as Z-Wave JS. What am I doing wrong?
Same for me with a brand new install
My brand new Sonoff USB is discovered as a Z-Wave device and kicks off the "Z-Wave JS add-on installation", which after ages stops at a screen asking me to configure the S0 key, S2 Access Control key etc. I don't really want to flash firmware till I know what's happening. I guess this is in the same area as the reported problem but not quite the same manifestation. Core version is core-2021.12.8 I do alerady have ZHA installed with a Sonoff Coordinator configured but not attached,
Support for matching sonoff dongle was added in 2022.2 via #62171
Thanks. I just updated my core and it has only gone to 2021.12.8. EDIT I just noticed it isn't changing to the latest (2021.12.9)
So I'm off to research how to upgrade it to the version you mention.
Thanks again
2nd EDIT: Reading the release info, I realise this may not be available till Feb. Patience isn't one of my strongest points LOL
Thanks - I now have the latest update and this problem is solved.
Not sure if just leaving this "working as design" now as it might be better to just let HA assume that generic adapters are Z-Wave?
Anyway, I believe that the root issue of "USB discovery entries for Z-Wave JS are too generic" is still there as the USB discovery used by the Z-Wave integration will still any USB device that uses a Silicon Labs CP2102N USB-to-UART Bridge / USB-to-Serial Converter chip with VID "10C4" and PID "EA60" (or VID "0658" and PID "0200") as a unique to only Z-Wave dongles/adapters even if it does not also contain a custom "Product Description" ("description") string as well and instead are shipping by default with the standard "Product Description" ("description") string from Silabs?
https://github.com/home-assistant/core/blob/dev/homeassistant/components/zwave_js/manifest.json
{"vid":"10C4","pid":"EA60","known_devices":["Aeotec Z-Stick 7", "Silicon Labs UZB-7", "Zooz ZST10 700"]}
{"vid":"0658","pid":"0200","known_devices":["Aeotec Z-Stick Gen5+", "Z-WaveMe UZB"]}
https://github.com/home-assistant/core/blob/dev/homeassistant/generated/usb.py
{
"domain": "zwave_js",
"vid": "10C4",
"pid": "EA60"
}
"domain": "zwave_js",
"vid": "0658",
"pid": "0200"
},
I think the fact remains that it is really that custom "Product Description" string that should be the real key to discover an adapter as uniquely being for Z-Wave, and not just the generic VID and PID if the Z-Wave adapter manufacturer has not changed those (in which case they would also have to provide custom device drivers for the operating system / kernel too).
Compare to example discovery by ZHA which does require that Zigbee USB dongles/adapters have a "Product Description" ("description") string for it to be discovered even though there are many Zigbee USB dongles/adapters available out there with missing custom "Product Description" ("description") string and instead shipping with the default string from Silabs as standard:
https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json
{
"vid": "10C4",
"pid": "EA60",
"description": "*2652*",
"known_devices": ["slae.sh cc2652rb stick"]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*sonoff*plus*",
"known_devices": ["sonoff zigbee dongle plus"]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*tubeszb*",
"known_devices": ["TubesZB Coordinator"]
},
https://github.com/home-assistant/core/blob/dev/homeassistant/generated/usb.py
{
"domain": "zha",
"vid": "10C4",
"pid": "EA60",
"description": "*2652*"
},
{
"domain": "zha",
"vid": "10C4",
"pid": "EA60",
"description": "*sonoff*plus*"
},
{
"domain": "zha",
"vid": "10C4",
"pid": "EA60",
"description": "*tubeszb*"
},
This and related questions is by the way discussed in this thread on the Home Assistant community forum here:
Slightly off-topic but the best long-term solution would really be if could convince manufacturers of the most popular new Zigbee USB dongles/adapters, like Aeotec and Zooz (as well as Silicon Labs themselves for their Silicon Labs UZB-7 reference hardware), to start writing a custom "Product Description" ("description") string to the programmable EEPROM in CP210x series for each new USB adapter type before shipping to customers to allow applications like Home Assistant to discover them as unique products.
This could even be performed as a post-sale fix using for example this open source library like cp210x-program from VCTLabs:
https://github.com/VCTLabs/cp210x-program
(or https://github.com/DiUS/cp210x-cfg but that is a C program and not Python for not as good for most developers here).
ITead did release a post-sale fix for early shipping “Sonoff Zigbee 3.0 USB Dongle Plus” adapters which was the missing "Product Description" ("description") string written to EEPROM of CP2102N but sadly they choose to use a closed source binary tool for it:
https://www.facebook.com/SONOFF.official/posts/2927251720919807
That binary program from ITead also does not work on Linux or Mac OS and has also shown to not work on all Windows OS either.
Yes, you can write your own description with such programs. We've used https://github.com/DiUS/cp210x-cfg for example for our newer USB dongles. Note that it at first might seem logical to have a custom VID/PID, but this means that you've to start to ship your own drivers for this as a manufacturer, which is of course complete nonsense to do for something this general.
Good luck in convincing all manufacturers in doing this though. I'd still recommend a discovery procedure that knows about it. In our case it's a Bluetooth Mesh stick not a ZWave stick.
We are also extremely likely to see many Thread (OpenThread Border Router) USB dongles for Matter (formerly CHIP) connectivity arriving soon and probably become very popular next year (if such native integration component gets added to Home Assistant).
That could also become even more confusing to new radio USB dongle/adapters buyers and beginners if manufacturers do not sell different commercial product models with at least unique SKUs/article-IDs pre-flashed from their factories with different firmware since some MCU radio chip hardware supporting multiprotocol (like example TI CC26x2/CC13x2 and Silabs ERF32MG1x/ERF32MG2x) chips can be used for Zigbee Coordinator, OpenThread Border Router (OTBR), or Bluetooth 5 Low Energy (BLE) / Bluetooth Mesh depending on which application firmware is used.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
@RicArch97 Has this been fixed?
@Hedda As a manufacturer we can tell you that indeed adjusting the "product description" falls into the scope of things we can do post-manufacturing. However, I'm pretty sure other manufacturers will be less flexible. :-)
I believe that root cause for this should still be considered an issue consideration that needs an active choice to ignore or not.
Today the USB Discovery will report all and any USB devices that are based Silicon Labs CP210x UART to USB bridge/converter chip with VID "10C4" and PID "EA60" + ship with a non-unique unmodified factory default USB product description from Silabs as an "Z-Wave Controller" and such Home Assistant notify that it discovered Z-Wave JS.
Maybe solve by remove current VID "10C4" and PID "EA60" from Z-Wave USB discovery as that would no longer make it generic?
{
"vid": "10C4",
"pid": "EA60",
"known_devices": [
"Aeotec Z-Stick 7",
"Silicon Labs UZB-7",
"Zooz ZST10 700"
]
}
Unfortunately, I do have any other recommended resolution as the correct solution would be for Z-Wave Controller USB dongle manufacturers like example Aeotec, RaZberry, and Zooz to actually change the product description on the CP210x chip before shipping their products.
the correct solution would be for Z-Wave Controller USB dongle manufacturers like example Aeotec and Zooz to actually change the product description on the CP210x chip before shipping their products.
That is by the way how this was solved by Zigbee Coordinator USB adapter manufacturers who most of which now have added USB product descriptions to their products, including those using these very same CP210x chips with VID "10C4" and PID "EA60":
https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json
So today the ZHA integration will not detect any generic USB dongles or peripherals as Zigbee Coordinator adapters, even if they could actually be a Zigbee Coordinator USB adapter without an USB product description set by the manufacturer.
As we are still waiting for some (thankful not all) vendors to action adding the description strings, there hasn't been any progress on this issue.
As we are still waiting for some (thankful not all) vendors to action adding the description strings, there hasn't been any progress on this issue.
I guess those manufacturers do not prioritize it. Still fortunate really only Aeotec, RaZberry, and Zooz that need to be convinced.
They can and should change USB product description IDs with the Simplicity Studio Xpress Configurator tool (discussed starting on page 6 of the AN721: USBXpress Device Configuration and Programming Guide) or third-party tools like the cp210x-program.
There is maybe no point in them prioritizing writing USB product descriptions on their older Z-Wave 500 series controllers, (even though they still sell a lot of them), however, it would be very nice from the point-of-view of future Home Assistant end-users if those three manufacturers of Z-Wave controller for USB could at least be convinced into writing USB product descriptions for all of their Z-Wave 700 and 800 series controllers.
Maybe most important would be to try to convince Silicon Labs to write a USB product description to their reference hardware?
Sticks that are already in the field won't be updated by manufacturers anyway.
I think it's much more robust to do it similar to the ZHA integration (don't detect generic USB dongles as specific adapters) as @Hedda pointed out.
That would also make it possible to close this issue. Otherwise this will be open forever.
I think it's much more robust to do it similar to the ZHA integration (don't detect generic USB dongles as specific adapters)
Simply removing detection of generic USB adapters as Z-Wave might possibly also motivate Z-Wave Controller manufacturers to add descriptions to future batches that they manufacture, and motivate users to feature request this change from manufacturers.
{
"vid": "10C4",
"pid": "EA60",
"known_devices": [
"Aeotec Z-Stick 7",
"Silicon Labs UZB-7",
"Zooz ZST10 700"
]
}
Simply removing detection of generic USB adapters as Z-Wave might possibly also motivate Z-Wave Controller manufacturers to add descriptions to future batches that they manufacture, and motivate users to feature request this change from manufacturers.
I expect that will likely provide motivation at the cost of damaging the vendor relationships. It seems pretty heavy handed.
Even those current vendors might want to bring out different sticks in the future (e.g. Matter, etc.) with the same SiLabs chip on-board. It's just weird to assume that a CP210x UART bridge is a Zwave device.
This is still very valid I think, or more today than before since there and now so many Zigbee USB dongles out there from loads of different manufacturers and some could be using the same Silicon Labs CP210x UART bridge chip with as Z-Wave USB dongles.
Even those current vendors might want to bring out different sticks in the future (e.g. Matter, etc.) with the same SiLabs chip on-board. It's just weird to assume that a CP210x UART bridge is a Zwave device.
Exactly. The fact is that while not quite as popular as Z-Wave Controller USB adapters, we know that there are many other existing home automation related USB peripherals and adapters/dongles/sticks that also use these common Silicon Labs CP210x serial-to-USB bridge chips with this same VID "10C4" and PID "EA60" combination has already been shipped for several years without a USB product description as a unique identifier, including though not exclusive to at least; a few different Zigbee Coordinator adapters, LoRa/LoRaWAN USB Transceiver, a few Bluetooth USB transceivers (ex. Feasycom FSC-BP309), 1-Wire Bus Master Transceiver Adapter, Infrared (IR) USB Transceiver, ELV USB-WDE1 Weather Data Receiver, Chinese 433Mhz CC1101 SDR USB Wireless RF Transceiver, and other RTL-SDR Software Defined Radio adapters, as well as several ESP32/ESP8266/ESP8285 and AVR Arduino-clones Development Boards (including RFLink RF Transceiver if based on those), and this same VID and PID combination is and have been used by Silabs CP2101, CP2102/CP2102N, CP2103, CP2104 and CP2109 for many years.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
We are also extremely likely to see many Thread (OpenThread Border Router) USB dongles for Matter (formerly CHIP) connectivity arriving soon and probably become very popular next year (if such native integration component gets added to Home Assistant).
That could also become even more confusing to new radio USB dongle/adapters buyers and beginners if manufacturers do not sell different commercial product models with at least unique SKUs/article-IDs pre-flashed from their factories with different firmware since some MCU radio chip hardware supporting multiprotocol (like example TI CC26x2/CC13x2 and Silabs ERF32MG1x/ERF32MG2x) chips can be used for Zigbee Coordinator, OpenThread Border Router (OTBR), or Bluetooth 5 Low Energy (BLE) / Bluetooth Mesh depending on which application firmware is used.
@bdraco Not sure if "thread" or "and matter" will be the correct component and domain which will need to use USB discovery for quick start setup to initiate the installation config flow for Thread and/or Matter over Thread using an OTBR (OpenThread Border Router) radio USB dongles? Will the USB discovery part only be added to the "thread" component manifest?
https://github.com/home-assistant/core/blob/dev/homeassistant/components/thread/manifest.json
https://github.com/home-assistant/core/blob/dev/homeassistant/components/matter/manifest.json
If so then guess you or some will sooner or later add "usb" to that component's manifest in Home Assistant for USB discovery of the new Home Asisstant SkyConnect USB dongle and other future upcoming third-party OTBR USB dongles?, (similar to the zha manifest https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json)
Again, I think that one of the problems is the compromise that has been done in Home Assistant's USB discovery for Z-Wave Controller dongles in Home Assistant Supervisor currently only uses VID + PID + Description from the USB-to-serial converter chip, and that means that if a Z-Wave Controller manufacturer has not written a custom USB description to the EEPROM of the USB-to-serial bridge chip on the dongle board then it will right now make assumptions based on only the VID and PID which can be generic if the Z-Wave Controller manufacturer has not changed them (which most Z-Wave Controller manufacturers, unfortunately, do not do for whatever unknown reason).
Perhaps also need serial probing which can check supported CLI/API protocols and firmware to make USB discovery more precise?
That would really be a feature request, but maybe Home Assistant could have a USB and Serial Port manager that each integration needs to report to which ports it uses, as then it could do serial scan, list, and open probe for plugged-in serial devices?
https://github.com/jleben/python-serial/blob/master/examples/scan.py
Try to open each and every serial port then do a probe and check for not used ports and then use an application probe?
https://stackoverflow.com/questions/22081560/python-testing-serial-ports-for-answer
https://stackoverflow.com/questions/24214643/python-to-automatically-select-serial-ports-for-arduino
That is, trying to connect using known CLI protocols and command to read the application firmware? Alternatively just list all serial ports with something connected to them?
For example zigpy-znp look to have tests to check uart connection?
https://github.com/zigpy/zigpy-znp/blob/dev/tests/test_uart.py
https://github.com/zigpy/zigpy-znp/tree/dev/tests/application
https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md
Regardless, if possible always first give users option to manually select or type in the serial port before doing scan and probe:
https://stackoverflow.com/questions/11750926/identifying-serial-usb-device-python
"No matter how you configure your device, at some point you're probably going to have to ask the user where the port is, or poll all serial devices for a known response. (Polling has it's pitfalls though, so read on!). Unlike USB devices, there is no vendor/device ID that is made known to the OS when you attach a plain-old serial device.
First you need to find the serial ports. Here's a question that might help: What is the cross-platform method of enumerating serial ports in Python (including virtual ports)?.
Once you have a list of serial ports, you could ask the user whether they know which one to use. If they do, problem solved!
If they don't, you could offer to poll ALL serial devices with some data that you know will yield a certain response from your device. Keep in mind though that if the user has other serial devices attached, your string of "hello" bytes might actually be the self-destruct sequence for some other device! Hence, you should warn the user that polling may interfere with other devices, and always prompt them before you do so.
Without knowing more about your code (eg. what comms framework, if any, you're using; are you doing this in the console or are you using a GUI toolkit, etc), it's impossible to say what the best way to code this might be. In the simplest case, you could just loop over all of your serial devices, send the greeting and check for a response. (You could also do this in parallel: loop once for the greeting, and loop again to check what's in the buffer. If you're going to get fancier than that, use a proper library.)"
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
Still open questions
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
Still has question not answered
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
Not answered
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
Still not answered
The problem
in
/homeassistant/generated/usb.py
there are some entries for VID/PID combo's that identify USB dongles with a specific integration.For Z-Wave JS this is included in the file:
The VID:10C4 and PID:EA60 belong to a very generic cp210x chipset by Silicon labs. The problem is that all other devices that aren't Z-Wave JS radio's now show up as Z-Wave.
I'm sure this isn't a problem for the current core integrations as Z-Wave JS and ZHA are about the only onces that use USB, but if you'd use any other dongles from a custom integration this will become very confusing for users. Also for future proofing purposes, it might be useful to identify more devices with this chipset within core.
One solution could be to identify based on description (iProduct) too just like ZHA but i'm not sure if those are provided with the Z-Wave sticks.
What is version of Home Assistant Core has the issue?
core-2021.9.0
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
USB Discovery
Link to integration documentation on our website
https://www.home-assistant.io/integrations/usb/
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
^ not a z-wave dongle but is identified as one.