What is the order of operations when the same event both changes the truth state of the Required Expression and is a trigger for a rule? Two situations of interest:
I want a rule to execute on a collection of triggers, but one of those is gating -- if that condition is false, ignore the others; when it becomes true, or when any of the others occur while it remains true, the actions should run. I almost want a "Required expression becomes true" trigger option iff a required expression has been defined.
I'm aware that the alternate way to write this is to trigger on everything, but begin the rule with a check for the gating condition and exit immediately if it's not true. It works, but it's less intuitive.
I want to trigger on a transition from state A to state not-A. Can I set a required expression of state A and trigger on any change?
I'd assume that when the required expression becomes true, the subscriptions for the trigger events are created/removed; thus, the first condition won't fire and the second one will?
These questions are just begging to be rendered as logical statements, so that we're 100% on what's being asked. And let's number the statements as well, for easier reference.
[1] I want a rule to execute on a collection of triggers, but one of those is gating -- if that condition is false, ignore the others; when it becomes true, or when any of the others occur while it remains true, the actions should run. I almost want a "Required expression becomes true" trigger option iff a required expression has been defined.
[2] I'm aware that the alternate way to write this is to trigger on everything, but begin the rule with a check for the gating condition and exit immediately if it's not true. It works, but it's less intuitive.
[3] I want to trigger on a transition from state A to state not-A. Can I set a required expression of state A and trigger on any change?
Am I hearing you right?
[1] A OR [A AND B]
where A is the Req Exp and B is one or more (OR'd) triggers
In this case, you may as well just have A as your trigger, because that's logically equivalent.
[2] If A = TRUE then trigger
Yep, saying same thing, logically speaking, as in [1].
[3] If A = (value) then trigger
This will only evaluate to TRUE if A transitions from (some other value) to (value), so there's no need to concern yourself with A's state prior to the transition.
However, RM does let you define a trigger using a Variable, like this:
Variable X != (value), which of course will trigger the rule the moment X steps off of that value onto any other.
To sum up: Triggers are essentially "leading edge" events (i.e. 'Switch turned on' or 'Sunset'), whereas Conditions are usually steady states (i.e. 'Wednesday', 'Var > 5', or 'Switch is on') that persist over a longer time span. Having a Required Condition that evaluates to FALSE spares having to even look at any of the Triggers, as you correctly surmised.
This is correct. When a Trigger involves the same event that might change the truth of the Required Expression, it will only actually trigger the rule when the Required Expression is already true. If the Required becomes true because of the event, that won't trigger the rule (second one will). Such device events can be seen in the Event Subscriptions for the rule to run method stHandlerA.
Thanks, good to confirm that. I think in certain cases it might be nice to have a "Required Expression becomes true" trigger that fires the rule during the wake-up where the subscriptions for other triggers are registered.
The most common I can think of are rules which don't matter when no one's home -- the immediate impulse is to put a Required Expression of "Mode is NOT Away" and then list the triggers that matter when someone is home. But the rule also needs to execute when someone arrives home, to choose the appropriate state for the current conditions.
But as noted, I'm aware there are mechanisms to accomplish the same effect already, so it may not be worth the effort for what's basically a shorthand.
