During investigation of a ConBee II connectivity problem related to libusb, a openSUSE kernel developer came to the conclusion that the ConBee II is probably not supporting the newest libusb connection method.
The relevant comment with regards to the ConBee II is comment #34:
I don’t know what’s the USB controller used by Conbee II, I didn’t findout the datasheet of Conbee II either in google or manufacturer web site(dresden elektronik). So can’t confirm whether its USB controller has certain limitations/defects.
I can only make the following guesses:
Case A: the USB controller used by Conbee II can’t correctly response the ctrl message that coming from ioctl in userspace.
Case B: the USB controller used by Conbee II can’t correctly response multiple kinds of requests that coming from ioctl in userspace.
deCONZ and GCFFlasher don’t use libusb but connect to the USB devices by opening respective files /dev/ttyACMx and /dev/ttyUSBx and do the port setup (baudrate etc.) via cfsetospeed, cfsetispeed and tcsetattr.
For ConBee III the correct baudrate is crucial and in some virtual setups like Docker and and VMs might require the parameter --baudrate=115200. ConBee II works even without it due to the native USB interface.
I don’t really have an idea why it won’t work in openSUSE, other than the usal stuff like checking that the user has access right to above mentioned files, on Debian this is done by putting the user in the dialout group.
Hi, thanks for reaching out! Unfortunately it’s not that simple (serial vs host device):
What got me to raise this issue in the first place is that pass through as a USB host device did work in Leap 15.2 (see comment #0 / bug description.) That means there was a time that libusb worked as expected as a driver for the Conbee II.
If your read the bug from the beginning, you’ll also see that I’ve now changed to using the Conbee II as a serial device (as you’re suggesting) and that works pretty much ok.
But the additional problem is that with virt-manager I only have the option to pass through the Conbee II as a USB host device, not as a serial device. That is rather odd if the Conbee II doesn’t support that. It also means I need to hack the VM configuration file to insert serial device info to enable the Conbee II for a VM. That’s a big UX problem, next to a configuration management nightmare.
If you “search://conbee II usbfs did not claim interface before use” you’ll see quite a big list of people running into the same issue in relation to qemu/libvirt. IMHO that should not be discarded with a simple “just use it as a serial device”.
Ok thanks I was confused about the libusb since deCONZ itself doesn’t use it.
If I understood the linked thread correctly there are new requests against the USB configuration descriptor and the response isn’t what was expected.
I’ll check the code in the coming days to see if there is something wrong. In contrast to ConBee I and III which use a FTDI chip, the ConBee II has a native USB interface on the MCU itself and the application firmware contains the USB code (which is based on ASF).
Note if there is a bug it can only be fixed in the application firmware, the bootloader contains a copy of the USB driver but is fixed and can’t be updated.