J’ai passé pas mal de temps aujourd’hui sur le sujet du bug de l’intégration Zigbee2mqtt, et j’ai trouvé d’où venait le bug 
Il s’agit d’un bug qui intervient quand:
Etape n°1 : Le container Mosquitto est mis à jour par Watchtower ( n’importe quand )
Etape n°2 : Puis, Gladys est mise à jour (même si c’est 2 jours après)
Si entre les deux, aucun appareils dans le réseau Zigbee n’est ajouté/retiré et si le container Zigbee2mqtt n’est pas redémarré, alors Gladys ne recevra pas la liste des appareils Zigbee au démarrage, et sera « dans le noir », d’où les erreurs que vous voyez.
Comme vous pouvez le constater, il y a beaucoup de « si » qui font que ce scénario n’est pas forcément vérifié chez tout le monde, et n’est pas vérifié à chaque mise à jour de Gladys car il faut qu’il y ait une mise à jour de Mosquitto en amont pour que le bug se produise.
La raison pour laquelle se bug se produit, est que Zigbee2mqtt utilise une fonctionnalité de MQTT qu’on utilise pas dans Gladys, les messages « retained » (persistent) pour que ce message soit délivré à chaque nouveau client se connectant.
Hors, actuellement le container Mosquitto lancé par Gladys est lancé sans persistence et ainsi ces messages sont perdu si Mosquitto est redémarré.
Que faire en attendant qu’on mette à jour Gladys ?
Le plus simple si votre instance est déconnecté, c’est tout simplement de redémarrer le container Zigbee2mqtt:
docker restart gladys-z2m-zigbee2mqtt
Ce qui aura pour effet de re-publier ce message et Gladys re-trouvera sa liste de devices.
La suite
Maintenant il faut modifier l’intégration Zigbee2mqtt dans Gladys pour trouver une parade à ce souci.
On en discute actuellement avec @AlexTrovato sur un autre sujet, mais il y a pas mal de testing avant de publier un changement donc le fix ne sera pas non plus tout de suite.
Merci pour votre patience et pour vos retours 