Getting "OldItemDate" within a rule without persistence?

Using OH3.2 and I’d like to have quick access to the last timestamp or better yet, how many (milli)seconds ago the change was?

So, I can use event.oldItemState or event.itemState to access the current item’s state and the last state it was. Is there a way to get something like event.oldItemDate or similar to quickly get the time since last item change?

Maybe add a rule, that on each change of your item will store the current timestamp

That’s one way - but with each item and adding some “last changed”-item it gets a bit out of hand.

You can of course use persistence, like described here:

But perhaps there’s already a “quick solution” within the rules’ engine meta-information…? like in “oldItemState” I mean.

If I’m not mistaken you are referring to “implicit variables” with your “quick solutions”.
Can’t say if such “quick solution” exists for this information, however even if it exists it would only be useable in a rule that provides such. Like “previousState” is only available in a rule that has at least one command event trigger.
What kind of rule-triggef you are looking for?

my use case is:

  • item changes
  • get previous state and timestamp
  • get triggered state

With that and the current timestamp I’d be able to count the milliseconds between both and do some calculations. in my specific use case it would be the data of a S0 interface. the existing solution has been proven not reliable, as the onewire S0 counter does in fact reset to 0, if there’s an short outage - advertised was different! :wink:
So either I write a script somewhere else polling the onewire S0 (or directly from the gas meter) and persisting the counter somewhere and then resend the information to openHAB, I simply considered writing a rule and just adding to a persisted counter item, which should in theory survive an outage.

There is no implicit variable and nothing within openHAB that tracks this information except for persistence. If you don’t want to use persistence, you’ll have to keep track of the timestamp yourself. Your options are:

  • Persistence, obviously, though the persistence strategy cannot use a periodic strategy (therefore rrd4j isn’t suitable).
  • Another DateTime Item and rule to update it’s state when it’s matching Item is updated/changes
  • Add the timestamp as metadata to the Item and have a rule to update the metadata when the Item is updated/changes (not available in Rules DSL but should be doable in Blockly).
  • A “global” variable inside your rule (this will reset on a rule’s reload).
  • If using JS Scripting there’s the cache which can store the timestamp with a rule to update it (this will reset on an openHAB restart).
  • When/if it’s merged (I’m confident it’ll be available in 3.3 release), there is a recent PR that implements a generic pair of caches available to all the rules languages where data can be stored (will be reset when all rules with references to an entry are unloaded).

Personally I’d probably use Persistence or the Item Metadata approach. They have the advantage of not needing more than the Item itself and the metadata will survive an unloading of the rule or even a restart of OH.

1 Like

If you are talking millisecond accuracy, persistence methods are best avoided due to vagaries of database timestamping, I should think.

2 Likes

Yeah, I did it that way, was just an idea to save some code and perhaps CPU/IO time, if the information was already there…

ok, but it’s really not a big issue here, it’s just to get a proper reading of the gas consumption here to issue some logic afterwards. Not big deal, if it isn’t exactly correct.