How to know if I could trust .lastUpdate in a rule

I have some rules which are triggered by “changed”. In this rule I need to know how long it is from that rule trigger to the last one or compare thsi with a .lastUpdate from another item to decide something.

one of my rules:

rule "ADAM6050_00_DI00_TimerMode"
		Item ADAM6050_00_DI00_TimerMode changed to ON or
                Item ADAM6050_00_DI00_TimerMode changed to OFF
                if((ADAM6050_00_DI00_Proxy.lastUpdate("mapdb").millis - ADAM6050_00_DI00_TimerMode.lastUpdate("mapdb").millis) > 1200)
... some code

It looks like sometimes the persistance service is to slow and the rules runs before the new timestamp is set for the last change time of the item.

Then my rule works with the wrong older timestamp. A sleep will fix this maybe? But how long should the sleep be to get a trusted correct timestamp.

I could not use a longer sleep then 500ms because this rule triggers a light by motion. And the delay should not be too long.

But 500ms sleep does not fix it on every time. Mostly, but not on every run of the rule.

Any idea how to know if the timestamp is set correct?

Is there a way to get .lastChanged instead of .lastUpdate from mapdb? I think, this is not possible and even not with rrd4j. I do not have a sql persistence service running.

That would be previousState(true) I think

Thanks for the answer, but neither MAPDB nor RRD4J have this feature. Only a real database which has more then one entry and the entries will not aggregate as in RRD4J.

But this is the minor problem.

The real problem is how to know if timestamp is set or not at that time the rules runs.

Is there a way to get the timestamp for .previousState(true)?

Yes, this does not return a state object, it is a historicItem object which has a stamp, I think by xxx.timestamp method

I do not think it possible to determine if persistence has any outstanding writes, which is what you really want to know.

If your persistence service is performing poorly, don’t use it. Create your own timestamps in associated Items, perhaps.

I used this in other rules. And run into the same problem. It takes a while if I use item.postupdate to get the value in the item.


In not all cases the second line has the value I posted to it the line before. Sometimes it takes 500ms to use it. I use var variables as interim to solve this and use the item.postUpdate value only in the next run of the rule.

var newvalue = (item as number).intValue

if(newvalue != xxx)
1 Like

Yes, it does take a few milliseconds. When you post an update to an Item, it passes on to the openHAB event bus for anyone interested to see e.g. bindings, rule triggers etc. This is by design.

It’s a good way to illustrate the issue, but once you understand how openHAB works you never do this in reality, and that’s what you say you have dealt with already, so all is well.

Your system is sick in some way, that is excessive to implement an update.