Montag, 3. Juli 2023
Nach einer Stunde debugging, USB-Stick ausstöpseln, einstöpseln und dutzende Male Firmware flashen entdecke ich endlich After a sudo apt update && sudo apt full-upgrade and a reboot deconz no longer connects to the conbee 2:
Das heute Vormittag eingespielte Debian-Update löscht /dev/serial/by-id/*. Dies verhindert offenbar, dass deCONZ Phoscon den USB-Stick findet. Das Problem erkennt man auch daran, dass folgender Befehl nichts findet:
# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------+--------+---------+------------+-------
Auf einem Raspberry Pi mit existierendem /dev/serial/by-id/* schaut das hingegen noch so aus:
# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------+--------+---------+------------+-------
/dev/ttyAMA0 | 0x0000 | 0x0000 | | RaspBee
/dev/ttyACM0 | 0x1CF1 | 0x0030 | DE1234567 | ConBee II
Die Lösung: In deconz.service einfach noch das USB-Device mitgeben: ExecStart=/usr/bin/deCONZ ... --dev=/dev/ttyACM0. ttyACM0 ersetzt man mit dem tatsächlichen Device (findet man mittels dmesg gleich nachdem man es eingestöpselt hat).
Danach den Service stoppen, neu starten — und dann sollte die ZigBee-Welt wieder in Ordnung sein (der Ausfall des USB-Sticks während zwölf Stunden machte es nötig, dass ich bei vielen Sensoren kurz den Knopf manuell drücken musste, um sicherzustellen, dass die Verbindung und Datenanlieferung noch funktioniert …)
Wichtig: dmesg muss den USB-Stick erkennen …
...
[55209365.334638] usb 2-3: new full-speed USB device number 15 using xhci_hcd
[55209365.488837] usb 2-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[55209365.493029] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[55209365.497062] usb 2-3: Product: ConBee II
[55209365.501528] usb 2-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[55209365.505835] usb 2-3: SerialNumber: DE1234567
[55209365.512617] cdc_acm 2-3:1.0: ttyACM3: USB ACM device
...
… und mit lsusb muss er auch aufgeführt sein — sonst könnte ein anderes Problem vorliegen:
...
Bus 002 Device 013: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
...
In der Zwischenzeit hatte ich alles ausprobiert, insbesondere dutzende Male das Firmware geflashed. Hierzu habe ich die ZIP-Datei des neuesten (Beta) Release 4.0.4 von gcfflasher heruntergeladen und auf zwei Linux-PCs sowie macOS entpackt.
Um den Flasher zu kompilieren, installiert man unter Debian zuerst die benötigten Pakete (unter macOS geht’s gleich weiter zur Kompilation):
# apt-get install pkg-config build-essential libgpiod-dev
Danach kompiliert man das Binary:
./build_posix.sh
Anschliessend lädt man die neueste Firmware vom offiziellen Server in das Flasher-Verzeichnis herunter, und gibt dann unter Linux ein:
# ./GCFFlasher -d /dev/ttyACM3 -t 60 -f ./deCONZ_ConBeeII_0x26780700.bin.GCF
Unter macOS lautete der Befehl:
# ./GCFFlasher -d /dev/cu.usbmodemDE1234567 -t 60 -f ~/tmp/deCONZ_ConBeeII_0x26780700.bin.GCF
Auch hier wieder beachten, das effektive Device (unter Linux war es bei mir auf einem Laptop /dev/ttyACM0, auf dem anderen /dev/ttyACM3; unter macOS war es /dev/cu.usbmodemDE24421441) mitzugeben. Dass der Flasher richtig funktioniert, seht ihr, wenn folgende Ausgabe erscheint:
read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written
Manchmal auch
read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
bootloader syned: unlock! READY
100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written
Den Diskussionsforen entnehme ich zudem, dass es vorkommen kann, dass das System den USB-Stick „vergisst“. In dem Fall startet man den Firmware-Update-Befehl bevor man den USB-Stick überhaupt eingestöpselt hat. Während sich die Meldungen à la retry connect bootloader /dev/cu.usbmodemDE1234567 auf dem Bildschirm stapeln, stöpselt man den USB-Stick ein, und dann sollte das Firmware-Update umgehend beginnen.
Links
