Similar to the mqtt.dump action, an mqtt.query action is necessary. This action would return the retrieved value as a variable to the calling script. Ideally, a parameter parse_json (that defaults to false) would take the MQTT value returned and parse it as JSON, returning an object to the calling script instead of a string.
Currently, users have to manually read the mqtt_dump.txt file in scripts, and manually parse the contents read from the file. This is racy and buggy.
Why not just use an mqtt sensor?
Because:
Look at this:
Itās unnecessary complexity. I just want to issue a single query every once a month or so.
I think you want to create a new mqtt system. The current mqtt system is a push system: clients push messagesto the broker, the mqtt broker pushes received messages to subscribers. AFAIK there are no provisions to query a broker without subscribing. So a sensor makes sense, a query not so much.
Thatās simply not correct. MQTT dump works perfectly with retained messages as well as with waiting for a non-retained message to show up on the bus. All Iām asking is for the same feature in an mqtt.query action.
EDIT: I am not even asking for a feature where the action sends a message and then it waits for a response. This is just simply looking at whatever might already be on a topic that has been retained. Thatās really all Iām asking for.
Where would the data be retrieved from? Isnāt the whole point of MQTT to be a push system from sensors to brokers (with retained value to keep it).
Does MQTT protocol even support a sensor asking a broker for latest retained value at specific topic? Not sure, I may be wrong.
Mqtt dump just subscribes to the whole mqtt tree, just as utilities as e.g. Mqtt Explorer do.
From the retained value of the topic, or from any message that arrives on the topic during the wait time.
Yes this is natively supported in the MQTT integration.
No it isnāt. The mqtt integration listens to push messages from the broker, it doesnāt retrieve them or āask for themā. I suggest you read up on the mqtt protocol.
How does this work at the MQTT protocol levels so that broker knows it has to reply to your request? Where can I read about this please? Is it MQTT 3.x or 5.x?
Edit: There is no retrieve command in the MQTT protocol standard. To have what you want, the HA would need to keep track (and retain) raw messages from MQTT broker that would allow you to retrieve them locally. And this is where sensor can help you.
I think I under what youāre requesting.
You want an action that temporarily subscribes to a topic and then either:
timeout period, for a message to be published to the topic.The received message is reported in response_variable.
I think retrieving a stored message would be feasible but Iām not sure the development team would permit an action that has a variable-length timeout.
Actions typically have a brief, hard-coded timeout. Are you aware of any existing actions that have a built-in timeout feature?
FWIW, actions that are similar to what you are requesting are calendar.get_events and weather.get_forecasts.
I see what you are asking here, sounds not that hard and you have the models mentioned above as precedent and possible models of what to do. Contribute itā¦
In the mean time, do a tiny python script to do what you want and call that when you want to. I do one to shut off something in the back-end on occasion. Resets my rf433 battery alerts when I want to clear one after changing a battery.
When you want to run it itās an available action: āpython_script.battery_clearā.
Bingo! That describes perfectly what Iām requesting.
TBQF even if the action had a zero timeout and no way to configure it, that would already be useful for harvesting retained messages. But being able to wait arbitrary amounts of time for MQTT messages to arrive in scripts would be a gamechanger for heavy users of MQTT!
No, thatās the exact opposite of what I have requested. Your script is publishing stuff to MQTT. I want an action to read retained messages. I see no support in the python_scripts integration to read messages from MQTT.
Iām familiar with MQTT. I suggest you look up how the mqtt.dump action works, because (contrary to what you seem to be implying) that action already does half of what I requested here ā only instead of returning the data to the calling script, it dumps the data into a file called mqtt-dump.txt.
I know, it subscribes to the mqtt root topic, and dumps that information in a file. It is not a query. Read the mqtt protocol specifications.
Ya, I use it to publish. You would need to use something else.
My point is you can easily roll your own function there using what is available in the broker, which is the same toolset HA would have to implement your suggestion.
How are you achieving it now?
Faced with the same requirement, I would create an MQTT Sensor that stores the received message in its attributes (16K of storage space and value isnāt limited to being a string) and exclude it from the Recorder integration (no history is maintained).
Yah thatās horribly messy and the very thing i want to avoid.