USB passthrough into LXD Home Assistant VM - Conbee II Zigbee Stick

LXD
1

Recently, I’ve created a VM for Home Assistant (which works extremely well so far) and I wanted to pass into the VM the Conbee II Zigbee stick.

After doing a little research I was able to get it to be seen in the VM by using the below device setup in the VM profile:

ttyACM0:
      type: usb
      vendorid: 1cf1
      productid: 0030

image
image747×897 38.6 KB

The issue is that the VM is unable to actually utilize the device itself. It is not able to interact with it or start the Zigbee radios it seems.

Is there a better/more correct way to pass this type of device into a VM so that it can interact with it? Would a unix-char be a better option or is the profile config for the device incorrect? Any help on this issue would be great.

2

Hmm, nope, for a VM that should be the way to go.

In my case I use my Conbee II with a Docker version of zigbee2mqtt so I just run all that in containers, talking to my MQTT server which Home Assistant finally connects to.
So I can say that it works with containers. Usually VMs are simpler as it’s just USB.
Maybe see if there are any tools to directly poke at the Conbee to see what may be going on?

3

Thanks Stephane for the quick reply.

I too am trying to go the route of MQTT using the MQTT broker add-on and the Zigbee2MQTT add-on in Home Assistant.

When setting it up and adding the specific config that Zigbee2MQTT asks for:
In the configuration.yml:

serial:
  adapter: deconz

then setting the serial port in the Zigbee2MQTT add-on:

port: /dev/ttyACM0

The below is the log output:

[12:11:00] INFO: Preparing to start...
[12:11:00] INFO: Socat not enabled
[12:11:01] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:info  2023-04-17 12:11:04: Logging to console and directory: '/config/zigbee2mqtt/log/2023-04-17.12-11-04' filename: log.txt
Zigbee2MQTT:info  2023-04-17 12:11:04: Starting Zigbee2MQTT version 1.30.3 (commit #unknown)
Zigbee2MQTT:info  2023-04-17 12:11:04: Starting zigbee-herdsman (0.14.103)
Zigbee2MQTT:error 2023-04-17 12:11:04: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2023-04-17 12:11:04: Failed to start zigbee
Zigbee2MQTT:error 2023-04-17 12:11:04: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2023-04-17 12:11:04: Exiting...
Zigbee2MQTT:error 2023-04-17 12:11:04: Error: Error while opening serialport 'Error: Error: I/O error, cannot open /dev/ttyACM0'
    at SerialPort.<anonymous> (/app/node_modules/zigbee-herdsman/src/adapter/deconz/driver/driver.ts:200:28)
    at SerialPort._error (/app/node_modules/@serialport/stream/dist/index.js:76:22)
    at /app/node_modules/@serialport/stream/dist/index.js:112:18

To me this is showing that it can’t access the serial port somehow. Any thoughts given the error above?

Otherwise, yes I may have to try to set up the conbee on another machine to see if I need to poke at it’s firmware or something else.

4

Anything useful in dmesg?

Normally /dev/ttyACM0 is just a serial device, so there’s not a lot to it really.
One thing that was an issue in the past was other processes trying to mess with such devices. The one I can remember is modem-manager which would treat all ttyACM devices as USB modems and would connect to them preventing anything else from interacting with it.

But I’d be pretty surprised if you have modem-manager running in a normal LXD VM.
That said, doesn’t hurt to check ps aux | grep -i modem :slight_smile:

5

Inside the VM, running dmesg gets tbe below (I believe this is the most relevant section):

[17948.918159] usb 1-7: USB disconnect, device number 10
[17949.298080] usb 1-8: new full-speed USB device number 11 using xhci_hcd
[17949.443104] usb 1-8: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[17949.443111] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17949.443115] usb 1-8: Product: ConBee II
[17949.443118] usb 1-8: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[17949.443120] usb 1-8: SerialNumber: DE2496751
[17949.448160] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
[17952.328373] usb 1-8: USB disconnect, device number 11
[17953.410289] usb 1-4: new full-speed USB device number 12 using xhci_hcd
[17953.556099] usb 1-4: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[17953.556118] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17953.556122] usb 1-4: Product: ConBee II
[17953.556125] usb 1-4: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[17953.556127] usb 1-4: SerialNumber: DE2496751
[17953.558131] cdc_acm 1-4:1.0: ttyACM0: USB ACM device

