Conbee II stopped working on RPi 4

Phoscon App General Support
1

Hi,

I have been using Conbee II on my RPi 4 for several years. 2 nights ago is suddently stopped working. Been trying to fiddle with updating everything I cann but cannot get it working again. When connecting to a windows 10 machine it seems to work. Anyone has any idea what has happened and how I might fix it?

Detail follows…

It just stopped working during the night. I as asleep so noboy was doing anything on my RPi 4 :-). It had been days since I updated the RPi distribution so no fail due to updates.

Tried to update FW from my RPi 4, but failed. The updater seems to identify the ConBee II but keep repeating “reboot” and then simply stop by saying “retry, failed”. I was however able to flash new FW from Windows and the deCONZ app in Windows seems to work altough I have not tried to add devices.

Normally, I run bullseye-beta deconz software but downgraded to bullseye. Same problem.

Normally I run headless. Tried the deCONZ app and ConBee II on my RPi 4 but does not show up in the “connect to device” dropdown menu. Attaching some logs below - not sure it helps (I cannot understand them…)

10:21:40:166 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0

10:21:40:171 failed to reconnect to network try=5

10:21:40:172 wait reconnect 4 seconds

10:21:41:169 wait reconnect 3 seconds

10:21:42:165 wait reconnect 2 seconds

10:21:43:166 wait reconnect 1 seconds

10:21:43:234 COM: /dev/ttyACM0 : (0x1106/0x3483)

10:21:43:235 COM: /dev/ttyAMA0 : (0x0000/0x0000)

10:21:43:236 dev /dev/ttyAMA0

10:21:43:238 auto connect com /dev/ttyAMA0

10:21:45:166 try to reconnect to network try=6

10:21:45:166 APS-DATA.request id: 124, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0300, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:21:45:167 asdu (length: 5): 1052000b40

10:21:45:181 GW update firmware not found:

10:21:47:166 APS-DATA.request id: 128, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0000, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:21:47:167 asdu (length: 5): 1056000040

10:21:49:166 APS-DATA.request id: 132, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0000, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:21:49:167 asdu (length: 5): 105a000040

10:21:49:168 APS-DATA.request id: 133, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0000, cluster: 0x0033, ep: 0x00 → 0x00 queue: 0 len: 2 tx.options 0x04

10:21:49:169 asdu (length: 2): 2600

10:21:50:166 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0

10:21:50:167 try to reconnect to network try=7

10:21:51:168 APS-DATA.request id: 136, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0000, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:21:51:169 asdu (length: 5): 105d000040

10:21:53:177 APS-DATA.request id: 140, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0300, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:21:53:178 asdu (length: 5): 1061000800

10:21:54:170 device disconnected reason: 1, device index: 0

10:21:55:165 failed to reconnect to network try=8

10:21:55:166 wait reconnect 15 seconds

10:21:55:218 COM: /dev/ttyACM0 : (0x1106/0x3483)

10:21:55:218 COM: /dev/ttyAMA0 : (0x0000/0x0000)

10:21:55:219 dev /dev/ttyAMA0

10:21:55:281 COM: /dev/ttyACM0 : (0x1106/0x3483)

10:21:55:282 COM: /dev/ttyAMA0 : (0x0000/0x0000)

10:21:55:282 dev /dev/ttyAMA0

10:21:55:283 GW firmware update select /dev/ttyAMA0 device

10:21:55:286 GW update firmware not found:

10:21:56:165 wait reconnect 14 seconds

10:21:57:165 wait reconnect 13 seconds

10:21:58:165 wait reconnect 12 seconds

10:21:59:166 wait reconnect 11 seconds

10:22:00:166 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0

10:22:00:167 failed to reconnect to network try=9

10:22:00:167 wait reconnect 10 seconds

10:22:01:166 wait reconnect 9 seconds

10:22:02:166 wait reconnect 8 seconds

10:22:03:166 wait reconnect 7 seconds

10:22:04:165 wait reconnect 6 seconds

10:22:05:165 failed to reconnect to network try=10

10:22:05:166 wait reconnect 5 seconds

10:22:05:235 COM: /dev/ttyACM0 : (0x1106/0x3483)

10:22:05:236 COM: /dev/ttyAMA0 : (0x0000/0x0000)

10:22:05:236 dev /dev/ttyAMA0

10:22:05:237 GW firmware update select /dev/ttyAMA0 device

10:22:05:255 GW update firmware not found:

10:22:06:169 wait reconnect 4 seconds

10:22:07:165 wait reconnect 3 seconds

10:22:08:165 wait reconnect 2 seconds

10:22:09:165 wait reconnect 1 seconds

10:22:09:221 COM: /dev/ttyACM0 : (0x1106/0x3483)

10:22:09:222 COM: /dev/ttyAMA0 : (0x0000/0x0000)

10:22:09:222 dev /dev/ttyAMA0

10:22:09:223 auto connect com /dev/ttyAMA0

10:22:10:166 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0

10:22:10:167 reconnect network failed, try later

