Rules and Rule Sets
Rules are a collection of trigger conditions with optional constraint conditions that allow you to create logic that reacts to some change in entity states. The triggers in a rule are the conditions that cause action. When a rule's trigger conditions are met, if there are no constraints, the rule will set, and launch its Set reaction. One a rule is set, it does not launch action again until it is reset (when the trigger conditions are no longer met). When a rule transitions from set to reset, it will launch its Reset reaction, if any. The constraints on a rule are used to restrict when a rule may set; these are most often used in conjunction with time conditions to prevent reactions from occurring at certain times of day or night.
A very common rule example is a motion-controlled light. A single condition in Triggers is used to check the state of the motion sensor entity (e.g. "motion sensor binary_sensor.state is TRUE"). The Set reaction then contains an action to turn on a light. The Reset reaction may contain an action to turn off the light.
Trivial Example Alert!
This is a trivial example only; in practice, you usually need to do a little more, but often it's not much. In this case, the light only remains on for as long as the motion sensor indicates there is motion. But some motion sensors only send this signal for a few seconds, and some for a couple of minutes, and regardless, it's almost always not the length of time you actually want. To get the timing desired, the most common solution is to apply a "delay reset" option (aka an "off delay") to the motion sensor trigger condition, specifying the minimum length of time you want the light on when motion is sensed. This has the effect of keeping the light on for at least that long, and if there are repeated motion sensor events during the delay, the delay is automatically extended. See Condition Options for detail on how to find and set the "delay reset" option, and other handy (but advanced) features.
Rule Sets are just organizational groups that help you organize your rules. They have no effect on the execution of rules whatsoever. You can organize your rules any way you want, and reorganize them at will without disrupting their logical. When you're starting out, you may be wondering how you should organize your rules; if you're not sure, start by creating a rule set for each room, and put the rules for that room in that rule set. You might also make separate rule sets for rules that do house-wide tasks.
How Rules are Evaluated
Rules are evaluated whenever they are enabled and a change in an entity or other condition that is the subject of one of the rule's triggers is updated. For example, if a rule has a trigger on a logic state for a motion sensor, the rule will be watching that entity and re-evaluate whenever the entity changes state. If a rule has a time-based condition, it will evaluate whenever it hits an "edge" — a point in time at which Reactor has determined that the rule should be re-evaluated.
When a rule is evaluated, the following happens in the order shown:
- The rule's expressions, if any, are evaluated in their listed order;
- The rule's trigger conditions are then evaluated;
- If the rule's trigger condition result is the same as its prior state; evaluation stops.
- If the rule's trigger condition state is changing from false to true, the constraint conditions are evaluated; if the constraint conditions (if any) result in false, evaluation stops. Otherwise, the Set reaction is launched;
- If the rule's trigger condition state is changing from true to false, the Reset reaction is launched.
It is important to note these facts about rule evaluation and consider them when devising your conditions:
- Rules only run their reactions when the trigger state changes. That is, if some stimulus causes the evaluation of triggers to change state from false to true (and any constraint conditions are also met), the rule sets and the Set reaction will be run. If a later stimulus causes another evaluation of the triggers and the result is still true, the rule is already set so the Set reaction is not run again, because there is no rule state change (it was set before and is still set now).
- Constraints only apply to restricting/preventing the Set reaction from running; the constraints do not prevent the Reset reaction from running, and it will launch any time a rule's state changes from set to reset.