Please contribute to the database of supported USB sticks

[andrewfg]

Introduction

In OH core there is a PR #3922 which on new OH installations does the following..

1. scan USB devices on the user's system
2. detect if any of them are a Zigbee stick, and if so,
3. suggest that the Zigbee binding to be installed

This issue relates to point 2. above.

Background

OH has several USB device scanners for different operating systems and configurations. These scanners can ALWAYS detect the USB stick vendorId and productId integer codes. Some (but not all) of these scanners can also retrieve the manufacturer and product description strings. But unfortunately, depending on the user's operating system and user rights, the latter strings may be missing.

Ideally in order to detect if a USB device supports Zigbee we would search for common strings like "Zigbee" in the product string. Yet on systems where the 'product' string is missing we need another way to identify what the USB device supports.

In order to do this, I have started to create a database between hex 'vendorId:productId' pairs and the descriptions of known supported USB sticks. Example below..

            "0403:6001", "FTDI / UART", // this does not support Z-Wave or Zigbee
            "0403:8A28", "FTDI / ZigBee",
            "0451:16A8", "Texas Instruments / ZigBee",
            "0658:0200", "Aeotec / Z-Wave",
            "10C4:89FB", "Silicon Laboratories / ZigBee",
            "1CF1:0030", "dresden elektronik / ZigBee"

Call to Action

Can you all please give me your contributions towards the above-mentioned database? Can you please provide me with the vendorId, productId, plus a brief description similar to the examples above? Many thanks for your contributions.

Signed-off-by: Andrew Fiddian-Green [email protected]

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/please-contribute-to-database-of-z-wave-zigbee-usb-sticks/152087/1

[stefan-hoehn]

1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]

[andrewfg]

You can check what is already in the database here

[cdjackson]

I see in your list you have 10C4:EA60 - this is a generic CP210x serial to USB interface and will therefore very likely find a load of different devices.

[andrewfg]

I see in your list you have 10C4:EA60 .. very likely find a load of different devices

@cdjackson I guess you are responding to the comment above the last line in the database code below? :) .. Many thanks.

       /*
         * ==== EnOcean sticks ====
         */
        // the following generic is used in EnOcean sticks => EXCLUDE supported binding ids!
        "0403:6001", "Future Technology Devices / GENERIC",

        /*
         * ==== Zigbee sticks ====
         */
        "0403:8A28", "Future Technology Devices / Rainforest Automation / ZigBee",
        "0451:16A8", "Texas Instruments / ZigBee",
        "10C4:89FB", "Silicon Laboratories / ZigBee",
        "1CF1:0030", "dresden elektronik / ZigBee",

        /*
         * ==== Z-Wave sticks ====
         */
        "0658:0200", "Sigma Designs / Aeotec / ZWave.me UZB / Z-Wave",
        "1A86:55D4", "Nanjing Qinheng Microelectronics / Zooz 800 / Z-Wave",

        /*
         * ==== Zigbee sticks || Z-Wave sticks ====
         */
        // maybe the following is generic => please report false positives !!
        "10C4:EA60", "Silicon Laboratories / Aeon Labs / Zooz 700 / sonoff / Z-Wave / Zigbee"

In this context I am weighing the utility of suggesting potential addons to new users -- they can anyway choose whether to accept the suggestions -- versus the non- utility of having too many false positives. The decision is made more complex by the fact that USB device discovery code works better or worse depending on which OS the system is on, plus various other configuration aspects (see table below). In the cases where all the data can be read, we could filter the suggestions based on the product description text in addition to the vendorId and productId. However in the other cases, we could not. So in other words, false positives are more likely on some systems than others.

=> I welcome your thoughts on this.

[andrewfg]

@cdjackson apropos the above => do you have direct experience of what kind of devices would report false positives for 10C4:EA60 ? If it was a memory stick then we might have larger issues, whereas if it is something fairly exotic perhaps fewer.

[cdjackson]

I guess you are responding to the comment above the last line in the database code below?

Correct - you have a comment to report false positives and my point is that these IDs are the standard ones used by the CP210x chips which are simple a serial adaptor. Therefore they will likely be picked up by many different devices.

In this context I am weighing the utility of suggesting potential addons to new users -- they can anyway choose whether to accept the suggestions -- versus the non- utility of having too many false positives.

Sure - but it's a balance, right. If it starts getting it wrong too often, then it will annoy people and be of limited work. Alternatively if it doesn't detect something, same problem... On the other hand, don't most people already know if they have a zigbee or zwave (or ??) stick since they went to the store (or online) and bought one :)

do you have direct experience of what kind of devices would report false positives for 10C4:EA60

