ConBee Firmware update inside docker container fails

[jo-me]

Hi, I'm trying to get deconz + rest running in a docker container on a Raspberry Pi 2 with a ConBee attached with the factory firmware installed. I'm not using the whole deconz raspbian but want to install it on my existing system (running Raspbian Stretch) coexisting with a Z-Wave Stick.

The application itself seems to work - i could even pair my Hue remote - but the integrated firmware mechanism doesn't.

The firmware update tool fails and the firmware stays the same. I've tried to run the container in privileged mode and by just providing /dev/ttyAMA0 but that did not make a difference.

What are the prerequisites for using GCFFlasher ? Why is GCFFLasher saying "use RaspBee (/dev/ttyAMA0)" instead of ConBee?

Thank you for any hints!

2017-10-18T18:17:00.064169322Z 20:16:51:028 HTTP API POST /api/81FB54DFE1/config/updatefirmware - 192.168.178.38 2017-10-18T18:17:00.064260783Z 20:16:51:028 [{"success":{"/config/updatefirmware":"0x26190500"}}] 2017-10-18T18:17:00.064355785Z 20:16:51:082 hide node: 0xEE38 2017-10-18T18:17:00.064445735Z 20:16:51:133 GW firmware start update (device not connected) 2017-10-18T18:17:00.064536310Z 20:16:51:253 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state 2017-10-18T18:17:00.064628188Z 20:16:51:253 device state timeout ignored in state 5 2017-10-18T18:17:00.064718450Z 20:16:51:373 GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26 2017-10-18T18:17:00.064811369Z no device specified use RaspBee (/dev/ttyAMA0) 2017-10-18T18:17:00.064901320Z using firmware file: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26190500.bin.GCF 2017-10-18T18:17:00.064992103Z 20:16:51:373 GW firmware update exit code 1 2017-10-18T18:17:00.065082053Z 20:16:52:053 Wait reconnect after firmware update 2017-10-18T18:17:00.065280235Z 20:16:53:052 Wait reconnect after firmware update 2017-10-18T18:17:00.065458573Z 20:16:54:052 Wait reconnect after firmware update 2017-10-18T18:17:00.065553940Z 20:16:55:053 Wait reconnect after firmware update 2017-10-18T18:17:00.065709361Z 20:16:56:053 Wait reconnect after firmware update 2017-10-18T18:17:00.065808061Z 20:16:57:053 Wait reconnect after firmware update 2017-10-18T18:17:00.065899574Z 20:16:58:053 Wait reconnect after firmware update 2017-10-18T18:17:00.065989941Z 20:16:59:052 Wait reconnect after firmware update 2017-10-18T18:18:11.957763996Z 20:18:07:053 Wait reconnect after firmware update 2017-10-18T18:18:11.957827592Z 20:18:08:081 dev /dev/ttyAMA0 2017-10-18T18:18:11.957893583Z 20:18:08:174 Device firmware version 0x260B0500 2017-10-18T18:18:11.957959105Z 20:18:08:212 unlocked max nodes: 200 2017-10-18T18:18:11.958034367Z 20:18:08:499 Device protocol version: 0x0104 2017-10-18T18:18:11.958110150Z 20:18:08:712 Current channel 15 2017-10-18T18:18:11.958177860Z 20:18:08:759 CTRL got nwk update id 0 2017-10-18T18:18:11.958249008Z 20:18:08:775 CTRL ANT_CTRL 0x02 2017-10-18T18:18:11.958378281Z 20:18:08:932 Device protocol version: 0x0104

[manup]

Previous discussion https://github.com/dresden-elektronik/deconz-rest-plugin/issues/9

I've no experience with Docker but here are some insights related to ConBee and GCFFlasher

• GCFFlasher detects ConBee by looking for respective USB vendor/product id (FDTI; 0x0403 : 6015)
• then it uses libftd2xx to reset the ZigBee SoC on ConBee

Mapping ConBee to /dev/ttyAMA0 is problematic since on this address a RaspBee is expected, which is handled very differently for firmware update; /dev/ttyUSB0 is better.

Please provide the output of:

    # available USB devices
    $ lsusb

    # and list of devices (after mapping to /dev/ttyUSB0)
    $ GCFFlasher_internal -l

It should be possible to get it working in Docker, at least it runs fine in Virtual Box environments.

[jo-me]

Thank you for getting back to me. GCFlasher apparently does not recognize anything if ConBee is mapped to ttyUSB0.

