Release 2.3.6 introduces a new feature in Rule 5.1: Conditional Triggers. Just as it sounds, a Conditional Trigger involves the evaluation of a Condition upon an event that would trigger the rule, and only triggers the rule if the Condition is true. To make this possible in a rule, first a Condition has to be defined. This is now possible on the main page of the rule:
The Create Conditions page is now available both on the main page, and the Actions page. Below, the first Condition has been created, and notice that it is presently marked as unused:
Note that the Condition no longer is marked as unused, since it is used in a Conditional Trigger. At this point, once this rule is installed, every time the Front Door opens, the Condition is evaluated, and if it is true, i.e., between Sunset and Sunrise, the rule will be triggered. If the Condition is not true, i.e., during the day, the rule would not be triggered when the door opens.
Difference Between Required Expression and Conditional Trigger
In some ways a Conditional Trigger is similar to a Required Expression, but there are key differences:
A Required Expression can contain multiple Conditions in an expression, and that expression must evaluate to true for any Trigger to fire the rule. Furthermore, if the Required Expression is false, the event subscriptions for the rule's Triggers are removed, and nothing at all happens for any of those events.
A Conditional Trigger comprises a single Condition, and each Trigger can have its own Condition (or none). Whenever the corresponding trigger event occurs, the Condition is evaluated, and the rule will be triggered only if that Condition is true.
A rule can have both a Required Expression and Conditional Triggers. Only if the Required Expression is true are subscriptions created for each Trigger, and only if the Condition for a Conditional Trigger is true will that trigger event fire the rule.
I'm trying to wrap my head around this, maybe all my rule trigger's required expressions are so simple I haven't seen the need for it. Can you give a quick example where this new feature simplified one of your rules?
Personally, it has to do with what changes at what frequency. With a Required Expression, every time anything referenced in the expression changes, the rule has to wake up, see if the RE is true or not, and subscribe/unsubscribe to the trigger events. If it's something infrequent (Person X leaves/arrives), that's fine. If it's something frequent (motion in Living Room), that will be a lot of useless load.
On the other hand, a Trigger Condition is only evaluated after-the-fact when the trigger occurs, meaning less load if triggers are rare.
Also, you can use them to effectively make AND triggers, like:
At 9:30 PM, only if bedroom door closed
When door closes, only if after 9:30
The previous spelling of this would be to trigger both at 9:30 and when the door closes, then immediately check at launch if both conditions are true and exit if not.
That's probably equivalent load to what this feature does, but it makes the rule easier to understand when you revisit it in a year.
Without knowing the semantics of the trigger event subscription mechanism I wouldn't have guessed that there was additional load generated every time any of the elements of a Required Expression changed; I would have assumed the Required Expression was simply evaluated on receipt of a Trigger the way the Conditional Trigger's conditions are.
This is actually the primary distinction between the two -- however, the tradeoff depends on the complexity of the Required Expression and the triggers, and relative frequency of events.
If a Required Expression has relatively sedate events, while the triggers might happen frequently, then using a Required Expression is clearly superior. This is because without subscriptions in place for the trigger events when the Required Expression is false, the rule will not even load when those would-be trigger events happen. Note: Every time a rule loads, its state has to be loaded, some code executed (how much depending on the Required Expression, Actions, etc), and then state written back out. All of that consumes processor resources (not much, but more than zero).
If, on the other hand, a Required Expression has relatively frequent events causing its evaluation (each of which loads the rule), and the triggers are relatively sedate, then a Required Expression may not be the best design for that rule.
I think all of this can very easily be overthought. The overall frequency of events relative to CPU power is quite small for most hubs, and for most hubs it really doesn't matter what the relative overhead of one approach to another is. It's a rare hub for which any of this matters. If it does matter, odds are high that hub is going to have other issues as well, and using more than one hub is probably something to consider.
Bottom line about Required Expression vs Conditional Trigger: Use what makes sense to you, what you can easily understand, and that seems logical. Avoid complexity. KISS.
