Condition Options
In the right-side "tools" area of each condition in the condition editor is a downward-pointing arrow (chevron) that opens the options pane for the condition. Not all condition types support all options, so the options shown in the conditions pane will reflect the supported set for the subject condition.
The above image shows the options pane open, with a sequence being set up between the two Device State conditions (Inhibit Switch #3 Status must change to 1 before the VirtualSwitch #14 Status goes to 1 for the group to be successful/true).
The condition options can be collapsed (hidden) by clicking the upward-pointing arrow (chevron) in the "tools" area of the condition row.
The sequence restriction is used when the order of triggering is important to the condition's meaning. For example, let's say we want a ReactorSensor that trips when a door sensor is tripped (door opened) while the house is in Away mode, but not if the door is open when the house enters Away mode (perhaps the door is still open because you haven't left yet). That is, the Away mode transition has to come before the door opens for the overall condition to be met (true). To implement this, the group, configured using the "AND" operator, would have two conditions. The first would be a House Mode condition for Away mode. The second would be a service condition that matches the Tripped=1 state of the door sensor device, plus the selection in the options of the first condition from the "Only after" dropdown. This means that the second condition can only become true if the change of the door sensor's Tripped state from 0 to 1 occurs after the time at which Away mode became active. If the door is already open when the house enters Away mode, the timestamp of the door opening is before that of the house entering Away mode, so the ReactorSensor will not trip. If the door is then closed, and later opens, then the timestamp of that later opening is after that of the house entering Away mode (meeting the "Only after" sequence restriction), so the ReactorSensor does trip. The additional "within" time specification restricts the success of the condition to the sequence of action occurring within the specified number of seconds (e.g. if B comes after A within X seconds); if 0, which is the default, there is no time restriction.
The "Sustained for" option allows the condition to become true only if the test result is sustained true for the set number of seconds. This is useful, for example, if you want to program a condition for a door being left open for more than 5 minutes--you would set a service condition for your door sensor to test if the "Tripped" variable is equal to "1", then add the duration option "Sustained for at least 300 seconds". Any time the door is opened, the state variable value test is met, but the ReactorSensor will not consider the overall condition met and mark it true until that state has been sustained for an unbroken period of at least 300 seconds. This timing survives Luup reloads/restarts.
You can invert the timing test, and require that a test result be sustained for less than a period of time for the condition to be true. This might be used, for example, if a switch is turned on and quickly turned off (and that may then turn off all the lights in the room).
The "Repeats" option allows the condition state to become true only if the condition's test state match repeats the specified number of times over the specified interval (e.g. a motion sensor trips 3 times in a minute, or a switch is turned on twice--on-off-on--within 10 seconds). This is one of my favorite options, as I use it to make "master" switches where turning a particular switch on and off twice in rapid succession turns off all the lights in the room or on that level of my house.
The Delay Reset option allows you to delay the transition from true to false of a condition for a set period of time (in seconds). If, at the end of the delay period, the test state is still false, then the condition state goes to false. If the test state goes true during the delay, the delay is cancelled and the condition state remains true; if the test state later goes false, a new delay period is started. So, if the test state toggles between true and false multiple times within the delay period, the net effect is that the delay is extended.
This can be used to "debounce" a sensor, like a door sensor. This classic example gave rise to this option: a Reactor user wanted to send a notification when a door was opened, but if the door was opened and closed several times in rapid succession, only one notification be sent. By setting the "delay reset" period, when the door is closed, the delay goes into effect, and during the delay, any subsequent opening and closing of the door is ignored and does not trigger additional notifications, as long as those swings occur during the delay. A new notification will not be sent until the door opens after having been closed for at least as long as the delay period.
This is a particularly useful feature for motion sensors and lights: a motion sensor used to turn on a light when tripped and off when untripped will turn the light on when you enter the room and turn it off when the sensor stops sensing motion, which may be just a few seconds if you stop moving, potentially leaving you in the dark in the middle of the room. If you then just move a little, the light flicks back on. Wouldn't it be nice if the light stayed on longer? If we add, for example, a 10-minute reset delay, then the light will go on when we enter the room, and remain on, and any time we move just a little bit, the 10-minute delay starts over, thus ensuring the light remains on while we are in the room (as long as we move enough to make our continued presence known to the motion sensor). If we leave the room, the light will go out 10 minutes later. In effect, this one condition option provides the most basic function of the DelayLight plugin, and probably the most common automation requested.
The "Latch" option fixes the state of a condition, when met, to true until the group to which that condition belongs goes false, even if the test state of the latched condition becomes false. Using latched conditions successfully has two requirements:
- It must be used with at least one non-latched condition in the same group, because the non-latched condition(s) is/are what resets the group--if you don't have an unlatched condition to reset the group, the latched conditions will stay latched forever (even if you manually untrip the ReactorSensor).
- The parent group must use the "AND" operator, as any other operator would allow the latched condition to hold the parent group true and thus never reset.