With the ConBee mapped to /dev/ttyUSB0 (and deCONZ running):

root@3e29af2118cb:/# lsusb
unable to initialize libusb: -99
root@3e29af2118cb:/# GCFFlasher_internal -l
rmmod: ERROR: ../libkmod/libkmod-module.c:777 kmod_module_remove_module() could not remove 'ftdi_sio': Operation not permitted
rmmod: ERROR: could not remove module ftdi_sio: Operation not permitted
rmmod: ERROR: Module usbserial is in use by: ftdi_sio
GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin'
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin'

With the ConBee mapped to /dev/ttyAMA0:

root@5ede9e24ac36:/# lsusb
unable to initialize libusb: -99
root@5ede9e24ac36:/# GCFFlasher_internal -l
rmmod: ERROR: ../libkmod/libkmod-module.c:777 kmod_module_remove_module() could not remove 'ftdi_sio': Operation not permitted
rmmod: ERROR: could not remove module ftdi_sio: Operation not permitted
rmmod: ERROR: Module usbserial is in use by: ftdi_sio
GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26
RaspBee: /dev/ttyAMA0 (default)
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin'
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin'

Do you think that it may have to do with the config files in /boot?

I'm running stretch on the RPI2, but the container is based on resin/rpi-raspbian:jessie, because with the stretch base image it did not find the dependencies of deCONZ.

[manup]

With the ConBee mapped to /dev/ttyUSB0 (and deCONZ running):

both should not run at the same time as only one can access the device. This would explain the error:

rmmod: ERROR: Module usbserial is in use by: ftdi_sio

Do you think that it may have to do with the config files in /boot?

I don't now, haven't used Docker yet.

[manup]

Maybe this helps:

https://stackoverflow.com/questions/24225647/docker-any-way-to-give-access-to-host-usb-or-serial-device

[jo-me]

Yeah flashing would not work then, of course, but notice the "RaspBee: /dev/ttyAMA0 (default)" line in the second block while it did not notice the ttyUSB0 device in the same way..

[manup]

The test for RaspBee on /dev/ttyAMA0 is very simple it only checks that the file is present.

For USB devices GCFFlasher also checks if the USB vendor and product id matches; if the test fails it won't be listed.

[jo-me]

Would the output above indicate that it did not find the device because it was not there? Or couldn't it find it because the application was running?

[manup]

It must fail when deCONZ is also running, so you should try it without running deCONZ.

unable to initialize libusb: -99

This is also strange, but it can be fixed as follows:

https://www.jann.cc/2014/09/06/sandboxing_proprietary_applications_with_docker.html#usb-support

[jo-me]

Yeah, adding the USB controller should allow lsusb. Is that needed, though? In privileged mode, all devices were accessible.

But docker aside, if I were to install deconz directly on Raspbian, my ConBee would also be called /dev/ttyAMA0.

How does GCFlasher look for the USB device with the mentioned vendor/product id?

And secondly, triggering the update mechanism from inside the web UI takes care of stopping deconz, flashing and then restarting it, right? This is what I did to produce the log output in the first post.

[manup]

Yeah, adding the USB controller should allow lsusb. Is that needed, though? In privileged mode, all devices were accessible.

Try it :) I don't know.

But docker aside, if I were to install deconz directly on Raspbian, my ConBee would also be called /dev/ttyAMA0.

Nope it becomes /dev/ttyUSB0 (in case only one USB devices is attached).

How does GCFlasher look for the USB device with the mentioned vendor/product id?

It uses libraries libft2xx and QSerialPort.

And secondly, triggering the update mechanism from inside the web UI takes care of stopping deconz, flashing and then restarting it, right? This is what I did to produce the log output in the first post.

Yes albeit it's a bit aged deCONZ runs from a script, we are currently working on transforming these parts to systemd services.

[jo-me]

okay... in my case it was recognized by raspbian as /dev/ttyAMA0..

Maybe the host system needs to be set up differently. The deconz autostart script does some magic specifically for raspbian systems regarding the files in /boot. I did the enableuart and bluetooth parts so far, but that did not change the device name.

