ConBee 2 wird nicht erkannt: Stick, Port und Berechtigungen prüfen

Der ConBee steckt im USB-Anschluss, deCONZ läuft, und in Phoscon steht trotzdem, dass kein Gateway gefunden wurde. Das ist der Punkt, an dem die meisten hängenbleiben. Die Ursache liegt fast immer an einer von fünf Stellen, und die lassen sich der Reihe nach abarbeiten.

Wichtig ist die Reihenfolge. Wer mit der Firmware anfängt, obwohl das Betriebssystem den Stick gar nicht sieht, sucht an der falschen Stelle.

Schritt 1: Sieht der Rechner den Stick überhaupt?

Die erste Frage ist die grundlegendste. Kommt der Stick auf der USB-Ebene an?

lsusb

In der Liste muss eine Zeile mit der Kennung 1cf1:0030 auftauchen. Je nach System steht dahinter „dresden elektronik ingenieurtechnik GmbH ConBee II“ oder „Dresden Elektronik ZigBee gateway“.

Fehlt die Zeile, ist das Problem rein elektrisch. Dann hilft nur ein anderer Anschluss, ein anderes Kabel oder ein anderer Rechner. Software-Einstellungen ändern daran nichts.

Aufschlussreicher ist der Blick ins Systemprotokoll, während der Stick eingesteckt wird:

sudo dmesg -w

Beim Einstecken sollten Zeilen zu cdc_acm und zu einem neuen Gerät erscheinen. Kommen dort stattdessen Meldungen über wiederholtes An- und Abmelden, liegt ein Stromversorgungs- oder Störungsproblem vor. Dazu unten mehr.

Schritt 2: Welches Gerät ist entstanden?

Hier lauert der erste echte Stolperstein, und er betrifft alle, die ihren Stick gewechselt haben.

Der ConBee II meldet sich als /dev/ttyACM0. Der ConBee III dagegen als /dev/ttyUSB0, weil er einen anderen seriellen Wandler nutzt. Wer eine Anleitung für den ConBee II befolgt und einen ConBee III betreibt, trägt den falschen Pfad ein und wundert sich.

Prüfen lässt sich das so:

ls -l /dev/ttyACM* /dev/ttyUSB*

Warum die Nummer die falsche Adresse ist

Die Zählung nach ttyACM0, ttyACM1 und so weiter vergibt der Kernel in der Reihenfolge, in der Geräte auftauchen. Steckt ein zweiter serieller Adapter am Rechner, kann der ConBee nach einem Neustart plötzlich die andere Nummer haben. Dann läuft deCONZ gegen ein Gerät, das etwas ganz anderes ist.

Die stabile Adresse steht woanders:

ls -l /dev/serial/by-id/

Dort erscheint ein Name, der die Seriennummer des Sticks enthält, beim ConBee II etwa usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE1234567-if00. Dieser Name bleibt gleich, egal an welchem Anschluss der Stick steckt und in welcher Reihenfolge der Rechner startet.

Diesen Pfad trägt man überall ein, wo nach dem Gerät gefragt wird. Das ist der einzige Weg, der auf Dauer hält.

Schritt 3: Darf der Benutzer darauf zugreifen?

Das Gerät ist da, deCONZ kommt trotzdem nicht heran. Dann fehlen meistens die Rechte.

ls -l /dev/ttyACM0

Die Ausgabe sollte als Gruppe dialout zeigen. Steht dort etwas anderes, etwa audio, hat eine falsche Regel zugeschlagen.

Der Benutzer, unter dem deCONZ läuft, muss Mitglied dieser Gruppe sein:

sudo usermod -aG dialout $USER
groups

Der entscheidende Punkt kommt danach. Die neue Gruppenzugehörigkeit greift erst nach einer neuen Anmeldung. Ein einfacher Neustart des Dienstes reicht nicht. Im Zweifel den ganzen Rechner neu starten, das erspart eine lange Fehlersuche.

Schritt 4: Der ModemManager, die klassische Ursache

Das ist der Klassiker unter Debian und Ubuntu, und er kostet regelmäßig einen ganzen Abend.

Der ModemManager ist ein Dienst, der nach Mobilfunkmodems sucht. Taucht ein neues serielles Gerät auf, greift er danach und schickt Befehle hin, um herauszufinden, ob es ein Modem ist. Genau in diesem Moment will deCONZ ebenfalls auf den Stick zugreifen, und zwei Programme auf derselben Schnittstelle vertragen sich nicht.

