Zigbee - Firmware-Update von ezsp zu Ember

Top, vielen Dank!

Aber wenn ich das richtig verstehe, funktioniert das nur für einen bestehenden Benutzer, der zu Ember wechseln möchte?

Ein neuer Benutzer, der Ember mit einem Schlüssel auf einem älteren Firmware auswählt, wird diese Warnung nicht erhalten, weil Zigbee2mqtt niemals starten wird, oder?

Ja, du hast recht. Ich werde die Logs prüfen, um die Nachricht zu erkennen und anzuzeigen.

So decken wir alle Szenarien ab.

Meiner Meinung nach kann man diese Art von Logs ganz einfach erkennen!

Langfristig könnten wir sogar die häufigsten Fehler erkennen, die man auf diesem Forum sieht, um dem Benutzer noch mehr Transparenz zu bieten.

Hallo,

Ich habe die Logs-Lektüre (wie bei den Updates) implementiert und ein Image gebaut.
Ich kann unseren spezifischen Fall nicht testen (da mein Dongle auf dem neuesten Stand ist), aber ich werde einige Tests mit anderen Mustern in den Logs durchführen.

Die AI-Rezension hat einige Rückmeldungen zu fehlenden Resets gegeben und ich denke, die Testabdeckung ist nicht perfekt. Ich kümmere mich darum.

Möchtest du auf den vollständigen PR warten oder schon den ersten Teil (ohne die Logs) ausliefern?

Das ist für mich in Ordnung (Abdeckung und PR-Rückmeldungen). Es bleibt noch zu testen :thinking:

Danke @cicoub13, ich werde es testen!

Kleine Frage:

Ich habe einen Sonoff-Dongle, der nie aktualisiert wurde. In welcher Reihenfolge muss ich das machen?

@cicoub13 Ich habe es gerade getestet und sehe keine Nachrichten in der UI :confused:

Der API-Status-Call gibt zurück:

{
    "usbConfigured": true,
    "mqttExist": true,
    "mqttRunning": true,
    "zigbee2mqttExist": true,
    "zigbee2mqttRunning": true,
    "gladysConnected": false,
    "zigbee2mqttConnected": false,
    "z2mEnabled": true,
    "dockerBased": true,
    "networkModeValid": true,
    "coordinatorFirmware": {
        "maintrel": "1 ",
        "majorrel": "7",
        "minorrel": "3",
        "product": 12,
        "revision": "7.3.1.0 build 176",
        "type": "EZSP v12"
    },
    "z2mContainerError": null
}

Die Zigbee2mqtt-Logs:

Starting Zigbee2MQTT without watchdog.
[2026-02-24 17:19:21] info: 	z2m: Logging to console, file (filename: log.log)
[2026-02-24 17:19:21] info: 	z2m: Starting Zigbee2MQTT version 2.7.1 (commit #6d30fa156cf208189edbbd7db8422a6fc657fb9e
)
[2026-02-24 17:19:21] info: 	z2m: Starting zigbee-herdsman (7.0.4)
[2026-02-24 17:19:21] info: 	zh:ember: Using default stack config.
[2026-02-24 17:19:21] info: 	zh:ember: ======== Ember Adapter Starting ========
[2026-02-24 17:19:21] info: 	zh:ember:ezsp: ======== EZSP starting ========
[2026-02-24 17:19:21] info: 	zh:ember:uart:ash: ======== ASH Adapter reset ========
[2026-02-24 17:19:21] info: 	zh:ember:uart:ash: RTS/CTS config is off, enabling software flow control.
[2026-02-24 17:19:21] info: 	zh:ember:uart:ash: Serial port opened
[2026-02-24 17:19:21] info: 	zh:ember:uart:ash: ======== ASH starting ========
[2026-02-24 17:19:22] info: 	zh:ember:uart:ash: ======== ASH connected ========
[2026-02-24 17:19:22] info: 	zh:ember:uart:ash: ======== ASH started ========
[2026-02-24 17:19:22] info: 	zh:ember:ezsp: ======== EZSP started ========
[2026-02-24 17:19:22] error: 	z2m: Error while starting zigbee-herdsman
[2026-02-24 17:19:22] error: 	z2m: Failed to start zigbee-herdsman
[2026-02-24 17:19:22] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-02-24 17:19:22] error: 	z2m: Exiting...
[2026-02-24 17:19:22] error: 	z2m: Error: Adapter EZSP protocol version (12) is not supported by Host [13-18].
    at EmberAdapter.emberVersion (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1408:19)
    at EmberAdapter.initEzsp (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:670:9)
    at EmberAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1539:24)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/controller/controller.ts:143:29)
    at Zigbee.start (/app/lib/zigbee.ts:70:27)
    at Controller.start (/app/lib/controller.ts:101:13)
    at start (/app/index.js:149:5)

Logisch, ich habe readZ2mContainerLogs nur bei der Container-Installation hinzugefügt :man_facepalming:

Ich füge es an einer anderen Stelle hinzu