Can you confirm that the serial port settings in raspi-config has to be set to no/no (refer to https://github.com/dresden-elektronik/deconz-rest-plugin/issues/233) for ConBee?

[manup]

okay... in my case it was recognized by raspbian as /dev/ttyAMA0..

Then there is the issue, ttyAMA0 is the pi UART.

The deconz autostart script does some magic specifically for raspbian systems regarding the files in /boot.

The changes will do the same as raspi-config used manually. On a Raspberry Pi 2 the bluetooth part can be ignored. And these changes are needed for RaspBee only, on plain RaspBian ConBee should be detected out-of-the-box as /dev/ttyUSBx device.

Is you ConBee attached directly or via USB hub?

Can you confirm that the serial port settings in raspi-config has to be set to no/no (refer to #233) for ConBee?

As described in following link, the settings should be No/Yes but these settings are only needed for RaspBee shield, not by ConBee.

https://github.com/dresden-elektronik/deconz-rest-plugin#software-requirements

Heres a screenshot with these exact same settings and ConBee running a Update: Raspbian Strech ConBee and RaspBee attached. Since HW serial port is enabled RaspBee is on /dev/ttyS0.

Just tried also with No/No serial port settings the ConBee update works.

[jo-me]

Hmm I'm a little confused now..

Went back to check the device name and found that I was apparently irritated by the suddenly appearing ttyAMA0 device which I though must be the newly added ConBee. You were right, however, it is actually ttyUSB0.

By running udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0) the system gives some info about the device. It shows (among other output):

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/ttyUSB0': KERNELS=="ttyUSB0" SUBSYSTEMS=="usb-serial" DRIVERS=="ftdi_sio" ATTRS{latency_timer}=="16" ATTRS{port_number}=="0"

So far so good.

I changed the docker call to map the ttyUSB0 device again - this time with the correct device name on the host system side - and even the matching controller as you suggested.

lsusb (from within the container) returns now all devices even though not all are mapped into the container:

root@8322f2d83b1a:/# lsusb Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 001 Device 006: ID 0658:0200 Sigma Designs, Inc. Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I don't have a hub connected. All USB devices are connected directly to the pi (wifi stick, bluetooth stick, Z-wave stick and ConBee).

In terms of deCONZ, this seems to be a step in the wrong direction though. It apparently misses the ttyAMA0 device. The log is full of this now:

19:55:12:714 dev /dev/ttyAMA0 19:55:13:683 dev /dev/ttyAMA0 19:55:13:716 dev /dev/ttyAMA0 19:55:14:686 dev /dev/ttyAMA0 19:55:14:721 dev /dev/ttyAMA0 19:55:15:694 dev /dev/ttyAMA0 19:55:15:737 dev /dev/ttyAMA0 19:55:16:676 dev /dev/ttyAMA0

This looks similar to this issue: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/220

Needless to say that the firmware updating is also not working :) However, GCFFlasher does find 1 FTDI device now. Yey!

root@8322f2d83b1a:/# GCFFlasher_internal -l rmmod: ERROR: ../libkmod/libkmod-module.c:777 kmod_module_remove_module() could not remove 'ftdi_sio': Operation not permitted rmmod: ERROR: could not remove module ftdi_sio: Operation not permitted rmmod: ERROR: Module usbserial is in use by: ftdi_sio GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26

   1  FTDI device found

device	vendor	product	serial	description

failed to open FTDI device (0) status = 3

modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin' modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin'

To me it looks like deCONZ needs to be told which device to use. Everything seems to be geared towards the Raspbee device..

Btw, I'm using the latest beta (2.04.82) along with the matching -dev package.

Thanks for your support so far @manup !

[manup]

Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd

That looks good this is the ConBee device.

To me it looks like deCONZ needs to be told which device to use. Everything seems to be geared towards the Raspbee device..

deCONZ uses the QSerialPort library of Qt5 to enumerate and talk to ConBee, maybe it has issues to find the USB device inside Docker container for some reason. I'm afraid that I can't help much here due the lack of Docker experience.

Or it's an rights issue, at least on Ubuntu the user must be in the group dialout to access the /dev/ttyUSB0 device.

[jo-me]

Yes, the user in the container (root) is added to the dialout group.

I've made some progress at least on the flashing side. Since deconz does not actually use the USB device I tried to flash it from the command line.

But just like deCONZ, GCFFlasher saw the FTDI device but did not actually use it when called with "GCFFlasher_internal-f ".

After I found out how to give it the correct device ("-d 0" for ttyUSB0), flashing worked:

root@fbb1c8152e43:/# GCFFlasher_internal -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26190500.bin.GCF -d 0 rmmod: ERROR: Module ftdi_sio is not currently loaded rmmod: ERROR: Module usbserial is not currently loaded GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26 using firmware file: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26190500.bin.GCF reset via FTDI

