Rule 5.1 Predicate and Repeat While/Until Rule

Bruce, (@bravenel), two questions about the new Rule 5.1 improvements. I looked, but couldn’t find the answer.

  1. Predicates:

If a Predicate is false, are trigger events dropped or, instead, are they queued, such that they fire the rule’s actions when the Predicate becomes True? I can imagine use cases for either design, but knowing the answer is helpful for designing complex Rules.

  1. Repeat While rule, Repeat Until rule:

If a succession of OR conditions becomes True, or a succession of AND conditions becomes False, does evaluation of the rule stop and execution of the actions begin without evaluation of the remaining conditions, or, instead, is the entire rule expression evaluated and then tested? Could be useful to know when ordering the rule expression. Also, is order of evaluation guaranteed to be the written order of the conditions (sub rules) in the rule?

Thanks in advance.

1 Like

They don't happen, no queuing. If Predicate is false, subscriptions to trigger events are removed, so the rule is not triggered at all. When the Predicate becomes true, the event subscriptions are recreated, and the rule will be triggered again. Even with subscriptions active, the last state of the Predicate is checked before any actions are run, and if false, the rule exits. Net: Predicate false means the rule is not triggered.

Correct, it is a strictly left to right evaluation, and once something to the left of OR is true, or the left of AND is false, it returns true or false and stops evaluating. Of course, you have to take into account parenthetical grouping, but this will hold true for any sub-rule as well.

3 Likes

"Preconditions" is only part of what is happening, as what you can use there is a full logical expression, not just conditions.

As soon as you open the Predicate page it says:

The rule defined here must be true for the Triggers to fire Actions:

The use of the word "rule" here is consistent (now) with other parts of the UI. A "rule" is a logical expression made up of conditions, logical operators, and parenthetical grouping. It is called such in each context where this sort of thing can be used: IF THEN, WHILE, REPEAT, WAIT etc.

It's difficult to find words that succinctly describe "a logical expression". "Conditions" was found to be lacking...

1 Like

Given that you can add/subtract a variable to another variable, you only need a single 'temp' variable, that can be a local variable.

set temp to acTemp - senTempMBR
set acTempVar to abs(temp)
set temp to acTemp - senTempKitchen
set temp to abs(temp)
set acTempVar to acTempVar + temp
set temp to acTemp - senTempHBath
set temp to abs(temp)
set acTempVar to acTempVar + temp
set acTempVar to acTempVar / 3

These sort of things point towards writing your own custom app in Groovy.

2 Likes

You can use log actions to show step by step what is happening as the app runs. Those acceptable %variable-name% as a way to show variable values.

I'm talking about doing your own logging directly from the rule, using the log action. Those logs you are showing are pulling information from the UI of the rule creation, and it is not updated in realtime as the rule runs, hence can be misleading as to what is actually happening.

1 Like

If you put in your own logging with log actions, I would suggest you turn that off.

2 Likes