Persistence - maximumSince Different Type returned depending on Timespan?!

Setup, Configuration and Use Scripts & Rules
,
1

I am trying to evaluate the minimal temperature over a given timespan.

Therefore I have the following:
items:

Number:Temperature HEATING_WOHNBEREICH_TEMPERATURE "Temperature Wohnbereich [%.1f %unit%]" <temperature> {channel="mqtt:topic:mosquitto:aqaraTemperatureWohnbereich:temperature"}

Rules DSL excerpt:

val Number historicValuesTimespan = 120
val Number currentTemperature = (HEATING_WOHNBEREICH_TEMPERATURE.state as QuantityType<Number>).toBigDecimal
val Number maxTempInTimeFrame = (HEATING_WOHNBEREICH_TEMPERATURE.maximumSince(now.minusMinutes(historicValuesTimespan)).state as QuantityType<Number>).toBigDecimal
val Number minTempInTimeFrame = (HEATING_WOHNBEREICH_TEMPERATURE.minimumSince(now.minusMinutes(historicValuesTimespan)).state as QuantityType<Number>).toBigDecimal

logInfo(LOGGER, "current:" + currentTemperature + ", max:" + maxTempInTimeFrame + ", min:" + minTempInTimeFrame)

This just gathers the current Temperature and max/min within the last 120 minutes.

So when I set historicValuesTimespan to 1 (1 minute), everything works fine. Log outputs this:

2022-02-26 13:36:47.128 [INFO ] [ore.model.script.heating.wohnbereich] - current:23.27, max:23.27, min:23.27

However 1 minute is not helpful in this case, just shows that in this case, everything seems to work fine, as all variables have assigned a correct value.

Now changing historicValuesTimespan to 120 minutes, I receive an error message:

2022-02-26 13:38:28.923 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'heating_wohnbereich-1' failed: Could not cast 21.72 to org.openhab.core.library.types.QuantityType; line 61, column 38, length 116 in heating_wohnbereich

Line 61 is actually the 3rd line (“minimumSince”).

Anyone an idea what might be causing this error?

2

Meanwhile I mastered it. It looks like there is some special HistoricItem Implementationw with InfluxDB. Depending on the timeframe I suppose the Value from OpenHab is returned or the value from InfluxDB. However these return different types. I created a lambda to cover this:

val retrieveNumberValueFromHistoricItem = [ HistoricItem historicItem |

    val historicItemState = historicItem.state
    
    //As with InfluxDB historicItem returns a "DecimalType in case value is from InfluxDB and QuantityType in case the value is from OpenHab, 
    //we have to decide how to handle it
    if (historicItemState instanceof DecimalType) {
        return historicItemState
    }else if (historicItemState instanceof QuantityType) {
        return historicItemState.toBigDecimal
    }else{
        throw new IllegalStateException("Value from " + historicItem.name + " is neither DecimalType nor QuantitType. Found: " + historicItemState.class.toString)
    }        
]
3

Your OH version might be important here.

Not quite sure what you mean there. You can direct historicState() etc. to retrieve from a particular database - but you haven’t done so.
In that case, it should consistently go to whatever your default persistence service is - which will be rrd4j unless you have changed it.

I’d be surprised if you got much sense out of rrd4j at “one minute” requests, there probably isn’t any data that young.

4

Maybe it’s not interesting anymore, I tinkered a bit and found another solution (rrd4j), which works for me

rule "test persistence"
    when 
      Item Dummy_4 changed to ON
then
    val Long  historicValuesTimespan = 2880L
    val Number currentTemperature = (radiator_valve_03_Temp.state as QuantityType<Number>).toBigDecimal
    val Number maxTempInTimeFrame = (radiator_valve_03_Temp.maximumSince(now.minusMinutes(historicValuesTimespan)).state as QuantityType<Number>).toBigDecimal
    val Number minTempInTimeFrame = (radiator_valve_03_Temp.minimumSince(now.minusMinutes(historicValuesTimespan)).state as QuantityType<Number>).toBigDecimal

logInfo("test min-max", "current:" + currentTemperature + ", max:" + maxTempInTimeFrame + ", min:" + minTempInTimeFrame)

end
5

Comment - for RRD4J, weird stuff happens when NaN records creep into the data. For most users, this might happen when rebooting across a “scheduled” recording timeslot. As you reach further back in time, NaN are less likely to be encountered due to RRD4J unique averaging process.
So far as I know, minimumSince() and maximumSince() are not affected by this, but historicState() is, and potentially others.

Very short timespan (1-5 min) historicState() for RRD4J have their own problems.

I mention these as relevant to OP, in absence of further info.