Eclipse Community Forums: Eclipse SmartHome » Persistence method to store historical data

Help

Home

Home » Archived » Eclipse SmartHome » Persistence method to store historical data

Show: Today's Messages :: Show Polls :: Message Navigator

Persistence method to store historical data [message #1730566]

Tue, 26 April 2016 16:59

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

I would like to suggest adding a new PersistenceService method -: store(HistoricState), or, store(time, state)...

I have two use cases for this -:
1) A number of devices these days provide an internal storage of historic data, and to conserve battery, it is recommended not to poll the data regularly, but to grab it in slower time. This sort of function is not currently possible as we can only store data with the current time. Some ZWave devices do this, and quite a few BLE devices look like they request this to reduce battery. (AMR devices being a good example here).
2) If we want to aggregate data, for example to store a daily value, it would have to be stored at the end of the day, and would actually be stored with the next days date. I know we can get around this by adjusting the times after the query, but it's not nice.

I appreciate this may not work on all persistence services (e.g. rrd), but I still think it's a useful feature as devices become more complex and feature rich.

Of course, for OH2 there is no persistence defined other than the OH1 API - I'm not sure if there's something completely new planned, either way, I think this ought to be included...

This is just for discussion at the moment - not urgent - but I wanted to throw it in to the pipeline for future consideration.

Chris

Report message to a moderator

Re: Persistence method to store historical data [message #1730568 is a reply to message #1730566]

Tue, 26 April 2016 17:24

John Cocula

Messages: 21
Registered: June 2015

Junior Member

This would be a good feature for some wi-fi thermostats that provide historical data via their own APIs, but there is no "home" for it in Eclipse SmartHome at present. For a binding to periodically retrieve historical datasets from its source and store it alongside other persisted item states would be valuable for cases where the source performs added-value computation that cannot be done otherwise. It would also be valuable to have continuous datasets even over periods when ESH was not running and therefore could not persist item states itself.

A related idea would be that bindings could implement an interface like "QueryableOnlyPersistenceService" (roughly speaking), so the backing store is on the other side of the API/protocol that the binding already implements.

Report message to a moderator

Re: Persistence method to store historical data [message #1730606 is a reply to message #1730568]

Wed, 27 April 2016 05:31

Yordan Mihaylov

Messages: 10
Registered: January 2016

Junior Member

I think this daily store can be part of automation of the system. I mean you can add a rule in rule engine which will be triggered on daily period and will store collected data.

Report message to a moderator

Re: Persistence method to store historical data [message #1730635 is a reply to message #1730606]

Wed, 27 April 2016 09:13

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

Yordan Mihaylov wrote on Wed, 27 April 2016 06:31

I think this daily store can be part of automation of the system. I mean you can add a rule in rule engine which will be triggered on daily period and will store collected data.

Yes, that was my point 2. While this can be done at the moment using a rule, and this is what I've done for the past few years, it's not very nice because the time is stored at the time of generation of the agregated data. This will mean that the data for Today will have Tomorrows date since it will be processed tomorrow. This can be fixed in the display software, but it's not very nice.
To do this properly, the time also needs to be set when the data is stored.

In any case, the real need is for my first point and this is simply not possible now to set the time of stored data. The second point is a (very) nice to have and will be made possible by the introduction of the suggested API to store history data.

Chris

Report message to a moderator