Historic state updates from bindings

[wborn]

With the implementation of eclipse-archived/smarthome#1872 there is now some basic infrastructure for handling historic state. However there still seems to be no API for historic state updates from bindings.

Ofcourse to get it all working there also needs to be a ModifiablePersistenceService implementation for this.

See also:

• OH community discussion
• Historic state updates from bindings eclipse-archived/smarthome#4765

[wborn]

The bounty has also been migrated from ESH! After closing the ESH issue I claimed it myself. 💵

[simon-lgb]

I have run into this issue while experimenting with bindings. After reading the related issues, as far as I can tell, no progress has been made on this? Would it still make sense to implement ModifiablePersistenceService?

There is one main issue I can think of: Bindings usually do not work with items directly. I think there either needs to be an easy way for bindings to figure out what items new states should be persisted to, or ideally an option to provide historic states directly to channels (although I think that would require a lot more work).

I think the best way forward would be to start compiling a list of all persistence services that could implement ModifiablePersistenceService and work with their maintainers? That would solve half of the problem and as the REST API already has the capability to work with these services, it would actually add some improved functionality by itself.

[wborn]

There hasn't been any progress so far and I think the ModifiablePersistenceService interface can still be used for this. We would probably still want to hide the Items from ThingHandlers and let the framework figure out which Items are linked and have what persistence configured. I.e. we could add some methods similar to the updateState(...) methods, e.g. historicState(...) which would have the same method signature but also have a ZonedDateTime parameter.

This issue is about providing the API in the core. The persistence add-ons can already implement a ModifiablePersistenceService interface today, although it is not very useful since you can only use them with REST calls currently. 😉

My use case for this would be to store historic state into persistence in the event that my openHAB instance was offline for some reason. Then when it is up and running again, the binding can request missing historic state from devices and persist it using this API. That way I would be less bothered about downtime. 🙂

[marvkis]

Hi. I just stumbled over ModifiablePersistenceService while looking for some entry-points for my idea. As it seems to be a different use-case, I write my idea / user-story. Maybe when there is design-work done on this API this idea could also be kept in mind. To my idea:

I plan to bulid some kind of Energy-Management system for my home working with predictive / forcast data. This data is a forcast for 'good' electrical energy (i.e. from corrently, as Visual or API/JSON) to schedule the operation hours of 'planable consumers' like washing mashine, heat pump, car charging.. An other use-case: weather-forcast data. When there is a temperature-forcast accessible I could pre-calculate the energy required for heating. And an air based Heat-Pump is most efficient during the time of day with the highest outside temperatures - so why not heat up the warm water storage buffer (vessel?) during these hours and fill up some further thermal energy storage for the cold night hours?
It also seems the future we will bring electricity tariff's with different prices throughout the day - so i think those things might become quite interesting.

Okay, mapping it down to OH: I think @wborn's concept might also work for future data - the ZonedDateTime parameter is just a timestamp in the future in this usecase. But how to handle 'updates'? (We get a new value for a point where already have a value stored). I think in the 'forcast data' scenario it would be okay to just override the existing value. But is it also okay when updating 'historic' data? Or might there be some calculation like average between existing / new data? Haven't spent mouch thoughts on this yet...

The next part in the puzzle is: how to access the forcast data? Okay, at the current (quite early) state it would be great to have it accessible in the rule / scripting context. Maybe something like a PersistenceExtension.getAllStatesBetween(...) similar to PersistenceExtensions.getAllStatesSince(). But when things evaluate there might be add-ons / bindings with the need to access those data. I.e. an add-on for scheduling car charging or other 'planable power consumers'. So it would be great to have a way to query the data form an add-on - but I currently have no idea how to solve this without an add-on having knowledge about the item to query.

Is my idea a possible use case or is it to abstract?

[J-N-K]

@wborn I just had a look if this could be implemented. The historicState(ChannelUID, State, ZonedDateTime) looks doable, I have two possible ideas how to implement that.

But unfortunately it is only half of what you would need for your use-case. You would need a way to determine what is the last state/timestamp that was persisted through this channel. That's very difficult because a single channel can be linked to different items (which may or may not be persisted on different occasions) and one item may be linked to different channels (e.g. a String item could be linked to several channels providing messages where only the last message is relevant for the user. The persisted values would then be a kind of log, but the last persisted state may not be from your binding and you would still lose states when you resume persisting there). Of course this is not necessary, when the binding can determine by itself what needs to be added (e.g. because the remote system knows which values have been retrieved in the past).

[seime]

@marvkis Please see a more blunt approach here; openhab/openhab-addons#12935 that does not require changes to core (but more implementation in each binding)

[altaroca]

I had a need for this feature and implemented it here #3000.
What is my use-case? There are states which devices only expose after the fact (e.g. power consumption per month/day/hour). Using a normal state event those can be persisted. But due to some latency they will then persist some seconds after the beginning of the new month, let's say 2022-06-01 00:00:25. With direct access to historic states the time can be passed along and the data persisted correctly at 2022-05-31 23:59:59.999. Also I'd like the ability to automatically add previous intervals if the first reading was missed.

[wborn]

Sounds like exactly the same use case I have @altaroca, so it is very nice of you to create a PR for this. 👍 I'm also planning to use this with influxdb so if there is a PR for implementing ModifiablePersistenceService with influxdb (openhab/openhab-addons#12013) that would also help. 😜

I just noticed there is openhab/openhab-addons#12935 for this. 🙂

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/update-things-channel-with-timestamp/143413/2

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/using-persistenceservice-in-binding/143477/9