- Platform information:
- Hardware: Docker
- openHAB version: 3.4.2
Hello, I am looking how I can calculate the delta since the beginning of the year. I have already tried it with different variants (LocalDateTime, Eppoch etc.), but always despair at the OH3 Date Time Conversion.
val ZonedDateTime firstDayThisYear = now.withMonth(1).withDayOfMonth(1).withHour(0).withMinute(0).withSecond(0).withNano(0)
logInfo("TEST","Since " + firstDayThisYear + " Consumption: " +(VI_PowerConsumption_TV_Total.deltaSince(firstDayThisYear) as Number))
2023-02-14 14:12:02.521 [INFO ] [org.openhab.core.model.script.TEST ] - Since 2023-01-01T00:00+01:00[Europe/Berlin] Consumption: null
I’m assuming Rules DSL.
Given this error, you’ve got the ZonedDateTime stuff working just fine. The problem is the call to persistence. You could make the calculation of the first day of the year a little shorter but based on the log what you have there works.
Do you have data that goes back that far? For most of the databases, if there isn’t data around the time time you request it will return null. You can look at a chart or call
historicState and see if it returns anything.
yes DSL Rule.
Yes you are right, the oldest data is from 20th January.
If I set firstDayThisYear to day 20, I get a value back. Is there a way that it just uses the oldest value if there is no data to 01.01?
No, you’ll just have to wait until next year and change the 20th back to the 1st.
Too bad, ok then I have to check all that measure Things and set the correct date.
Thanks for your help.
Is there a workaround for this topic? Maybe JS? I’m having the same issue. I might never have values for the StartDay as new data might not be available every day.
It’s a limitation of persistence. If there is no data, there is no result.
The big problem is if you have no data anywhere near the start of the year. I don’t know how far on either side of the start date persistence looks but it’s going to be days or weeks. If you’ve data that close I think you are fine. If not, no results.
This isn’t a problem for rrd4j as there will always be data given it saves periodically whether the Item changes or not. But only if the Item existed and was configured to save before the start date. If not, no results are returned.
Thanks for clarification. I have energy readings which are just not available during winter time. There is also no search function for persistence, when the first valid value is available. I’m using MySQL as persistence service. If the energy reading is NULL, I think you will run into the same issue with rrd4j. Even if rrd4j would write a NULL, deltaSince won’t find the first valid value.
Does it make sense to write an issue that it is possible to define a search window on both sides of the start date or a new
The way rrd4j works, you cannot have gaps in the data.
NULL doesn’t get saved to persistence so I’m not entirely certain how that’s handled. Either rrd4j defaults to 0 or it uses the last persisted value. But in either case there will be a value saved.
rrd4j requires a value to be saved every minute or else the data compression doesn’t work and no queries end up working.
I have created an issue for this topic. In my opinion the implementation is actually not correct as historicItem() which is used in deltaSince() is always searching into the past.