openhab/openhab-core

Expire to apply also to items with no events

Opened this issue · 7 comments

ssalonen commented

I would find it convenient that Items could also "expire" even when no event is received.

Currently expiration timer is not starting with fresh start and the item will remain in NULL state.

Since this is backwards incompatible change, it would probably have to be behind a UI flag

Would this be accepted?

Your Environment

  • Version used: (e.g., openHAB and add-on versions)
  • Environment name and version (e.g. Chrome 111, Java 17, Node.js 18.15, ...):
  • Operating System and version (desktop or mobile, Windows 11, Raspbian Bullseye, ...):
ssalonen commented

Could also have "initial expiration duration", used only for the situation when there is no incoming events

rkoshak commented

This would be a good addition to Expire I think.

In the past I've worked around this through a rule. Basically it's a system started rule that updates the Items with Expire metadata with the Item's current state. However, that approach will only work for Expire configs that work on updates and won't work for Expire that only look for changes.

But such a rule's script action would look something like this (JS Scripting):

items.getItems().filter( i => i.getMetadata('expire') !== null ).forEach( i => i.postUpdate(i.state));

I've also on my list of things to do to add a startup behavior to https://community.openhab.org/t/threshold-alert-and-open-reminder-4-0-0-0-4-9-9-9/144863 as that rule template has the same problem as Expire of not starting the timers after OH starts but the Items don't update/change after startup. It does however, support alerting when an Item stops changing or updating later on, which is part of this. issue.

  • 👍1
spacemanspiff2007 commented

What happens when you have mapdb configured for the items?
Wouldn't then the item state be restored and expire run as expected?

Could also have "initial expiration duration"

While I get the idea I think an on_startup flag would be both sufficient and easier to use.

  • 👍1
rkoshak commented

Wouldn't then the item state be restored and expire run as expected?

No, restoreOnStartup happens before Expire is enabled. Only when an Item is updated after runlevel 80 (IIRC) trigger expire. Any updates before that (restoreOnStartup occurs around 30 I think) will not trigger expire.

While I get the idea I think an on_startup flag would be both sufficient and easier to use.

There are two parts to this. The first is dealing with the startup behavior and dealing with the fact that whether there is restoreOnStartup or not if the Item never changes or is updated after expire starts to run the Item will never expire.

The second one is dealing with the case where an Item doesn't receive any update for a time. Presumably this would be a case where the Item remains in the expired state. It is useful to get some sort of indication that an Item that normally periodically is updated stops being updated (e.g. expire to OFF after it's been ON for five minutes but expire to UNDEF when the Item is not updated for 30 minutes).

spacemanspiff2007 commented

Sorry - I don't understand your last two points. Can you rephrase them a little bit.

My suggestion was that instead of

Number  MyNumber { expire="5s,state=0,initial_expiration_duration=5s" }

this

Number  MyNumber { expire="5s,state=0,on_startup" }

would be easier to use and for almost all use cases sufficient.
Just a flag that this expire should be run on startup, too.

Both would run an expire after startup (which is the new suggested feature).

Maybe it even would make sense to run expire on startup as a default and have the user explicitly opt out, e.g.

Number  MyNumber { expire="5s,state=0,no_startup" }
ssalonen commented

The case of "initial expiration duration" can already be implemented similar to @rkoshak suggested, so I agree to keep it simple with a yes/no flag.

I actually did not realize that there is such a generic simple rule to "fix" this issue with all items...solves my immediate problem

rkoshak commented

I actually did not realize that there is such a generic simple rule to "fix" this issue with all items...solves my immediate problem

There's a rule template on the marketplace. https://community.openhab.org/t/restart-expire-4-0-0-0-4-9-9-9/146377. It has a couple more config options than the simple forEach above but it basically does the same job.

would be easier to use and for almost all use cases sufficient.

Based on my reading of "expire items with no events" I see two cases where an Item no longer receives events:

  1. It never received any events after OH started up. This case is handled easily with a boolean flag.

  2. The Item was receiving events for awhile but stopped receiving events. You want the Item to change to one state when the Item remains different from a given state for a given time but you want it to expire to a different state if the Item doesn't receive an update for a given time. For example, an Item gets updated every hour. When it changes to ON you want to command it OFF after five minutes. But it if doesn't receive an update for two hours you want it to become UNDEF to indicate it might be offline.

Maybe 2 isn't worth the effort to address in Expire, but it is a useful and relevant use case.

  • 👍1