Hello, there!
I want to send previous state via MQTT.
Openhab doc:
1$ item name
2$ item alias as defined in the persistence/mqtt.persist file.
3$ item state: a string representation of the item state. ON/OFF, OPEN/CLOSED and UP/DOWN states are transformed to 1/0 values, respectively.
4$ current DateTime in long format.
Is there some key for previous state?
You cannot query MQTT Persistence from OH. It is write only.
If you use some other persistence you get the previous state using the following in a rule:
ItemName.previousState //the most recent update
ItemName.previousState(true) // most recent state that was different from the current oneWhat do you mean? It’s not possible to get previous state?
So, question to Chris - can i ask you to add it as feature?
like Rick already (clearly) wrote: you can use another persistence service (like rrd4j or mysql or influxdb…etc) to store and retrieve previous or historical states of items.
As a second step, you could send that retrieved state to the broker using the MQTT Action within a rule.
To request a new feature to be added, you can always open an issue on github (search the forum on how to do this)… but… the request should make sense. This is not the case here.
I explain, Dim, why MQTT persistance is the most effective for external applications. When some important event happen it’s required to react immediately. If to use JPA/JDBC/DB persistance - the application must periodically check database for new events. It’s not immediate reaction.
So, the best way for openhab to have HTTP persistance (to send http request), but there is no one. And i don’t see alternative for MQTT.
As a second step, i don’t prefer to create rule with MQTT Action for every thing item. Group association is also is not decision. That why i suggest to improve MQTT persistance as most effective and add additional parameter.
a persistence service is for storing and retrieving item states, not for acting in any other way based on events (e.g. no checks for new events in the DB service)
MQTT is nice and fast but there is a better way to communicate to external services these events/states: the MQTT-EventBus integration.
The MQTT persistence gives you only 1 advantage vs this integration: You can fine tune the selection of the items for which the state will be channeled to MQTT.
Of course, there is always the standard MQTT binding which can be used to publish states/commands immediately (with or without the use of a persistence service)
Yes, and using MQTT persistence is one way to publish Item updates/changes to external applications. But to receive updates/commands from external applications one needs to create Items with incoming MQTT bindings. And in neither of these cases is querying for the most recent update required nor supported.
Persistence is NOT to be used to interact with external applications. Persistence is strictly intended to be by openHAB to store and retrieve historical data about openHAB Items. If you want to use MQTT to receive commands or updates from external entities you should be using the MQTT Binding and/or the MQTT Event-Bus, not MQTT Persistence.
And even if one were to add the ability of the MQTT Persistence add-on to query for historical data, you have the same problem. OH would have to periodically check the database for new events.
I think you are really confused about the purpose of Persistence. I’ll say it again, Persistence is for openHAB to store and query for historical data about openHAB Items.
You want to use Bindings and the REST API. There is an HTTP binding that can send HTTP requests to get information from or post/put information to external servers. There are HTTP actions that let you do the same from Rules. There is a fully capable REST API that allows external services to do almost anything you can think of, including updating and sending commands to Items, via HTTP GET, PUT, and POST calls.
Based on what I understand you are trying to do, Persistence is not the correct tool for the job. You should be using the MQTT binding, HTTP binding, HTTP Actions, and/or the MQTT Binding, not MQTT Persistence.
Thanks for this advice, i’ll read and try.
It’s just your HO. I don’t see criminal to use external HTTP service to store openhab events via HTTP Persistence.
May be it’s incorrect to use Persistence as immediate states changing transport, but i don’t see adequate alternative. Again - to write rules for each item and catch states’ changes and send it via MQTT/HTTP Actions - is not decision.
What is wrong with the MQTT binding?
You can send messages. You can subscribe to and receive messages. If you use the event bus you can send and receive messages on all of your items. There is no polling. There is no delay.
Neither dim nor I have mentioned anything about rules
The correct answer is to use the already existing proper binding than to add capability to the MQTT Persistence add on that will let you misuse it to do what is already supported in the bindings.
Rich, for now MQTT persistance send all items’ state changes without any configurations. As i understand, to use MQTT binding I need to configure each item in my system. For me it’s easier to cache previous state at external application.
One more question, please. I saw somewhere it’s possible to change 0/1 state values in persistance? To have ability to send ON/OFF, OPEN/CLOSED and UP/DOWN states.
No, if you use the Event Bus configuration all your Items will be published without creating separate Item configurations. Plus, if you publish back to the right topic from your external devices then your Items can be updated or commanded from outside OH.
No. Persistence has nothing to do with this. You can change how it appears on your sitemap using a transform on the Item’s label using a transform. Or you can change the value itself using the Transform field for MQTT Items that you define individually.
If you need to transform the messages that are sent you must define an Item with an MQTT binding for each Item you want to publish.
Hm. Very interesting. Thanks for your advice, Rich. Let me try it.
Ok. MQTT event bus - alternative to MQTT persistance. But…
statePublishTopic - When available, all status updates which occur on the openHAB event bus are published to the provided topic. The message content will be the status. The variable ${item} will be replaced during publishing with the item name for which the state was received.
Again, i don’t have previous state.
I’m not sure that I understand what you are trying to do. The MQTT event bus will publish changes to all OpenHAB items to the configured topic, and allow you to control all OH items via MQTT as well. This will allow you to keep another program in sync with OH, or control OH via anything that speaks MQTT.
If whatever your trying to tie to OH is subscribed to the event bus topic, it will have received any item state changes when they happened and can do whatever it wants with that information. Why do you need to resend the previous state?
Then please describe in detail what you are trying to accomplish because nothing you have mine this far points to using previous state.
Everything you have mentioned thus far is related to having OH communicate with an external program.
Right now you are saying “I need oranges, my bicycle won’t move.” It makes no sense.
Ok. In my case I need to know is the item state greater or less than the previous one. Was it reduction or increase of some item state (like temperature).
This is just additional information, feature, if we talk about event bus. Current state is not enough to initialize any event exclude “The item state was changed to <>”.
The problem is already solved this way.
The proper solution is to use a queriable persistence. MQTT Persistence is not designed to support queries. Adding this support is no trivial and would require an almost complete rewrite if the add-on, largely because there is no storage to pull historic data from in the MQTT broker.
You can use any of the persistence addons except MQTT, MapDB, and rrd4j if you have non-numeric Items.
SQLite is embedded and doesn’t require running anything external. InfluxDB is poplar because it works with Grafana for nice charting.
All changes or updates to persisted items get saved immediately. In the slowest of circumstances the data is available in rules within 100 milliseconds.
Surely impossible in my case. Any database require the periodic database request to get new states. It’s not interactive way.
I think I understand what you are trying to do and if I’m correct it is impossible and will never be possible until a 2.0 version of the MQTT binding is completed that supports automatic discovery.
What you want to do is just say “hey, I’m using MQTT, create all my Items for me”. This can’t be done. You must create all your Items.
Your focus on the MQTT Persistence, even it if supported quering is misplaced because Persistence in OH is stricly about HISTORIC DATA which is available to Rules only. You can’t drive OH through Persistence. All you can do is save historic data, create charts from that data, query that historic data to make decisions in Rules, and in the case of the MQTT Persistence Addon, publish the changing states of Items in OH to MQTT topics.
It all runs on Items. You cannot create Items from Persistence, Persistence REQUIRES the Items in order to work.
The only way to have interactive communication between MQTT clients and OH is to create MQTT Items. There is no short cut. Adding the ability to query in the MQTT Persistence Engine will not help you.