Alarmo

Available sensors should show up automatically in the sensors tab in the Add sensors card. Simply check the sensors that you wish to include in the alarm, and click 'add to alarm'. Review the configuration for each sensor in the sensors card.

Sensor types

The sensor configuration in the Alarmo panel allows defining a type for each sensor entity.

Setting a type for a sensor has the benefit that the appropriate configuration is automatically set. HA defines device classes for binary sensors. When assigning sensors to Alarmo, the type of the sensor is automatically determined based on this property (if it is defined).

Note that assigning a sensor type is not mandatory, and all configuration settings can also be set manually. It is also possible to deviate from the predefined configuration after setting a type.

The following table defines the sensor types and the predefined configuration: | Type | Device classes | Arm modes | Enabled configuration options | | ------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------- | | Door | door
garage_door
lock
opening | Armed Away
Armed Home
Armed Night
Armed Vacation | Arm after closing
Use entry delay | | Window | window | Armed Away
Armed Home
Armed Night
Armed Vacation | - | | Motion | motion
moving
occupancy
presence | Armed Away
Armed Vacation | Use exit delay
Use entry delay | | Tamper | tamper
sound
vibration | Armed Away
Armed Home
Armed Night
Armed Vacation | - | | Environmental | carbon_monoxide
gas
heat
moisture
smoke
safety | N/A | Always on |

Configuration options

Note that depending on the sensor type, some options may be hidden. This is done for your convenience, if this is undesired you can clear the sensor type to have all options selectable.

| Option | Description | Recommended usage | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Use exit delay | Allow the sensor to be active when arming starts.
If disabled, the sensor must be inactive prior to arming the alarm, otherwise the arming will fail.
Only applies to arm modes having an exit delay.
Only applies to the moment of arming: after the exit delay has started, the sensor may become active (allows you to leave the house). | Motion sensors (and optionally doors) in the path between your alarm panel and the exit. | | Use entry delay | Use entry delay (as set for the arm modes) for the sensor.
If enabled, the sensor triggers the alarm after the entry delay, otherwise this happens immediately.br>Only applies to arm modes having an entry delay. | Motion + door sensors in the path between entering the house and reaching the alarm panel. | | Always on | Activation of the sensor always triggers the alarm, even when the alarm is disarmed.
The triggering is immediate (entry delay is not used). | Safety sensors, such as fire detectors. | | Allow open after arming | Sensor is allowed to remain active until after the alarm is set to armed.
The initial activation is ignored, a second activation (after becoming inactive) triggers the alarm. | Motion sensors which have a long delay until being reset (longer than the exit delay). | | Arm after closing | Deactivation of the sensor during the exit delay causes the alarm to proceed to armed state.
If other sensors are still active at this moment, the arming fails.
Alarmo uses a built-in 5 seconds delay to allow for contact bounce (the chattering of a door when pulling it shut). | Front door sensor (combined with Allow open after arming on motion sensors which may be still active). | | Bypass automatically | If the sensor is still active when the alarm is armed, the sensor will be excluded from the alarm (instead of causing the arming to fail) until the alarm is disarmed again.
This setting can be defined per arm mode. | Windows that may be left open (e.g. when going to sleep). | | Trigger when unavailable | If the sensor state becomes unavailable this is treated the same as the sensor being activated.
HA defines the unavailable state for sensors for which the state is undeterminate (can be either open or closed). This usually occurs when a battery-powered sensor loses connection to the gateway, but it could also be the result of tampering of the sensor. | Sensors for which reliability is important. |

Sensor groups

In a group, the triggering of a single sensor is ignored, but consecutive events (of 2 different sensors) will trigger the alarm.

Any sensor can be added to a group, but a sensor can only be member of 1 group. The amount of groups is unlimited, though it is recommended to minimize this (e.g. one group per room or floor).

A sensor group needs to have at least 2 sensors to function correctly (else it would never be triggered), and needs to be configured with a time-out time, after which consecutive sensor events are not longer considered related.

Clicking the 'setup groups' button while editing a sensor brings you to an overview of existing groups and allows you to create new ones and edit existing ones.

Codes and users

By default, the alarm has no code and can be locked and unlocked by anyone who has access to HA. It is recommended to set a code for disarming the alarm as minumum security level.

To do so, go to the codes tab, and enable the setting 'use disarm code'.

Next, set up a user and give it a name and code. It is recommended to use the same name as your HA account, but this is not required.

Codes

