Fehler beim Start von Z2m

Guten Abend,

Ich musste meinen Server umziehen und beim Wiederaufbau habe ich mich wohl beim USB-Port für meinen Sonoff-Dongle vertan… :zwinkernder_gesicht_mit_zunge: und jetzt, wenn ich alles neu starte, habe ich:

Gladys-Log:

Z2m-Log:

Ich habe versucht, das Problem zu beheben, aber ich bin nicht so gut darin.

Ich würde mich über eine kleine Troubleshooting-Sitzung freuen, die hoffentlich allen hilft :schwitzendes_lächeln:

Vielen Dank im Voraus.

hallo,
bei Gladys wird über zstack als Treiber gesprochen, ist dein Dongle nicht normalerweise in ezsp oder ember?

Danke für das Feedback, aber ich habe streng genommen nichts geändert, außer dass ich den Dongle an einen anderen USB-Anschluss angesteckt habe, glaube ich. Danach habe ich ihn wieder an den ursprünglichen USB-Anschluss gesteckt und die Konfiguration erneut durchgeführt. Also habe ich das hier:

Leider kann ich dir nicht helfen, denn ich bin über Ethernet und nicht über USB mit SMLIGHT verbunden, daher habe ich wenig Kenntnis über diese Probleme.

Na gut, heute Abend schalte ich alles per Hand aus :zwinkernder_gesicht_mit_zunge:

Ich brauche wirklich Hilfe, vielen Dank im Voraus.

Was ich in den Logs nicht verstehe, ist:

  1. Container bereits gestoppt
  2. Container mit USB-Dongle-Pfad /dev/ttyUSB1 sollte entfernt werden

2026-02-24T09:59:58+0100 installMqttContainer.js:114 (Zigbee2mqttManager.installMqttContainer) MQTT-Broker-Container erfolgreich gestartet
2026-02-24T09:59:58+0100 installZ2mContainer.js:34 (Zigbee2mqttManager.installZ2mContainer) Zigbee2mqtt-Container mit USB-Dongle-Pfad /dev/ttyUSB1 sollte entfernt werden (neuer USB-Dongle-Pfad /dev/ttyUSB0 konfiguriert)…
2026-02-24T09:59:58+0100 errorMiddleware.js:68 (errorMiddleware) Fehler: (HTTP-Code 304) Container bereits gestoppt -

wobei:

Was soll ich tun?

Hallo @jcmoriaud,

Die Logs zeigen, dass Gladys versucht, den Container zu stoppen, um die Konfiguration mit dem neuen USB-Port zu ändern, aber der Container ist bereits gestoppt und offensichtlich mag Gladys das nicht besonders.

Um die Container auf deinem Gerät anzuzeigen, einschließlich der gestoppten, kannst du folgendes tun:

sudo docker ps -a

Falls der Container gladys-z2m-zigbee2mqtt vorhanden und gestoppt ist, kannst du folgendes tun:

sudo docker rm gladys-z2m-zigbee2mqtt

Damit wird der Zigbee2mqtt-Container entfernt und die Situation entblockt.

Danach gehe zurück in die Benutzeroberfläche und aktiviere die Integration erneut, was einen Container mit dem richtigen USB-Port neu starten sollte!

Halte uns auf dem Laufenden, falls du danach einen weiteren Fehler hast :slight_smile:

Ja, ich sah den Container mit „ps -a“ als „exited“. Ich habe also rm ausgeführt und es läuft wieder:

Allerdings habe ich keine Verbindung mehr zwischen den 3 Containern:

et das steht in den Logs:

2026-02-24 17:42:14] info: z2m: Currently 10 devices are joined.
[2026-02-24 17:42:14] info: z2m: Connecting to MQTT server at mqtt://localhost:1884
[2026-02-24 17:42:14] error: z2m: MQTT failed to connect, exiting… (connect ECONNREFUSED 127.0.0.1:1884)

et:

026-02-24T18:35:59+0100 scene.actions.js:192 () BadParameters [Error]: Zigbee2mqtt expose not found: « zigbee2mqtt:0xa4c138db0c5ad722:switch:binary:state » with property « state »
at Zigbee2mqttManager.setValue (/src/server/services/zigbee2mqtt/lib/setValue.js:38:11)
at DeviceManager.setValue (/src/server/lib/device/device.setValue.js:22:24)
at /src/server/lib/scene/scene.actions.js:190:27
at tryCatcher (/src/server/node_modules/bluebird/js/release/util.js:16:23)
at MappingPromiseArray._promiseFulfilled (/src/server/node_modules/bluebird/js/release/map.js:68:38)
at MappingPromiseArray.PromiseArray._iterate (/src/server/node_modules/bluebird/js/release/promise_array.js:115:31)
at MappingPromiseArray.init (/src/server/node_modules/bluebird/js/release/promise_array.js:79:10)
at MappingPromiseArray._asyncInit (/src/server/node_modules/bluebird/js/release/map.js:37:10)
at _drainQueueStep (/src/server/node_modules/bluebird/js/release/async.js:97:12)
at _drainQueue (/src/server/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/src/server/node_modules/bluebird/js/release/async.js:102:5)
at Immediate.Async.drainQueues (/src/server/node_modules/bluebird/js/release/async.js:15:14)
at processImmediate (node:internal/timers:485:21)
2026-02-24T18:36:00+0100 connect.js:46 (MqttClient.) Error while connecting to MQTT - Error: connect ECONNREFUSED 127.0.0.1:1884
2026-02-24T18:36:05+0100 connect.js:46 (MqttClient.) Error while connecting to MQTT - Error: connect ECONNREFUSED 127.0.0.1:1884
2026-02-24T18:36:10+0100 connect.js:46 (MqttClient.) Error while connecting to MQTT - Error: connect ECONNREFUSED 127.0.0.1:1884

Ich werde mal die Firewall überprüfen…

Ist der dedizierte Mosquitto-Container für Zigbee2mqtt hochgefahren?

Schau dir seine Logs an, um zu sehen, was nicht stimmt.

alle Container sind hochgefahren:

die Logs:

et

ich sehe die Fehler… aber danach…

Ein geschlossener ufw-Port?

Der Container « mosquitto » startet in einer Endlosschleife, weil er seine Konfigurationsdatei nicht findet.

Ich glaube, du hast mir gesagt, dass du das gesamte Verzeichnis « zigbee2mqtt » gelöscht hast, oder? :sweat_smile:

Hast du versucht, die Zigbee2mqtt-Integration zu deaktivieren (mit dem blauen Schalter)?

Warte, bis alle Container gestoppt sind. (Du kannst das mit docker ps überprüfen)

Klicke dann erneut auf den Schalter, normalerweise werden die Konfigurationsdateien neu erstellt, wenn sie fehlen.

Ja, ich hatte den Container tatsächlich gelöscht.

Ich habe die Sequenz wie angegeben wiederholt und alles funktioniert! Super, danke!!!

Ich stelle die Frage, um nicht zu sagen, eine große… aber könnte diese Situation, falls sie manchmal auftritt (ich wage nicht zu glauben, dass ich der Einzige bin…), nicht automatisch gelöst werden?

Ausgezeichnet !! Na toll !