Das Ergebnis sieht aus wie ein defekter Stick. Die Verbindung bricht ab, das Gerät gilt als belegt, oder die Firmware meldet sich als nicht verbunden.

Ob der Dienst läuft:

systemctl status ModemManager

Wer kein Mobilfunkmodem betreibt, braucht ihn nicht:

sudo systemctl stop ModemManager
sudo systemctl disable ModemManager
sudo apt remove modemmanager

Das Deinstallieren ist dem bloßen Abschalten vorzuziehen, weil der Dienst sonst bei der nächsten Systemaktualisierung wieder aktiv werden kann.

Schritt 5: USB 3.0 stört den Zigbee-Empfang

Dieser Punkt ist anders gelagert. Der Stick wird erkannt, deCONZ verbindet sich, und trotzdem funktioniert nichts richtig. Geräte lassen sich nicht anlernen, die Reichweite ist lächerlich gering, oder die Verbindung bricht immer wieder ab.

Die Ursache ist physikalisch. USB-3.0-Anschlüsse und deren Kabel senden Störstrahlung im Bereich um 2,4 Gigahertz, und genau dort funkt Zigbee. Ein Stick, der direkt neben einer USB-3-Buchse oder auf einem Rechnergehäuse sitzt, arbeitet unter Dauerbeschuss.

Die Lösung kostet wenige Euro. Ein USB-2.0-Verlängerungskabel von einem bis zwei Metern bringt den Stick vom Gehäuse weg. Das ist keine Bastellösung, sondern die Empfehlung, die dresden elektronik selbst ausspricht.

Drei Dinge dabei beachten: Der Stick gehört möglichst an einen USB-2.0-Anschluss, nicht an einen blauen USB-3-Port. Die Verlängerung sollte kein USB-3-Kabel sein. Und der Stick gehört weg von Netzteilen, Festplatten und WLAN-Antennen.

Wer bereits eine Verlängerung nutzt und weiter Probleme hat, kann als Nächstes den Zigbee-Kanal wechseln. Wie das mit der Reichweite zusammenhängt, steht im Beitrag zu Reichweite erhöhen.

Schritt 6: Firmware prüfen und aktualisieren

Meldet Phoscon den Stick als verbunden, aber ohne Firmware, oder steht dort eine Version, die zur deCONZ-Fassung nicht passt, ist ein Firmware-Update fällig.

Dafür liefert dresden elektronik den GCFFlasher mit. In der aktuellen Reihe heißt das Programm GCFFlasher, ältere deCONZ-Fassungen brachten es als GCFFlasher_internal mit. Es unterstützt ConBee I, II und III sowie die RaspBee-Module.

Vor dem Flashen muss deCONZ beendet werden, sonst hält es die Schnittstelle belegt:

sudo systemctl stop deconz
GCFFlasher -l

Die Liste zeigt die gefundenen Geräte samt Pfad. Taucht der Stick hier auf, ist er grundsätzlich ansprechbar, und das ist schon eine wichtige Erkenntnis. Die passende Firmwaredatei holt man von dresden elektronik und spielt sie mit dem angezeigten Gerätepfad ein.

Ein Hinweis aus der Praxis: Wenn das Flashen scheitert, läuft in neun von zehn Fällen noch der ModemManager. Siehe Schritt 4.

Wenn deCONZ in einem Container läuft

Sobald Virtualisierung ins Spiel kommt, verschiebt sich das Problem. Der Stick wird auf dem Wirtssystem erkannt, im Container fehlt er trotzdem.

Docker

Der Container braucht das Gerät ausdrücklich. Wichtig ist auch hier der stabile Pfad:

--device=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE1234567-if00:/dev/ttyACM0

Links steht der echte Pfad auf dem Wirt, rechts der Name, unter dem das Gerät im Container erscheint. Die Seriennummer im Beispiel ist durch die eigene zu ersetzen.

Proxmox mit LXC-Container

Über die Weboberfläche geht das nicht, die Konfigurationsdatei des Containers muss von Hand ergänzt werden. Zwei Zeilen sind nötig, eine für die Freigabe der Gerätekategorie und eine für die Einblendung.

lxc.cgroup2.devices.allow: c 166:* rwm
lxc.mount.entry: /dev/serial/by-id/usb-..._ConBee_II_DE1234567-if00 dev/ttyACM0 none bind,optional,create=file

