I don’t know whether I understood the function of averageSince correctly. I understood that averageSince corrects the averaging over time, that is: if I have 1 minute a value of 10.0 and 59 minutes a value of 10.0 it is supposed to return 10 * 1/60 or 0.166666667 for averageSince(now.minusHours(1)).
I use influxdb as the default persistence and I persist on every change on default. My results are not as expected. I only get a value of 5.0. I generated the data with a time cron activated rule and fed these into two number items. One was persisted as mentioned above, the other one also every minute. If I operate averageSince on the item being persisted every minute I get the expected result.
rule "switch"
when
Time cron "0 0 0/1 * * ?" // stündlicher Aufruf volle Stunde
then
szTest.sendCommand(10.0)
szTest2.sendCommand(10.0)
Thread::sleep(60000) // 1 Minute warten
szTest.sendCommand(0.0)
szTest2.sendCommand(0.0)
logInfo ('rule','Test-Mittelwerte: {} - {}', szTest.averageSince(now.minusHours(24)), szTest2.averageSince(now.minusHours(24)))
end
Gets the average value of the State of a persisted Item since a certain point in time. This method uses a time-weighted average calculation (see example below)
Possibly. Commands and Updates to Items are processed in parallel in the background. It is almost certainly the case that your two commands to szTest and szTest2 after the sleep have not yet been fully processed and the new states saved to the database before you get to that logInfo that calls averageSince.
Okay, but that should affect both items then. Where does the difference come from ? I have now complete 24 h results, and these show IMHO that the averageSince does NOT do any time based calculations (or it does it in a way I don’t understand).
Not necessarily. It can take some milliseconds to perform an averageSince. The data may not be there for the first Item but the time it takes to calculate the average on that first Item is enough that the data is there for the second Item once you get to the call to that averageSince.
Add a 100-500 msec sleep before your logInfo to ensure that both Items have updated and saved to persistence before trying to pull the averageSince.
I’m not saying whether or not the time based calculations are happening (though the code appears to be there to do it). I’m just pointing out that you are currently likely seeing problems caused by timing.
Please guide me what I am to do next. I am not expecting a solution for this but I am willing to contribute. I. e. figuring out how to file a bug report or even help to find a solution. But before I start to “mess things up” I would ask if somebody can check my conclusions. Thanks a lot.
I think the relevant code for this is in the openhab-core repo.
Assuming your interpretation is correct and it’s calculating incorrectly than the next step is to file an issue. Either the docs are wrong or the code is wrong.
All right, I had a look at the code of averageSince.
The problem is that the value is weighted with the timespan to the previous HistoricItem instead of the timespan to the next HistoricItem.
If you store the values every minute, all timespans are the same and it does not really matter. However, if you store it only every change, it might make a huge difference.
@mschlee: Might this explain your observations too?
Thanks for the hint. My first post here explained that I can individually configure influxdb to use a 1 minute persistence for items which are not updated periodically - so I found a way to get what I want. The intention of this post was to show that averageSince does not work as expected - which has been confirmed now by at least one other user. I hope that this helps others.
