Seems overly restrictive.
A substantial proportion of uses for current createTimer() rely on being able to detect in a rule if a timer is already running or not.
A fair proportion also require rescheduling, although that could be fudged with a cancel/restart approach.
An improvement over current timer would be a means to readout target or unexpired time.
These could be fairly easily supplied by a few channels per timer-Thing.
The hard part about this approach is how to interface to these channels from rules. Preferably without the faff of pre-declaring a multitude of Items. Or is that the key to success, having a more fluid environment of dynamical created Items?
Rule calls/creates timer Thing with name XXX
Items XXX-running , XXX-timestamp , XXX-trigger or suchlike are automatically conjured up.
I’m unfamiliar with new rules environment - does/will it allow use of channels directly? (avoiding Items altogether)
So some clarity. For me anyway. I’ve only been using OpenHab for a few weeks so my knowledge is limited but this thread is certainly opening my mind to possibilities.
Effectively at the moment rules can be timers because they can be triggered at some time in the when clause.
It seems like what might help is a timer class which has a rules like file but instead of a when clause, they just have a name so we effectively have a bunch of named rules that can be triggered by the timers firing or I guess also potentially called by name by other routines.
Right now Rules can be triggered by time using a Cron expression. These are not Timers and not what we are talking about, that I’d also a need in the Next Gen Rule Engine.
Timers are something else. Right now in the current Rules DSL we can schedule a little chunck of coffee to run at some time in the future inside a Rule. Once created, we can cancel or reschedule the Timer as needed.
Unfortunately, creation and user of Timers in this way is not possible in the NGRE. This thread is exploring how to bring this capability to the NGRE using OH 2.x concepts.
OH 2 is quite different from OH 1 and the NGRE is quite different from the Rules DSL.
Not to sound daft, but what are NGRE and DSL? And FWIW, I’ve never seen OH 1 so all I have to go on is past languages and my feeble attempts to learn OH 2.
Rules DSL, Domain Specific Language. The default language rules are written in. It has been around for a very long time and is loosly based on the obscure XTend language.
The Experimental Next Gen Rules Engine (NGRE) will eventually replace Rules DSL. It is structured very differently but it supports more standard languages like JavaScript and Jython.
The topic of this thread is figuring out how to bring functionality that exists in the current rules DSL to the up and coming NGRE in a way that makes sense given the underlying architecture, conventions, and artifacts that make up OH 2.
I’m not so sure that taking what we might call cron-style rule triggers out of the discussion is right.
There are two different time related needs;
Do something (run a rule) at scheduled times e.g. on the hour
Do something (run a rule) at arbitrary times e.g. in ten minutes time
Plus of course means to manage the timers
The arbitrary version is really just scheduling plus a run-once condition.
Seems likely to be driven by the same mechanism, even if there are two or more ways to control it.
I see current ‘expire’ binding as just a shorthand special case of the arbitrary timer, with “Do something to this Item” and hidden rescheduling.
I agree that there needs to be a lot of new work on scheduling on OH and perhaps using the same infrastructure for creating Timers from Rules and cron type triggers would be appropriate.
But I’m not sure forcing ALL scheduling through Things is necessarily a step forward. Would you rather set up the cron expression as a trigger, with a nice UI form that helps you build the expression, or would you rather have to create a new Thing on a different UI page and trigger the Rule based on the command channel of the Thing?
One of the concerns I have already is that the NGRE is already going to diffuse code that we are already used to being all in one place all over the place. Moving Rule scheduling to Things only exacerbates that.
However, if that can be the first step towards building a better scheduling service into OH that can support modifying of the schedule from the user’s UIs I can live with that trade.
I will admit that I’m a bit myopic right now in my view of NGRE and how to move forward with it that I’m failing to see a lot of the benefits that the new way enables. I’m mainly seeing functionality that we are losing.
The Thing -> Channel Timers were just a first proposal.
Personally I’m now convinced that a dedicated framework sub-component like the current rules timer scheduler with its own REST API endpoint and PaperUI section is a better choice.
I’m liking this idea better as well. I got excited when I read about it in the Issue. I can see all sorts of opportunities a separate service like this can enable.
Another rule starts TimerXYZ Some other rule can cancel/reschedule
If timers are Item-y in this way, perhaps they could also be Group-y for shared code purposes. More I think on it, more it feels like a viable way to manipulate timers from rules is to have them act a bit like Items. Send commands, read “states”.
But there is no nice GUI that pops up when you Rule runs that lets you build a cron expression. Maybe I’m not seeing what you are proposing.
As I see it, from a usability perspective (not the underlying services that actually implement the Timers) I would want to:
configure a Rule to trigger periodically; I should not have to write a Script Action to make this happen
schedule/reschedule/cancel some code to execute at some calculated time in response to events; I should be able to do this from inside a Script Action, perhaps as an Action unto itself
have a way to determine what is scheduled and when it is scheduled to run; I should be able to access this from Script Actions and “but only if…” Scripts, a UI in PaperUI would be super nice as well.
The more I think about it the more I really like splitting this off as a separate service. The separate service can support all three use cases and provide the hooks necessary to use the service in all three ways described above given new trigger types and script functions.
I do like the ability to Group Timers and David’s proposal does include that feature. I wish there were a way to Group Trigger Channel triggers too.
I’m not super keen on Things and Items to implement this because it requires a lot of extra work (particularly if you are using PaperUI to click create new Items) compared to what we have now. I think we can achieve the same end result without needing to create a bunch of new Things and Items.
So, building a rule in GUI the first bit is “when to run”, i.e. choose an Item change, channel event etc.
We add a ‘Timer’ event option to that, up pops the timer-related GUI.
One of the primary options is for ‘Periodic’ Selecting that gets us to a cron kind of setup menu.
This kind of timer could appear anonymous, but if we give it a handle as below it can be accessible for adjustment, alarm clock style.
Another primary option is ‘Once’, to be triggered when a given timer expires. The woolly bit is assigning somehow a handle, a name, that is also available for other rules to start and manage.
I think that whatever actual object underlies here needs to be created by the rule defining process, just as a cron-style trigger is now.
I guess the GUI part here is popping up an invitation to name it, and subsequently allowing that named thing (small t) to be used in other rules.
When you access the named timer within other rules code, you get the options to start/stop/reschedule/interrogate
Whether the engine behind that is a separate service I wouldn’t know.
