USB hardware and Cloudron Docker images

[jadudm]

The question: Is it possible for me to have a Cloudron Docker container that grabs a USB serial device?

---

I have set up Home Assistant in a Cloudron container, and mosquitto (an MQTT broker) in another. They talk to each-other. They're friends.

I would like to have a container running zigbee2mqtt. This is a node app that talks to a USB zigbee adapter (I'm using this one).

Is it possible for me to have a Cloudron Docker container that grabs that USB device?

If I was spinning this up outside of Cloudron, I'd use the devices tag in my docker-compose.yml. (This is the zigbee2mqtt compose, for reference.)

[mehdi]

@jadudm Question : is there a specific reason that you are not using ZHA instead of Zigbee2MQTT ? Sorry, I know this is a bit off-topic as it would not change anything with regards to the USB problem, except that you would have to pass the USB to the HomeAssistant container ^^

[jadudm]

@mehdi Good question, and correct; if I could pass the USB device through to a Cloudron-hosted container, I could just pass the USB Zigbee radio directly to HA.

For the record: I have answered my question. The rest is detail/how I solved it.

I had previously already packaged HA and MQTT as Cloudron containers. I pushed those images to my local Docker image repository (hosted on my Cloudron! Haha!), and then... pull them locally. (Silly, but it works.) I did this because I had one Tasmota-based WiFi switch that I was trying to control, and it was (I thought) easiest to have it talk via WiFi to the MQTT server, and in turn, HA could subscribe/catch the device that way.

This worked.

Cloudron is running on a Proxmox-hosted VM. I realized I could spin up a second VM...

One VM is running Cloudron; the second VM is running nothing but zigbee2mqtt. I passed the USB device to that VM, and am running (of all things) the Docker image for z2m, with the USB device poked through to the container. (It's virtualization all the way down...) I then talk from z2m to the mqtt server running on Cloudron, and HA was happy to find all of the Zigbee devices that way.

[girish]

@jadudm Devices are not exposed to containers. Usually, we add a flag in the manifest and expose devices to containers as needed. The idea being that in the future we can atleast "warn" or "inform" the user that the app wants to use the device. For example, emby uses the graphics card for vaapi api use. For example, https://git.cloudron.io/cloudron/box/-/blob/master/src/docker.js#L390

You can patch that specific function to add more devices there. If you can tell me what or how to expose the USB devices to the container, we can try to adjust the manifest accordingly.

[mehdi]

@girish It usually depends on the device, but in this usecase (a zigbee usb stick), it's a TTY to USB device that has to be passed. I got something similar in my local HA install, and here's the relevant docker-compose bit:

    devices:
      - '/dev/ttyUSB0:/dev/ttyUSB0'

I believe the equivalent docker run option would be:

--device=/dev/ttyUSB0:/dev/ttyUSB0

[mehdi]

Of course, the thing is the device being passed should be configurable by the user : you can't blindly pass ttyUSB0 and assume it will always work.

[girish]

@mehdi Ah, I see. Maybe we need device permission and some sort of device selector in the UI.

[robi]

@girish Right, device enumeration happens at the OS level, and it's not always consistent for silly kernel reasons.

From there one needs to be able to list all USB devices and have the user choose or add additional code to interrogate all USB devices for hints and choose automatically based on what the app is looking for (zigbee vs mouse/keyb).

[girish]

@robi indeed, I guess additional complication is also that device names can change.

[robi]

@girish yes, but generally only during major OS upgrades and new ways of handling of those driver subsystems.

[girish]

@robi I think it also changes with the physical USB port that the device connects to (?)

[robi]

@girish it can, since many systems now have a transitional period of USB2.0 and USB 3.0 hubs.

[mehdi]

Another, safer, way, would be to use the alternative paths. In my case, that would be /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 or /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0