Your code is stored completely secure. It is encrypted in the same way as your login credentials, and stored in the HA storage registry. When you enter a code, this will be encrypted too, and the encrypted values will be compared for a match. So it is impossible to recover your pin code. This also means that if you lose your pincode, you cannot unlock the alarm (there is no backup code!)

Services

The following sections define the Alarmo-specific services that are supported.

alarmo.arm

The following table provides the settings that can be provided with the alarmo.arm service:

| Setting | Optional/required | Description | Example value | | ------------ | ----------------- | -------------------------------------------------------------------------------------------------- | ---------------------------- | | entityid | Required | Entity-ID of the alarm. | alarmcontrol_panel.alarmo | | code | Optional | Code used for arming the alarm. Only needed if a code is required for arming. | 1234 | | mode | Required | Mode in which to arm the alarm to. Valid values are away, home, night, vacation, custom. | away | | skip_delay | Optional | Set to true to arm without any exit delay. | true | | force | Optional | Set to true for enforced arming, causing any open sensors to be bypassed. | true |

alarmo.disarm

The following table provides the settings that can be provided with the alarmo.disarm service:

| Setting | Optional/required | Description | Example value | | ----------- | ----------------- | ----------------------------------------------------------------------------------- | ---------------------------- | | entityid | Required | Entity-ID of the alarm. | alarmcontrol_panel.alarmo | | code | Optional | Code used for disarming the alarm. Only needed if a code is required for disarming. | 1234 |

alarmo.skip_delay

alarmo.enable_user

| Setting | Optional/required | Description | Example value | | ------- | ----------------- | ------------------------------- | ------------- | | name | Required | Name of the user to be enabled. | Frank |

alarmo.disable_user

| Setting | Optional/required | Description | Example value | | ------- | ----------------- | -------------------------------- | ------------- | | name | Required | Name of the user to be disabled. | Frank |

Events

alarmofailedto_arm

The following table provides the data that is provided with the alarmofailedto_arm event: | Property | Description | Example value | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | entityid | Entity-ID of the alarm. Particularly useful in case multiple areas are configured. | alarmcontrol_panel.alarmo | | areaid | Internal ID assigned by Alarmo to the area. Particularly useful in case multiple areas are configured. Unaffected by renaming of the area (in contrast to entityid). | 12345678 | | reason | Reason/context of why the arming failed. Possible values: opensensors, notallowed, invalid_code. | sensors | | sensors | list of entity-IDs of the sensors causing the failure. Only set if reason equals opensensors. | [binarysensor.front_door] | | command | Arming mode used for the operation (which has failed). | arm_away | | contextid | If alarmo.arm or alarmo.disarm service was used prior to the failure and contextid was provided with this service, the same value will be returned. Otherwise this parameter will not be sent. | 23 |

alarmocommandsuccess

The following table provides the data that is provided with the alarmocommandsuccess event: | Property | Description | Example value | | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | entityid | Entity-ID of the alarm. Particularly useful in case multiple areas are configured. | alarmcontrol_panel.alarmo | | areaid | Internal ID assigned by Alarmo to the area. Particularly useful in case multiple areas are configured. Unaffected by renaming of the area (in contrast to entityid). | 12345678 | | action | Action that was performed. Possible values: arm, disarm. | arm | | arm_mode | Arm mode in which the alarm was armed. Only set if action equals arm. | away | | delay | Delay time used (in seconds) until the alarm will be set to the arm_mode. Only set if action equals arm. | 30 | | contextid | If alarmo.arm or alarmo.disarm service was used prior to the failure and contextid was provided with this service, the same value will be returned. | 23 |

alarmoreadytoarmmodes_updated

Note: While the alarm entity is disarmed, sensors which have type motion are not watched. This is done to prevent excessive recalculation while people are inside the house. It is advised to configure the alarm such that motion sensors should never cause arming to fail (e.g. by setting an exit delay which is sufficiently large).

The following table provides the data that is provided with the alarmoreadytoarmmodes_updated event: | Property | Description | Example value | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | entityid | Entity-ID of the alarm. Particularly useful in case multiple areas are configured. | alarmcontrol_panel.alarmo | | areaid | Internal ID assigned by Alarmo to the area. Particularly useful in case multiple areas are configured. Unaffected by renaming of the area (in contrast to entityid). | 12345678 | | armedaway | Indicates whether or not all conditions for arming in mode armedaway are met. Possible values: true, false. Only provided in case the arm mode armed_away is enabled for the entity. | true | | armedhome | Indicates whether or not all conditions for arming in mode armedhome are met. Possible values: true, false. Only provided in case the arm mode armed_home is enabled for the entity. | true | | armednight | Indicates whether or not all conditions for arming in mode armednight are met. Possible values: true, false. Only provided in case the arm mode armed_night is enabled for the entity. | true | | armedcustombypass | Indicates whether or not all conditions for arming in mode armedcustombypass are met. Possible values: true, false. Only provided in case the arm mode armedcustombypass is enabled for the entity | true | | armedvacation | Indicates whether or not all conditions for arming in mode armedvacation are met. Possible values: true, false. Only provided in case the arm mode armed_vacation is enabled for the entity. | true |

