Dear Community
I’m having an random issue where extreme high values of certain Items are stored in the persistence service rrd4j. The logging show the following details whereby the Item values look fine.
Item ‘MKLeveringT2Hoog’ changed from 1907022 to 1907023
In this case I would expect the value to be stored as 1 as the item is configured as COUNTER
Looking at the value 1.1442138E8 that is stored in rrd4j its way off.
2024-04-16 18:40:02.065 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored ‘MKLeveringT2Hoog’ as value ‘1.1442132E8’ with timestamp 1713285600 in rrd4j database
2024-04-16 18:40:18.108 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘MKLeveringT2Hoog’ changed from 1907022 to 1907023
2024-04-16 18:40:19.504 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored ‘MKLeveringT2Hoog’ as value ‘1.1442138E8’ with timestamp 1713285618 in rrd4j database
2024-04-16 18:41:01.991 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored ‘MKLeveringT2Hoog’ as value ‘1.1442138E8’ with timestamp 1713285660 in rrd4j database
2024-04-16 18:41:18.155 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘MKLeveringT2Hoog’ changed from 1907023 to 1907025
2024-04-16 18:41:19.594 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored ‘MKLeveringT2Hoog’ as value ‘1.144215E8’ with timestamp 1713285678 in rrd4j database
The persistence strategies
// persistence strategies have a name and definition and are referred to in the “Items” section
Strategies {
everyMin : "0 * * * * ?"
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
// if no strategy is specified for an Item entry below, the default list will be used
default = everyUpdate
}
/*
* Each line in this section defines for which Item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* Item (excl. the group Item itself).
*/
Items {
MKVerbruikT1Laag, MKVerbruikT2Hoog, MKLeveringT1Laag, MKLeveringT2Hoog : strategy = everyMin, everyHour, everyDay
AllMyItems* : strategy = everyUpdate, everyMin, everyHour, everyDay
}
There is no such thing as a counter type item, the only valid type is a ‘number’.
How that changes depends on the channel the item is linked to (or rules that ‘count’ i.e. set it if no such channel).
Persistence including rrd4j is only ever storing what’s in the item state so start looking there rather than in the db (events.log for when the item changes, openhab.log for why, eventually you need to add loggings to your rules to find out why).
My bad.
The Items values are Numbers.
The way these numbers are treated in rrd4 is as COUNTER.
As far as I understand the difference between two consecutive values is stored in rrd4j as long as there is no negative outcome.
The Item state is looking good and has the correct values.
In the example : 1907023
which is exactly the value I receive from the sensor.
However when rrd4j persists this Item, the value is way to high , 1.1442138E8
In the example, I would expect rrd4j to persist a value of 1 (1907023 - 1907022)
Most of the time, the values are good, but a few times a day, this extreme high values is stored in the rrd4j DB.
Using RrdInspector to read the DB , I can see the high values and correct them but this is quite annoying.
No, except maybe that you should not be messing with rrd4j config. I wouldn’t know if your config is valid at all or causes this (very likely the cause is in rrd4j because as you say the OH item values are fine).
That’s beyond OH scope, and I don’t see the point in deviating from OH default install (= NO rrd4j.cfg), so why at all ? Anybody is using standard setup with counter-like items like kWh in energy meter.
Hello Jan,
Conversion to 1.1442138E8 is not obvious, this is for sure value retrieved from rrd. Sadly, rrd4j persistence does not “print” raw value it calculates from item state. Is your item a Number:Energy or just a Number?
Also, internal representation of numbers within openHAB rely in some cases on BigDecimal which might result in some semi-random after-comma parts. AFAIR it was discussed to increase precision, of calculations on OH end, but again might interfere with what you see. Without knowing internal representation of your item state its not clear, it could be that rrd4j really saw such difference. Change state description pattern of your item to %f and compare what you see there.
Hi Lukasz,
Thx for jumping in.
The Item is just a Number.
Meanwhile I have linked a new Item to the same channel from where I get the values.
This Item is not falling into the Counter group for rrd4j but in the normal persistence…
The value for this new Item is stored as it’s shown i.e. 1912919 in the rrd4j db.
The value for the existing Item (considered as Counter) is stored as a very high nmbr. ie. 1.1442138E8
I think it’s related the the RRD DsType being a COUNTER.
All the values are processed with this high number every 60 seconds but the difference between the new value and the previous value is small and seems to be correct.
What I’m thinking of right now , is that when the previous value is not found or 0, the stored value will be that very high number.
ToBe Continued.
Example of the error on the rrd4j DB. Retrieved with RrdInspector Tool
|1713295980|Tue Apr 16 21:33:00 CEST 2024|2.1000000000E01|
|---|---|---|
|1713296040|Tue Apr 16 21:34:00 CEST 2024|1.6000000000E01|
|1713296100|Tue Apr 16 21:35:00 CEST 2024|1.7000000000E01|
|1713296160|Tue Apr 16 21:36:00 CEST 2024|1.7000000000E01|
|1713296220|Tue Apr 16 21:37:00 CEST 2024|1.7000000000E01|
|1713296280|Tue Apr 16 21:38:00 CEST 2024|7.1582052267E07|
|1713296340|Tue Apr 16 21:39:00 CEST 2024|7.6900000000E02|
|1713296400|Tue Apr 16 21:40:00 CEST 2024|1.6000000000E01|
|1713296460|Tue Apr 16 21:41:00 CEST 2024|1.6000000000E01|
|1713296520|Tue Apr 16 21:42:00 CEST 2024|1.6000000000E01|
