I’m confused why you need the persistence for this at all. My rule template calculates the last shutdown time when OH starts up again, every time OH starts up. MapDB always only saves the most recent value. It doesn’t save more than that. So the value in mapDB is always going to match the current state of the Item.
I see no point in using persistence for this if all you need is the most recent OH shutdown time.
In fact, you really get the last two shutdown times because the Item stores the last change too, assuming you have mapdb configured with restoreOnStartup.
The sequence of events would be as follows.
- OH shuts down
- OH begins startup
- Items are loaded
- restorOnStartup initializes
laatsteafsluitingopenhab with the value the Item had before 1 (this is the shutdown time that occurred before 1)
- The rule enginee starts
- The Last Shutdown Timestamp rule runs and determines the time of step 1 based on the events.log and updates
laatsteafsluitingopenhab with that time
- This change is recorded in mapdb
At this point:
laatsteafsluitingopenhab.state is the value from step 6laatsteafsluitingopenhab.previousState is the value from step 4laatsteafsluitingopenhab.persistence.getAllStatesSince(daybeforeyesterday) is an array with a single value which is the value from step 6
So the use of mapdb does buy you something here as it’s needed to do the restoreOnStartup which gives you the previousState on the Item. But you don’t need to use persistence to get that value and in fact, with mapdb, it won’t even get you that value.
So this feels like an XY Problem. Why are you trying to use getAllStatesSince here?
Some stylaistic notes about the code.
There are several ways to access an Item like this:
items.laatsteafsluitingopenhab
items["laatsteafsluitingopenhab"]
items.getItem('laatsteafsluitingopenhab')
The advantage of the first and last option is I think the intellisence built into the MainUI code editor can more reliably autocomplete the Item name (ctrl-space).
One of the worse parts of dealing with dates and times is dealing with “magic” numbers. But this is why openHAB provides ZonedDateTime and why all the actions take that class. It becomes much more human readable. And when you add in time.toZDT() you have multi-tool to convert just about anything to a ZDT without resorting to tedious "number of hours * number of minutes * …: operations which require a higher mental load in the long run to read and understand later.
Alternative ways to calculate daybeforeyesterday
time.toZDT().minusDays(2) // time.toZDT() returns now, then subtract two days
time.toZDT().minusHours(48) // time.toZDT() returns now, then subtract 48 hours
time.toZDT('P-2D') // ISO8601 Duration added to now (negative number)
time.toZDT(time.Duration.ofDays(-2)) // Duration added to now (negative number)
Not only are these shorter to write, they just say what they do. It takes very little cognitive load to understand what the code does. And more complicated calculations become much easier. Let’s say you want two days ago at 8:00 AM. time.toZDT('8:00 AM').minusDays(2).
Let’s say you want to know how much time has passed between the last two shutdowns.
const shutdowTimes = items.laatsteafsluitingopenhab.persistence.getAllStatesSince(time.toZDT('P-90D')); // let's go back 90 days, OH can remain running for a long time
const lastTwo = shutdownTimes.slice(-2); // get the two most recent entries
const delta = time.Duration.between(lastTwo[0], lastTwo[1]); // time between the last two timestamps
Of course the above code assumes you are using something besides mapdb which can save more than one past value.