Creating readiness indicator entities

Below is a code example for creating a binary sensor indicating whether the alarm can be set to mode armed away:

template:   - triggers:       - trigger: event         eventtype: alarmoreadytoarmmodesupdated         event_data:            entityid: alarmcontrol_panel.alarmo     binary_sensor:       - name: "Alarmo Ready To Arm Away"         state: '{{ trigger.event.data.armed_away }}'

MQTT

The MQTT support needs to be enabled before it can be used. This setting is available in tab "General".

State topic

The state topic is an output topic, i.e. the data is sent by Alarmo and should be received by another application (such as a wall panel display).

Default state topic (can be configured):

alarmo/state

Alarmo will send the current state of the Alarmo entity as payload (string). See here for the complete list of payloads. The payload which is sent per state can be configured if desired.

The data published on the state topic shall be sent with a retain flag. This means that the last sent payload shall be stored in the broker, and as soon as an application subscribed to the topic, the most recent data shall be available for it.

Event topic

The event topic is an output topic, i.e. the data is sent by Alarmo and should be received by another application (such as a wall panel display).

Default event topic (can be configured):

alarmo/event

The published payloads on this topic are formatted as JSON struct, which contains the event name, and optionally some extra parameters.

The following table shows the events which are published on the event topic, together with the parameters which are sent for a certain event):

| Event | Description | Parameters | | ----------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ARMAWAY | The alarm has been armed in mode armedaway | - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming). | | ARMHOME | The alarm has been armed in mode armedhome | - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming). | | ARMNIGHT | The alarm has been armed in mode armednight | - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming). | | ARMVACATION | The alarm has been armed in mode armedvacation | - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming). | | ARMCUSTOMBYPASS | The alarm has been armed in mode armedcustombypass | - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming). | | TRIGGER | The alarm has been triggered | - sensors: list of sensors (usually a single sensor) which caused the triggering of the alarm. Each list item is a struct with the entity_id and name of the sensor entity).
- delay: entry delay (in seconds) configured to postpone the triggering (i.e. time during which the alarm is in state pending). | | FAILEDTOARM | The arming was prevented or cancelled due to one or more blocking sensors. | - sensors: list of sensors which prevented the arming operation. Each list item is a struct with the entity_id and name of the sensor entity). | | COMMANDNOTALLOWED | The conditions for which the command is allowed are not met (see commands). | - state: current state of the alarm entity.
- command: the command that was provided by the user. | | NOCODEPROVIDED | The command was rejected because no code was provided, while the operation requires a code. | | | INVALIDCODEPROVIDED | The command was rejected because a wrong code was provided, or the provided code is not allowed for the operation. | |

Example payload on the event topic (Consider the scenario where the alarm is armed in state armed_away and the front door is opened):