flashing 130438 bytes: |===============================| verify: .... SUCCESS modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin' modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.53-v7+/modules.dep.bin'

Not sure whether that was the correct firmware file though.. it was the one that deconz apparently downloaded. But given that it returned "SUCCESS" I assume it worked. I hope that deCONZ calls GCFFLasher with the correct device name if it recognizes the device itself.

So now the missing link is the device detection of deCONZ...

[jo-me]

@manup, would it be possible to add an command line parameter to force deCONZ to use a certain device just like it is possible with GCFFLasher already?

[manup]

@manup, would it be possible to add an command line parameter to force deCONZ to use a certain device just like it is possible with GCFFLasher already?

Yes this should be possible, I put it on the list.

[doctorjames]

I just received a ConBee and ran into the same issue with starting deConz. I want to run it in an lxc container on a Turris Omnia router which has the the same Arm ABI as the raspberry pi.

I used a Qt serial port example to debug what was happening and found it's trying to use udev device information which is not available in a container.

The following hack fixes this so the vendor and model gets found (I put this in the /etc/rc.local):

mkdir -p "/run/udev/data/"
echo "E:ID_VENDOR_ID=0403" >"/run/udev/data/c188:0"
echo "E:ID_MODEL_ID=6015" >>"/run/udev/data/c188:0"

Check the filename matches the device major/minor your USB device is allocated.

And to run the firmware flasher you have to run:

rmmod ftdi_sio on the host, run GCFFlasher in the container, then run modprobe ftdi_sio again on the host.

Hopefully this can be of use to also fix the issue on docker containers, though being able to specify the device as a command line argument is a much better fix.

[marthoc]

@doctorjames this is great work - thank you for this, it will allow me to finish my work on (Docker) containerizing deCONZ.

I’m wondering (out loud) if the vendor and modelid are the same for all Conbee and all RaspBee?

[doctorjames]

@marthoc Great.

I would expect the IDs would be the same for all Conbees since that's just a pair of standard FTDI bridge IDs as far as I know. A random device with those IDs could be something other than a Conbee, so if you had a arduino with a FTDI interface or something like that also connected you'd need to use udev on the host to give the Conbee a special /dev name based on its serial number.

In the container, as far as deConz is concerned it identifies those IDs as a Conbee and this will allow it to open successfully. deConz will request any further information it needs (like firmware version) directly from the device. This might also work for the RaspBee so it's worth trying, though a RaspBee doesn't usually appear as a USB device so it could theoretically mislead deConz if there are any communication differences. (If it is a problem, just look in e.g. /run/udev/data/c188:0 on the host to see what a RaspBee udev description looks like and narrow down the minimum necessary entries).

[Kane610]

@marthoc any progress with this?

[marthoc]

@Robban in fact I was working on this just now. Should have something viable for you to try tonight.

[Kane610]

@marthoc wow! I just moved all stuff over to my x86 machine from rpi2. Great timing, hopefully I can just move the database so I don't have to go around reseting all lights... I can probably try it out next week if everything goes well

[marthoc]

@Robban were you using Conbee on the RPi?

[Kane610]

@marthoc yes, but I wanted more power so now it is Xeon 👍 Now hass restarts in 1 second instead of 90

[marthoc]

@Kane610 It’s not tested, but it implements the workarounds that are necessary; I’m going to test with a small setup tomorrow and my Conbee and see how if it works: https://hub.docker.com/r/marthoc/deconz/

[marthoc]

@doctorjames I'm a bit surprised having finally gotten to implement this in docker that this workaround still doesn't appear to let me use the Conbee inside the container... not quite sure what is up but I've double checked that my Conbee has the same VENDOR and MODEL id's and on the host the data is in /run/udev/data/c188:0 also. Any further information from debugging that you could share?

@Kane610 the work appears to continue but I'd appreciate it if you could try the image out and see what happens?

[marthoc]