In regard to the system messing with hit as a USB Modem, this is the output of ps aux | grep -i modem:

210 root      0:00 grep -i modem

Now, another thing I was led to was the permissions of the USB device inside the VM:

crw-rw----    1 root     audio     166,   0 Apr 17 18:51 /dev/ttyACM0

Not sure yet if this set of permissions is causing the issue (seems weird that it’s owned by the audio group though).

6

Alright, another possible solution (although I am not sure how to adapt this to a LXD VM Profile) based on seeing another Home Assistant post that talks about an I/O Error from a Conbee II.

Seems others using Unraid with a Home Assistant VM have an issue that requires them to pass the device through as a usb-serial device. Here’s their config using KVM:

<serial type='dev'>
      <source path='/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_3DE24#####'/>
      <target type='usb-serial' port='1'>
        <model name='usb-serial'/>
      </target>
      <alias name='serial0'/>
      <address type='usb' bus='0' port='4'/>
    </serial>

Any idea Stepane if something similar to this (maybe unix-char or something else) would allow it to pass through in LXD using a similar method?

7

I did some additional digging and put Zigbee2MQTT into debug mode. Below is the output for the Conbee:

[14:23:28] INFO: Preparing to start...
[14:23:28] INFO: Socat not enabled
[14:23:28] INFO: Zigbee Herdsman debug logging enabled
[14:23:29] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:debug 2023-04-18 14:23:32: Loaded state from file /config/zigbee2mqtt/state.json
Zigbee2MQTT:info  2023-04-18 14:23:32: Logging to console and directory: '/config/zigbee2mqtt/log/2023-04-18.14-23-32' filename: log.txt
Zigbee2MQTT:debug 2023-04-18 14:23:32: Removing old log directory '/config/zigbee2mqtt/log/2023-04-17.12-08-48'
Zigbee2MQTT:info  2023-04-18 14:23:32: Starting Zigbee2MQTT version 1.30.3 (commit #unknown)
Zigbee2MQTT:info  2023-04-18 14:23:32: Starting zigbee-herdsman (0.14.103)
Zigbee2MQTT:debug 2023-04-18 14:23:32: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null,"disableLED":false},"backupPath":"/config/zigbee2mqtt/coordinator_backup.json","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","databasePath":"/config/zigbee2mqtt/database.db","network":{"channelList":[11],"extendedPanID":[221,221,221,221,221,221,221,221],"networkKey":"HIDDEN","panID":6754},"serialPort":{"adapter":"deconz","path":"/dev/ttyACM0"}}'
2023-04-18T19:23:32.574Z zigbee-herdsman:adapter Failed to validate path: 'Error: spawn udevadm ENOENT'
2023-04-18T19:23:32.576Z zigbee-herdsman:deconz:driver Set delay to 0
2023-04-18T19:23:32.577Z zigbee-herdsman:controller:log Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13],"panID":6754,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11]},"serialPort":{"path":"/dev/ttyACM0","adapter":"deconz"},"databasePath":"/config/zigbee2mqtt/database.db","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","backupPath":"/config/zigbee2mqtt/coordinator_backup.json","adapter":{"disableLED":false,"concurrent":null,"delay":null}}'
2023-04-18T19:23:32.578Z zigbee-herdsman:deconz:driver Opening with /dev/ttyACM0
2023-04-18T19:23:32.589Z zigbee-herdsman:deconz:driver Serialport opened
2023-04-18T19:23:32.589Z zigbee-herdsman:controller:log Started with result 'resumed'
2023-04-18T19:23:32.590Z zigbee-herdsman:controller:log Injected database: true, adapter: true
2023-04-18T19:23:32.591Z zigbee-herdsman:controller:database:log Writing database to '/config/zigbee2mqtt/database.db'
2023-04-18T19:23:32.625Z zigbee-herdsman:deconz:driver send read parameter request from queue. seqNr: 1 paramId: 1
2023-04-18T19:23:35.577Z zigbee-herdsman:deconz:adapter checking coordinator simple descriptor
2023-04-18T19:23:35.580Z zigbee-herdsman:deconz:driver DATA_REQUEST - destAddr: 0x0 EP:0 SeqNr. 2 request id: 1
2023-04-18T19:23:42.630Z zigbee-herdsman:deconz:driver Timeout for request - CMD: 0xa seqNr: 1
Zigbee2MQTT:error 2023-04-18 14:23:42: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2023-04-18 14:23:42: Failed to start zigbee
Zigbee2MQTT:error 2023-04-18 14:23:42: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2023-04-18 14:23:42: Exiting...
Zigbee2MQTT:error 2023-04-18 14:23:42: undefined

