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:
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.
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
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 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?