Phoscon lost connection with ConBee II since last update, flashing issues

Last weekend I updated my deCONZ to the latest (beta) release. Unfortunately, it lost connection with the ConBee II and I haven’t been able to restore it since. In particular, I’m getting stuck on flashing the firmware. I’m hoping anyone can help me, as currently about a dozen of ZigBee devices are unreachable.

I’m running deCONZ on a Raspberry Pi 4B. ConBee II is plugged into one of the USB ports. There’s also a connection to the smart electricity meter in another USB port. Previously, there has never been an issue that those consumed too much of the available energy, so I don’t think that is the problem. On the Raspberry, there’s also a dockerized version of Home Assistant running. DeCONZ is mainly running in non-gui mode, but switching to deconz-gui service did not resolve this issue.

I’ve followed the steps from the FAQ. I’m not using a USB extension cable, but I never had issues previously and none of the hardware was changed recently. The gateway details in Phoscon are as follows:
Vendor unkown
Product (blank)
Version 2.22.00 / 19-9-2022
Firmware: Not connected

The current version of deCONZ has been installed.

ConBee II is registered in the system:
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 003: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The serial interface is available:
pi@raspberrypi:~ $ ls -l /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 May 19 09:57 /dev/ttyACM0

Then to (re-)flash the firmware, I closed phoscon, unplugged and re-plugged the ConBee II stick while waiting sufficiently long, downloaded the latest firmware and attempted to flash it. The result:
pi@raspberrypi:~ $ sudo GCFFlasher_internal -d /dev/ttyACM0 -t 60 -f deCONZ_ConBeeII_0x26780700.bin.GCF
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
retry, failed

When inspecting sudo GCFFlasher_internal -l, the result is:
pi@raspberrypi:~ $ sudo GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
/dev/ttyAMA0 | 0x0000 | 0x0000 | | RaspBee

Note that I’m using a ConBee II and not a RaspBee.

Any ideas on what I could try next?


You updated your full pi by any chance?

If so, you probably are affected by this:

1 Like

Hi Mimiix, thank you very much! Indeed, this was what I did, and the steps outlined in that topic solved the issue for me.

Summary of the resolution:
Look up device serial nuber through dmesg.
Then create a symbolic link that includes this serial number:
ln -s /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE{YOUR-SERIAL-NUMBER-HERE}-if00 …/…/ttyACM0

Next, I edited both
by extending one of the lines with a --dev argument:
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyACM0

Finally, reload the service and all should work again
systemctl daemon-reload
systemctl restart deconz.service
(or deconz-gui if you use that one)

Thanks a lot! My devices work like a charm again.


Here comes an easier solution:

  1. Install a working version from debian backports
    To install the working version of 252.5-2~bpo11+1 (one line, use copy & paste):

cd ~;wget --print-architecture.deb --print-architecture.deb;APT_LISTCHANGES_FRONTEND=none sudo apt install --fix-broken ./libudev1_252.5-2~bpo11+1_dpkg --print-architecture.deb ./udev_252.5-2~bpo11+1_dpkg --print-architecture.deb; rm libudev1_252.5-2~bpo11+1_dpkg --print-architecture.deb udev_252.5-2~bpo11+1_dpkg --print-architecture.deb

This command should just want to install the two packages (udev & libudev). If it tries to do something else, particularly removing a large quantity of packages, stop and reassess the situation

  1. Reboot
    After doing that reboot the pi by running

sudo reboot

Take care // Bjuckan

Thanks for this thread. Took me a half day to narrow this failure down.
With adding --dev in deconz.service my setup was working again.

Easier you said ? What could be easier and less risky than just adding a text file into /usr/lib/udev/rules.d ? :wink:

If I use —dev= /dev/ttyACM1 it works fine.
If I create a Symlink in 99-com.rules and use this instead of ttyACMx it does not work. Any idea , why it doesn‘t like the Symlink