Hier matin, après un redémarrage sauvage, j’ai profité d’avoir la main pour recaler un sauvegarde antérieure à la dernière MAJ.
Ca a fonctionné de nouveau toute la journée.
L’instance a du se remettre à jour cette nuit…
Ce matin de nouveau plus rien…
@b3n.0 Je pense qu’il y a une confusion sur ce qu’une restauration fait dans Gladys.
Une restauration restore les données uniquement, mais ne reinstalle pas une ancienne version de Gladys, donc la seule chose que tu as testé toi ici c’est juste l’action de redémarrer Gladys qui a du débloquer ta situation.
Est-ce que tu peux créer un sujet séparé sur le forum pour expliquer tes problèmes car j’ai du mal à comprendre ce qui ne va pas chez toi ? Merci 
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 
Je n’ai pas d’autre info à te communiquer: Gladys locale, Gladys + et ssh était planté, un redémarrage à tout réglé.
Depuis que j’ai changé l’alimentation de mon Raspberry pi3 avec SSD, c’est très rare que Gladys plante.
J’ai plus de soucis avec zigbee2mqtt notamment une prise xaomi qui; aller savoir pourquoi
est connecté à presque tous mes appareils et parfois elle fait des siennes (débrancher/rebrancher la prise et parfois redémarrer zigbee2mqtt) .
@pierre-gilles En effet il y a eu confusion !
Je rentre chez moi ce soir et constate que tout est reparti alors ce matin c’était planté !
Du coup je ne sais pas ce qui cest passé…