Skip to content

# 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.

In the simplest form, a set of conditions will be created (by you) in the Triggers section of the rule. Once saved and the rule enabled, the following will happen:

1. The rule's expressions, if any, are evaluated first, according to the rules for Rule-based Expressions;
2. The conditions in the rule's Triggers are then evaluated, producing a true or false boolean result;
3. If the Triggers result is true, the rule state transitions to SET; otherwise, it transitions to RESET;
4. If that's a change from the rule's prior state, the actions in the rule's Set or Reset reaction are run based on the new rule state.

So basically, when the Triggers conditions are met, the Set Reaction runs once. When the Triggers conditions are no longer met, the Reset Reaction runs once.

The Triggers will be re-evaluated if a dependent entity or other system object changes. For example, if you have a condition that is sensitive to a sensor's value, the rule's conditions will be re-evaluated any time that sensor's value changes.

The actual flow of control for a rule is actually just a little more complicated. There is also a set of conditions called Constraints. The Constraints are not active and don't trigger action, rather they are more like a passive filter that can prevent it. For example, let's say you want a motion sensor to turn on a light, but only between sunset and sunrise. The Triggers would include sensing motion from the motion sensor, and with a condition watching that motion sensor entity, the rule would re-evaluate any time the motion sensor state changed. The time period between sunset and sunrise is a Constraint; it is only checked if the Triggers detect motion. If the Constraints aren't met, processing of the rule stops and the rule does not change state. If the Constraints are met, the rule will change state and, presumably, the light will be turned on.

Here is a complete flowchart of the evaluation process:

Most users don't do a lot with Constraints, they just put everything in Triggers with the appropriate logic.

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 result 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.

Updated: 2025-Nov-24