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 