seltsam ja. Ich habe noch keinen „Zigbee“-Schlüssel und das Gladys-Bild startet ohne Probleme neu.
Das, was ich daran nicht verstehe, ist, dass ich Alex einen Raspberry Pi 3B mit einem 64-Bit-Image für die Entwicklung mit einem Zigbee-Dongle zur Verfügung gestellt habe, ohne Probleme mit USB/Zigbee.
Der gemeinsame Punkt (meiner Meinung nach) zwischen allen, die Probleme haben, ist der Sonoff-Dongle.
Hallo zusammen und ein frohes neues Jahr.
Bei mir war es genauso, ich hatte nie Probleme mit dem Zigbee-Stick und meinem Rpi in 3b+ in 64-Bit, aber große Probleme mit dem Bluetooth. Seit ich auf 32-Bit umgestiegen bin, gibt es keine Bluetooth-Probleme mehr und alles funktioniert einwandfrei. Vielleicht hilft das ja? 
ich weiß nicht, ob das hilft, aber es scheint zwei Arten von Sonoff-Schlüsseln zu geben … in Bezug auf die Referenzen:
P → Texas Instrument
E → SiliconLabs
Phil
bon, ich habe gerade auf einem 32-Bit-Bild getestet und… 
immer noch das Gleiche
Um mein Kommando ls -l /dev/serial/by-id/ zu unterstützen =>
usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_723abadaef21ec1181a720c32c86906c-if00-port0 → ../../ttyUSB0
für die Schlüsselauswahl gesehen
/dev/ttyUSB0 - iTead -10 c4
/dev/ttyAMA0
Auf meinem Pi 3B+ hatte ich diesen Fehler nie, ich hatte eher „Unterspannung“ und „Error SYS - Ping nach 6000ms“ mit dem Zigbee-Schlüssel CC2652R.
Es ist schon verwirrend zu sehen, dass der Schlüssel auf anderen Systemen funktioniert und nicht hier.
Hallo
Auf deinem Screenshot sehe ich, dass du den Port /dev/ttyAMA0 ausgewählt hast, obwohl dein Kopieren und Einfügen zeigt, dass dein Sonoff-Schlüssel auf dem Port /dev/ttyUSB0 ist. Hast du den Port /dev/ttyUSB0 ausgewählt?
Ach, eine kleine Präzisierung: Ich bin auf die 32-Bit-Version umgestiegen, habe den Pi neu gestartet und keine Probleme mehr. Ich habe einen Pi 3B.
Ich hatte in der Vergangenheit versucht, eine Installation auf einer Freebox-Delta-VM durchzuführen, und das war auch ein Albtraum…
die zwei superhääääääääääääääääse 
Der wird’s mal haben, den werden wir mal haben 
Ich habe kein Sonoff
Bei mir, wenn ich den dmesg ausführe, bin ich wie du auf /dev/ttyUSB0, also musst du auf dem USB0-Port und nicht auf AMA0 sein. Mir ist das einmal passiert, dass die Verbindung zwischen Gladys MQTT und ZigBeeMQTT nicht mehr funktioniert hat. Ich habe den Ordner zigbee2mqtt in « /var/lib/gladysassistant/ » gelöscht und den PI neu gestartet. Dann bin ich zurück in die MQTT-Dienstkonfiguration gegangen und habe auf „ZigBee-Dienst aktivieren“ geklickt, und alles hat wieder funktioniert. Man muss nur ein wenig warten, bis alles verbunden ist (allerdings musst du danach alle deine Geräte neu verbinden).
Ich denke, dass für cce66 der Schlüssel funktioniert, da er am USB0-Port erkannt wird. Itead -10c4 ist der Name des Schlüssels
Ich hatte die beiden Schlüssel, die Sonoff auf meiner Produktionsinstanz und die CC2652R.
Ich hatte Probleme mit beiden.
Seitdem bin ich auf einen Mini-PC mit der Sonoff umgestiegen, ich habe keine Probleme mehr.
Ich sollte mit der CC2652R auf dem verbleibenden Pi 3b+ testen.
Auf derselben Hardware, aber mit HA, habe ich diese Parameter und es funktioniert
"serial": {
"disable_led": false,
"port": "/dev/ttyUSB0"
Bei Gladys wird dies in der Anzeige abgerufen und es funktioniert nicht
/dev/ttyUSB0 - iTead -10 c4
Vielleicht eine Spur, der man nachgehen sollte? Wo ist dieser Parameter in der Gladys-Oberfläche eingetragen? In einer Datenbank? In einer Datei? Im Gladys-Container?
vielleicht funktioniert die USB-Portweiterleitung je nachdem, ob man auf dem PI oder dem NUC ist, anders?
Genau! Das Problem ist: Ist das der erwartete Name und nicht nur /dev/ttyUSB0?
Ich habe die gleichen Probleme, die auch anderswo in « Hilfe zur Konfiguration von Zigbee2mqtt » erwähnt werden.
Ich habe alles ersetzt, außer dem Pi, auf den ich Ende Januar warte.