Die 166 steht für Geräte der Art ttyACM. Beim ConBee III mit seinem ttyUSB lautet die Zahl 188. Wer diese Zeile vom ConBee II übernimmt, ohne sie anzupassen, bekommt ein Gerät ohne Zugriffsrechte.

Bei der Einblendung darf nur der Name der Verknüpfung stehen, nicht der Teil mit dem Pfeil auf das Zielgerät, den ls -l mit ausgibt.

Home Assistant OS

Hier ist es am einfachsten, weil das System den Stick selbst durchreicht. In den Einstellungen des deCONZ-Add-ons oder bei der Einrichtung der Integration erscheint eine Auswahlliste mit den gefundenen Geräten.

Zwei Punkte führen trotzdem zu Ärger. Wählt man dort den Pfad mit der Nummer statt den langen Namen mit der Seriennummer, kann er sich nach einem Neustart verschieben. Und wenn schon eine andere Integration den Stick belegt, etwa ZHA parallel zu deCONZ, bekommt die zweite nichts. Immer nur ein Dienst darf auf den Stick zugreifen.

ConBee II oder ConBee III

Beide Sticks laufen mit deCONZ und Phoscon, in der Fehlersuche unterscheiden sie sich aber an drei Stellen.

• Der Gerätepfad. ConBee II wird zu ttyACM0, ConBee III zu ttyUSB0. Das betrifft jede Konfigurationsdatei und jede Container-Einstellung.
• Die Firmware. Für den ConBee III gibt es neben dem GCFFlasher auch eine Aktualisierung über eine Weboberfläche, was die Sache vereinfacht.
• Thread. Der ConBee III bringt eine eigene Firmware für Thread und Matter mit. Beim ConBee II ist das bestenfalls ein Versuchsfeld.

Für einen Neukauf ist der ConBee III die naheliegende Wahl. Wer einen ConBee II im Einsatz hat, muss deswegen nicht wechseln. Das Zigbee-Netz läuft damit unverändert gut.

Die Prüfliste in Kurzform

1. lsusb zeigt 1cf1:0030. Wenn nicht: anderer Anschluss, anderes Kabel.
2. ls -l /dev/serial/by-id/ zeigt den Stick. Diesen Pfad überall eintragen.
3. Der Benutzer ist in der Gruppe dialout und hat sich danach neu angemeldet.
4. Der ModemManager ist entfernt.
5. Der Stick hängt an einer USB-2.0-Verlängerung, weg vom Gehäuse.
6. GCFFlasher -l findet ihn, deCONZ ist dabei gestoppt.
7. Im Container ist das Gerät durchgereicht, mit der richtigen Gerätenummer.
8. Nur ein einziger Dienst greift auf den Stick zu.

Weiterlesen in der ConBee-Reihe

Läuft der Stick wieder, geht es hier weiter. Der Einstieg ist Teil 1 mit der Installation auf dem Raspberry Pi, in dem der komplette Aufbau von vorn beschrieben ist.

• Teil 1: Installation auf Raspberry Pi
• Teil 2: Anlernen von Geräten
• Teil 3: Steuerungen erstellen
• Teil 4: Integration in ioBroker
• Teil 5: Xiaomi Button in ioBroker
• Teil 6: Reichweite erhöhen
• Teil 7: IKEA Tradfri Fernsteuerung
• Teil 8: Aqara Switch und Events
• Teil 9: IKEA Tradfri Bewegungsmelder
• Teil 10: Tuya Temperatur- und Luftfeuchtigkeitssensor
• Teil 11: IKEA Tradfri Dimmer
• Teil 12: IKEA Tradfri E27 Leuchtmittel

Fazit

Ein ConBee, der nicht erkannt wird, ist selten defekt. In den allermeisten Fällen sind es der ModemManager, eine fehlende Gruppenzugehörigkeit oder ein Gerätepfad, der sich nach einem Neustart verschoben hat.

Wer von Anfang an den Pfad unter /dev/serial/by-id/ verwendet und den ModemManager entfernt, hat zwei der drei häufigsten Ursachen ausgeschlossen, bevor sie auftreten. Die Verlängerung gegen die Störstrahlung kostet dazu drei Euro und erspart später die Suche nach einem Reichweitenproblem, das gar keines ist.

Transparenzhinweis: Die Amazon-Links in diesem Artikel sind Partnerlinks. Wenn Sie darüber bestellen, erhalten wir eine kleine Provision. Für Sie ändert sich am Preis nichts.