I have a basic alarm system in Reactor that I’ve meant to make into a video for some time, but my lab where I film has been such a mess that I haven’t done it. It’s a long config, but I don’t think too difficult to understand for anyone who has spent a little time with Reactor.
The first thing I did was make a group called “Logic Elements” that’s NUL. This is a container for some logic sub-functions.
To my “Logic Elements” group, I first added three “zone” subgroups. I called them “Z1 Smoke Detectors”, “Z2 Perimeter”, and “Z3 Interior”. These are all OR groups. The Z1 group gets all of my smoke detectors (“thanks, Captain Obvious”). The Z2 Perimeter group gets those door sensors (or locks or whatever) that should have a delay before causing an alarm when tripped. These are your entry/exit doors, typically. The Z3 Interiors group gets my motion sensors (more on this at the end). The conditions in these groups are generally of the form: sensor device Tripped is TRUE (or lock Status is FALSE, for unlocked if you are using a lock as a sensor). Remember these must be OR groups, so any sensor tripping makes the group go true. Easy enough so far.
The first “Active” logic subgroup is “Away Mode Breached”, created as a child of “Logic Elements”:
Group: Away Mode Breached - AND
- Condition: House Mode in Away, Vacation
- Group: Away Zone Rules - OR
- Group Interior Zone Muted - AND
- Condition: Group State “Z3 Interiors” is TRUE
- Condition: Group State “Z2 Perimeter” is FALSE
- Group Perimeter Delayed - AND, sustained for 15 seconds (or whatever entry delay)
- Condition: Group State “Z2 Perimeter” is TRUE
This group goes true in away or vacation mode when either the Z3 Interior or Z2 Perimeter groups go true. The interiors are gated by the perimeter, so that if the perimeter group is true, the interiors are muted — when you enter, it’s often the case that a door sensor trips first (perimeter) followed by an interior (motion sensor as you come in); this structure prevents the motion sensor from overriding the delay and immediately triggering the alarm.
Onward… we use night mode to mean what many alarm systems call “stay”, the mode in which interiors are not considered but perimeters are (so you can secure the house but still be in it). This subgroup is also created as a child of “Logic Elements”:
Group: Night Mode Breached - AND
- Condition: House Mode is Night
- Group: Night Zone Rules - OR
- Condition: Group State “Z2 Permimeter” is TRUE
This should be simple enough: if the perimeter is breached in night mode, the group goes true. Notice there are no delays here: breaching the perimeter at night is an immediate alarm.
Finally, we add “Home Mode” to “Logic Elements”: This group simply tests if we’re in home mode; there are no zone tests:
Group: Home Mode - AND
- Condition: House Mode is Home
OK. Now the big business. The “In Alarm” group, which should be created under root (top) determines if the system should be in alarm:
Group: In Alarm - OR
- Condition: Group State “Away Mode Breached” is TRUE
- Condition: Group State “Night Mode Breached” is TRUE
Easy, right? If either of our “breached” conditions is true, the system should be in alarm. Now let’s make some noise. The last group “Sound Siren” should be created under root:
Group: Sound Siren - OR
- Condition: Group State “Z1 Smoke Detectors” is TRUE
- Group Breach Hold - AND
- Condition: Group State “In Alarm” is TRUE, pulse mode output, 240s one time
- Condition: House Mode is Away, Night, Vacation
(The last condition could also be: Group State “Home Mode” is FALSE)
Here we check if the smoke detector zone is tripped, because we always sound alarms when smokes are tripped, regardless of house mode or any delays. The “Breach Hold” subgroup checks “In Alarm” for true while in away, night, or vacation house modes. If smokes are tripped or Breach Hold is true, the true activity for this group can turn on a siren, send messages, turn on lights, whatever. The false activity can turn them off. Notice that the Breach Hold group is pulse output for 4 minutes (240 seconds) — that limits the amount of time a siren will sound to 4 minutes, which is common in the US for alarm systems to prevent a false alarm (e.g. broken perimeter sensor) from sounding the alarm indefinitely.
This is intended to just be a starting point, and a demonstration of using groups to isolate functional logic. There are lots of alarm features you could add; for example, this simple model doesn’t address that some perimeter zones should not have a delay when tripped. For example, you may have a side- or basement door that you don’t normally use for entry/exit; this should cause an immediate alarm when tripped and the system is active. It’s not appropriate to add those sensors to Z3 Interiors because they would be ignored in Night mode. I leave it as an exercise for the reader to add the necessary logic (spoiler/hint: it should be easy to create another group for them “Z4 Perimeter Immediate” and add conditions to the “Rules” groups for the various house modes).
