Charts via rrd4j - stopped filling persistence

If you are really want to show data for a year, your custom setup(the one with the smaller size) doesn’t give you that data. It stores data for 300*7 minutes only!!!
The default setup goes longer!
If need assistance for a setup according your needs, just call. I’m using a setup for charts covering 24 houres, a week and 4 weeks. All switchable from the UI.

thanks for your help, I just used the examples provided in the docs… :wink:
So, for me, best would work:

  • accurate setting for the last 48h
  • more or less accurate for the last week
  • could be less accurate for everything else
  • Maximum could be a year or so, just to see it in comparison

I really don’t get the parameters and stuff. I suppose, the .archives= section does this? and you can define more than one configuration with the “:” as seperator? But I don’t get it 100%… So, if you can, please help me out! :wink: :egg:

Let’s take this example:

MyLogger.def=GAUGE,90,0,U,60
MyLogger.archives=MAX,.5,1,1440:MAX,.5,5,2016:MAX,.5,15,2668
MyLogger.items=MyItwm1, MyItem2, .....

First line:
“Gauge”; As stated in the Docs “represents the reading of e.g. a temperature sensor…”
“90”: The “heartbeat”, if no new value is stored after “heartbeat” seconds, the value is considered missing when charting.
“0” : The setting for the minimum value.
“U”: The setting for the maximum value (in this case Unlimited)
“60” The step size, sets the timeintervall(seconds) between consecutive readings.
Second line, the archives, each archive is defined by 4 values:
“MAX”: The “consolidation” function, which is used if more then one value is received during the steps size timeframe (see next point) this function is used to compress the data (in this case the maximum of all values is used, it could also be AVERAGE)
“.5”: “xff”, frankly, I have no clue!
“1”: Steps or Granularity. Steps (not the same as step in the first line!!!) are the number of consecutive readings that are used the create a single entry into the database for this timeintervall. The timeintervall covered is calculated by Step(seconds)*Steps.
“1440”: Rows, the number of Steps that are hold in this archive.
In the example we have 3 archives:
The first is using 1 Steps, which cover 60 seconds(or 1 minute) and holds 1440 values. So archive 1 holds data for 24 houres (24*60 minute Steps ).
The second is using 5 Steps, which cover 5*60 seconds(or 5 minutes) and holds 2016 values. So archive 2 holds data for 7 days (7*24*12 5-minute Steps).
The third is using 15 Steps, which cover 15*60 seconds(or 15 minutes) and holds 2668values. So archive 3 holds data for 4 weeks days (28*24*4 15-minute Steps).
I think the third line doesn’t need any explantion.

Remaining is the problem, why such configuration isn’t used all the time!

1 Like

Ok! Thanks a lot!

rossbuehel.def=GAUGE,600,U,U,60
rossbuehel.archives=AVERAGE,0.5,1,2880:AVERAGE,0.,5,2016:AVERAGE,0.5,15,2668:AVERAGE,0.5,240,8760
rossbuehel.items=RB_MiWeather_Pressure_Kitchen,RB_MiWeather_Temperature_Kitchen,RB_MiWeather_Humidity_Kitchen,RB_MiWeather_Temperature_Outside, RB_MiW

Now I understood, thanks a lot!
I added AVERAGE,0.5,240,8760, which should make a archive for 4h per day for a year, right?

PS: I have only new values every 6-12 minutes, so my heartbeat is 600
PPS: the 0.5 means, if more than half of the time for the heartbeat there’s no data, it’ll be undefined.

I think your calculation went the wrong direction, you are using correctly 240 to make 4 hour steps. However when saving 8760 of those, you have 8760 * 4 hours covered, which equals 4 years if I’m not mistaken.

I forgot to mention that each database can have only one consolidation function, so they have to be the same in all archives.

Thanks for the xff explanation.

I GOT IT!

problem is, the rrd4j.cfg doesn’t allow for spaces in configuration lines! After eliminating the spaces in the items line, it worked!!!

PS: Oh. I don’t mind, if it’s 4 years! :sunglasses:
PPS: you don’t need to restart oh2, deleting the *.rrd files works also

1 Like

Spaces? The ones after a “,”?

Yep. Mustn’t be any…

1 Like

Changed my setup that way and added a database with correct max and min, all files are of the expected size.

A BIG THANK YOU!

Hello everyone,
I know it’s an old thread but my problem seems to be very similar to this one. I am running Openhab 2.5.4 on Openhabian Raspi 3B.