@doctorjames Solved it (though I'm not sure precisely how), maybe it has to do with deCONZ version 2.05.05 but the minimal entries you posted above didn't cause Conbee to be recognized in the container. Instead I populated /run/udev/data/c188:0 with:

I:2178680
E:ID_BUS=usb
E:ID_VENDOR_ID=0403
E:ID_MODEL_ID=6015
E:ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E:ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E:ID_PCI_INTERFACE_FROM_DATABASE=EHCI
E:ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E:ID_MODEL_FROM_DATABASE=Bridge(I2C/SPI/UART/FIFO)
E:ID_VENDOR=FTDI
E:ID_VENDOR_ENC=FTDI
E:ID_MODEL=FT230X_Basic_UART
E:ID_MODEL_ENC=FT230X\x20Basic\x20UART
E:ID_REVISION=1000
E:ID_SERIAL=FTDI_FT230X_Basic_UART_DM0066XH
E:ID_SERIAL_SHORT=DM0066XH
E:ID_TYPE=generic
E:ID_USB_INTERFACES=:ffffff:
E:ID_USB_INTERFACE_NUM=00
E:ID_USB_DRIVER=ftdi_sio
G:systemd

Now on container start the Conbee is recognized. This was essentially the content of /run/udev/data/c188:0 on my host, though I removed these lines:

S:serial/by-path/pci-0000:00:1d.0-usb-0:1.2:1.0-port0
S:serial/by-id/usb-FTDI_FT230X_Basic_UART_DM0066XH-if00-port0
E:ID_PATH=pci-0000:00:1d.0-usb-0:1.2:1.0
E:ID_PATH_TAG=pci-0000_00_1d_0-usb-0_1_2_1_0

As they seemed to be system specific. Obviously, something additional was needed for deCONZ to recognize Conbee but as I didn't add lines one-by-one I'm not sure what specifically.

Testing continues.

[doctorjames]

@marthoc that's curious. Mine is still working fine on 2.05.06, though as I said before I'm running it in a standard lxc container so there will be more things installed than in a minimal docker environment and lxc and docker may have different default cgroup and device permissions.

In my lxc container I can see and walk the /sys/bus/usb/ hierarchy which is what lsusb seems to do. Is that available by default in docker?

Try systematically removing lines and see which additional ones are essential on your system as that might give a clue as to where the difference lies.

This is the Qt example I played with when originally investigating.

strace was also handy to investigate what file accesses were attempted.

[Kane610]

@marthoc sure, will try to get to it before the end of the weekend. Can you share your docker file for the container?

[marthoc]

@Kane610 Sure - in fact I was going to create a GitHub repo for it tonight as the basis of an automated build for amd64 so I’ll send it along when that’s done.

[Kane610]

@marthoc sounds good

[ghost]

@marthoc thanks alot for your work on this docker image. much appreciated !

I was fiddling around with getting deConz/Conbee to run headless in a LXC container - and got frustrated with the poorly made package (hardcoded 'pi' user, package simply chowning files to UID1000 etc) - and while searching for a solution ended up here.

You have made my first docker steps a pleasant experience.

Cheers ! PS: Yeah, I singed up to github to leave this comment.

[manup]

and got frustrated with the poorly made package (hardcoded 'pi' user, package simply chowning files to UID1000 etc)

@apeinspace if you have some ideas on how to improve the package, please share.

[doctorjames]

@manup A big improvement would be to think along the lines of putting the pi-related services and configuration in a separate package that depends on the main binary deconz one. The instructions could tell people to install the deconz-pi package and it would work as now for them, while people with custom setups would only install the deconz-bin or whatever you want to call it. You could also make only the deconz-pi package depend on wiring as that's not a standard debian package.

As I said above, the pi version works perfectly on a Turris Omnia router when running an ordinary debian arm image in an lxc container. I just had to change the hard-coded pi user etc. It would perhaps be better to get the deconz-bin package to create a deconz user and group for the service/database ownership and document adding the user account to the deconz group for people wanting to run the gui (you could also do this automatically in the deconz-pi package install). Of course then you would probably need to create and look for the database somewhere shared like /var/lib/deconz.

You could make it easier for people to keep up to date and to install dependencies automatically by setting up an apt repository. I've found reprepro to make this pretty easy. There are plenty of tutorials online on various blogs.

[ghost]

@manup thanks for following up. apologies if my wording was a bit harsh. easier to criticize than to create.

My thoughts are along the same line as @doctorjames. the package should be modular to cater for the different use cases. the PI is just one of the options. I would also advise that all configuration parameters (users/ports/IP/paths/headless vs. GUI/debug switches) move out of the start scripts into a config file.

the part about making UID 1000 owner of the deconz files was confusing. I believe creating an own deconz user and group, as stated above, should be the way to go.

However, I am happy with my docker container and deconz so far (it has only been a couple of hours) - it was about time ditch the Xiaomi Gateway ...

[marthoc]

@jo-me - if you’re still having this firmware update problem, I’ve solved it in the latest release of my deconz docker image (https://github.com/marthoc/docker-deconz); instructions are in the README. Since firmware updates from the web UI currently fail in docker (I’m exploring some workarounds for that), I wrote a bash script that does the updating, added it to my image, and gave instructions so that it can be invoked from the command line with a docker run command. It works on Conbee and RaspBee on both amd64 and armhf. You don’t even need to be using my image for your container to use the firmware flashing script, it can be used to flash any device on any system.

[geelenbert]

As linked per @marthoc 's thread, i'm having issue with running Deconz in a HassIO Docker environment. It looks like this is an issue that the usb device name needs to be set when creating the docker instance. @marthoc suggested that setting the usb device name as command line parmeter would give the option to solve this. @manup would this be possible to implement ?

[manup]

Yep I'll see to get it done during the next days, the feature is quite some time on the wish list.

[geelenbert]

@manup Did you get any change to add this in the last days ?

[geelenbert]

@manup Sorry for bumping this topic, but i realy am looking for this patch. Each time my system restarts, I have to do work arounds to get the Conbee detected as the USB0 device. Would it be possible to implement this option ?

[syphernl]

I'm wondering that as well. With the suggestion of @marthoc deCONZ is recognizing the stick in my LXC container (running via Proxmox). This is an unprivileged container otherwise deCONZ failed to start completely.

However, it seems to be disconnecting constantly:

20:31:33:621 COM: /dev/ttyUSB0 :
20:31:33:621 COM: /dev/ttyACM0 :
20:31:33:621 COM: /dev/ttyUSB1 : FT230X Basic UART
20:31:33:636 COM: /dev/ttyUSB0 :
20:31:33:636 COM: /dev/ttyACM0 :
20:31:33:636 COM: /dev/ttyUSB1 : FT230X Basic UART
20:31:33:637 auto connect com /dev/ttyUSB1
20:31:33:638 Serial com disconnected, reason: 4
20:31:34:620 COM: /dev/ttyUSB0 :
20:31:34:620 COM: /dev/ttyACM0 :
20:31:34:620 COM: /dev/ttyUSB1 : FT230X Basic UART
20:31:34:636 COM: /dev/ttyUSB0 :
20:31:34:636 COM: /dev/ttyACM0 :
20:31:34:636 COM: /dev/ttyUSB1 : FT230X Basic UART

The flasher itself doesn't work though:

root@deconz:~# GCFFlasher_internal -l
 ftdi_sio
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10

       2  FTDI devices found

 device | vendor | product | serial  | description
--------|--------|---------|---------|----------------------
failed to open FTDI device (0) status = 2

failed to open FTDI device (1) status = 2

Attached to the host are:

• ZWave stick (Sigma Systems) on ttyACM0
• DSMR cable (based on FTDI as well) on ttyUSB0
• ConBee on ttyUSB1

ttyUSB1 on the host has been forwarded as ttyUSB0 on the container:

lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB0 none bind,optional,create=file 0 0
lxc.mount.entry: /dev/bus/usb/004 dev/bus/usb/004 none bind,optional,create=dir

Created /run/udev/data/c188:1 with the content of the host, sans the serial-by/path, serial-by/id, ID_PATH, ID_PATH_TAG

device permissions should be sufficient:

root@deconz:~# ls -alh /dev/ttyUSB0
crw-rw-rw- 1 nobody nogroup 188, 1 Aug 22 20:05 /dev/ttyUSB0

Any pointers in getting this to work would be greatly appreciated!

Edit: With a more extensive debug mode it shows that it tries to open /dev/ttyUSB1 on the container but I'm forwarding it as ttyUSB0. Switching this around + doing the manual /run file creation seems to do the trick. As in: I'm seeing a bunch of zmNode things coming past in the logs and the PWA shows the stick rather than a box. Yet for some reason I cannot open up the Wireless Light Control?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[radio-van]

@doctorjames Could you please give a little bit more details about your setup? I also have Turris Omnia and ConBee stick, but no luck yet. I run an archlinux container (because I had troubles with deconz installation inside Debian container), I've added these lines to container config:

lxc.mount.entry = /dev/bus/usb/002/003 dev/bus/usb/002/003  none bind,optional,create=file
lxc.cgroup.devices.allow = c 189:* rwm

and seems like they're correct, at least lsusb inside the container shows ConBee stick, but deCONZ pwa app can't find it.

[jose-d]

@doctorjames Could you please give a little bit more details about your setup? I also have Turris Omnia

here is how-to for Turris Omnia and Conbee II: https://doc.turris.cz/doc/en/public/deconz_lxc_howto