Using RRD4 with COUNTER and value that may reset

Add-ons Persistence Services
1

Hi
I would like to do a graph of a value that is increasing. (Zwave start frames)
However when OH restarts the counter will reset and start from 0 again.
I tried to do this with a rr4dj.cfg configuration like this.

updated5min1HourAvg.def=COUNTER,1800,0,U,300
updated5min1HourAvg.archives=AVERAGE,0.5,1,288:AVERAGE,0.5,12,43800
updated5min1HourAvg.items=ZWave_controller_start_frames

This works fine until the OH restart then I get a single value that is very large (around 14.300.000). This value destroys the graph.
I know I can set a max on the graph Y axis that will prevent this. But I would prefer not to have strange values in the DB in the first place.
I guess the values originates from the counter decreasing and RRD4 not being able to handle this, but can anybody confirm this?
To me this makes the COUNTER function in RRD4 kind of useless, because most counters would have a scenario where they may get reset. For instance network traffic from a router that is used as example in the docs, if the router is reset this would also happen.

So is there anybody that knows a way to make the RRD4 COUNTER work with a value that normally does not decrease.
When I made the configuration I expected the decreasing value to just be ignored or set to 0.
What would happen if I set a MAX value of like 10.000 what value would then be stored ?

2

Did you get the solution?
I have the same problem, my ESP8266 is publishing the total volume of water that is passing through the flow sensor. I would like the water consumption to be something that keeps increasing its value as there is the flow, and if the system restarts, it restores the previous value and continues adding the volume of water that passes through the sensor.

In my case, the counter is zero. =//
I don’t know what to do anymore.

3

I did not find any solution I decided to live with the occasional high value.

4

Although I do not use rrd4j with a COUNTER I question that the observed resetting of the items state to zero is caused by rrd4j.
Are you using any technique to restore values on startup? If so, which? Did you somehow check the actual values of the persisted item ( other then looking into the persisted values)?
If you are using rrd4j to do the restoreOnStartUp, think about what values would be restored. The COUNTER persists the DIFFERENCE only!

IMHO the observed could be caused by the items value being reset to zero ( for example the persisted difference), in this case the rrd4j COUNTER is correctly showing this large difference.

5

Hi

Thanks for you reply.
I do not have any restoring of the state. My rrd4j.persist file has this line:

ZWave_controller_frames_acknowledged, ZWave_controller_start_frames : strategy = everyChange, everyMinute

For the record I changed my rr4dj.cfg configuration file a bit but this did not change anything.

updated5min1HourAvg3.def=COUNTER,1800,0,U,300
updated5min1HourAvg3.archives=AVERAGE,0.5,1,288:AVERAGE,0.5,12,744:AVERAGE,0.5,288,3650
updated5min1HourAvg3.items=ZWave_controller_start_frames,ZWave_controller_frames_acknowledged

When I query the database by opening "http://<host_ip_and_port>/rest/persistence/items/ZWave_controller_start_frames?starttime=2022-04-13T07%3A42%3A48.296Z&endtime=2022-04-14T07%3A42%3A48.295Z
I get the json that looks like this:

…{“time”:1649920800000,“state”:“35.0”},{“time”:1649921100000,“state”:“14133172.653333334”},{“time”:1649921400000,“state”:“75.0”},…

So for me it looks like the the extreme value originates from rr4d, but is the other ways I can check this ?

The item value is reset to zero by the Zwave binding. But my point is that almost all counters would have some reset to 0 scenario and for me it would make more sense to handle this in a distinguhable way. Either set it to 0 or maybe always return -1 as this value would never be possible in case the value actually is always increasing or maybe not store any value. There are many solutions that I think would work much better than returning some random huge number.

6

What make you think that this is a “random huge number”?
In order to see the directly stored values as opposed to consolidated values you better query your database for a timeframe within the range of your archive 1. All other values are consolidated, in your case it would be an average.
Additionally please try to define what YOU want to be persisted and compare it with what you defined.
Looking at your setup I see:
Used Datatype COUNTER
Fom the docs:

Please note that the persistence extensions will return difference instead of the actual values if you use this type; this especially leads to wrong values if you try to restoreOnStartup!

In other words the COUNTER will store only the difference between last and actual value! Resetting the items value will produce false entries since rrd4j doesn’t “know” you did reset ( your binding did that). Additionally the rrd4j COUNTER is by design only for

ever-incrementing values.

Used archives:
You did define more then one archive. By that you defined that the stored values ( of archive 1) are consolidated. You selected AVERAGE as the function to do that, are you comfortable with seeing the averagei increase over a longer period? If not, why not select another consolidation function ( like MAX, MIN or LAST) or even skip the consolidation and have a single archive only?

1 Like
7

Hi

Well I guess its not random it just did not make a lot of sense to me.
I did a bit of digging and found that the number properly originates from this code.

                    double diff = newValue - oldValue;
                    if (diff < 0) {
                        diff += MAX_32_BIT;
                    }
                    if (diff < 0) {
                        diff += MAX_64_BIT - MAX_32_BIT;
                    }
                    if (diff >= 0) {
                        updateValue = diff / (newTime - oldTime);
                    }

So the number is 2^32 minus the value before the reset divided be my update interval of 300 seconds. ( in my opinion close to random :slight_smile: )
Anyway it is clear that this is to handle 32 or 64 bit integer wrap arounds. This is fine but in my opinion having a datatype that would handle occasional resets would be more useful.
My graph is showing number of Zwave frames for every 5 minutes or the average frames pr 5 min over an hour or day. For me this works fine.
I guess I will just have to live with the occasional huge number.