Sometimes everyone forgets to do something important. In the context of a smart home/building, such an area is security. This tutorial presents a solution that will help you avoid the problem of forgetting to arm the alarm when leaving your home or company.
The assumption is as follows: if no motion is detected in the building for a specified amount of time, the alarm will be armed automatically. Sounds simple, right? Almost trivial. But to showcase the capabilities of the DOMIQ system, we’ll use a few concepts that may come in handy in the future, as they demonstrate the general operation model of the system and approach to problem solving. We’ll break our problem into steps 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.
For our solution, we need a way to detect motion in the building. Here, motion detectors connected to the alarm system come to our aid. To treat the building globally, we’re interested in detecting motion from all sensors simultaneously. At this point, you might be thinking: “I have dozens (or more) detectors in my building, 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 detection by any sensor connected to the alarm panel. In the DOMIQ system, the identifier for this is: E.IDS.input.
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.
As mentioned earlier, the alarm should be armed if no motion is detected for a certain time. So, as you might guess, we will need a timer. The running timer should restart the countdown if motion is detected again. This is where the TIMER command helps, which allows creating timers using a simple command triggered by 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.
At the same time, we use a feature of the TIMER command, which allows resetting the timer by calling the same timer ID again. In other words, every time any of the detectors detects motion, our timer will be reset and will start the inactivity countdown from scratch. Thus, the next assumption is fulfilled – we have a function that detects lack of activity!
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.
In fact, there is no mystery here – we’ll simply use another key feature available in the DOMIQ system – event macro definitions. The Base module allows sending any text commands in the system and simultaneously defining events that respond to those commands. A good example is 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:
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:
Based on our scenario, imagine that your alarm system has 10 zones. Without using a macro definition, it wouldn’t be possible to arm them all at once from the timer (the TIMER command can call only one command). Additionally, you might want to manually arm the entire system from the Remote app. Instead of arming all 10 zones manually, you can call your macro, and the system will send 10 commands that arm everything.
Macros are defined just like regular events, except for the Channel field, which in this case contains the command acting as the unique identifier of your macro.
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.
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 is about automatic alarm arming, but the concepts presented here can be used to implement other functionalities in the system. An example could be a macro definition for turning off all lights in the building or for a global macro to change heating/cooling temperature settings.
When describing the event for detecting motion from any sensor, I wrote about matching patterns and parameters. However, the information about which sensor triggered motion was not used anywhere. To capture this information, we use parameters. Just as patterns act as filters for events, parameters are containers that store what the patterns have filtered.
To show how it works, study the event definition below:
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 last detected movement into the variable VAR.lastInput. The parameter $C1 is a variable storing the value filtered by the pattern %d+. A single event definition can have a maximum of 9 parameters, numbered $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 great flexibility in declaring events in the DOMIQ/Base module.
Powered by BetterDocs