{   "event": "TRIGGER",   "sensors": [ # list of sensor(s) that causes the triggering     {       "entityid": "binarysensor.frontdoor",       "name": "Front Door"     }   ],   "delay": 60 # entry delay }

Command topic

The command topic can be used for external control of Alarmo through MQTT.

The command topic is an input topic, i.e. the topic is watched by Alarmo and data should be sent by another application (such as a wall panel). The data should never be sent with retain flag, as this might give undesired behaviour when HA is restarted.

Default command topic (can be configured):

alarmo/command

If Alarmo is configured to require a pincode or password for the (arm/disarm) command, the payload must be formatted as JSON according to the following format:

{   "command": "<my command>",   "code": "<my pin or password>" }

The supported commands can be found in commands.

If the provided payload does not have the correct format, lacks a code when it is required or contains a wrong code, the command shall be ignored. In other cases, you should see a change in the state topic.

Notes:

• The pin or password value should always be sent as a text/string value. A numeric value is not supported. This is due to the fact that a pincode could contain leading zeros (e.g. 0012), which would be lost if sent as a number.

• The command is treated as case-insensitive.

Multiple area usage

Alarmo shall publish the state updates for the Master Alarm and the areas in dedicated state topics:

• Master Alarm: alarmo/state
• Area: alarmo/<area_name>/state

{   "command": "<my command>",   "code": "<my pin or password>",   "area": "<area_name>" }

Notes:

• The MQTT configuration allows defining the topics for the Master Alarm only. The input topics (state/event topics) for the areas are automatically derived by inserting the area name. Example: setting state topic to my/custom/topic gives my/custom/<area_name>/topic as state topic for an area.

• If no area is provided, the command is addressed to the Master Alarm. If the Master Alarm is disabled, the command is ignored.

Automations

Push notifications

Procedure for setting up a notification

• In the Alarmo configuration panel, click "Actions" in the top menu.
• In the panel labeled "Notifications", click on "New Notification".
• Choose an event for which you would like to receive a push message, and choose the message content + title. Pick your device as target, and save the automation.
• Now Alarmo should start sending you messages :tada:

Wildcards

| Wildcard | Description | Example Text | Suitable events | | ---------------------- | -------------------------------------------------------------- | ------------------ | ------------------------------------- | | {{open_sensors}} | List of sensors (with their states) which are currently active | Backdoor is open | Failed to arm
Triggered
Entry | | {{bypassed_sensors}} | List of sensors which are bypassed | Bedroom window | Armed | | {{arm_mode}} | Current arming mode. | Armed Away | Leave
Armed | | {{changed_by}} | User who's code has been entered. | Niels | Armed
Disarmed | | {{delay}} | Delay in seconds until armed or the alarm is triggered | 30 | Arming
Pending |

Actionable notifications

Alarmo has built-in support for actionable push notification with the 'failed to arm' condition.

Example:

Available actions

The following actions are defined in Alarmo and can be used in actionable notifications:

| action | Description | Suitable events | | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | ALARMORETRYARM | Repeats the command that failed before.
Will only succeed in case the issue blocking the arming before has been restored. | Failed to arm | | ALARMOFORCEARM | Repeats the command that failed before.
The sensor/sensors that failed, shall be ignored (bypassed) while the alarm is armed. | Failed to arm | | ALARMO_DISARM | Disarm the alarm. | Armed, Leave, Entry, Triggered | | ALARMOARMAWAY
ALARMOARMHOME
ALARMOARMNIGHT
ALARMOARMVACATION
ALARMOARMCUSTOM_BYPASS | Arm the alarm in the corresponding mode. | None (intended for automations outside of alarmo). | Set up notification with actions

In the Alarmo notifications editor, create a notification and select an event. Choose your iOS/Android device as target, set a message and title as you want.

Switch to YAML mode. Look for the part that has data, and extend it as follows:

data:   ... # your message and title should be here already   data:     actions:       - action: ALARMORETRYARM         title: Retry Arm # feel free to change this text       - action: ALARMOFORCEARM         title: Force Arm # feel free to change this text

For more info about actionable notifications in HA, see here.

Note: In case you have multiple areas set up, the actionable notifications only work for the alarm master (since no area info can be sent along with the action data).

Actions

Switching a device

An important feature of a security system are the actuators (such as siren, lights, ...), which will hopefully cause a burglar threspassing your property to flee.

Alarmo features a built-in panel which can be used for switching devices on/off, depending on the state of the alarm.

Procedure for setting up an action

• In the Alarmo configuration panel, click "Actions" in the top menu.
• In the panel labeled "Actions", click on "New Action".
• Choose an event for which you would like to trigger a device, pick the HA entity from the list, choose whether it should be switched on, and save the automation.
• Now the device should automatically be triggered together with the alarm :tada:

The actions are currently limited to turning on or turning off a HA entity.

Advanced actions

It is recommended to trigger on a state change of the alarmcontrolpanel entity.

Example:

trigger:   - platform: state     entityid: alarmcontrol_panel.alarmo     to: 'triggered' action:   - service: switch.turn_on     target:       entityid: swich.mysiren

For the "failed to arm" condition, you can trigger on event instead:

trigger:   - platform: event     eventtype: alarmofailedtoarm condition:   - condition: template     valuetemplate: '{{ trigger.event.data.reason == ''opensensors'' }}' action:   - service: notify.mobileappmy_phone     data:       message: >         Could not arm because of the following problems:         {% for entity_id in trigger.event.data.sensors %}           - {{ stateattr(entityid, 'friendlyname') }} is {{ states(entityid) }}         {% endfor %}       title: test

Structure of the event data:

{   "reason": "opensensors", //other options: notallowed, invalid_code   "sensors": [ //only applicable if reason = open_sensors     "binarysensor.balconydoor"   ], }

Automatic arming