I’m using deCONZ 2.12.6 (GUI) and a RaspBee II on an RPi4 (5.10.60-v7l+). A few weeks ago, the zigbee network stopped working and the GUI told me that a firmware update is needed. I’ve confirmed it and a few minutes later, everything was working again but it happens again every few days.
So I’ve double checked that I’m on the latest version (RaspBee FW 0x26720700) but also tried to do a manual update:
sudo systemctl stop deconz-gui
sudo GCFFlasher_internal -t 90 -d /dev/ttyAMA0 -R 5 -x 1 -f deCONZ_RaspBeeII_0x26720700.bin.GCF
This resulted in a strange error/warning:
10:04:18:990 SLIP RX frame length: 8
10:04:18:990 bootloader v3 data request, offset: 163840, length: 256
10:04:18:990 bootloader v3 send data response, status: 0, offset: 163840, length: 256
10:04:19:071 SLIP RX frame length: 8
10:04:19:071 bootloader v3 data request, offset: 164096, length: 131
10:04:19:072 bootloader v3 send data response, status: 0, offset: 164096, length: 131
10:04:19:072 bootloader v3 finished all data
|10:04:20:124 verify application is running
10:04:22:128 failed to query application
and again, the deCONZ application started to shut down the network a few days later, forcing me to do a firmware update.
Am I missing something here?
The -d /dev/ttyAMA0 option is for the USB device ConBee II. Can you try it this command:
sudo GCFFlasher_internal -t 60 -f deCONZ_RaspBeeII_0x26710700.bin.GCF
For the -R and -t options, one of these should be enough.
I’ve already tried this command (exactly as it’s written in the wiki) and the result was the same.
sudo GCFFlasher_internal -l
my device is indeed /dev/ttyAMA0:
Path | Vendor | Product | Serial | Type
/dev/ttyUSB0 | 0x0403 | 0x6001 | AL4YQ1KO | Generic FTDI
/dev/ttyAMA0 | 0x0000 | 0x0000 | | RaspBee
We’ve had reports that deleting the packaged firmware files ceases the blocking GUI. So you might want to try removing the files from
Ok, there were some firmwares in that folder. Cleaned it and tried to update to the latest firmware. It seems to finish, although it still complains about the application query (see my 1st post).
Anyway, I’ll keep an eye on the gui. Hopefully it won’t forces me to repeat the update in the middle of the night…
Just to be clear here: The GUI is deconz and not Phoscon (being a web app and a REST API client for deconz).
I understood you got the notifications from deconz GUI. If you’ve tried to update the firmware all the time through Phoscon, then you should do it on the OS via GCFflasher.
Sorry for mixing up the names. I was always talking about the deCONZ user interface or, better said, a shell on the system running it.
And yes, I was always using GCFFlasher_internal.
After two weeks of testing, it seems to be stable now. Thanks @Swoop for telling me to remove the old files!
Great that it now works again. It would be interesting, however, to understand why that helps and what the root cause is.