averageBetween and sumBetween is undefined for NumberItem

I’m trying to get an average over time for a number item. My first issue is that the average seems to break when there are future values in influxdb. I get the following:

2022-10-31 19:59:43.353 [WARN ] [rg.openhab.core.model.script.average] - 3.860087029475309
2022-10-31 19:59:43.361 [WARN ] [org.openhab.core.model.script.max   ] - 3.32819
2022-10-31 19:59:43.372 [WARN ] [org.openhab.core.model.script.min   ] - 0

When running:

logWarn("average", NordpoolSpotPrice.averageSince(now.minusDays(1)).toString)now.minusHours(1)).toString)
logWarn("max", NordpoolSpotPrice.maximumSince(now.minusDays(1)).state.toString)
logWarn("min", NordpoolSpotPrice.minimumSince(now.minusDays(1)).state.toString)

I say “break” because an average should never be able to be more than max. My guess is that the average algorithm sums all values after the specified time, including future values, but only count the time until “now”.

Then I tried to work around this by using “averageBetween” instead, as described here. Unfortunately this gave the following error message:
The method averageBetween(ZonedDateTime, ZonedDateTime) is undefined for the type NumberItem;

As a second workaround, I thought I’d use sumBetween and divide by the amount of samples, but that gave the same error.

It’s hard for me to understand why “averageSince” should be supported, but not “averageBetween”, so perhaps I’m missing something?

Thanks in advance for any help!

Platform information:

  • Hardware: Raspberry pi 4
  • OS: openhabian
  • openHAB version: 3.3.0.M3
  • Persistence: influxdb

It would not surprise me that OH sums up every value after the given value. OH in general doesn’t really support future values in persistence and there are probably lots of situations where it assumes there wouldn’t be any.

As for averageBetween(), I think that was added after 3.3.0 M3. You should consider upgrading to OH 3.3 release to get it.

I;m not sure that is the case.

In general, there is never a record at exactly the “target” time of any persistence request. So the service assumes the next oldest record is still valid at a later time, unitil updated. Except I think max and min will report actual records, not presumably sustained values.
Example dataset
05:30 10
06:30 5
If we run a rule at 0700 and ask for -
historicState from 0600, we’ll get 10.
maxSince from 0600, we’ll get 5
averageSince from 0600, we’ll get 7.5 or so

Ah, great. I’ll give it a try!

I think I understand what you mean, that theoretically this could happen by one value being included in one case, but not the other. In my case, however, there is no such adjacent value that could bump up the average. I also saw this behavior with “sumSince”, giving much larger value than expected.

If the “between” functions exist in a newer OH verison I’m happy, but let me know if you want me to give more data on this.

While we’re on it, perhaps I should mention that the above “mininumSince” erroneously gives 0 (there is no zero value in my data set), and the timestamp from the returned historic item is exactly 1 day before the execution where no datapoint exists. I’m not planning to use it, but again, I’m happy to dig deeper if it might improve OH.

Confident that you are getting data from influxdb? Your code does not explicitly request this, in OH3 it would by default query rrd4j.

It’s only just sunk in with me that you refer to “future values”, so it’s no surprise really to find weird effects. OH persistence methods will be expecting to deal with data recorded by OH persistence service, and it just doesn’t “do” predictions.

I only have influxdb and mapdb installed, so that should not be it:

Yes, I think that’s what we are seeing.

I just updated to OH 3.4.0.M3, and the averageBetween works! I have my workaround, so I’m very happy. Let me know if there is anything I can help with, otherwise, thank you very much!

Don’t care really, but you have also provided the important setting here - default persistence service = influxdb. This is exactly what the default is about - the service to use in queries, when no service is specified by the rule author.

1 Like