Being new to openHAB, using openHAB3, inching along its nearly flat learning curve, I am thinking there is a simple answer to this question. I have page, action, oh-cells that toggle “smart” electrical power receptacle devices. The “smart” devices are Tasmota converted ESP8266 based products. These generic MQTT things use the MQTT Binding. Some devices are power monitoring capable. The oh-cell’s text fields are used to report the power monitoring data. For example the oh-cell’s footer text might be set to “footer: = ‘Now Drawing “ + items.BNLINKPLUG083E8F7823FishTankLights_Current.displayState”. This works, except openHAB does not update the data in the oh-cell when one thinks it should, like when invoking the oh-cell’s action. The oh-cell’s state changes, but not data like in the footer example. Sometimes the data is up-to-date. Data updating, when it is sometimes consistently working, seems like its delay is consistent with the device’s MQTT “tele period” setting. But I would not want to change that setting. I can cause openHAB3 to instantly update the oh-cell’s reporting by sending the Tasmota “Status 10” command to a particular device or by entering a TasmoAdmin web session utility, which polls all such devices and thereby results in openHAB3 instantly updating data from every such device. TasmoAdmin’s web interface apparently repolls when its web interface page becomes active in addition to responding to device state changes when its page is already active. That is what I have expected openHAB3 to do. What additions or changes should I do? I have plans for sensor data from more generic MQTT devices that I would expect more confidence in their currency.
Thank you
This openHAB version 3 is running in Docker on a lightly loaded RPI4.
Why not? That’s what it is for. If you want the data more frequently, get the device to send it more frequently.
Polling is something to be avoided when possible, on its face it takes double the transactions across your network to get the same info as autonomous/unsolicited reporting.
The ideal is “tell me when it changes”, which I believe can be achieved with custom rules in Tasmota, but I don’t know how.
Ok, I tried this suggestion, but it did not make any difference. I have yet to subscribe to the MQTT messages to actually know for sure what messages are sent and when they are sent. There is a flakiness that has me wondering exactly what is going on.
I was hoping for a definitive response like, “Yes, what you see is normal.” or “No, you need to do …”.
No, I do not want these devices automatically sending status messages at a more frequent rate even though it probably does not amount to much more traffic. Going the Tasmota rules route has been Plan B and I have started to think about it as roughly: On State change, Wait a tiny bit for circuits to settle, then Self command a Status 10 if such is possible.
The UI widgets are always going to show the state of the Item as it is right now. If invoking the action doesn’t cause the Item to change state, it’s not going to change state in the UI. How would it know what to change to?
Correct, the device publishes its current state, OH subscribes to that and updates the Item accordingly. The UI isn’t going to be able to invent information about the device out of thin air. If you are polling on the data instead of having the device push changes then the Item isn’t going to update any faster than the polling period.
But you are using the Generic MQTT Thing. As the name implies, it’s generic. It’s not the Tasmota MQTT Thing. That refresh behavior you describe is strictly a Tasmota behavior. It’s not something implemented by MQTT.
MQTT as a technology is designed as a push technology. The sensors know when it’s the best time to publish their sensor readings and so they independently publish their readings when they know its best. openHAB is the subscriber in this case and it will always have the most up to date sensor reading published.
One can implement a polling feature where a client publishes a message that all the sensors subscribe to and causes them to publish the current reading in response. But that’s all on you as the developer of the system that uses MQTT to implement. That’s not part of MQTT as a protocol because that’s not how it’s intended to be used.
You’ll have to create an Item to send a command to that will cause a message to be published to some topic that your sensors listen to that will cause them to publish their current readings.
