Zigbee-Schlüssel nach Wechsel des Mini-PCs erneut verbinden

Konfiguration
1

Hallo Entschuldigung für die Störung

Zuerst herzlichen Glückwunsch von einem Urgroßvater zur wundervollen Nachricht von der bevorstehenden Geburt Ihres Kindes.

Glückwunsch auch zu allen Fortschritten, das beeindruckt mich sehr …

Beim Wechsel des PCs, der Gladys hostet, komme ich nach der Neuinstallation dank der Backups von Gladys Plus nicht weiter mit der Reaktivierung des Sonoff-Schlüssels in zigbee2mqtt …

Fehler des Containers Zigbee2mqtt: Node-Fehler: write after end

Danke und einen schönen Tag

3

Hallo @mabille,

Ich habe mir erlaubt, deine Nachricht öffentlich zu machen. Vermeide es, mir solche Fragen privat zu schicken: Das kann anderen Nutzern helfen, und jeder im Forum kann dir weiterhelfen. Du hättest übrigens wahrscheinlich schneller eine Antwort bekommen, wenn du direkt öffentlich gepostet hättest :wink:

Vielen Dank für deine Glückwünsche und auch für deine Worte zu den Fortschritten von Gladys, das freut mich wirklich sehr!

Was dein Problem betrifft, bedeutet der Fehler Error: write after end im Zigbee2mqtt-Container fast immer, dass Zigbee2mqtt versucht, mit einem USB-Port zu kommunizieren, der nicht (oder nicht mehr) der deiner Sonoff-Schlüssel ist. Die Verbindung wird sofort geschlossen, und Zigbee2mqtt versucht weiterhin, darauf zu schreiben. Das kommt sehr häufig nach einem PC-Wechsel vor, da sich der Port, an dem der Schlüssel erkannt wird, oft von einer Maschine zur anderen ändert, während die Sicherung die alte Konfiguration wiederherstellt.

Ich empfehle dir, diese beiden Punkte in dieser Reihenfolge zu überprüfen:

1. USB-Port in Gladys neu auswählen

Gehe zu Einstellungen → Integrationen → Zigbee2mqtt → Konfiguration und schaue dir das Feld „USB-Port auswählen, an dem der Zigbee-Dongle eingesteckt ist“ an.

Selbst wenn bereits ein Port ausgewählt ist, wähle in der Liste erneut den aus, der zu deinem Schlüssel auf diesem neuen PC gehört, und speichere ihn. Gladys erstellt dann den Zigbee2mqtt-Container mit dem richtigen Gerät. Das ist der wichtigste Punkt, denn solange du nicht über diese Seite gehst, bleibt der alte Port erhalten.

Falls die Liste leer ist, bedeutet das, dass Gladys keinen Zugriff auf die USB-Ports des Geräts hat. In diesem Fall überprüfe, ob die Installation mit dem in der offiziellen Dokumentation angegebenen Befehl durchgeführt wurde: Bei einer manuellen Neuinstallation werden die Optionen für den Zugriff auf die Geräte manchmal vergessen.

2. Ausgewähltes Schlüsselmodell überprüfen

Gleich darunter ist das Feld „Modell des Zigbee-Dongles auswählen“ ebenso wichtig. Es bestimmt, wie Zigbee2mqtt mit dem Schlüssel kommuniziert.

Achtung, die beiden Sonoff-Modelle funktionieren nicht auf die gleiche Weise:

  • ZBDongle-P → SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P
  • ZBDongle-E → ITead Sonoff Zigbee 3.0 USB Dongle Plus V2 model "ZBDongle-E"

Falls das ausgewählte Modell nicht zu deinem Schlüssel passt, wird die Verbindung genau auf diese Weise scheitern.

Falls du eine ZBDongle-E verwendest, deren Firmware nie aktualisiert wurde, zeigt Gladys dir auf derselben Seite eine Warnung an. In diesem Fall wähle einfach den Eintrag ITead Sonoff Zigbee 3.0 USB Dongle Plus V2 model "ZBDongle-E" (legacy ezsp) aus: Es funktioniert, ohne dass du die Firmware aktualisieren musst.

