Chart won't show all data

Setup, Configuration and Use Items & Sitemaps
21

I am using two different databases in rrd4j, one is logging up to a month (PriceLogger), the other up to a year (TempLogger). Both are working as expected.

Here are the rrd4j.cfg lines used:

PreisLogger.def=GAUGE,90,0,3,60
PreisLogger.archives=MAX,.5,1,1440:MAX,.5,5,2016:MAX,.5,15,2668
PreisLogger.items=E10_1,E10_2,E10_3,E5_1,E5_2,E5_3,Diesel_1,Diesel_2,Diesel_3
TempLogger.def=GAUGE,90,U,U,60
TempLogger.archives=MAX,.5,1,1440:MAX,.5,5,2016:MAX,.5,15,2668:MAX,.5,240,1460
TempLogger.items=Temperature,CPUTemperature,Light_TH_Temperature,Light_TH_Humidity,CPU_Load,Memory_Used

Some notes: The last value first line (.def) of each database definition state the “step”, the number of seconds between each data entry. In my case lways 60 seconds (as it is supposed to be).
The other lines define the actual archives and the logged items.

@Bernhard82:
Your log entries show a “step” size of 30 (sensors), 3600 (default_other) or 60 (default_numeric). Used for your items should be the “sensors” one , however none of those settings correlate with the observed 210 seconds!
What is even more suspicious is the fact that the used database (sensors) has only 2 archives which cover 365 minutes with a resolution of 1 minute and 42.5 houres (7*365) with a resolution of 7 minutes.

22

@H102: Thx. I tried your config. It didnt change much however :frowning:

@opus:
I set up my rrd4j.cfg file to look like this:

Sensors.def=GAUGE,60,U,U,60
Sensors.archives=AVERAGE,0.5,1,480:AVERAGE,0.5,4,360:AVERAGE,0.5,14,644:AVERAGE,0.5,60,720:AVERAGE,0.5,720,730:AVERAGE,0.5,10080,520
Sensors.items=SonoffB13_T1,SonoffB13_T2,SonoffB13_T3,SonoffB13_T4,SonoffB13_T5,SonoffTH01_T,SonoffTH01_H,OctoprintPrinterBedTempTarget,OctoprintPrinterBedTemp,OctoprintPrinterHotEndTempTarget,Oc$

after reboot the config is loaded.

According to the logfile it should write a value every minute:

2018-07-22 10:05:00.135 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.5' in rrd4j database

2018-07-22 10:06:00.137 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.4' in rrd4j database

2018-07-22 10:07:00.125 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.4' in rrd4j database

2018-07-22 10:08:00.119 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.4' in rrd4j database

2018-07-22 10:09:00.098 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.5' in rrd4j database

2018-07-22 10:10:00.143 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.3' in rrd4j database

2018-07-22 10:11:00.107 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.4' in rrd4j database

2018-07-22 10:12:00.184 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.4' in rrd4j database

2018-07-22 10:13:00.116 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.3' in rrd4j database

2018-07-22 10:14:00.163 [DEBUG] [sistence.rrd4j.internal.RRD4jService] - Stored 'SonoffTH01_T' with state '34.4' in rrd4j database

but when I look at it through the REST API I only see an entry every 4 minutes now:

{"time":1532245440000,"state":"34.2999999999999971578290569595992565155029296875"},
{"time":1532245680000,"state":"34.32499999999999573674358543939888477325439453125"},
{"time":1532245920000,"state":"34.2999999999999971578290569595992565155029296875"},
{"time":1532246160000,"state":"34.3250000000000028421709430404007434844970703125"},
{"time":1532246400000,"state":"34.39999999999999857891452847979962825775146484375"},
{"time":1532246640000,"state":"34.5"},
{"time":1532246880000,"state":"34.42500000000000426325641456060111522674560546875"},
{"time":1532247120000,"state":"34.39999999999999857891452847979962825775146484375"},

I cannot tell, is this behaviour maybe normal? I mean, thinking about storage, it would be clever to not store every value if it is identical to the one before.

23

REST API does show that for me:

{
  "name": "E10_1",
  "datapoints": "1440",
  "data": [
    {
      "time": 1532171580000,
      "state": "1.47900000000000009237055564881302416324615478515625"
    },
    {
      "time": 1532171640000,
      "state": "1.47900000000000009237055564881302416324615478515625"
    },
    {
      "time": 1532171700000,
      "state": "1.47900000000000009237055564881302416324615478515625"
    },
    {
      "time": 1532171760000,
      "state": "1.47900000000000009237055564881302416324615478515625"
    },

So I get a reading every 60 seconds.ATM I’m out off clue for your case.
Reference the point that it would save space when not persisting identical values, rrd4j does need them in order to compute the different archives. Additionally rrd4j is saving the space by NOT keeping the minute wise data in the archives above 1. In your setup only the last 480 minute wise values are kept, or better should be kept if it would work as expected.

EDIT:
I made a (or better the usual) rrd4j mistake. I guess you made REST API call without setting the time, by that you are getting by default the last 24 houres. Rrd4j will always use that archive that fits the desired timeframe, in your case it is not archive 1 ( which is the only one holding data for every minute ). So what you are seeing is correct.
Do a REST API call for less or equal the timeframe covered by your archive 1 and you will see the minute wise data!

24

oh my god … I was in the middle of installing openhab on a spare sd-card when I read this.

yes … I was doing the REST API calls without the time … and yes when I do it with a correct timestamp I get 60-second values.
Thank god!

Btw for everyone else coming to this thread looking for a solution to a similar problem:
If you have changes the rrd4j.cfg file openhab still has that configuration somewhere. I have yet to find out where. just change the configuration you had to look the same as default_numbers.

last but not least: the REST-API URL to a valid “60second-search”:
http://openhabianpi:8080/rest/persistence/items/SonoffTH01_T?serviceId=rrd4j&starttime=2018-07-22T14:40:00&endtime=2018-07-22T18:00:00

Thank you @opus and @H102! I will see in 24h if the problem is solved but I am quite confident that it finally is :slight_smile:

1 Like
25

Thank God I didn’t fell asleep after the Kickbike tour. That problem kept me awake!:blush:

1 Like