I’m Using in my Hause automatisation ESP8266 to provide sensor data from e.g. BME280 and others. the data is Provide by HTML and catched by URL calls from openhab by the html binding.
Now I’m upgraiding my development by MQTT.
But unlike the normal MQTT I do not like the ESP to send the data in intervals, I like the openhab to call the ESPs via MQTT and than the ESPs are answering.
I was not able to find a interval setting un the MQTT binding like it is in the HTML binding.
Is there any thing I missed or is there an other way.
There isn’t one.
There is no polling mechanism in MQTT, because there is a broker in the way.
Polling or refreshing would only get the last message the broker has seen.
But you can make your own “polling” mechanism.
Send a topic that your remote device treats as a request for status, and replies to with a topic of its own.
For the curious and to about the XY Problem, why do you want to miss use MQTT in this way? What are you trying to solve? Perhaps there is something already built into MQTT that already solves this problem saving you a lot of work.
I wake up the thread here to follow-up the last response from @rlkoshak. My use case is very similar and intend to follow the advice re time rule trigger if nothing more ‘clever’ does not come up.
I have a few modbus-capable energy meters connected to the power lines at home. I can read them all via a single esp32 module that runs also an mqtt client to provide the readings. The thing is, this should happen at regular intervals (e.g. on top of every hour) to get reasonable time series data. It is possible to time-sync the esp32, so it can publish at time I want, but additional logic needs to be built into its firmware. It is way easier to do it the other way around: trigger an mqtt publish from outside (i.e. openhab) defining the logic / polling intervals there.
Time rule with cron trigger sounds like exact fit, but I am curious why would this be a misuse of MQTT
It is just that MQTT publish-subscribe methodology is not intended for everyday polling use. There is of course nothing to stop you superimposing your own rules on top when you have control of both ends e.g. making the esp32 recognise a “poll” instruction (which is not standard MQTT).
Polling sits uncomfortably with MQTT for multiple subscribers, for example.
For one thing, is it really more work to configure the ESP32 to simply publish the reading every X-seconds than it is to have it subscribe to a message and respond to that message by publishing the current readings?
Perhaps the sticking point is that you want it to publish exactly on the hour. That’s somewhat of an antipattern with MQTT. The meters should publish periodically independent of what the wall clock says. It’s super simple to configure the ESP to just publish every X seconds starting from when the device powered up. You just take a timestamp at start and then another one at the top of the loop with a modulo operation to see if X seconds has past. If it has report. If not go to sleep again.
Anyway, MQTT was designed in an industrial context (oil pipeline sensors to be specific). The sensors are all out there running independently. When the sensor decides it has something important to say (a new reading, it’s accumulated data for a given period of time, etc.) it independently publishes that data. The sensors are in the best position to know when it has something important to say.
The Broker is responsible for keeping up and reporting when the sensor goes offline (so don’t implement your own heartbeat).
Why is it this way? One reason is often there is more than one client subscribing to that sensor’s data. When you have more than one subscriber, who is responsible for generating the polling messages? What if that one client goes offline? Now nobody gets readings. What if all the clients generate polling messages? Than the readings will come in faster and potentially at an inconsistent rate.
And there is one more gotcha. What if a sensor only reports rarely (let’s say every five minutes) and the subscriber wasn’t connected to the broker when the last reading was reported. It could be up to five minutes before it receives any reading. MQTT has a feature built in for this use case too: retained messages. When a message is retained, and new subscribers to the topic will get the last published message.
So, in short, MQTT is carefully designed in such a way that information is pushed, not polled for. All the use cases where a poll might be required are handled with other features of the language (e.g. LWT, retained messages). If you really want to use polling, you should use REST on your ESP32s instead of MQTT.
Thanks Both for the insight! Great to understand the principle and intended use, and yes - I agree with the misuse term now reading the details.
In my setup I am very much in a special case with access on both ends possible, and w/o specific constraints regarding connectivity, multiple subscribers and sensors etc.
Still, I would probably go the REST route on the esp32 with HTTP binding in OpenHAB which seems the better fit.
I actually did not realise there are reasonably priced for home use TCP gateways. Indeed the Modbus binding with such one will be a thing to consider - it would eliminate the need of esp32 in the middle and allow to work with the meters directly in OpenHAB.
Well if you are a tinkerer it shouldn’t be too demanding to code the esp32 to act as gateway, you must have half the Modbus code in place already. Modbus-TCP to Modbus-RTU is fairly trivial, and traffic management forced to be simple by RTU being one-at-a-time query/response.
True, as usual there are multiple ways to achieve the same
I intend to describe the whole thing end-to-end from the energy meters to the reporting of stats / cost when finished.
