search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
69.97k stars 29.04k forks source link

USB discovery entries for Z-Wave JS are too generic #55586

Open RicArch97 opened 2 years ago

RicArch97 commented 2 years ago

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:

{
        "domain": "zwave_js",
        "vid": "10C4",
        "pid": "EA60"
}

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

2021-09-02T13:49:27,593849507+02:00

^ not a z-wave dongle but is identified as one.

probot-home-assistant[bot] commented 2 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)

bdraco commented 2 years ago

Can you turn on debug logging for homeassistant.components.usb and paste the Discovered USB Device line?

bdraco commented 2 years ago

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.

mrquincle commented 2 years ago

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.

bdraco commented 2 years ago

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

mrquincle commented 2 years ago

Still worth it to run sudo lsusb -v -d 10c4:ea60 for the Zooz stick as well.

RicArch97 commented 2 years ago

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')
bdraco commented 2 years ago

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.

RicArch97 commented 2 years ago

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

bdraco commented 2 years ago

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

bdraco commented 2 years ago

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)
RicArch97 commented 2 years ago

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.

bdraco commented 2 years ago

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.

github-actions[bot] commented 2 years ago

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.

mrquincle commented 2 years ago

@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.

bdraco commented 2 years ago

I think the problem is well understood, we are just waiting for vendors to provide identifiers at this point.

mrquincle commented 2 years ago

Ah, so you addressed it in https://github.com/home-assistant/core/pull/54986 and have this one open until the vendors respond?

Image

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?

bdraco commented 2 years ago

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.

Hammerhand17 commented 2 years ago

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? image

nicolasVr commented 2 years ago

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

GeoffMorg commented 2 years ago

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,

bdraco commented 2 years ago

Support for matching sonoff dongle was added in 2022.2 via #62171

GeoffMorg commented 2 years ago

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

GeoffMorg commented 2 years ago

Thanks - I now have the latest update and this problem is solved.

Hedda commented 2 years ago

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?

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

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:

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

Hedda commented 2 years ago

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.

mrquincle commented 2 years ago

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.

Hedda commented 2 years ago

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.

github-actions[bot] commented 2 years ago

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.

mrquincle commented 2 years ago

@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. :-)

Hedda commented 2 years ago

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?

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zwave_js/manifest.json#L22-L30

    {
      "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.

Hedda commented 2 years ago

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.

bdraco commented 2 years ago

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.

Hedda commented 2 years ago

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?

mrquincle commented 2 years ago

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.

Hedda commented 2 years ago

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.

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zwave_js/manifest.json#L22-L30

    {
      "vid": "10C4",
      "pid": "EA60",
      "known_devices": [
        "Aeotec Z-Stick 7",
        "Silicon Labs UZB-7",
        "Zooz ZST10 700"
      ]
    }
bdraco commented 2 years ago

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.

mrquincle commented 2 years ago

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.

Hedda commented 2 years ago

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.

issue-triage-workflows[bot] commented 1 year ago

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.

Hedda commented 1 year ago

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).

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

Hedda commented 1 year ago

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

https://stackoverflow.com/questions/24493379/pyserial-how-to-know-if-a-serial-port-is-free-before-open-it

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)?.

https://stackoverflow.com/questions/11303850/what-is-the-cross-platform-method-of-enumerating-serial-ports-in-python-includi

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.)"

issue-triage-workflows[bot] commented 1 year ago

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.

Hedda commented 1 year ago

Still open questions

issue-triage-workflows[bot] commented 9 months ago

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.

Hedda commented 9 months ago

Still has question not answered

issue-triage-workflows[bot] commented 6 months ago

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.

Hedda commented 6 months ago

Not answered

issue-triage-workflows[bot] commented 3 months ago

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.

Hedda commented 3 months ago

Still not answered