What’s funny is that indeed some values are showing up and some not. I had added a new binding and since then, some of these charts are not being updated like the first one, but the second chart is still being updated. The rrd files for all the values have an updated time-stamp.
Funnily enough, the binding that I added doesn’t have anything to do with the items that are plotted in the chart.

I also tried to remove all the old rrd files, but that didn’t solve the problem - the exact same values were being shown in the chart with the newer files as the older one. The values of the temperature are being updated as evident from the events log file.

Is it possible to check whether the error is in the rrd file writing (by looking at the file content itself) or in the chart plotting?

My rrd config is rather simple as below. Any suggestions?? Thanks a lot in advance!

Strategies {
// for rrd charts, we need a cron strategy
everyMinute : "0 * * * * ?"
        default = everyChange
}
Items {
        * : strategy = everyUpdate, everyMinute
}

Thanks a lot in advance!

That persists every Item of course.
Some Item types cannot currently be persisted … I don’t suppose this mystery new binding involves Location type Items?
That shouldn’t stop the other Items being persisted, but.

Yes, indeed, this implies ALL items are persisted but since it is rrd4j the file sizes are rather small. I have about 250 odd items, so it’s manageable.

The new binding is bsblan (https://www.openhab.org/addons/bindings/bsblan/). I am not sure whether it uses Location type items, but I only have numbers, strings and description items being used by it.

So, in the meantime I figured how to use the Rest API to query rrd4j values. For some items which are still being updated, I got a lot of data but for the others that are not showing changes in the chart, it just returns:

{"name":"gTemperaturePlot","datapoints":"0","data":[]}

This seems to suggest that no data is there but then I still do see old values… Not sure what’s going on.

UPDATE: so after some more playing with Rest API, when I choose an earlier starting date, I do see some data, (see below). As I said earlier the files are being touched by the Persistence since the time-stamps are updated, but the data is not there. Seems like Persistence opens the file but doesn’t actually write to it.

{“name”:“BSBLAN_Abgegebene_Heat_Hourly”,“datapoints”:“11”,“data”:[{“time”:1587420240000,“state”:“0.0”},{“time”:1587421080000,“state”:“0.0”},{“time”:1587421920000,“state”:“0.0”},{“time”:1587422760000,“state”:“0.0”},{“time”:1587423600000,“state”:“0.0”},{“time”:1587424440000,“state”:“2.0”},{“time”:1587425280000,“state”:“0.0”},{“time”:1587426120000,“state”:“0.0”},{“time”:1587426960000,“state”:“0.0”},{“time”:1587427800000,“state”:“1.0”},{“time”:1587428640000,“state”:“0.0”}]}

I should probably add that I updated my Openhab Stable last night to 2.5.4. Could that have caused a problem? Is there something that has changed in the new version which could cause this behavior?

Have you restarted (again) since upgrade? Upgrade rebuilds some cache and seems to be flaky after first boot, missing Items etc. Persistence services are old tech OH version 1, they just don’t do dynamic configuring. So an Item “missing” at persist start up will never be persisted.

Yes!
I restarted the Openhab service once after upgrade… Then rebooted the Pi -> didn’t help. Stopped Openhab, moved all the rrd files, restarted Openhab -> didn’t help. Then restored the old files again and started Openhab service.

So I removed the binding and restarted Openhab, but that didn’t help. I then cleared the cache, restarted Openhab TWICE, since the first time somehow didn’t resolve all the errors. The graphs now seem to be showing the new data as well. Luckily, my old data before persistence wasn’t working is still there! Maybe I will again try with the new binding in the future - perhaps clearing cache may help there as well. For now, I will observe it for some more time and see whether it works correctly.

It’s hard to see how the bsb binding could be involved, when you’ve some Items persisting and some not.
Still feels like an issue when persist starts and builds its list of items to persist (in this case “everything”) at startup time.
I still think selecting everything is lazy :wink: but do not think it would make any difference at all to this problem.

This whole business of flaky start-up process feels like it’s got worse with OH 2.5, with less predictable results.

The conclusion that no data was stored was drawn from a REST call for a group. Such would always give zero data!

? If you removed the old .rrd files, openHAB would have no way showing the old data! Either you removed other files or the graph is not using the files you think.

In order to see the actually minute-wise stored data using the REST API on a rrd4j database you have to limit the requested timeframe to the last 8 houres (assuming your rrd4j setup is using the defaults).

I wondered about that … with the * persist-everything in use, do Group states get persisted? (When they exist - not that any given Group necessarily has a valid state to persist.)

IMHO if a group would be peraisted by rrd4j, a file like gTemperature.rrd would be created which could only have ONE value at a time. But I have to guess that and still believe that only Items get persisted by the use of “*”.