this is my first post in this community (and it’s going to be a longer and more involved one), but I am a seasoned openhab user since OH2.0 and have looked at a lot of source code of OH core and addons. While I haven’t developed anything for OH yet, this topic might be just turn out to be my first venture in this project. I have a long software development history and know my way around in java; what follows are my observations from both a OH user and developer-oriented perspective.
Context and motivation
There has been a lot of discussions and proopsed solutions with regard to timers and I am also very interested in improving the current “situation”. What is the situation? From a user perspective (OH3 with main UI), all discussed solutions regarding one-shot scheduled execution of actions are based on rules (and scripts). In order to get a complete picture of how the setup “works”, one has to inspect the things and items layers (including profiles for their links) are configured and than also look at rules and “merge” this in your head. While I really like the OH3 main UI, it really makes it harder then it should be to get this overview (even for my own setup that I configured all by myself…but after some weeks pass by, I need to “rediscover” what exactly I did in order to accomplish a certain behaviour in my setup).
Let me give an example before continuing:
I have a robot vacuum cleaner that I like to start in 30 minutes, because I will be leaving the home in about 15 minutes. I would like to do this using either a thing (zigbee button) or from a touch display with BasicUI (possibly using other delay values). Essentially, I want to initiate something right now for sometime later on (because I keep forgetting to do that when actually leaving the building). I have a lot of use cases for those “one-shot” scheduled executions and most of them are not as trivial as with the vacuum cleaner: activate bed time scenario for kids per zigbee button: close shades now, power-on power-plug for sonos now, start playing sleeping music once sonos comes online, power-off sonos in 1 hour, send reminder via messenger to check on kids in 15 minutes).
While this is perfectly doable using rules, this approach sort of “clutters” my setup: In addition to essential control rules to make my things behave/react as I like (if this then that), I also have to implement timer related rules/scripts (if this then wait and than do that) and sometimes need proxy items (sometimes profiles for channel links are good enough) to achieve the desired behaviour.
My first two proposals are mostly UI focused and should improve the user-experience when looking at my setup (settings in main UI).
It would be great if the thing and item details page in main UI would list (and link to) rules that refer to this item or thing. Possibly grouped by trigger,action and condition usages. This should be straight-forward implementable, as rules are now with OH3 cleanly defined in syntax/structure. This would help greatly in order to understand the behavioural aspects of an item or thing. Bonus points: if the rule triggers a script execution, list and link to those scripts underneath the respective rule.
It would be very helpful for organising rules (maybe also scripts?) if rules were assignable to (nestable) groups, in order to easily find those rules that I am interested in (that for example deal with things/items in the living room). Maybe even a full integration in the semantic model structure?
Better (more user-friendly) setup/handling of timers; this is really a multiple-choice proposal-scenario (design-patterns) based on different approaches
Rule based delays
This is essentially the combination of proposal #1 and #2; further refinements are probably possible and should be analyzed.
→ refinement of already existing concepts/implementations
→ inherent “distribution” of delay logic/configuration over items, rules and maybe even scripts
→ managing active timers (running rule instances) should also be implemented somehow as a first-class citizen(?)
Transformations/profiles and proxy items:
Implement a DELAY transformation (and profile)
→ Uses and extends existing concepts (…and unit tests)
→ The delay can’t be done in the execution context of the transformation/profile due to blocking, thus a central service for asynchronosly handling the timers and the execution of the actions seems needed (including a settings page for listing/modifying active timers)
→ Requires proxy items (item “cluttering”) for good user experience and avoidance of unexpected side-effects regarding autoupdate and UI feedback “behaviour” and also timer state related items (time remaining, delayed actions, …)
Implement an action that implements the delay and gets contextual data (target thing-channel, state, …) passed as parameters.
→ no expectable side-effects
→ does not impact item/thing concept layers
→ Only really invokable from scripts (iirc)
→ This really isn’t an action in terms of the action concept
→ Whether actions are executed asynchronosly or not (to avoid blocking of invocation context)
Delay-implementing proxy thing
The idea here is to have items linked to (virtual) things that execute the respective command on the target thing after the delay (asynchronosly). Three implementation approaches come to mind:
→ each channel is configured to a specific delay, the command is taken from the invocation and the target thing-channel must be provided (metadata?)
→ each channel is configured to a channel-specific target thing/channel, the command is taken from the invocation and the delay must be provided (metadata?)
→ one generic channel, both command and thing-channel are passed in (metadata?)
→ fully consistent with the item->link->thing-channel data flow concept (and extendable via other mechanisms like expire)
→ status of pending (delayed) commands reportable by thing via (status) channel(s)
→ persistence of timers across system restarts easily implementable (if desired → config option?)
→ if based on implementation approach 3 (generic channel): other sorts of logic in additional delay channels can be implemented easily (for example: delay not in terms of absolute value but calculated from other item values…like a script?)
→ This really isn’t a thing in terms of the things concept
→ implementation specific: If implemented as individually configured things (one thing instantiated and configured for the “target” thing) → thing “cluttering”;
I really want OH to make one-shot delayed execution of commands easier to undertand and use and also better to maintain (more complete picture in a given context in main UI, mostly proposals #1 and #2) and am willing to tackle this myself over the next weeks/months. I would be really grateful for any feedback: I don’t want to implement something that works but won’t be accepted into mainstream.
I personally favor the deplay-implementing proxy-thing approach with a generic channel that is fully “configurable” via metadata; however, it does bother me quite a bit that it isn’t a thing in the sense of the concept; maybe it should be packaged not as a binding but rahter as a misc add-on (while still being a thing provider)?