Expiration timer via item metadata seems to fail erratically


after a few months of successfully using the metadata expiration timer settings on numeric items of type Point indicating distance of a bluetooth tag to ESP32s connected via MQTT to UNDEF after a brief interval (using 10 s, but value does not seem to make a difference), this now just stopped working for a subset of the items.

This may or may not have been connected to an OpenHab update; can’t tell for sure since one of the ESPs had been down for a while and got fixed just now.

Event and openhab logs show nothing special (in particular, no updates of the underlying things that could reset the timer), and there really are no incoming MQTT messages on those things.

Persistence is via JDBC/MariaDB, which show now recent values on the affected items.

Any thoughts on how to get this fixed or what might be causing this? Linking and unlinking the channels to the items did not help. Deleting and reconfiguring everything would be quite a hassle, and it would be good to know the root cause.

Any thoughts?

Thanks a lot in advance!

That is almost certainly your problem, though. Updates to “same value” do NOT get logged but DO restart the expire timer, by design.

Make a little rule to log out updates to your afflicted Item.

Just a note on this. A PR has somewhat recently been merged that adds a flag to the Expire metadata to tell it to ignore updates. I don’t know if the UI changes have been made to expose it though.

Thanks for the replies. Finally got around to taking another look.

Added a rule to log out all updates to the afflicted item as suggested. It does not receive any updates, but does not reset to UNDEF either after expiration.

Any thoughts on how to track the issue down further?

P.S.: The new and shiny “only on change” option does not help me in this case because I’m using the distance from G-Tags to detect presence; set the distance item to expire after 10 s, so that if the G-Tag is out of range, distance goes to UNDEF, which (combined with a couple of other conditions) signals absence.
P.P.S.: Weirdly enough, the items for three other G-Tags on the same ESP32 with exactly the same configuration reset fine, just different channels on the same thing…

Update: after a power off/hard resetting the RPi, this now works as before. Had rebooted any number of times before to no effect. Must have been some low level instability or whatever…