USB hardware and Cloudron Docker images

[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