Let eGeoffrey manage your alarm system

[user2684]

A pretty common use case for eGeoffrey is to monitor your house and alert you in case somebody is getting in while he shouldn't.

All of this is a bit more advanced to implement since there is (and cannot be) a package ready-to-use since your alarm can be based on one or more technologies. This How To is intended to depict a possible approach rather than step by step instructions.
What we want to achieve eventually here is to have different sensors integrated, each sensor can be armed or not and an alarm status button to control if the overall alarm is on or off. When on and an armed sensor triggers, we get a notification.

Step 1: identify which technologies to integrate

Depending if you have built your alarm system, you have a commercial product or a combination of the two, you first need to get this data into eGeoffrey before doing anything else. Usually, each technology you are using maps back to an eGeoffrey package capable of handling the data ingestion. Some real world examples are the following:

• MySensors (through the package egeoffrey-service-mysensors) : your custom arduino/ESP-based boards could have attached motion sensors, flood sensors, distance sensors, magnet sensors for your doors/windows ecc. All of those would trigger upon a condition and eGeoffrey can get the value for your through a MySensors gateway (serial, ethernet or MQTT). For some ready-to-use examples visit https://www.mysensors.org/ and https://github.com/mysensors/NodeManager.
• Zigbee (through the package egeoffrey-service-zigbee2mqtt) : commercial zigbee-based sensors interacting with a zigbee receiver attached to you raspberry device. If you don't know this project, it is definitely worth giving it a look at https://www.zigbee2mqtt.io/. Allows easily integrating a large number of commercial sensors (Philips, Xiaomi, etc.): https://www.zigbee2mqtt.io/information/supported_devices.html
• rtl433 (through the package egeoffrey-service-rtl433) : intercept radio communication between the sensor and the commercial alarm system through a cheap, TV USB dongle receiver and the rtl_433 project (https://github.com/merbanan/rtl_433). This works with any frequency (provided you attach the right antenna) and any make, despite the configuration of rtl_433 could be a bit complex.

Step 2: create your own sensors

Regardless of the way you get the data in, you need to configure eGeoffrey to store this input somewhere. Personally, I'm using a combination of the three above but regardless, you need to create a new eGeoffrey sensor for each input. To make this simple and reusable, do the following, for each device you want to integrate, create in eGeoffrey ("House" / "Sensors") a new sensor with the following settings:

• Format: integer (the sensor will just just store 1 or 0. Specifically we are interested in the "1" meaning the sensor has triggered)
• Retention Policy: single_value (we don't need to keep the history of triggers, just the latest value is fine)
• Convert acquired value before being saved: in case the device is not generating 0 or 1, use one of the available functions to convert it (e.g. true_to_1, etc.) If there is no suitable function available, you can create your own (go to "eGeoffrey" / "Modules", edit the configuration of "controller/hub" and in "processors" you can add a new one. This is the operating system command which is run to convert the placeholder %value% into the format you want/need)
• Service: associate the sensor to the service providing this data and configure it accordingly

At the end of this configuration, you sensor will get a new value of "1" every time it triggers (motion detected, door open, etc.)

Step 3: create the corresponding "armed" sensors

This is not strictly required but would make your alarm workflow much more advanced and flexbile. For each of the sensor above create a new sensor with the same name but with the _armed suffix. E.g. if your sensor was named door_first_floor, create one called door_first_floor_armed. Configured it in the following way:

• Format: integer (this sensor will be set to 0 or 1 depending if we want to sensor to "linked" be armed or not. When 0, the alarm will not trigger when the system is armed, when 1, it will)
• Retention Policy: single_value (we don't need to keep the history of triggers, just the latest value is fine)
• Service: do not associate it to any service, this will be controlled manually from the web interface only

Step 4: create an alarm status

We need a way to set the alarm on/off globally. To to this, create yet another sensor called e.g. alarm_status, once again format integer and single_value retention. This will be set to 0 or 1 from the web interface before we leave our house and before entering it again.

Step 5: add a new page with your sensors' information and alarm status

In the first line of your new page, add a "control" widget and connect it to the alarm_status sensor created before. In this way from the web interface you can turn the alarm on or off.

In the other lines, for each sensor, add a "control" widget associated to the "_armed" sensor, e.g. door_first_floor_armed. In this way you can arm/disarm some of your sensors. Remember, only "armed" sensors will generate a notification if triggering while the alarm status is on. The widget will report also the elapsed time since the last time you have changed from armed to disarmed or viceversa. If you want instead to show the elapsed since the last time the device has reported a status change, set the sensor identifier in "Elapsed from a different sensor". Based on the example above it will be door_first_floor. In this way you can control if the sensor is armed or not and last time it triggered (e.g. set a new value).

Step 6: add rule for triggering the alarm

What we need now is a rule which would send a notification through any notification module installed, every time a sensor which is armed triggers while the alarm status is on. Let's go to "House" / "Rules and create a new rule.
Since we could have many sensors managed by eGeoffrey, we don't want to create a rule for each sensor (e.g. Alarm from door sensor, Alarm from bedroom motion sensor, etc.). For this we are going to leverage the concept of "macro" which will allow us to create a single rule for all.

• Under "General", give the rule an identifier (e.g. "alarm"), set severity to "Alert", write down in "Rule Text" your alert message. Since we will be using macros, use the placeholder %i%which will be replaced dynamically by the name of the sensor which triggered. This rule will be of type "Realtime", meaning conditions will be evaluated every time a new value will be set to one of the "Triggers" (see below).
  

• Under "Macro", add all the sensors this rule will evaluate (in our case just door_first_floor). Remember, the %i% placeholder will be then made available throughout the rule configuration:
  

• Under "Triggers", we want this rule to be evaluated every time a new value is set to one of our sensors. Since we don't want to list again all the sensors (we did it already in "Macro"), just use the %i% placeholder here:
  

• Under "Constants" we need to define any constant value which will be used in our conditions. Since we already normalized everything to 0 or 1, let's define just a status_on to 1:
  

• Under "Variables" we need to define any variable which will be used in our conditions. Specifically we need three things: the status of the sensor, if the sensor is armed or not and the alarm status. Since the sensor and the armed condition depends on which sensor has triggered, we use the %i% placeholder here as well:
  

• Under "Conditions" it is finally the time to define when the alarm will trigger. We just need a single block with the following to be all true for the alarm to trigger: the alarm status to be on, the sensor value to be 1 (e.g. status_on), the sensor to be armed.

• Under "Actions" we don't need to set any additional action, we are ok with the notification for now
  

Step 7: test the rule

Save the rule, go back to your alarm page, arm each of your sensors and turn on the alarm status.

Then you can either trigger the remote device or setting 1 to the sensor from "House" / "Sensors". Regardless you will get a popup notification, a new line in the "Notifications" tab and a message delivered to you through any configured notification modules (e.g. email, slack, etc.)

Step 8: make it even more advanced

Just some other ideas you could implement (or at least what I did in my house):

• Have an info notification every time somebody turns the alarm on or off (through a rule monitoring any change in the alarm status sensor)
• Intercepting when you turn the commercial alarm on or off to set automatically the alarm status in eGeoffrey accordingly (through a rule monitoring a sensor which stores the status of the commercial alarm system)
• Have "always-on" alarm for a bunch of sensors (e.g. fire/flood devices, through an additional rule like the one before but not taking into account the status of the alarm)
• An "away-mode" option which, when triggered, arms additional sensors, useful when e.g. you want to arm motion sensors when not at home (through a rule with "Actions" set setting the "_armed" sensors to 1 when triggered
• Turn on a siren when the alarm in eGeoffrey triggers (by e.g. connecting the siren to something you can control as an actuator and adding an "Action" to the alarm rule which will trigger the remote actuator

[eporocrail]

@user2684
Just some thoughts about the "mysensors" interface.
When somebody is making his own sensor modules and is using a ESP based module, the way through the "mysensors" interface is superfluous. Where one needs to create software to have the data transmitted in the "mysensors" data format it is much more easy to transfer data directly in MQTT using once own format.

So generally speaking I do not see the use of the "mysensors" interface for people using ESP modules and MQTT.