10:22:10:665 networkState: CC_ReconnectNetwork

10:22:10:666 start reconnect to network

10:22:11:166 APS-DATA.request id: 176, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0006, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:22:11:167 asdu (length: 5): 1082000000

10:22:13:165 APS-DATA.request id: 180, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0006, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:22:13:166 asdu (length: 5): 1086000000

10:22:15:165 APS-DATA.request id: 183, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0006, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:22:15:166 asdu (length: 5): 1089000000

10:22:15:177 GW update firmware not found:

10:22:15:916 try to reconnect to network try=1

10:22:17:165 APS-DATA.request id: 187, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0300, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:22:17:166 asdu (length: 5): 108d000700

10:22:17:167 APS-DATA.request id: 188, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0000, cluster: 0x0033, ep: 0x00 → 0x00 queue: 0 len: 2 tx.options 0x04

10:22:17:167 asdu (length: 2): 2a00

10:22:19:166 APS-DATA.request id: 192, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0300, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:22:19:166 asdu (length: 5): 1091000700

10:22:20:165 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0

10:22:21:165 try to reconnect to network try=2

10:22:21:166 APS-DATA.request id: 195, addrmode: 0x03, addr: 0x84fd27fffe498fd7, profile: 0x0104, cluster: 0x0300, ep: 0x01 → 0x01 queue: 0 len: 5 tx.options 0x00

10:22:21:167 asdu (length: 5): 1094000700

10:22:21:369 device disconnected reason: 1, device index: 0

10:22:22:166 wait reconnect 15 seconds

10:22:22:270 COM: /dev/ttyACM0 : (0x1106/0x3483)

10:22:22:270 COM: /dev/ttyAMA0 : (0x0000/0x0000)

10:22:22:271 dev /dev/ttyAMA0

2

Hello, it seems ? Better to be sure, because it’s like a firmware issue, but if it work on a windows can be from the host, power issue for exemple.

How are you making the firwmare update ? using Phoscon or command line ?

Have you tried unplug/replug ? To restart the gateway (the USB port is always powered so it don’t restart)

Can check too After a sudo apt update && sudo apt full-upgrade and a reboot deconz no longer connects to the conbee 2 · Issue #6937 · dresden-elektronik/deconz-rest-plugin · GitHub but I don’t see the message “failed open com status” on your logs.

3

Are there multiple USB dongles plugged in?

/dev/ttyACM0 : (0x1106/0x3483) looks like a different device.

Can you please share the output of:

lsusb

ls /dev/serial/by-id/
4

Hi Smanar,
I updated through commandline.

Unplugged and switched USB ports several times… have also powered down the RPi and rebooted several times…

The issue linked might be related - will dig into it if something might work for me. Thanks!

5

Output below. Note I changed USB port for the Conbee II from previous log. I see no difference in the deCONZ log but lsusb indicates it.

I do not have a path /dev/serial/by-id/ . I do have /dev/serial/by-path/

pi@ghost:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 026: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
Bus 001 Device 009: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 010: ID 06c4:c411 Bizlink International Corp. D6000 Controller
Bus 001 Device 007: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 008: ID 046a:b090 Cherry GmbH Keyboard
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 005: ID 17e9:6006 DisplayLink Dell Universal Dock D6000
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@ghost:~ $ ls /dev/serial/by-path/
platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0

6

Update

This seems to be my issue as well. When adding --dev=/dev/ttyACM0 things seems to work again.

Weird that it stopped working in the middle of the night several days after last update. Anyway, now I can get my things back online again.

Thanks

7

When adding --dev=/dev/ttyACM0 things seems to work again.

Ha yes, this appears to be the recent regression on Debian/Raspbian where the symbolic links under /dev/serial/by-id/ aren’t created anymore.

I’ve added a workaround for this in GCFFlasher4 which can lookup the serial number also from /dev/ttyACMx paths (Linux support udevadm to list USB devices · dresden-elektronik/gcfflasher@fdf9101 · GitHub). This will be integrated into deCONZ v2.23.x as well, hopefully it also solves a few Docker issues.

2 Likes
8

For more background info on this.

Perhaps a bit off topic, but consider plugging in a USB SSD to run the operating system from. I’ve been running Pi-Hole on a Cubox 1 for 10 years now, and every 3 years or so i had to replace the SD card because it would crash on memory blocks that had gone bad. Use at least high quality SD cards like Sandisks en make DD image backups regularely. So if it crashes you can quickly get up running again. For this reason i didn’t use an RPi4 but an intel NUC7 with 8Gb memory and an 128Gb SSD running Debian11 with KVM virtual machine running HAOS (Homeassistant) and the Conbee2 stick.

9

Small followup, the fix from GCFFlasher4 is now ported to deCONZ, was a bit trickier than I thought.
The change uses udevadm to lookup the /dev/ttyAMCx and /dev/ttyUSBx devices based on the serial number from the symlink which is specified via --dev=... like --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE1948474-if00 (the link doesn’t need to exist).

Will be available with the next version.