deconz-rest-plugin: deCONZ to 2.05.88 failing to recognize Raspbee

How’s firmware flashing relevant here when reverting to a hassio-deconz-plugin < 6.5.0 (and thus older deconz) makes things work immediately again, without any re-flashing or the like? (yes, I’m affected as well, exactly same symptoms as described by others already)

Hi please let keep it civil here.

For RaspBee there shouldn’t be re-enumeration issues like for example we see for USB devices. I’m not sure what is happening here, or if it is an configuration problem.

On Raspbian we have seen that sometimes after an system update the serial configuration was reverted. In that case the steps to reconfigure it via raspi-config helped.

@manup, does that mean the problem will be solved in >2.05.88?

Yes it’s part of all the upcoming releases.

Hard to tell I did two tests in my setup to get a more detailed picture.

• deCONZ v2.5.88
• RaspBee I
• Raspberry Pi 4
• USB 3 SSD flash drive (no sd-card)
• deCONZ Add-on 6.5.0
• HassOS 4.16

Update from older firmware version

1. Logged in via SSH root shell → login
2. Attached to the Docker container docker exec -it addon_core_deconz bash
3. Via VNC disconnected deCONZ from RaspBee → deCONZ disconnect button under “File” menu item
4. In the SSH shell flashed old firmware

root@core-deconz:/# GCFFlasher_internal -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26350500.bin.GCF 
GCFFlasher V3_16 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device RaspBee (RaspBee)
deCONZ firmware version 26390500
RaspBee Bootloader premium
Vers. 1.02
build 201
3/08/01
 (4734 ms)
flashing 125732 bytes: |=============================|
verify: ....
SUCCESS

1. deCONZ reconnects automatically
2. In the Phoscon App → Menu → Settings → Gateway clicked the update firmware button (to version 0x26390500)
3. This worked fine and after the update deCONZ reconnected and the new firmware version was shown

Note: RaspBee I and ConBee I are more easy to handle as both use a FTDI chip which stays always up, even if the MCU reboots for the firmware update. So I think that the above issue is a different as other common USB re-enumeration issues. Related https://github.com/marthoc/docker-deconz/issues/298

Update when no firmware is installed

This state can be simulated by repeating above step 4) but aborting via Ctrl-C during the update:

root@core-deconz:/# GCFFlasher_internal -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26350500.bin.GCF 
GCFFlasher V3_16 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device RaspBee (RaspBee)
deCONZ firmware version 26390500
RaspBee Bootloader premium
Vers. 1.02
build 2013/08/01
flashing 125732 bytes: |====^C

Phoscon App shows now “Firmware not connected”.

In VNC deCONZ is also disconnected but shows the “Update Firmware” button. This exectues

 /usr/bin/GCFFlasher_internal.bin -d RaspBee -t 60 -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26390500.bin.GCF

But this doesn’t seem to work anymore. I repeated the firmware update with some more logging in the SSH shell.

GCFFlasher_internal -x 3 -d RaspBee -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26350500.bin.GCF
GCFFlasher V3_16 (c) dresden elektronik ingenieurtechnik gmbh
00:47:01:649 using firmware file: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26350500.bin.GCF 
00:47:01:765 ls dev: /dev/ttyAMA0 (0x0000/0x0000) sn: 
00:47:01:765 dev /dev/ttyAMA0
Reboot device RaspBee (RaspBee)
00:47:02:181 query bootloader v1 ID after 0 ms
00:47:03:683 query bootloader v1 ID after 1502 ms
00:47:04:184 query deCONZ firmware version
00:47:06:187 uart reset failed, try RaspBee reset
action: reset device RaspBee
wiringPi 2.60 initialized
00:47:06:457 query bootloader v1 ID after 62 ms
00:47:06:613 RX 48 bytes ASCII 
RaspBee Bootloader premium
Vers. 1.02
build 201 after 218 ms
00:47:06:613 bootloader start after 218 ms
RaspBee Bootloader premium
Vers. 1.02
build 201
00:47:06:616 GCF_ResetDeviceDone
00:47:06:619 bootloader v1 update firmware
3/08/01
 (54 ms)
3/08/01
STARTING (289 ms)
3/08/01
STARTING APP
 (292 ms)
could not sync with bootloader
root@core-deconz:/# 

Even after 10 attempts I always get the same error message could not sync with bootloader. Notice the communication does work as there are messages received from the bootloader, but there appears to be a timing problem here.

Curious about this I switched the same RaspBee I module onto another Raspberry Pi with a native Raspbian.

pi@raspberrypi:~ $ GCFFlasher_internal.bin -r -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26350500.bin.GCF 
GCFFlasher V3_16 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device RaspBee (RaspBee)
action: reset device RaspBee
wiringPi 2.50 initialized
RaspBee Bootloader premium
Vers. 1.02
uild 2013/ (52 ms)
uild 2013/08/01
 (52 ms)
uild 2013/08/01
R (390 ms)
uild 2013/08/01
RE (391 ms)
uild 2013/08/01
REA (391 ms)
uild 2013/08/01
READ (391 ms)
flashing 125732 bytes: |=============================|
verify: ....
SUCCESS

Here the firmware update went through fine in the first attempt.

So this might indeed be a timing issue, once the RaspBee I is in a state when there is no firmware installed (or a firmware update doesn’t succeed on the first try. Normally GCFFlasher recovers from that automatically due the -t 60 parameter (try for a minute).

I’m not sure if the different timing is caused by the virtualization or simply because my HassOS is under heavier load compared to the plain Pi with nothing really running on it.

The GCFFlasher internal state machine is already very fast, but perhaps the critical phase at 00:47:06:619 bootloader v1 update firmware can be tweaked a bit.

This should be working now in HA add-on with deCONZ v2.7.1, can anybody using this setup confirm?

The HA addon fucks up firmware updates now and then. read: Always

When is that bug going to be fixed on this end? As there is nothing in the Docker image of HA that influences this behavior.

Can we track that somewhere?

Didnt you say the functionality wasn’t broken? So now you do agree that it’s broken?

Wasn’t it my suggestion that you opened a issue on our git with related information on how to fix? Ah yes, I did before but you didn’t want to. You wanted to email.

Don’t worry, you don’t have to do anything. We got this covered. Should be included in next beta. Need you to fix something on your end then. But that’s fine right?

@mkai that’s worked for me thanks!