Introduce "expire" functionality for item states

[kaikreuzer]

Since openHAB 1.x bindings are incompatible with openHAB 3 and there is a substantial user base that has the 1.x expire binding in use, we should introduce a replacement for this functionality.

#744 was a first try to do so, but doing it as a profile has too many constraints.

As commented in #744 (comment), my suggestion would be to natively support the functionality in the core framework, similar to the "autoupdate". This would essentially also mean that item files of users stay fully compatible as the configuration could just be like:

Number Temperature "Temp [%.1f °C]" { expire="1h" }

Internally, this will just be a metadata provider with a specific namespace ("expire"), so reading and writing this information would directly be possible through the existing REST API as well.

@openhab/core-maintainers Would that make sense to you?

@ghys Is this something that could also be easily supported by the UI then? The most tricky part is probably the syntax of the expire configuration, but if that isn't a big issue to parse, I'd tend to stick to it for compatibility reasons.

[ghys]

@ghys Is this something that could also be easily supported by the UI then? The most tricky part is probably the syntax of the expire configuration, but if that isn't a big issue to parse, I'd tend to stick to it for compatibility reasons.

Shouldn't be a problem if it's regular metadata. Note that the UI doesn't use metadata providers {Edit: metadata config descriptions, sorry] but has its own list of well-known namespaces and implements a dedicated editor for each of them (where the parsing can be done to provide more than just a simple textbox, if desired.)

[wborn]

Would that make sense to you?

Yes it does to me. Since it's used by many it would be nice to see a compatible OH3 implementation. 🙂

[rkoshak]

I'm sure looking at the original binding code would be useful, but just in case it's helpful you can see my Jython rules version at https://github.com/rkoshak/openhab-rules-tools/blob/main/time_utils/automation/lib/python/community/time_utils.py. What might be of particular use is the duration_regex I use to parse the time config.

One thing that came up when I wrote the rules version of expire is how NULL and UNDEF states are handled with String Items. The 1.x binding basically makes it impossible to set a String Item to the String "NULL" or "UNDEF". To handle that case I had to add the ability to put the String in single quotes. For example expire=5m,state='UNDEF' to update the Item to the String "UNDEF" and expire=5m,state=NULL to update the Item to the state NULL. It's kind of an edge case but people asked for me to add it so there is clearly demand to support it. Not that it will help much with the Java but you can see the Jython rules for this at https://github.com/rkoshak/openhab-rules-tools/blob/main/expire/automation/jsr223/python/community/expire/expire.py . Just something to consider.

NOTE: When I wrote my expire rules it was mostly as a challenge to myself to see if I could do it and under the assumption that what ever you folks implement in the core would not be compatible with the 1.x binding config. I intended it to be a bridge. Since what you are proposing will be compatible, I'll deprecate my version when OH 3 comes out and eventually archive the rules.

I'm really glad the Profiles approach was abandoned. It simply does not support enough of the use cases that people use it for.

[kaikreuzer]

I'll try to have a go at implementing this.

@rkoshak Yes, I'd plan to look at the 1.x binding code, so thanks for mentioning its shortcomings. Using single quotes for exceptions in String items sounds pretty sensible. I'll make sure that using UNDEF and NULL is possible for those.

[cweitkamp]

Would that make sense to you?

Yes, I agree. It makes sense. With respect to backward compatibility it will be nice to see your implementation for it.

[wborn]

Can we assign this to you and put it in progress if you are working on it @kaikreuzer (openhab/openhab-addons#8407 (comment))?

[kaikreuzer]

Yes sir!

[boc-tothefuture]

Expire is widely used and used in a lot of different contexts and I think it fully makes sense to keep the syntax compatible with the 1.x binding to ease upgrade path.

While expire is being worked on, I wanted to understand and raise a discussion around if there is something to be done architecturally at this time support what I view as a highly common use case that while you can execute it presently with expire and a set of rules, it is a bit harder than it could be.

General use case:
Execute an automation after an item is in a specific state (and that state doesn't' change) for a specified duration.

Specific use case:
Turn off lights and fan when a room is unoccupied for 10 minutes.

There are multiple ways of handling this currently, some involves timers being created and reset, others involve creating of dummy objects with expire tied to them and then rules setting or resetting the switch. While all of these work, they are potentially more complicated than they need to be for a common automation.

Proposal:
Native built in method for execution an automation if an item is in a specific state for a duration. One potential of how this could be used is within the rules DSL is to add a new keyword "for".

rule "Alert when Master Bedroom Door Open"
When Item MasterBedroomDoor changed to OPEN for 10 minutes
then
...
end

I understand this would require a change to the rules engine, the questions I posing here are:

1. Is this worthwhile to make this common use case easier?
2. Does anything need to happen architecturally while adding expire that could be done to support this?

[Skinah]

So your wanting what I would call a “debounce” feature. Would be handy to stop a doorbell triggering multiple times if a PIR sensor is Flipping back and forth.

[moodyblue]

I support @boc-tothefuture proposal as an add-on. But expire binding works with grouped switches and I'm using this, so I also need the expire 1.0 functionality.

[DanielMalmgren]

What is the prio for the work on this, @kaikreuzer? I'm really thrilled by all the new fancy stuff in the OH3 milestones, but unfortunately I'm completely dependent on the expire functionality in my environment.

[kaikreuzer]

@DanielMalmgren It's my top prio. Unfortunately, I have some time and health issues right now. I'd hope to get a first version ready for milestone 3.

[bwosborne2]

@kaikreuzer
You take care of your health first & foremost. I imagine OH can progress under your deputies for a while to give you time to fully heal.

[kaikreuzer]

One thing that came up when I wrote the rules version of expire is how NULL and UNDEF states are handled with String Items.

@rkoshak I have added support for this with 93a8510

Execute an automation after an item is in a specific state (and that state doesn't' change) for a specified duration.

@boc-tothefuture I understand your suggestion and thought about if there's anything the expire feature could address about it, but didn't feel it is directly linked - I have hence not considered it in #1803.
I'd suggest that you best open a dedicated issue for it, so that we do not lose it once this issue here is closed.

[kaikreuzer]

Now that this is implemented and available in the OH3 snapshot 2019, it would be great to have to have some heavy-expiry-users test it to make sure it works as expected before releasing it soon with M3!

[bwosborne2]

And documentation on use? I am not a heavy user but use it 2 or 3 places.

[kaikreuzer]

See above: "This would essentially also mean that item files of users stay fully compatible"
So everything you see in https://www.openhab.org/addons/bindings/expire1/#item-configuration applies exactly this way.
No support through the UI yet (@ghys shall I enter an issue for that or will you pick it up anyhow?)

[ghys]

I'm planning to work on metadata in the near future so I'll include it in that PR.

[curlyel]

after an item is in a specific state (and that state doesn't' change) for a specified duration

FYI: Proposed a dedicated debounce profile here: #2172