Posts Tagged ‘ConBee II’

Montag, 3. Juli 2023

ConBee II USB-Stick wird nach Debian-Update nicht mehr erkannt

Link zu diesem Artikel

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

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 22. Mai 2022

Xiaomi Aqara Temperatursensoren gehen immer wieder verloren

Link zu diesem Artikel

Mein Haus ist voll mit kleinen quadratischen Xiaomi Aqara Temperatursensoren (Produktnummer: WSDCGQ11LM), die man auf Ali Express für etwa 15 Franken pro Stück kauft. Die Sensoren werden mit einer Knopfbatterie ausgestattet, die monatelang hält.

Etwa die Hälfte davon ist mit einem Aqara Hub verbunden, die andere Hälfte habe ich inzwischen auf einen Deconz Conbee II USB-Stick migriert, welcher an einem Linux-Server hängt.

Die Sensoren kommunizieren mit dem ZigBee-Standard.

Leider kommt es alle paar Wochen wieder vor, dass einer oder mehrere der am weitesten vom Hub resp. dem Linux-Server entfernten Sensoren „verloren“ gehen, das heisst plötzlich aufhören, periodisch Messwerte zu senden.

Da dies immer wieder passiert, habe ich ein Script geschrieben, dass mich alarmiert, wenn die letzte Messwertmeldung eines Sensor mehrere Stunden zurückliegt.

Ist dies der Fall, muss ich den Sensor neu mit deCONZ verbinden, indem ich den Reset-Knopf am Sensor mit einem japanischen Ess-Stäbchen mehrere Sekunden lang gedrückt halte, bis die LED des Sensors mehrfach blinkt. Danach noch ein kurzer Tipper auf den Reset-Knopf, und dann ist der Sensor wieder mit deCONZ gepaart.

Nichtsdestotrotz: Das nervt. Gewaltig.

Das Problem ist im Netz bekannt:

The Xiaomi/Aqara sensors use a non-standard zigbee protocol, where the time between check-ins is longer than most. For a lot of zigbee repeaters, the time is just longer than the threshold, so the devices get dropped from the network when they don’t check in “on time”. […] Xiaomi/Aqara devices enter “test mode” for the first couple hours after pairing, where they send data every 3-5 seconds rather than on events or at regular ~1hr check ins. I am in the habit of pairing any battery operated sensors in close proximity to the hub, and leaving them very close to the hub for a few hours after pairing to ensure proper communication and connection after the test mode ends.

My guess is that your sensor is connected to a repeater that doesn’t like the long time between check-ins, and is happy with the sensor while it’s in test mode, but drops it from the network after that.

Quelle: Xiaomi aqara loosing connection every couple hrs

Philips Hue und IKEA Tradfri Repeater helfen nichts

Spannend dabei ist, dass ich in jedem Zimmer mindestens eine Philips Hue Deckenlampe montiert habe, welche — da kabelgebunden — als ZigBee-Repeater funktionieren. Zudem habe ich in der Stube, welche luftlinienmässig am weitesten vom DeCONZ-Server entfernt ist, auch noch einen IKEA Tradfri ZigBee-Repeater installiert. Leider bringen diese Repeater in meinem Fall offenbar rein gar nichts.

WLAN-Interferenzen?

Eine mögliche Lösung könnte sein, den WLAN-Kanal zu ändern: FAQ: What WiFi Channel is least likely to interfere with SmartThings? Das möchte ich aber nicht ausprobieren, da ich mein Ubiquiti UniFi-WLAN-Netzwerk solche Parameter selber regeln lasse, und bis jetzt eine äusserst gute WLAN-Qualität hatte.

Neue Hardware?

Mittlerweile bin ich soweit, Xiaomi Aqara den Rücken zu kehren und Sensoren einer anderen Marke zu kaufen, falls sich diese in etwa im selben Preisrahmen bewegen, und stabiler sind.

Leider listet die offizielle Kompatibilitäs-Seite keine Alternativen für reine Temperatur- und Feuchtigkeitssensoren.

Eine inoffizielle Liste ist deutlich grösser.

Bei einer Google-Suche wurde mir der SONOFF WLAN-Luftfeuchte- und Temperatursensor SNZB-02 ZigBee für 12.45 CHF (Brack) präsentiert. Nach anfänglichen Problemen scheinen diese Sensoren gemäss Foren-Beiträgen nun mit deCONZ zu funktionieren. Ich werde mir mal ein Testprodukt bestellen.

Andere potentielle Kandidaten, welche ich auf die Schnelle nicht in Schweizer Shops gefunden habe:

  • Develco Temperature and Humidity Sensor HMSZB-110
  • Rehent Temperature and Humidity Sensor RH-ZTH1
  • Zemismart Temperature and Humidity Sensor ZXZTH

Nachtrag

Gestern, am 4. Januar 2023, sind auf einen Schlag drei Sonoff SNZB-02 Sensoren, welche ich mittlerweile im Haushalt betreibe, fast gleichzeitig stumm gegangen. Die Sensoren waren seit dem 7. Oktober 2022 aktiv und haben täglich zwischen 500 und 600 Mal Werte gesendet. Ein anderer Sonoff Sensor funkt munter weiter. Im DeCONZ Phoscon-Tool werden die Sensoren als offline angezeigt.

Ich habe die Sensoren ins Büro (in die Nähe des Conbee Sticks) gebracht und danach mit DeCONZ Phoscon neu gepaired: DeCONZ Phoscon in den Pairing-Modus schalten (Add new sensor > Other), Druck auf den Reset-Button, bis die rote LED dreimal durch das Gehäuse blinkt, Button loslassen, Sensor auf Tisch ablegen, und 10-15 Sekunden später färbt sich der Modaldialog in DeCONZ Phoscon grün. Ich werde die Sensoren nun über Nacht auf dem Schreibtisch belassen, und morgen — sofern sie immer noch Kontakt haben — wieder an ihren angestammten Ort hinterlegen.

Tags: , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen