You can get the historic “lastUpdate”-timestamp for an item using persistence like this:
items.getItem("ITEMNAME").history.lastUpdate();
is there a way to retrieve that information from openHAB core directly? without persistence-queries?
something like rawState.lastUpdate() or something?
Can’t you use the profile together with timestamp-change or timestamp-update ?
That would only complicate things. I’d like to have a faster and less costly way to reach that information. As I noticed, that sometimes the persistence entries are not yet written in the persistence as I tried to retrieve them. Doesn’t matter in my current use case, as I compare minutes, but sometimes I have to compare seconds, and then history.lastUpdate shows the penultimate update…
It would create an additional item which directly would be accessible. That’s too expensive ?
My use case is to monitor some items and if they’re not updated for a specific time I’ll send me a notification - and after an even longer time I’ll restart their binding.
the other use case is to check for an update coming from another rule - and there it could be mere seconds in between.
Both use cases deal with about 20 to 30 items, and I already have like 1500 items. I’d like to keep it down a bit! 
No, that information doesn’t exist anywhere outside of persistence.
@Wolfgang_S’s approach is the simplest.
The Threshold Alert rule template was made for this use case. I use this template to send me alerts when a door is left open for too long, a sensor Item doesn’t change for too long of a time (indicating something went wrong), a service/device status changes to OFF, the motion sensor at my dad’s house doesn’t detect motion for too long of a time, and more.
It’s a really common use case which is why I made the rule template.
Of all the things in OH, Items are the cheapest. Certainly you can avoid creating more Items but any solution that doesn’t is going to be way more complicated and effort in the long run.
Seconds between the rule making the call and the called rule running? That indicates a problem, not something you should really be trying to work around with rules or the like.
Another approach you could use is to create a SCRIPT transformation that sets a timestamp Item metadata on the Item when it’s updated from a Channel. Your rule that updates will need to do that itself. You’re saving some Items but not really saving any actual work and definitely not making your system more efficient compared to the timestamp profile and extra Items.
I tried it on different installations and a vanilla OH3.x. Especially the standard rrd4j persistence needs some time to write it on my Raspi4 (4GB) and JDBC (dedicated MariaDB-server) also sometimes response with some older values - but has all item-changes…
let’s see, if in OH4 it’s faster… apart from that I found some workarounds on that. Either extending the interval - or writing on some global variable (as Rich already pointed out).
Oh, you are referring to seconds between the event happening and it being saved in the database. Yes, there will always be some time and you cannot expect the event that triggered the rule to have been saved when the rule runs. Disk IO is slow. But it shouldn’t be seconds, it should be milliseconds.
The fastest I’ve used is MapDB.
There have indeed been some changes in rrd4j and persistence in general in OH 4 so it might be faster but it’s still going to take some time, perhaps more time than it takes for the rule to start running.
Way back in the past when the persistence trick was the only way to determine which member of a Group triggered a rule, a 300 msec sleep/timer was pretty reliable.