Issue of the topic: So i use lastUpdate extensively in my .rules files but more recently i kept getting failures due to null values being returned. Having read the documentation i noticed that if an update is waiting to commit to persistence then lastUpdate will return null. Not sure if this is recent change or ive just got lucky (been running these same rules since OH1). Anyway, thats how it is now, so my question is, is there a way to get the last persisted date irrespective of outstanding updates/changes… etc.
It was changed to have the behavior for both methods to be consistent. It will return null when the current state is different from the last state in persistence now. The best thing to do if it returns null is to use now().
I am happy changing this back if the better support for lastChange and lastUpdate as an item attribute gets accepted, because that would be the better and more reliable approach for this.
Not quite sure how using now() helps, Im just trying to check the time an update was last committed to persistence, I’m doing this so I can check if any devices have gone AWOL by providing the number of minutes since the last change i.e. now() - lastUpdate, if last Update returns null, then it breaks the formula . When did it change ??
If the time of the last write to the database is what you want, previousState.timestamp will give you that in all cases.
I argued most people expect to get the last update time of the item, not the last write to the DB. It is clear there is no consensus on this. I think the methods carry the wrong name. If the last persisted time is what you want as an outcome, it should have been called lastPersisted. But you could already get that from previousState.timestamp.
On the other hand, if you want to know when the item last got updated, you actually needed to have logic like:
get lastUpdate through method
get previousState
If previousState different from item state, the item has been updated since, so interpret (e.g. use now)
Returning null from lastUpdate makes that clear straight away.
If the current state of the Item is different from the most recent value saved in persistence, assuming you are using an everyChange or everyUpdate strategy and you have a reasonably fast persistence, when you get null back it means the Item changed in the last half second or so. So now is reasonable under those conditions.
If these conditions do not hold, now may not make sense.
You could also wait for 200 msec or so and try again. The new value will likely be saved after that.
I completely agree.
previousState is a little iffy too in terms of name too.
What all these methods do is highly dependent on the persistence strategies used and the database being used.
Thanks – previousState should work for me, ill give it a play… I understand your logic, but is there potential that the last persisted state actual is NULL, in which case using now is in error ?
Now ive had time to read the PR’s and stuff proper, im totally in agreement with you, lastUpdate should return the time of errmmm last update, not last persistence, returning null is just wrong !!
I would vote for the reversion to actually returning something closer to the name, and that hold true for last change also.
i guess this is very simliar to this albeit, this is for update ~(which used to return something) as opposed to change…
My proposal in the PR was to actually return now if the state of the item is different from the last one found in persistence. That of course makes the assumption that the reason for the difference is the delay in saving, or now can be used as a good approximation if another strategy than everyChange is used (e.g. everyMinute). It makes assumptions. These were debated, and the consensus was to return null. This essentially means: it changed but we don’t know when.
Returning the value written in the database is worse in my opinion (and actually has the same problem with assumptions being made).
That’s why having these values on the item, and not having to read it from persistence would solve it properly. And then it makes sense to go back to the old behavior on persistence, clearly stating the item methods (not using persistence) should be preferred unless you absolutely want what has been written in the database (and it can be different from the real change or update time).
It is, and it uses the same logic. Again, it is not because these methods returned something before, that what got returned always made sense. Returning is a way of saying we don’t know.
. When did it change ??
