Yesterday morning, after an unexpected reboot, I took advantage of having control to restore a backup from before the last update.
It worked again all day.
The instance must have updated itself during the night…
This morning, again nothing…
@b3n.0 I think there’s some confusion about what a restore does in Gladys.
A restore restores the data only, but does not reinstall an older version of Gladys, so the only thing you tested here was just restarting Gladys, which must have unblocked your situation.
Can you create a separate thread on the forum to explain your problems because I’m having trouble understanding what’s going wrong on your side? Thanks 
I spent quite a bit of time today on the Zigbee2mqtt integration bug, and I found where the bug came from 
This is a bug that occurs when:
Step #1: The Mosquitto container is updated by Watchtower (at any time)
Step #2: Then, Gladys is updated (even if it’s 2 days later)
If between the two, no devices on the Zigbee network are added/removed and the Zigbee2mqtt container is not restarted, then Gladys will not receive the list of Zigbee devices on startup, and will be « in the dark », hence the errors you see.
As you can see, there are a lot of « ifs » which mean this scenario doesn’t necessarily happen for everyone, and it doesn’t occur with every Gladys update because there needs to be an upstream Mosquitto update for the bug to occur.
The reason this bug occurs is that Zigbee2mqtt uses an MQTT feature we don’t use in Gladys: « retained » (persistent) messages so that this message is delivered to every new client that connects.
However, currently the Mosquitto container launched by Gladys is started without persistence, and those messages are lost if Mosquitto is restarted.
What to do while we update Gladys?
The simplest thing if your instance is disconnected is simply to restart the Zigbee2mqtt container:
docker restart gladys-z2m-zigbee2mqtt
This will re-publish that message and Gladys will regain its list of devices.
Next steps
Now the Zigbee2mqtt integration in Gladys needs to be modified to find a workaround for this issue.
We’re currently discussing it with @AlexTrovato on another thread, but there’s a fair amount of testing before releasing a change so the fix won’t be immediate either.
Thank you for your patience and for your feedback 
4 Likes
I don’t have any other info to give you: local Gladys, Gladys Plus and SSH were down, a restart fixed everything.
Since I changed the power supply of my Raspberry Pi 3 with SSD, it’s very rare that Gladys crashes.
I have more issues with zigbee2mqtt, notably a Xiaomi plug which — go figure — is connected to almost all my devices and sometimes misbehaves (unplug/replug the plug and sometimes restart zigbee2mqtt).
@pierre-gilles Indeed there was confusion!
I got home tonight and noticed that everything is back up, whereas this morning it was down!
So I don’t know what happened…