This is a generic serial bridge - it's used in a lot of devices - anything from development tools to, well, anything that interfaces USB to serial. I use it a lot in different projects here - it's like the Silabs version of the FTDI chipset that used to be used in every USB serial bridge out there. I have some commercial ESP32 devices here that use the CP210x, so they would be detected - it's a reasonably common chipset.

[andrewfg]

don't most people already know if they have a zigbee or zwave (or ??) stick since they went to the store (or online) and bought one

Yeah. My tendency would be to suggest add-ons generously. The user can then say to themselves 'hey I don't have one of those' and decline the suggestion.

(I did this myself just now on M5 .. the finder discovers my printer as two candidate suggestions -- namely HP Printer and lpp printer -- and I chose to install the first suggested add-on and not the second.)

[andrewfg]

commercial ESP32 devices here that use the CP210x, so they would be detected

Interesting. Do those devices have an integration binding into OH? Because if so, we should probably suggest that binding too. Or?

[cdjackson]

Do those devices have an integration binding into OH?

No - they aren't anything to do with openhab or home automation. My point is just that these are common chips used in loads of devices so there will likely be a lot of false suggestions when using generic IDs.

[mherwege]

Yeah. My tendency would be to suggest add-ons generously. The user can then say to themselves 'hey I don't have one of those' and decline the suggestion.

(I did this myself just now on M5 .. the finder discovers my printer as two candidate suggestions -- namely HP Printer and lpp printer -- and I chose to install the first suggested add-on and not the second.)

I don’t think this is the way to go. Being too generous will downplay the value of the feature. Too many false positives will lead to people not trusting the feature at all.
Your example about printers is not similar, as both will work (I have the same). It is users choice. So I do think it is a balance of finding as much as possible why avoiding too many false positives. I don’t think we should include something that is not conclusive enough.

[m4rcu5]

I run a Bitronvideo BV 2010/10 ZigBee USB dongle, which is identified as the following device 10c4:8b34 Silicon Labs BV 2010/10

A older device, but works like a charm for me.

Hope that helps!

[andrewfg]

don’t think we should include something that is not conclusive enough

@mherwege understood. And just so you know, the current PR is leaning towards excluding generic chips.

[andrewfg]

@mherwege just to clarify..

• Currently the Linux usb scanner will read the USB product information (on top of the USB chip vendorId and productId) -- so on Linux we can already exclude false positives.
• Currently there is no Windows or Mac usb scanner -- so there is no chance of getting any positives at all.
• I am proposing to add a scanner for Windows and Mac which would only read the vendorId and productId -- so -- on Windows -- we are introducing the potential to provide a) real positives and b) potentially false ones too.
• In the Windows case we just need to decide which vendorId and productId combinations are uniquely linked to real positives, which might produce false positives too, and in those cases what is the ratio between real and false.

[rkoshak]

See openhab/org.openhab.binding.zwave#1906 (comment)

I have the HUSBZB-1 which is a combo Zwave/Zigbee dongle.

[    4.166839] usb 2-1: new full-speed USB device number 2 using xhci_hcd
[    4.322066] usb 2-1: New USB device found, idVendor=10c4, idProduct=8a2a, bcdDevice= 1.00
[    4.322094] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[    4.322109] usb 2-1: Product: HubZ Smart Home Controller
[    4.322128] usb 2-1: Manufacturer: Silicon Labs
[    4.322135] usb 2-1: SerialNumber: 312001DC

[   23.564413] usbcore: registered new interface driver usbserial_generic
[   23.564424] usbserial: USB Serial support registered for generic
[   23.603471] usbcore: registered new interface driver cp210x
[   23.603485] usbserial: USB Serial support registered for cp210x
[   23.603506] cp210x 2-1:1.0: cp210x converter detected
[   23.605635] usb 2-1: cp210x converter now attached to ttyUSB0
[   23.605659] cp210x 2-1:1.1: cp210x converter detected
[   23.607496] usb 2-1: cp210x converter now attached to ttyUSB1

[andrewfg]

I run a Bitronvideo BV 2010/10 ZigBee USB dongle

@m4rcu5 just for the avoidance of doubt, does your stick actually have the word 'ZigBee' in its name? Otherwise we would need to also check for the word 'Bitronvideo'..

[Skinah]

I have probably 3 different common brands of sticks here, I missed what you want done to actually fetch the data?
What linux command do I run to get the output or is it the openHAB logs in TRACE that provide the info?

[andrewfg]

linux command do I run

lsusb or dmesg

[cdjackson]

I'll close this as I think it's done. If I spot any new sticks coming through I'll make sure they are added.