Hello, excellent work on this new version 5. It’s really well done. Thank you very much.
A simple scene sends an MQTT message:
2.) MQTT receives the data, processes it and returns the results in MQTT format. (see Debugging)
3.) Result: nothing arrived, the data is not recorded or displayed in Gladys, etc.
So, it’s not logical, but it happens to me often with custom topics. You just need to click ‹ save › again in the relevant device and everything reappears!
Perfect, thank you very much, that was the trick needed. It’s a bit tedious to review each virtual device, but it works. Thanks
Hi everyone!
This topic is now in development .
A PR has been opened to restore the subscription to custom MQTT topics on broker connection:
master ← claude/mqtt-scenes-feedback-5o9ogp
ouvert 05:29PM - 28 Aug 26 UTC
### Description
A user reported on the forum that, since 5.0.1, MQTT data sent … back to Gladys was no longer received: the scene published its message fine, the external system answered on the expected topic, but nothing arrived in Gladys. The workaround found on the forum was to open each virtual device and click "save" again.
This is a real regression, not a UX issue, and it affects every device with a custom MQTT topic (not only those used in scenes).
Root cause:
- Custom topics of device features are registered by `listenToCustomMqttTopicIfNeeded`, called from `device.add` when devices are loaded in RAM. That function only sends a `SUBSCRIBE` if `this.mqttClient` already exists.
- In the new boot sequence, `device.init()` runs **before** `service.startAll()`, so at that point the MQTT service is loaded but not started: `mqttClient` is `null`. The topics are pushed into `deviceFeatureCustomMqttTopics`, but no `SUBSCRIBE` is ever sent.
- Unlike topics registered through `subscribe()` (default topics, Home Assistant state topics), the device custom topics are not part of `topicBinds`, so the `connect` handler did not replay them either.
Result: after a restart, the broker never forwards those topics to Gladys, until the user saves the device again (`device.add` runs a second time, this time with a connected client). The same happened after saving the MQTT configuration, since that builds a brand new client.
Fix: the `connect` handler now also subscribes to the custom topics registered so far, deduplicated by topic. A regression test covers the exact sequence (topics registered while `mqttClient` is `null`, then connection) and fails on `master`.
## Forum
Forum: https://community.gladysassistant.com/t/question-about-the-mqtt-in-scenes/10739
### Checklist
- [x] Tests pass: `npm_config_service=mqtt npm run test-service` → 253 passing, including the new regression test (which fails without the fix)
- [x] Linter and prettier pass on the changed files (`npx eslint`, `npx prettier --check`)
- [x] No undocumented breaking change
---
_Generated by [Claude Code](https://claude.ai/code/session_0118ndMFrKoZ3XWYdgPpk7RF)_
## Summary by CodeRabbit
* **New Features**
* Custom device MQTT topics are now automatically subscribed to when the MQTT connection is established.
* Duplicate and empty topics are ignored to prevent unnecessary subscriptions.
* **Bug Fixes**
* Ensures custom topics registered before connection become active after connecting.
Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.
Thanks for the feedback @ruegerth , I’ll fix that
mutmut
August 28, 2026, 6:36pm
6
I had the same issue with my custom topics for my teleinformation.
I’m going to do a 5.0.2 today!
mutmut
August 29, 2026, 2:17pm
8
I’m currently overhauling my network infrastructure a bit and I realized that if Gladys loses contact with its MQTT broker (external in my case), then the custom topics don’t reactivate on their own. You need to back them up to « reactivate » them.
mutmut
August 30, 2026, 11:07am
10
I had written before the 5.0.2 release, I need to retest.
EDIT: it’s good with 5.0.2, automatic reconnection to custom topics!
