Can i use it to connect to Opera GX’s new smart home update?
@ATHOM @Emile I hope you support this app since you published.
Three related questions about using MQTT Server and HomeyScript together for state management.
1. Internal publish → trigger loopback
When a HomeyScript (or any flow action) publishes via the “Publish topic” action card, the “A message is published on topic” trigger card in the same app does not fire. The trigger only responds to messages from external MQTT clients (Node-RED, MQTT Explorer, ESP32, etc.). The publish action completes without error, but the trigger is silent.
This was independently confirmed by another user @robertklep . Is this by design to prevent feedback loops? Is there a setting to enable it?
2. Retained messages
Does the “Publish topic” action card support publishing with the retain flag? And if a flow subscribes to a topic that already has a retained message, does the trigger fire immediately on that retained delivery — or only on new publishes?
If both work, retained topics would be a clean way to store and share state between scripts and external tools without needing logic variables.
3. HomeyScript logic variables — single-variable read
Homey.logic.getVariables() fetches all variables every time. Is there a way to read a single variable by ID or name — something like Homey.logic.getVariable({ id }) — without pulling the full list?
The full fetch is slow (~200ms) and forces scripts to cache the object locally, which creates a stale-read race condition when two HomeyScript instances run concurrently and both overwrite shared state.
@DirkG @RonnyW @robertklep @Emile
Update: device publishing can now be switched off (v1.3.0)
Following up on the request for a device filter / broker-only option (@RonnyW, post #11, Aug 2024) and the note that every message triggered the flow cards (@robertklep, post #7): Emile has added both, now live.
- v1.2.0: a message is only checked against trigger cards that are actually used in a flow.
- v1.3.0: two settings, “Publish devices to /homey” and “Publish devices to /homie”. Untick both and the app works as a plain broker. The device topics it published before are removed from the broker.
Why it matters: the app publishes every Homey device, 12 messages per change (value plus name, type, unit and so on, in both formats). On my Homey Pro (296 devices, several energy meters updating every few seconds) that was 70–120 messages a second, which nothing here reads. I only use the app as the broker for my own ESP32 boards.
After updating and unticking both boxes:
- broker traffic dropped to just my boards’ own messages
- the old device topics are gone from the broker
- the app’s CPU at night went from about 1.2–1.8 % to 0.4 %, and the whole Homey from 20–25 % to 18 %
- boards and MQTT flows work as before
If another system (Home Assistant, Node-RED, …) reads those topics, leave the boxes ticked: that is what device publishing is for.
Thanks @Emile for the quick fixes!
