I wanted to ask what do you think about “timer vs. trigger with DateTime Item”?
If we take the example “message by open window”, I have always used timers until now. It’s easy, but I find creating the timers and reading them later difficult.
But apart from that, how do you see it? Using an item as a DateTime trigger of a rule is very new, would you prefer a DateTime trigger based on an item in the meantime?
In my mind this is more resource friendly and I can persist the DateTime Item and am therefore safe from a restart.
In my example I would have to change my rule, which reminds me of the open window as well as closes the associated thermostat into many small rules, each with its own DateTime item…
If I’m not mistaken, the DateTime trigger internally uses the cron scheduler, which in turn ends up using the same scheduler infrastructure as a timer. So from the resource perspective, there’s no significant benefit either way.
It comes down to how you’d prefer to create and manage your scheduled tasks.
There’s going to be a bit more overhead for the system in managing and logging extra Item and an extra rule framework, etc., but I can’t imagine that is of any significance in real life.
I haven’t really got my head round how you manage such Item-triggered rules. How do you “cancel” such a Timer, set the controlling Item to NULL? If you “reschedule” by changing the Item, does the old schedule really get cancelled or might you get two runs? etc.
These features are important once you get past trivial delay applications.
One significant difference is that rule-spawned timers inherit some context from parent e.g. you can calculate some temporary x in a rule, and use that x in the timer when it runs later. The important part there is that x was calculated at the moment the timer was set up - not when the timer executes. It’s a capture or memory.
// example
val oldValue = myItem.state // this will also be available in the Timer
myItem.postUpdate(temporaryState)
createTimer (whenever) [
// restore old value
myItem.postUpdate(oldValue)
]
// this kind of use is common in many old timer examples
An Item triggered timer does not get that inheritance. You can duplicate something similar with two rules - rule A calculates x, puts it in some global store (which itself can be a challenge in some uses), then sets up timer Item for rule B, the real timer.
No, just the one run. It’s smart enough to only run the rule at the time the Item is currently.
DateTime Item triggers are best used when you want something independent to happen at a specific time. For example, an alarm clock rule that runs every day based on the alarm on your phone.
Timers are best used when the thing that happens in the future requires information about what happened to cause it to be scheduled in the first place (e.g. which Item changed to what state to cause the Timer to be created in the first place (as @rossko57 described).
They are not equivalent and have distinct use cases.
