Version OH2.5 , rrd4j running with default config.
rrd4j compacts data over time. Generally Item states are persisted at 1 minute intervals into an archive that covers only 8 hours. The next archive is auto created with averaged data at 4 minute intervals covering 24hrs, next archive 14 minute intervals covering a week, etc.
These archives may be viewed as boxes of defined timeslots or cells. if no data was recorded for a given timespan (there is a gap in the data) any archive may have one or more cells populated with NaN representing 'empty'.
Example data with gaps/NaN in this discussion thread
https://community.openhab.org/t/rrd4j-historicstate-and-nan-gaps-in-data/103342
While my non-fulltime development systems has more gaps than most, gaps of several minutes can arise for any user simply during upgrade or reboot.
This is all working as expected.
Persistence offers method myItem.historicState(someInstant) for use in rules, to recover the recorded data at a past instant in time. The returned object includes stored state, and timestamp of the record.
In most cases, there will never be a record for the exact instant requested - the persistence service instead fetches the immediately preceding record in time, which may be some minutes or days earlier, but is presumed to be the state still in force at 'instant'.
For rrd4j this works as expected only where the next-previous record is a valid record.
But if the target instant falls in a "gap", the next-previous record may be NaN. In this case persistence service looks no further and returns null to the user rule, as though no data is available.
The expected behaviour here would be as for other persistence services - historicState() should reach back in time as far as is necessary to find the next valid data, passing over NaN cells.
Alternatively, returning an historicState object with state UNDEF but the correct timestamp of the NaN cell would at least allow users to make there own management arrangements.
I do not know if this issue belongs with rrd4j add-on or more generally in the persistence framework.
Version OH2.5 , rrd4j running with default config.
rrd4j compacts data over time. Generally Item states are persisted at 1 minute intervals into an archive that covers only 8 hours. The next archive is auto created with averaged data at 4 minute intervals covering 24hrs, next archive 14 minute intervals covering a week, etc. These archives may be viewed as boxes of defined timeslots or cells. if no data was recorded for a given timespan (there is a gap in the data) any archive may have one or more cells populated with NaN representing 'empty'. Example data with gaps/NaN in this discussion thread https://community.openhab.org/t/rrd4j-historicstate-and-nan-gaps-in-data/103342 While my non-fulltime development systems has more gaps than most, gaps of several minutes can arise for any user simply during upgrade or reboot. This is all working as expected.
Persistence offers method myItem.historicState(someInstant) for use in rules, to recover the recorded data at a past instant in time. The returned object includes stored state, and timestamp of the record. In most cases, there will never be a record for the exact instant requested - the persistence service instead fetches the immediately preceding record in time, which may be some minutes or days earlier, but is presumed to be the state still in force at 'instant'.
For rrd4j this works as expected only where the next-previous record is a valid record.
But if the target instant falls in a "gap", the next-previous record may be NaN. In this case persistence service looks no further and returns null to the user rule, as though no data is available.
The expected behaviour here would be as for other persistence services - historicState() should reach back in time as far as is necessary to find the next valid data, passing over NaN cells.
Alternatively, returning an historicState object with state UNDEF but the correct timestamp of the NaN cell would at least allow users to make there own management arrangements.
I do not know if this issue belongs with rrd4j add-on or more generally in the persistence framework.