Die gute Nachricht ist, dass, wenn du denselben Schlüssel wie zuvor verwendest, dein Zigbee-Netzwerk und alle deine Geräte genau so wiedergefunden werden. Du musst nichts neu paaren, sobald die Verbindung wiederhergestellt ist.

4

Danke für die Unannehmlichkeiten …

5

Hallo Obwohl der Dienst Z2M scheinbar wieder verbunden ist … eine Nachricht …

Fehler im Container Zigbee2MQTT: `[2026-09-21 08:44:48] error: zh:ezsp:uart: Can't send DATA frame (0,1,0): 1800012800 …

Danke

6

Hallo Jean-Jacques,

Kein Problem, und gute Neuigkeiten: Der Service ist wieder verbunden, das Schwierigste ist geschafft :slightly_smiling_face:

Dieser neue Fehler hat nichts mehr mit dem vorherigen zu tun: Er kommt vom Treiber, der für die Kommunikation mit deinem Schlüssel verwendet wird. Das Präfix zh:ezsp:uart zeigt an, dass Zigbee2mqtt den alten Treiber ezsp verwendet. Das ist sehr wahrscheinlich automatisch passiert: Bei einem Update hat Gladys die bestehenden ZBDongle-E-Konfigurationen in ... (legacy ezsp) umbenannt, um bestehende Installationen nicht zu beeinträchtigen. Allerdings ist dieser Treiber auf Seiten von Zigbee2mqtt heute veraltet und verursacht genau diese Art von Kommunikationsfehlern.

Was ich dir empfehle zu tun:

Gehe zurück zu Einstellungen → Integrationen → Zigbee2mqtt → Konfiguration, und wähle im Feld „Zigbee-Dongle-Modell auswählen“ den Eintrag ohne den Hinweis „(legacy ezsp)“, also:

ITead Sonoff Zigbee 3.0 USB Dongle Plus V2 model "ZBDongle-E"

Dann speichere. Gladys wird dann Zigbee2mqtt mit dem modernen Treiber (ember) neu starten, der viel stabiler und immer noch gewartet wird. Deine Zigbee-Geräte bleiben erhalten, es gibt nichts neu zu paaren.

Ein besonderer Fall: Dieser Treiber erfordert ein Schlüssel-Firmware in Version 7.4.x oder höher. Wenn dein Firmware älter ist, wird Gladys dich mit einer Warnung auf derselben Seite darauf hinweisen, und Zigbee2mqtt wird nicht starten. In diesem Fall musst du das Firmware des Schlüssels aktualisieren (das ist in wenigen Minuten von einem Windows-PC mit Chrome aus möglich).

Eine Frage nebenbei: Melden deine Zigbee-Geräte ihre Werte korrekt an Gladys (Temperaturen, Zustände, etc.)? Ich frage, weil Gladys die letzte Fehlerzeile aus den Container-Logs anzeigt, selbst wenn sie nicht blockierend ist. Wenn alles normal funktioniert, kann diese Meldung nur eine vorübergehende Warnung sein, aber der Wechsel auf den Treiber ember ist in jedem Fall die richtige Entscheidung.

Letzter Tipp, gültig für alle Zigbee-Schlüssel auf einem Mini-PC: Wenn du Geräteabbrüche bemerkst, schließe den Schlüssel an ein kurzes USB-Verlängerungskabel an, statt ihn direkt am Gehäuse anzuschließen, und wenn möglich an einen USB-2.0-Port. USB-3.0-Ports und die Nähe zum Gehäuse stören das 2,4-GHz-Signal stark.

7

Nochmals DANK, das Problem klärt sich auf … mir bleibt nur noch, das Firmware-Update durchzuführen … aber ich habe nur einen PC mit Mint zur Verfügung … und ich schaffe es nicht …

In der im Hinweis vorgeschlagenen Anleitung bin ich verloren und weiß nicht, welche Option ich wählen soll …

8

Am besten besuchst du diese Seite mit Google Chrome, Chromium oder Microsoft Edge: https://darkxst.github.io/silabs-firmware-builder/

Falls du Berechtigungsprobleme hast, musst du sicherstellen, dass dein Benutzer zur Gruppe dialout gehört

ansonsten sudo usermod -a -G dialout $USER

9

Danke, ich werde es mit Chromium testen, das ich installieren werde … Danke

10

Und wenn ich einen neuen Schlüssel kaufe, wäre er dann aktuell?

11

Logisch ja, aber Logik ist nie rational :frowning:
Du bist nicht sicher vor einer Schlüssel mit einem alten Firmware aus einem alten Lagerbestand.

12

Das kommt drauf an, bei wem, aber eher ja. Aber das ist eine einfache Operation, du schaffst das :flexed_biceps:

13

2026-09-21 17:39:37 emscripten zigpy.serial[42] INFO pyserial-asyncio-fast wird anstelle von pyserial-asyncio verwendet
2026-09-21 17:39:39 emscripten zigpy.appdb[42] DEBUG SQLite-Version für <webserial_transport.MockSqlite3 object at 0x16f41c0>: 3.31.1
2026-09-21 17:39:39 emscripten universal_silabs_flasher.flasher[42] INFO Prüfen von ApplicationType.GECKO_BOOTLOADER bei 115200 Baud
2026-09-21 17:40:22 emscripten zigpy.serial[42] INFO pyserial-asyncio-fast wird anstelle von pyserial-asyncio verwendet
2026-09-21 17:40:24 emscripten zigpy.appdb[42] DEBUG SQLite-Version für <webserial_transport.MockSqlite3 object at 0x1005f20>: 3.31.1
2026-09-21 17:40:24 emscripten universal_silabs_flasher.flasher[42] INFO Prüfen von ApplicationType.GECKO_BOOTLOADER bei 115200 Baud

das ist die Rückmeldung beim Versuch, unter Chromium zu aktualisieren

14

Der Flasher bleibt bei Probing ApplicationType.GECKO_BOOTLOADER hängen, da er den Schlüssel nicht in den Bootloader-Modus versetzen kann. Die häufigste Ursache: Der Zigbee2mqtt-Container läuft noch und hält den USB-Port offen, wodurch der Web-Flasher nicht exklusiv darauf zugreifen kann, um die Reset-Sequenz zu senden.

Bevor du das Flashen neu startest:

  1. Gehe in Gladys zu Einstellungen → Integrationen → Zigbee2mqtt und stoppe/deaktiviere die Integration (oder stoppe einfach Gladys).
  2. Trenne den Sonoff-Schlüssel vom USB-Port und schließe ihn erneut an.
  3. Gehe zurück zu https://darkxst.github.io/silabs-firmware-builder/ mit Chromium und starte die Portauswahl neu.

Falls es immer noch am gleichen Punkt hängen bleibt, nachdem Zigbee2mqtt gestoppt wurde, überprüfe auch, ob der richtige serielle Port im Tool ausgewählt ist (manchmal erscheinen mehrere Geräte /dev/ttyUSB*).

15

Danke für die Tipps, aber ich bin blockiert … selbst nachdem ich den Z2M-Dienst in Gladys gestoppt habe, wenn ich den Dongle wieder an den Laptop mit Mint anschließe und in Chromium das Update nicht durchläuft, mit denselben Logs …

Ist meine Methode vielleicht nicht richtig?

16

Hast du den Dongle wirklich ein- und ausgeschaltet? Bist du sicher, dass du die richtige Option wählst, wenn du auf „Verbinden“ klickst?
Ich habe diese exakt gleiche Seite verwendet, um meinen Dongle zu aktualisieren (aber unter Mac/Chrome).

17

Das Chromium, das ich installiert habe, ist auf meinem Mint-Laptop … nicht auf Gladys … ist das richtig?

18

Danke für eure Hilfe, aber jetzt muss ich mich erstmal ausruhen… Die Nacht bringt Rat… Morgen, falls ich es nicht schaffe und bevor ich in einen neueren Dongle investiere, baue ich ihn auseinander und versuche den physischen Bootloader

Nochmals danke

19

Vielleicht eine dumme Frage, aber bist du dir sicher, dass du den Sonoff E und nicht den P hast? Sie sehen sich sehr ähnlich…

20

Ja, es gibt einen BOOT-Knopf, wenn du öffnest. Gute Nacht