How to handle historic values from an API service

Hey all,

I am working on a new binding for a service that is offering data for up to two years in the past using from-to parameters up to today-1.

The question now is how to go about doing this in a binding. Should I have the from and to as binding parameters? Maybe just from and up to today-1? How to persist historic data since each value has its own timestamp so it is not saving only value but a value timestamp pair? Is there any similar binding where I would see how this is done?

Thank you for all your help,

Ziga

I know of bindings that will store future values in persistence, so access to persistence should be too much of an issue from a binding in general, but I think that only works for the in memory persistence. OpenWeatherMap and Tibber are two such bindings I know use this.

I’m not aware of any bindings that save past values. And you can run into trouble because mapdb and rrd4j won’t work at all (mapdb only saves one value, the most recent and the way rrd4j compresses the values as they age make it so you can’t alter/add data that is older than that first bucket). Another complication is what to do when the user has more than one persistence configured. Which one to save the values to? What if the user doesn’t want the old values saved?

Since this would only need to be done once, I think the best approach would be to create a Thing Action. Calling the action from a rule will returns a TimeSeries of all the values between the times the user passes to the Action. Then the user can persist the TimeSeries using .persist on the relevant Item and specify which DB to persist the data to.

In JS it would look something like:

const zigasBindingActions = actions.get('zigaBindings', 'id:of:relevant:thing');
const timeSeries = zigasBindingActions.getHistory(time.toZDT('P-2Y'), time.toZDT()); // between two years ago and now
items.MyRelevantItem.persistence.persist(timeSeries, 'influxdb');

Presumably MyRelevantItem, is linked to a channel to get updates from now on, so the above lines only need to be run once when first setting up the Thing. It could be pasted and run from the -Scratchpad- Script. In the docs for the binding mention that mapdb and rrd4j shouldn’t be used.

I’m questioning whether that should be a binding at all. It is possible to make a persistence add-on instead, which sounds like would be a better fit. But, there are many details missing that would be needed to determine if it can actually be done.

I would start by studying these interfaces, and see if there’s a way to make that “fit” with the service.

That really depends on the data and what the binding is doing with it. Some more details could be helpful.

You could have a look at Energi Data Service - Bindings | openHAB. This binding fetches data from yesterday until tomorrow. It has a console command for fetching historic data - see Manually Persisting History. So if your need is similar, i.e., fetching data two years back in time is needed as a manual one-time event, then you could do something similar. A Thing action, like @rlkoshak mentioned, would be even more user-friendly, since this is now available in the UI, but both options will allow you to trigger historic persistence with parameters.

That depends on the use-case. If you want to provide a new “engine” for storing data, then yes, but if you want to retrieve data from an API and store that data in one of the already supported engines (such as PostgreSQL, MariaDB, InfluxDB etc.), then a binding seems like the best fit.

Yes, there is too little information about exactly how this is to be used, but I’m still not sure that I understand how a binding would make sense. I mean, a binding provides Things. How would you go about applying those data to other channels/Items? Or maybe that’s not the goal.

As I understand it, the goal is to populate the persistence for one or more Items linked to a Channel on a Thing provided by this binding with the data the service stores and makes available. In short, to import the two years worth of points into OH for charting, etc.

1 Like