openhab-core: Introduce "expire" functionality for item states
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.
https://github.com/openhab/openhab-core/pull/744 was a first try to do so, but doing it as a profile has too many constraints.
As commented in https://github.com/openhab/openhab-core/pull/744#issuecomment-485055862, 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.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (12 by maintainers)
Commits related to this issue
- Item metadata: add expire editor, change default widget logic Disallow standalone widgets to be selected for list items (close #536). Allow slight alterations to the default widgets suggested by the... — committed to ghys/openhab-webui by ghys 4 years ago
- Item metadata: add expire editor, change default widget logic (#540) Disallow standalone widgets to be selected for list items (close #536). Allow slight alterations to the default widgets suggest... — committed to openhab/openhab-webui by ghys 4 years ago
- Added expire functionality as core framework feature (#1803) * Added expire functionality as core framework feature Closes #1620 Signed-off-by: Kai Kreuzer <kai@openhab.org> GitOrigin-RevId: 63ec43... — committed to ConnectorIO/copybara-hab-core by kaikreuzer 4 years ago
@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.
Yes sir!
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”.
I understand this would require a change to the rules engine, the questions I posing here are:
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?)
@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.
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.