Das Gladys-Update zerstört keine bestehenden Installationen, aber wenn du auf den neuen Treiber migrieren möchtest:

  • Firmware des Dongles aktualisieren
  • Dongle ohne (legacy ezsp) in Gladys auswählen

@cicoub13 übrigens, wenn ich so darüber nachdenke, wenn der Fehler unbekannt ist, können wir den Fehler sogar „roh“ in der Oberfläche anzeigen, das erspart es uns, Anfängern zu sagen, dass sie die Logs anschauen sollen :grin:

Ich schaue heute Abend

Okay, heute Abend verfügbar für Tests, falls nötig

Ich habe ein neues Image gepusht, das sowohl bekannte als auch unbekannte Fehler behandelt
Ich habe auch die Log-Lektüre in den Stream-Modus geändert
Ich denke, die Datei readZ2mContainerLogs verdient eine gründliche Überprüfung in Ruhe.
Ich werde es morgen auf dem RPI testen

@cicoub13 Ich habe gerade einen Test durchgeführt und habe dies in den Logs:

2026-02-25T08:33:23+0100 <warn> readZ2mContainerLogs.js:97 (Zigbee2mqttManager.readZ2mContainerLogs) Zigbee2mqtt: Fehler beim Lesen der Container-Logs: stream.on ist keine Funktion

Ich habe heute Morgen auf dem RPI aktualisiert und getestet. Es scheint zu funktionieren :slight_smile:
Ich höre jetzt asynchron für 30 Sekunden mit forward:true zu
Wenn ein bekannter Fehler auftritt (der Ember-Firmware-Fehler), stoppen wir das Hören und melden den Fehler. Andernfalls warten wir 30 Sekunden und melden den letzten Fehler roh an die Front.

Ich konnte den speziellen Fall des Ember-Firmware-Fehlers nicht testen, aber ich habe andere Fehler generiert.
:warning: Es funktioniert nur bei einer Konfigurationsänderung oder bei der Aktivierung des Dienstes (aber das ist, denke ich, das, was wir wollen).

Man könnte den ersten Fehler für mehr Reaktivität melden, aber er ist nicht sehr aussagekräftig :thinking:

Für den Block

[2026-02-25 10:31:08] error: 	z2m: Error while starting zigbee-herdsman
[2026-02-25 10:31:08] error: 	z2m: Failed to start zigbee-herdsman
[2026-02-25 10:31:08] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-02-25 10:31:08] error: 	z2m: Exiting...
[2026-02-25 10:31:08] error: 	z2m: Error: Failed to start EZSP layer with status=HOST_FATAL_ERROR.
    at EmberAdapter.initEzsp (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:666:19)
    at EmberAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1539:24)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/controller/controller.ts:143:29)
    at Zigbee.start (/app/lib/zigbee.ts:70:27)
    at Controller.start (/app/lib/controller.ts:101:13)
    at start (/app/index.js:149:5)

Danke @cicoub13, das ist wirklich cool!

Gerade getestet und es funktioniert perfekt:

Ich denke, das wird den Neulingen bei Gladys wirklich helfen, über den Ember-Aspekt hinaus :slight_smile: Bravo :clap:

Nur eine Anmerkung, könnte die Fehlermeldung nicht verbessert werden, um die verschiedenen Optionen anzugeben: Firmware des Schlüssels aktualisieren oder den Legacy-Treiber ezsp auswählen?

Ansonsten habe ich etwas getestet und verstehe nicht, warum das passiert, wenn ich zu „ezsp“ zurückrolle (ich wähle den alten Treiber aus + klicke auf Speichern), dann habe ich das:

Erst wenn ich auf den Schalter „Deaktivieren“ + „Aktivieren“ klicke, sehe ich die Dienste wieder in Grün.

Eine Idee?

Beim Wechsel des Dongles wird der Z2M-Container neu gestartet (mit der neuen Konfigurationsdatei) und nicht neu erstellt.
Daher enthalten die Logs weiterhin die vorherigen Fehler und die Container sind in einem instabilen Zustand.

Ich habe einen Commit und ein Docker-Image erstellt, um den Container bei einem Dongle-Wechsel neu zu erstellen. Ich denke, das ist sauberer. Ich konnte es nicht wirklich testen und werde morgen (Donnerstag) nicht darauf schauen können.

Ja, ich habe das geändert in „Achtung: Die Firmware Ihres Ember-Koordinators ist veraltet. Die Version 7.4.x oder höher ist erforderlich. Sie können diesem Leitfaden folgen, um sie zu aktualisieren. Andernfalls wählen Sie den Dongle (Legacy ezsp) in der Konfiguration aus.“

Danke!

Super :slight_smile:

Ich habe es gerade getestet, jetzt habe ich einen anderen Fehler :smiley:

Die einzige Möglichkeit, von einem Dongle zum anderen zu wechseln, ist, zwischen jedem Wechsel eine Deaktivierung + Reaktivierung durchzuführen.

Ich denke, das ist bereits das heutige Verhalten. Ich werde am Freitag Tests durchführen, um es zu verbessern.