Charts via rrd4j - stopped filling persistence

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 “*”.

Yes, that should be obvious. Maybe @akashkumar will tell us :smiley:

He will have this rrd file, just because he did a REST call to it. It gets created by this, I have no idea why ( filed an Issue last year).

1 Like

So it seems I was a bit hasty in assuming that the error was fixed. Apparently, after clearing the cache only the initial values were stored for all the values that I tested. Thereafter, the same problem reappears, i.e. only a few values are being stored, as visible in the graph below.

Perhaps that is the problem indeed. Initially I only started out with 50+ items, so I thought it would be fine. Maybe with 200+ it is reaching its limits. I do have an SSD attached (through an external hub) though, so normally it shouldn’t be a problem, but then who knows!

Which persistence services do you have installed?
Is rrd4j set as the default service?

My apologies. I wasn’t aware of that but even the other values aren’t stored. I had checked other values then too. Here is a log of another parameter. It seems only some values were stored after clearing the cache:
{"name":"Masterbed_Temperature","datapoints":"10","data":[{"time":1587630960000,"state":"21.0"},{"time":1587631200000,"state":"21.0"},{"time":1587631440000,"state":"21.0"},{"time":1587631680000,"state":"21.0"},{"time":1587631920000,"state":"21.0"},{"time":1587632160000,"state":"21.0"},{"time":1587632400000,"state":"20.934444444444445"},{"time":1587632640000,"state":"20.8"},{"time":1587632880000,"state":"20.8"},{"time":1587633120000,"state":"20.8"}]}

I can confirm that new values were collected by openhab (when I grep for this element in events.log), but not stored. As mentioned earlier, the timestamp still corresponds to the most recent element value read by Openhab, and NOT of the content in the rrd file.

Well, the graph is still using those files. It just seems that when using the REST URL, there is a default time start used. When I chose an earlier date to start showing the values, they were all there. Of course when I remove the old files, that data is not shown.

Sure, but I can really confirm that for some elements all data is stored, while for the rest, no updates are made, just file time-stamp is updated.