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 »
I rolled back my zigbee2mqtt to 2.14.2 but I still have the same problem, knowing that I had tested 2.14.3 and the light was working very well
Thanks
Hi @prohand ,
Thanks for the feedback! On my end, I can’t reproduce the issue: I’m on 5.3.1 and all my Zigbee2mqtt lights are working normally.
The error Zigbee2mqtt expose not found means that, when the scene sends the command, Gladys can’t find your lamp in the list of devices that Zigbee2mqtt sends to it on startup. So, the command itself isn’t the problem: Gladys can no longer « see » your Zigbee2mqtt devices.
To understand what’s happening on your end, can you tell me:
In Integrations → Zigbee2mqtt , are the three links (Gladys ↔ MQTT ↔ Zigbee2mqtt) all green?
Does the Discovery tab of the integration list your devices, including « Hallway Light »?
Are your other Zigbee2mqtt devices still reporting their states in Gladys (sensors, lamp state when you turn it on from Zigbee2mqtt)?
If you restart Gladys, does it work again, even temporarily?
I saw in your logs your integration gladys-z2m-devices-monitor. Is it connected to the same MQTT broker as Zigbee2mqtt, and is it publishing messages on the topics zigbee2mqtt/...? Did you install or update it at the same time as 5.3.1? If you can, try disabling it for a moment to see if the lights work again.
Thanks!
Thanks for the quick reply
Well, it seems to have come back on its own, and at the same time, I received the update messages on my channel, even though I had done the update a while ago. I even rebooted Gladys.
Just a small detail: I had to reactivate the zigbee2mqtt service right after the update. I don’t know if that’s normal or if I just wasn’t patient enough
Great, thanks for the feedback!
The fact that everything came back just as you received the update message is the key that explains everything: Gladys only sends this message once all integrations have started. They start one by one, and the first startup after an update can take some time (updating Docker containers, starting external integrations…).
As long as the Zigbee2mqtt integration hasn’t finished starting, Gladys doesn’t yet know about your devices, hence the expose not found error in your logs. Once the startup is complete, everything returns to normal on its own.
So nothing is broken in 5.3.1, and normally you didn’t need to reactivate the Zigbee2mqtt service: it would have started on its own. You just needed a bit more patience
Hi everyone!
This topic is now in development .
A PR has been opened to clearly show that Gladys is still in the process of starting its integrations:
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)_
Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.
