Hello,
Tomorrow evening I will start developing a monitoring integration for Zigbee.
Indeed, as seen in this topic, the battery sensor indications are unreliable:
I’m sharing a Node-Red flow with you to measure the reception time of a Zigbee sensor signal. If the time between each signal reception is greater than 24H (configurable) then a Telegram alert is sent. I created this function because the battery indication of Zigbee sensors is not reliable and several times I was caught out on a temperature when the sensor was no longer working. This can be annoying when you need this value in a scene. Now I know if one of my sensors no longer sends data after 2…
It is therefore necessary to be alerted when a sensor no longer shows signs of life
I’ll keep you posted here when I have a stable version available in the store
The integration is available :
https://github.com/prohand/gladys-z2m-devices-monitor
Please read the documentation to understand how it works:
# Z2M Devices Monitor — documentation
Cette intégration surveille vos appareils Zigbee2MQTT et vous alerte quand l'un
d'eux **ne donne plus signe de vie**.
## Pourquoi ne pas se fier à la batterie
Le pourcentage de batterie remonté par un appareil Zigbee est une estimation
grossière, rarement rafraîchie et souvent fausse : une pile CR2032 affiche
couramment 100 % jusqu'au jour où le capteur cesse de répondre. Et surtout, la
batterie ne dit rien des autres façons de mourir : un appareil débranché, sorti
du réseau, qui a perdu sa route ou dont le routeur parent est tombé.
Un appareil Zigbee vivant **parle**. Les capteurs envoient leurs mesures, les
routeurs répondent, tout se manifeste au moins périodiquement. Le seul fait
vraiment fiable est donc : _quand ai-je entendu cet appareil pour la dernière
fois ?_ — et la seule question utile : _se tait-il depuis plus longtemps qu'il ne
le devrait ?_
C'est exactement ce que fait cette intégration.
Ce fichier a été tronqué. afficher l'original
A scene must be created to be alerted according to what is indicated here:
https://github.com/prohand/gladys-z2m-devices-monitor/blob/main/docs/fr.md#être-alerté--créer-la-scène
Don’t hesitate to report your comments / bugs to me
Integration installed and scene built in 5 minutes, that’s great. And largely thanks to the hyper-clear explanations.
Well done @prohand and thanks, because it’s going to be very useful for me to no longer be fooled by a ‹ sleeping › sensor.
Small bug on my production instance that I didn’t have on my dev:
Fix applied in version 1.0.2:
StephaneB:
Integration installed and scene built in 5 minutes, it’s great. And largely thanks to the hyper-clear explanations.
Bravo @prohand and thank you, because it’s going to be very useful for me to no longer be fooled by a ‹ sleeping › sensor.
Thanks
Attention on the scene I just corrected a typo where you must not forget to recover the state:
Yes. I did it instinctively, and then I thought I should let you know so you could adjust. But you were faster
guim31
August 14, 2026, 6:33pm
7
Hi @prohand and thanks for your work!
Lazy question… I have a lot of devices, I can’t see myself adding them one by one to gladys in your integration. Could we add an « Add all » button?
guim31:
Hi @prohand and thanks for your work!
Lazy question… I have a lot of devices, I don’t see myself adding them one by one to gladys in your integration. Could we add an « Add All » button?
Hi
Here is the AI’s response:
I checked the functionality on the Gladys side before answering, because there is a fundamental constraint.
The « Add » button on this screen belongs to the core of Gladys, not to the integration. The Discovery screen (front/…/external-integration/discover-page/) displays a card per published device, and each button makes a POST /api/v1/device with the user’s JWT. The host API for integrations (/api/integration/v1/…) only exposes status, discovered_device, device (read), state, config, container… — no device creation route. An integration can propose devices, but never create them. Therefore, an « Add All » button in the integration configuration screen is not technically possible.
I’ll let you create a feature request following this feedback
guim31
August 14, 2026, 7:55pm
9
I’m not sure this request is very useful if it involves the core of Gladys. I’ll just take the time to click
Hello @prohand . In your integration, would you be able to manage the following things:
in your ‹ supervision › tab:
restart the Zigbee manager (and it would be great if it were accessible in a scene, to trigger it regularly)
enable/disable pairing
in your ‹ device › tab:
rename a device (i.e., give it a name different from 0x… in the Zigbee interface, and have Gladys take it into account to not lose data history, and usage in scenes and dashboards)
Hi @StephaneB
This integration is only for monitoring Zigbee elements.
Your two points could, however, I think, be the subject of an improvement request for the zigbee2mqtt integration
I can’t connect to this integration. My broker’s address is IP:1884, and I think the application wants it to be IP:1883.
I get this response.
MQTT Broker unreachable at —.—.-.—:1884 (connect ENETUNREACH 0.0.7.92:1883).
I just pushed a fix
Actually, you had to put mqtt:// before the address
With the fix, both are possible now
Connected as soon as I did your update, my 25 devices are being monitored. Thanks.
guim31
August 26, 2026, 3:57pm
15
Same for me, everything is ready!!
Thanks for the work!
Hi @guim31 ,
I’m in the same situation as you: already 55 Zigbee gadgets, and more are coming… So, a bulk add would be great
Hello,
This is related to the core and not the plugin as indicated here, a feature request needs to be made:
Hi
Here is the AI’s response:
I checked the functionality on the Gladys side before answering, because there is a fundamental constraint.
The « Add » button on this screen belongs to the core of Gladys, not to the integration. The Discovery screen (front/…/external-integration/discover-page/) displays a card per published device, and each button makes a POST /api/v1/device with the user’s JWT. The host API for integrations (/api/integration/v1/…) only exposes status, discover…