Any other thoughts @stgraber on if using a different device type might solve this?

Tonight I will try to put the Conbee into a Windows machine to test if it can be seen by Deconz or Phoscon directly to ensure the device itself is not problematic.

8

I was able to try the Conbee in a Windows machine with the Deconz/Phoscon software. Everything worked as expected, the device was found, and it was able to connect to zigbee devices.

@stgraber - my gut feeling is that it has something to do with how the device is passed to the VM. Any ideas on things to try??

9

@monstermunchkin any idea of what may be going on?
I seem to recall having a problem like that once before.

@ZeroGravitas can you maybe show lsusb -vvv both from the host (prior to starting the VM) and then from inside of the running VM.

10

@stgraber Below is the output of lsusb -vvv for the host:

Bus 006 Device 030: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.01
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1cf1 Dresden Elektronik
  idProduct          0x0030 ZigBee gateway [ConBee II]
  bcdDevice            1.00
  iManufacturer           1 dresden elektronik ingenieurtechnik GmbH
  iProduct                2 ConBee II
  iSerial                 3 DE2496751
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0043
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              16
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        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     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

And below is the same output inside the Home Assistant VM:

Bus 001 Device 020: ID 1cf1:0030
Bus 001 Device 001: ID 1d6b:002
Bus 002 Device 001: ID 1d6b:003

It’s odd because if I go into Settings > Hardware and look for the Conbee, it’s at ttyACM0 and the attributes are what is shown below but using lsusb -vvv it only identifies as Device 020:

DEVLINKS: >-
  /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2496751-if00
  /dev/serial/by-path/pci-0000:01:00.6-usb-0:7:1.0
DEVNAME: /dev/ttyACM0
DEVPATH: /devices/pci0000:00/0000:00:01.0/0000:01:00.6/usb1/1-7/1-7:1.0/tty/ttyACM0
ID_BUS: usb
ID_MODEL: ConBee_II
ID_MODEL_ENC: ConBee\x20II
ID_MODEL_ID: '0030'
ID_PATH: pci-0000:01:00.6-usb-0:7:1.0
ID_PATH_TAG: pci-0000_01_00_6-usb-0_7_1_0
ID_REVISION: '0100'
ID_SERIAL: dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2496751
ID_SERIAL_SHORT: DE2496751
ID_TYPE: generic
ID_USB_DRIVER: cdc_acm
ID_USB_INTERFACES: ':020201:0a0000:'
ID_USB_INTERFACE_NUM: '00'
ID_USB_MODEL: ConBee_II
ID_USB_MODEL_ENC: ConBee\x20II
ID_USB_MODEL_ID: '0030'
ID_USB_REVISION: '0100'
ID_USB_SERIAL: dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2496751
ID_USB_SERIAL_SHORT: DE2496751
ID_USB_TYPE: generic
ID_USB_VENDOR: dresden_elektronik_ingenieurtechnik_GmbH
ID_USB_VENDOR_ENC: dresden\x20elektronik\x20ingenieurtechnik\x20GmbH
ID_USB_VENDOR_ID: 1cf1
ID_VENDOR: dresden_elektronik_ingenieurtechnik_GmbH
ID_VENDOR_ENC: dresden\x20elektronik\x20ingenieurtechnik\x20GmbH
ID_VENDOR_ID: 1cf1
MAJOR: '166'
MINOR: '0'
SUBSYSTEM: tty
TAGS: ':systemd:'
USEC_INITIALIZED: '32284612048'

Home Assistant OS is running Debian underneath so I am wondering if the differences between an Ubuntu Host and Debian VM could be a part of the issue?

11

After finally getting some time to test the conbee passed through to a lxc container which is running docker, I finally got things working.

Passing it through as a unix-char to the lxc container worked great, and then passing that into the zigbee2mqtt docker container worked perfectly.

I think I’ll go the route of running home assistant and it’s add on’s in a docker lxc. Resource wise, it is nice not to have it tied up in a vm.

As for the final solution of passing the conbee into a lxd vm and being seen correctly, I really don’t know the answer. If anyone is able to figure that out with a lxd vm please post the solution here so others can find it.