Persistence problems SQL & rrd4j config

Hey Forum,

I want to work with historic data in my rules to setup some state-machine. Unfortunately I need for my usecase historic data (every change the last 10 minutes).

First try was with the default rrd4j. But it seems there is no way to configure persistence via the UI and the results seem a bit randomly to me. Looking in the charts it seems like not every change is logged and I couldn’t even deduct from the data the methodology / config being used.

Second try was with MariaDB which was better but while debugging I encountered the problem that when I query via persistence the last 10 minutes I get only the changes in the last 10 minutes but it doesn’t return the value active in the last 10 minutes (so if the change was 12 minutes ago and the next one 8 minutes ago the change 12 minutes ago was still active at 10 minutes ago). Bug or Feature?

I guess the behavior I could change by going back to config files for persistence (everything else I could manage in the UI) but I guess there is no way to get around the SQL problem (asside from storing data super oftern so that the problem is minimized), right?

Feature.
If there’s a record for 12mins, that state is assumed to remain valid until the next change comes along (at 8 minutes, here).
Note that this is based on records, not actual events. It’s up to you to choose the appropriate record keeping strategy for your use- everyChange, everyMinute, whatever.

1 Like

That’s true of all persistence services. OH 3 does not yet support configuring persistence through the UI. But rrd4j doesn’t fit your use case anyway because it must save a value every minute in order to work. But, every change should get saved too. So I can’t comment on that.

1 Like

Thanks for your comments, will work on file based config

That was my expected behavior but not how it’s done.

-12min: 9
-8min: 6
-5min: 5

PersistenceExtensions.maximumSince(ir.getItem(event.itemName),

DateTime.now().minusMinutes(10)).state
Will deliver 6 instead of 9 which I had expected

Oh you didn’t say you were using that.
That’s working as designed.
The maximum record since 10 minutes is 6

If you use historicState(“10mins”) you should get 9.
Different purposes.

You could make an enhancement case for max/min to reach back in time, like historicState() does.
It’s arguable which is “best”, but reducing to the simple case - no records at all since time X, would prefer last value from before X to value null?

Counter argument, since the value for you reduced from 9 to 6 it probably wasn’t 9 at 10 minutes but somewhere inbetween. You’re asking for imaginary data.
Same applies tohistoricState() of course, but that comes with a real timestamp that allows you to make your own evaluation of trustworthiness.

2 Likes

I still don’t think that is how it should be :slight_smile: but with the historicState I have a solution (max(maximumSince(10min),historicState(10min))

Thanks for your support