Ich habe heute viel Zeit mit dem Zigbee2mqtt-Integrationsbug verbracht und herausgefunden, woher der Bug kommt 
Es handelt sich um einen Bug, der auftritt, wenn:
Schritt 1: Der Mosquitto-Container von Watchtower aktualisiert wird (zu irgendeinem Zeitpunkt)
Schritt 2: Dann wird Gladys aktualisiert (auch wenn das zwei Tage später ist)
Wenn zwischen diesen Schritten keine Geräte im Zigbee-Netzwerk hinzugefügt oder entfernt werden und der Zigbee2mqtt-Container nicht neu gestartet wird, erhält Gladys beim Start keine Liste der Zigbee-Geräte und ist « im Dunkeln », was zu den Fehlern führt, die ihr seht.
Wie ihr sehen könnt, gibt es viele « wenn »-Bedingungen, die dazu führen, dass dieses Szenario nicht bei jedem auftritt und nicht bei jeder Gladys-Aktualisierung, da eine Mosquitto-Aktualisierung vorausgehen muss, damit der Bug auftritt.
Der Grund, warum dieser Bug auftritt, ist, dass Zigbee2mqtt eine MQTT-Funktionalität verwendet, die wir in Gladys nicht nutzen: die « retained » (persistenten) Nachrichten, damit diese Nachricht an jeden neuen Client gesendet wird, der sich verbindet.
Allerdings wird der von Gladys gestartete Mosquitto-Container ohne Persistenz gestartet, und diese Nachrichten gehen verloren, wenn Mosquitto neu gestartet wird.
Was tun, bis Gladys aktualisiert wird?
Wenn eure Instanz offline ist, ist das Einfachste, den Zigbee2mqtt-Container neu zu starten:
docker restart gladys-z2m-zigbee2mqtt
Dies wird die Nachricht neu veröffentlichen und Gladys wird ihre Geräteliste wiederherstellen.
Was als Nächstes?
Jetzt müssen wir die Zigbee2mqtt-Integration in Gladys ändern, um eine Lösung für dieses Problem zu finden.
Dazu diskutieren wir aktuell mit @AlexTrovato in einem anderen Thema, aber es gibt viel Testarbeit, bevor wir eine Änderung veröffentlichen können, also wird der Fix auch nicht sofort kommen.
Danke für eure Geduld und euer Feedback 