1. Introduction #
Everyone occasionally forgets to do something important. In the context of a smart home or building, security is one such area. This tutorial presents a solution that helps you avoid the problem of forgetting to arm the alarm when you leave your home or business.
The assumption is as follows: if the system detects no motion in the building for a specified period of time, it will automatically arm the alarm. Sounds simple, right? Almost trivial. But to showcase the capabilities of the DOMIQ system, we’ll use a few concepts that may prove useful to you in the future, as they illustrate the system’s general operating model and approach to problem-solving. We’ll break our problem down into stages and solve it step by step.
For the purposes of this tutorial, we present integration with the Satel Integra alarm system. The configuration description will refer entirely to the Events tab in the Base module configurator.
2. Solution #
2.1. Motion detection in the building #
For our solution, we need a way to detect motion in the building. This is where the motion sensors connected to the alarm system come in handy. To treat the building globally, we’re interested in detecting motion across all sensors at once. At this point, you might be thinking: “there are several dozen of them in my building (or even more), so I’ll need a lot of events.” Not at all — we’ll do everything using a single event!
Matching patterns and parameters
Matching patterns and parameters will help us. This is a functionality of the event processor in the Base module, which allows defining rules to capture many actions in the system within a single definition. Matching patterns can be thought of as a filter that captures certain things and lets others through. You can read more about patterns and parameters in the Base module documentation: https://domiq.pl/produkt/domiq-base/
The base event will be motion detected by any sensor connected to the alarm control panel. In the DOMIQ system, the identifier E.IDS.input is used for this purpose.
So the first step is to add a new event. You can fill in its description for easier navigation.
In the Channel field, enter: E.IDS.input.(%d+)
Here we used a matching pattern: %d+, which means “capture one or more digits”. If we wrote just %d, our pattern would capture only a single digit between 0–9.
Additionally, thanks to the matching pattern, the number of the sensor that was triggered will be known. In the Data field, enter: 1, because we are interested in motion detection.
2.2. Lack of activity in the building #
As mentioned earlier, the alarm is to be armed once the system detects no motion for a specified period of time. So, as you’ve probably guessed, we’ll need a timer. A running timer should restart its countdown whenever motion is detected. This is where the TIMER command comes in handy, letting you create timers using a simple command triggered from an event.
In the Actions section, click +Command and fill in the window as follows:
Name: TIMER.autoalarm.1h.C.alarmon
Value: 1
A few words of explanation: the command TIMER.autoalarm.1h.C.alarmon creates a timer named autoalarm (the name must be unique within the system configuration, as it serves as a unique identifier for the timer). The timer has a defined delay of 1 hour – of course, you can use a different value. After the time elapses, the timer will execute the command C.alarmon. For now, we won’t explain what this command does – we’ll get to that later.
In one go, we’re also taking advantage of a property of the TIMER command that lets you reset the timer by calling the command again with the same timer identifier. In other words, every time motion is detected by any of the sensors, our timer will be reset and will restart counting down the period of inactivity. So the next assumption is fulfilled — we now have a functionality that captures the absence of activity!
2.3. Arming the alarm #
The final step of our solution is to arm the alarm zones when the system detects no motion in the building.
Now we return to the “mysterious” command C.alarmon, which was defined in the timer.
Basically, there’s no secret here, since we’ll simply use another important functionality available in the DOMIQ system — event macro definitions. The Base module lets you send any text commands within the system, while simultaneously defining events that respond to those commands. An example of this is exactly our C.alarmon command, which will be sent by the timer once it finishes counting down. The content of this command can be anything, as long as it follows a few rules:
- It is prefixed with C. or E.
- It does not contain Polish characters, spaces, or other special characters. Only dots and underscores are allowed. Therefore, a valid command could look like: C.alarm.on or C.alarm_on.
Try to think of this command as a unique identifier for your macro.
To make the system respond to such a command, you need to define another event, which we call a macro definition or macro for short.
What are macro definitions for?
Macros give two fundamental benefits:
- “Wrapping” multiple commands into a single definition that can easily be invoked within the system. It’s therefore a mechanism that lets you reuse the same definition in multiple places. A macro defined in events can be triggered, for example, by pressing a button in the Remote app, as the result of a timer running, or as the outcome of a function in Logic.
- Thanks to wrapping multiple commands into one, you can easily reuse this macro elsewhere, avoiding the need to redefine the same commands in other events — saving you time and the Base module’s resources.
Based on our scenario, imagine your alarm system has 10 zones. Without wrapping the commands into a macro definition, it wouldn’t be possible to arm them all simultaneously from the timer (the TIMER command can only trigger a single command). Additionally, you might also want the ability to manually arm the entire alarm system, e.g. from the Remote app. Instead of manually arming all 10 zones, you can call your macro, and the system will automatically send the 10 commands that arm the whole system.
Macro definitions don’t differ in any way in their setup from a regular event, except for the content of the Channel field, which in this case doesn’t contain a predefined identifier, but instead the command that serves as your macro’s unique identifier.
So let’s do it! Add a new event and define it as follows:
Channel: C.alarmon
Data: 1
In the Actions section, add commands to arm the respective alarm zones. Below is an example for one zone:
Name: C.IDS.armed.1
Value: 1;pin:1234.
3. Summary #
Now we’ve reached the end of our solution. To wrap it up, let’s go over the most important steps again:
1. We defined an event for motion detection by any sensor, which sets a timer that counts down to automatic alarm arming:
Channel: E.IDS.input.(%d+)
Data: 1
Actions -> +Command
Name: TIMER.autoalarm.1h.C.alarmon
Value: 1
2. We defined a macro definition for the action of arming the alarm zones. The macro will be triggered by the timer after the countdown ends:
Channel: C.alarmon
Data: 1
Actions -> here you define any number of commands sent to individual alarm zones.
Our tutorial covers automatic alarm arming, but you can use the concepts presented here to implement other functionalities in the system. An example here could be a macro definition for turning off all the lights in the building, or a macro for globally changing the heating/cooling temperature settings.
4. Appendix (for the curious) #
When describing the event for detecting motion from any sensor, I mentioned match patterns and parameters. However, the information about which sensor triggered the motion wasn’t used anywhere. Parameters are exactly what’s used to capture this information. Just as match patterns act as a kind of filter for events, parameters are a kind of container that stores what those patterns have filtered out.
To show how this works, study the following event definition:
Channel: E.IDS.input.(%d+)
Data: 1
Actions -> +Command
Name: C.VAR.lastInput
Value: $C1
The above event will save the number of the motion sensor that most recently detected motion in the VAR.lastInput variable. The parameter $C1 is a variable that stores the value filtered out by the %d+ pattern. A single event definition can contain a maximum of 9 parameters, which are numbered sequentially from $C1 to $C9.
Below is an example with 3 matching patterns and 3 parameters:
Channel: E.LCN.output.(%d+).(%d+).(%d+)
Such an event captures actions from any LCN dimmable output in any segment and module.
If you want to separately capture the segment number, LCN module ID, and output number, then these values are available respectively in parameters $C1, $C2, and $C3.
Patterns and parameters are a powerful mechanism that introduces real flexibility into declaring events in the DOMIQ/Base module.