Hello,
@pierre-gilles
gladys | 2026-11-02T18:17:44+0100 scene.executeActions.js:47 (executeAction) BadParameters [Error]: Zigbee2mqtt expose not found: « zigbee2mqtt:Lumière couloir:switch:binary:state » with property « state »
J’ai rollback mon zigbee2mqtt en 2.14.2 mais j’ai toujours le même problème sachant que j’avais testé la 2.14.3 et la lumière fonctionnait très bien
Merci
Salut @prohand ,
Merci pour le retour ! De mon côté, je n’arrive pas à reproduire : je suis en 5.3.1 et toutes mes lumières Zigbee2mqtt fonctionnent normalement.
L’erreur Zigbee2mqtt expose not found veut dire que, au moment où la scène envoie la commande, Gladys ne trouve pas ta lampe dans la liste des appareils que Zigbee2mqtt lui envoie au démarrage. Ce n’est donc pas la commande en elle-même qui pose problème : Gladys ne « voit » plus tes appareils côté Zigbee2mqtt.
Pour comprendre ce qui se passe chez toi, tu peux me dire :
Dans Intégrations → Zigbee2mqtt , est-ce que les trois liens (Gladys ↔ MQTT ↔ Zigbee2mqtt) sont bien au vert ?
Est-ce que l’onglet Découverte de l’intégration liste bien tes appareils, dont « Lumière couloir » ?
Est-ce que tes autres appareils Zigbee2mqtt remontent toujours leurs états dans Gladys (capteurs, état de la lampe quand tu l’allumes depuis Zigbee2mqtt) ?
Si tu redémarres Gladys, est-ce que ça remarche, même temporairement ?
J’ai vu dans tes logs ton intégration gladys-z2m-devices-monitor. Est-ce qu’elle se connecte au même broker MQTT que Zigbee2mqtt, et est-ce qu’elle publie des messages sur les topics zigbee2mqtt/... ? Est-ce que tu l’as installée ou mise à jour en même temps que la 5.3.1 ? Si tu peux, essaie de la désactiver un moment pour voir si les lumières remarchent.
Merci !
Merci pour le retour rapide
Bon visiblement c’est revenu tout seul et j’ai reçu en même temps les messages de la mise à jour sur mon canal alors que cela fesait un moment que j’avais fais la MaJ
Petite précision j’ai dû réactiver le service zigbee2mqtt juste après la MaJ
Super, merci pour le retour !
Le fait que tout soit revenu au moment où tu as reçu le message de mise à jour, c’est l’indice qui explique tout : Gladys n’envoie ce message qu’une fois toutes les intégrations démarrées. Elles démarrent une par une, et le premier démarrage après une mise à jour peut prendre un moment (mise à jour des conteneurs Docker, démarrage des intégrations externes…).
Tant que l’intégration Zigbee2mqtt n’a pas fini de démarrer, Gladys ne connaît pas encore tes appareils, d’où l’erreur expose not found dans tes logs. Une fois le démarrage terminé, tout est rentré dans l’ordre tout seul.
Donc rien de cassé dans la 5.3.1, et normalement tu n’avais pas besoin de réactiver le service Zigbee2mqtt : il aurait démarré à son tour. Il fallait juste un peu plus de patience
Salut tout le monde !
Ce sujet est désormais en cours de développement .
Une PR a été ouverte pour afficher clairement que Gladys est encore en train de démarrer ses intégrations :
master ← claude/quirky-ptolemy-igd5y2
ouvert 06:09PM - 02 Nov 26 UTC
### Description
After the 5.3.1 update, a user reported that their Zigbee2mqtt … lights no longer worked, with `Zigbee2mqtt expose not found` in the logs. It came back on its own: everything started working again at the exact moment they received the "Gladys has been updated" message. That message is only sent once **every** integration has started. Gladys starts its integrations one after the other, and the first start after an update can be long. Until Zigbee2mqtt was started and had received its device list, no device could be controlled. The UI said nothing about this, and the error looked like a regression.
This PR makes this state visible and the error explicit.
**Server**
- `service.startAll` publishes its progress (`done` / `total`, the integration being started, the ones still waiting) on the new `system.services-startup` websocket event. The same state is available on `GET /api/v1/service/startup` (authenticated). External integrations are named by their manifest, native ones are translated by the front.
- `Promise.map` with `concurrency: 1` does not start services in list order: past the first one, it takes them from the end. The progress follows the service actually being started. The start order itself is left unchanged.
- Zigbee2mqtt `setValue`:
- if the device list (`bridge/devices`) has not been received yet, it throws a new `ServiceNotReadyError` (HTTP 503). The message says Zigbee2mqtt is not ready yet: Gladys may still be starting, or it is not connected to Zigbee2mqtt;
- if the device is missing from that list, the message says it may have been removed or renamed in Zigbee2mqtt;
- the `expose not found` error is kept, but only for its real meaning: the device is known, the property is not.
**Front**
- While the integrations start, the sidebar shows a "Gladys is starting" notice: X/Y integrations started, the one in progress, the ones waiting. Only integrations the user can recognize are named (a catalog card or an external integration); technical services such as `usb` or `example` are only counted. On mobile, a one-line strip under the top bar shows the same state, and tapping it opens the menu with the details. The notice disappears on its own once the boot is over.
- Websocket reconnection fix (`Session.js`): after a disconnection, the front retried **once** after 1 s. If Gladys was still restarting at that moment (the normal case during an update), the tab never reconnected and stopped receiving live updates until reloaded. A connection that cannot be opened is now retried every 2 s, for the current socket of a session that is still logged in. Without this fix, the notice could never appear in a tab left open during an update.
**Screenshots** (dev server with every service start slowed down by 1.5 s to observe the boot)
Desktop: the notice at the bottom of the sidebar, e.g. "Gladys démarre — 20/39 intégrations démarrées… En cours : Zigbee2mqtt — En attente : Enedis, CallMeBot, Philips Hue, API OpenWeather, Appareils virtuels MQTT et 10 autres". Mobile: a strip "Gladys démarre 31/39 intégrations" under the top bar.
**Tests**
- Server: `npm run coverage` passes, and every new or changed line is covered (`service.startAll.js` progress with 3 services, so the out-of-order start is exercised; `service.startupState.js`; the new route; the 503 mapping; the two new Zigbee2mqtt messages).
- Front: `prettier-check`, `eslint` (no errors), `compare-translations`, `npm run build`.
- End to end, by hand with Playwright: with the page open, the server was restarted with slowed service starts. The websocket reconnects, the notice counts from 0/39 to 38/39 with the right integration "in progress", then disappears.
- Cypress: run locally, results to follow in a comment.
### Related request
Forum: https://community.gladysassistant.com/t/probleme-lumiere-zigbee2mqtt-suite-maj-en-5-3-1/11486
### Checklist
- [x] If a forum topic or GitHub issue exists, the description links it (`Forum: https://community.gladysassistant.com/t/...` or `Closes #...`)
- [x] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed. Cypress: run in progress, see below
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [x] No undocumented breaking change
---
_Generated by [Claude Code](https://claude.ai/code/session_01MNjB35CGPpnAqEm175K3wR)_
N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.
