Reactor can run actions directly, without relying on Vera scenes. These Reactions are run when a condition group changes state (e.g. from false to true or vice versa). Each condition group has two Reactions: one for when the group becomes true, and one for when the group becomes false. An Reaction can have one or more actions, which are the individual steps to be taken in response to group's change of state.
The following action types are available in Reactor Reactions:
- Entity Action - Run an action on a entity (e.g. turn a light on or off, change dimming level or thermostat mode, etc.);
- Delay - Delay execution of subsequent actions in the Reaction;
- Run Reaction - Start another Reaction;
- Stop Reaction - Stop a running Reaction;
- Notify - Send a notification;
- Set Variable - Set a variable's value;
- HTTP Request - HTTP GET or POST request to a remove server/service
- Shell Command - Run a shell command
- Comment - A comment to help you document your Reaction.
The Reactions Tab
The Reactions tab is where you will define and edit your global Reactions, which are Reactions that can be run by any rule (i.e. the Reaction's built-in set and reset reactions can use Run Reaction actions to run global Reactions).
Starting at the top of the screenshot the "Show Reactions" dropdown (A) lets you choose which Reactions are shown. Because there are two Reactions for each group, the list can get quite long quickly, and often only a couple of the Reactions are actually used, so this menu lets you filter the view. For example, if you choose "In Use", the view will only show Reactions that have actions in them.
Each Reaction has an action list: the list of actions it will perform. Actions are performed in the order shown in this list.
The "Save" and "Revert" buttons (B) appear in each action list header and are used to save the current Reaction configured, or revert to the last saved, respectively. The revert is the only "undo" offered, so you are encouraged to save often.
Below that are the actions. Each action has a selectable action type (C), the action parameters (D), and action controls (E). The action parameters (D) vary from action type to action type. The action controls (E) have some standard buttons and some action-specific buttons. You can see from the screenshot that every action has up- and down-arrow buttons, and an "X" button; these are "move up", "move down" and "delete", respectively. The action-specific controls are covered in the description of each action type.
At the bottom of each Reaction, below the action list, are two buttons: "Add Action" and "Copy From...". The "Add Action" button adds a new action to the end of the Reaction's action list. The "Copy From..." button presents a pop-up menu from which you can select another Reaction; the selected Reaction's actions will be imported into the current Reaction (at the end).
Reactions and Action Execution
An Reaction can have one or more actions. The actions are run sequentially. Actions that spawn Luup jobs (such as turning a Z-Wave device on or off) do not block until the action completes — the job is submitted and the next action in the Reaction is run immediately, and so the next action may complete before the job finishes or perhaps is even started by Luup.
In the discussion of conditions and groups, there is a callout box ("Important Concept!") that states that groups, like any condition, only have two states: true and false. Reactions are only run when the state of a group changes, that is, goes from false to true, or from true to false. Let's use an example to illustrate why this concept is so important.
Let's say we have a group with two conditions, and it's an OR group, so either condition (or both) being true results in the group itself being true. We start with both conditions false, so the group is also false. When one of the conditions goes true, the group goes true, and any actions in the "is TRUE" Reaction for the group are then run. However, if later the second condition in the group also goes true, the group is already true and does not change state as a result, so the "is TRUE" Reaction is not run again.
As illustrated in the example above, Reactions only run once per state transition of their group.
Reactions can have delays, which pause the run of all actions listed after the delay. Multiple delays are permitted. This is very much like Vera scenes, except that Reactor Reactions are durable across reloads and reboots of the system. An interrupted Reaction will resume after the restart, and effort is made to keep the delayed actions on schedule. For example, if a delay of 5 minutes in encountered in execution at 2:15:03PM, and a reload or reboot occurs during the delay, the actions would resume at 2:20:03PM as long as the system is up and ready at that time (otherwise, they will occur as soon as the system allows after the scheduled time).
When a group switches between true and false states, it's possible that delayed actions from the previously-started state's Reaction, called the counter-activity, are still running or waiting to run. If there are actions for the group's new state, the counter-activity will be stopped — the delayed actions will be cancelled and not allowed to run. If there are no actions for the group's new state, the counter-activity will be allowed to complete. For example, if you have a rule with a "Set" reaction that turns on a light, delays 60 seconds, and then turns off the light, and the group goes false during the 60-second delay period and there are "is FALSE" Reaction actions, the turn off of the light will never happen. But, if there are no "is FALSE" actions, the true Reaction will be allowed to turn off the light as scheduled.
The existence of any action, even just a comment, in a group state's Reaction is sufficient to stop the counter-activity. So, if you have a true Reaction with several actions and delays, and you want those to stop on group false, putting a comment in the group's "is False" Reaction as the sole action is sufficient to stop the true Reaction.
Timing is not guaranteed!
The foregoing describes the order in which Reactions are started. But if, for example, two Reactions have equal delays, there is no guarantee which will resume first when the delay period expires.
The comment action doesn't actually do anything, it's just a placeholder for text that you can use to document your Reaction.
It does have one special feature: if the first character is a "*", the comment text is written to the system log, which can be seen in the Logic Summary (Tools tab).