This is an alarm system integration for Home Assistant. It provides a user interface for setting up your own alarm system completely from the browser.

• Alarmo
  • Introduction
    • Features
    • Preview
  • Installation
  • Updating
  • Uninstalling
  • Usage
    • Alarm functionality
    • Arm modes
    • Alarmo entity
      • States
      • Attributes
      • Commands
    • Areas
    • Alarm Master
      • States
      • Commands
    • Sensor configuration
      • Sensor types
      • Configuration options
      • Sensor groups
    • Codes and users
      • Codes
    • MQTT
      • State topic
      • Event topic
      • Command topic
      • Multiple area usage
    • Automations
      • Push notifications
        • Wildcards
        • Actionable notifications
      • Actions
        • Switching a device
        • Advanced actions
      • Automatic arming
    • Alarmo-card
  • Say thank you

This is an integration for the alarm_control_panel domain in HA. It allows to combine existing sensors for creating a security system for your house. The integration is comparable with the Manual Alarm in HA, but also has some additional features that makes it easier to use.

Alarmo consists of 3 parts:

• Alarmo component: a custom component for HA that controls the states of the alarm panel entities in HA.
• Alarmo panel: a GUI for configuring the settings of your alarm (sensors, delays, actions etc.)
• Alarmo card: a custom card for arming / disarming the alarm.

• Fully compatible with Home Assistant and the Alarm Panel Card.
• Has an integrated panel for complete management via UI (no YAML required).
• No restarts required when making changes.
• Can set up to 4 arm modes (armed_away, armed_home, armed_night, armed_custom_bypass), each with configurable delays and security perimeter.
• Supports configuring your existing HA entities as security sensors. These sensors will be watched automatically.
• Allows setting up multiple users with individual pincode and permission levels.
• Will restore its previous state after restart of HA.
• Built-in actions: receive push notifications when anything changes in the alarm, activate a siren when the alarm is triggered, etc.
• Supports splitting up your house security system into multiple areas which can be armed independently.

The following diagram describes the operational states of the alarm and provides a simplified overview of the functionality.

The alarm can be activated (armed) in a certain mode. This mode defines a certain set of sensors and represents the security zone (or perimeter).

The following modes are supported:

• Armed away
• Armed night
• Armed home
• Armed vacation
• Armed custom bypass (let's just call it armed custom from now on)

In the tab general you can find the settings for each mode. There are flip switches to enable/disable modes.

After installing Alarmo the entity alarm_control_panel.alarmo shall be added to HA. You can use this entity together with the Alarm panel card, or in conjuction with automations to automatically arm/disarm the alarm.

The Alarmo entity follows the state definitions as defined by HA:

The Alarmo entity defines the following attributes:

The Alarmo entities support the following commands:

An area is a physical compartment of your house, such as a garage, 1st floor of the house, garden, etc. Alarmo will create an alarm_control_panel entity for each area which can be armed and disarmed independently. An area has its own set of sensors and can have dedicated configuration for arm modes, exit/entry times and automations.

In the general tab of the Alarmo configuration UI, there is a card showing the areas in your setup. You can add additional areas, as well as rename or remove existing areas. Alarmo requires at least 1 area to be set up to be functional.

The name of an area defines the entity ID as well. The entity will be instantly renamed after saving.

Warning: renaming an area changes the entity ID, which might break your Lovelace cards and automations outside of Alarmo, so treat it with care.

Alarmo has the option for enabling an alarm master. The option appears in the general tab in general settings if you have multiple areas defined.

The alarm master is meant for operating your areas synchronously. An extra alarm_control_panel entity is created for the master, which watches the state of the areas for and mirrors its own state with that.

The Alarm Master will watch the states of the area entities and updates its own state accordingly.

The following table shows the rules which are implemented to determine the the master alarm state (in order of priority):

Notes:

• The Alarm Master cannot determine its state if some are disarmed while others are armed. If the Alarm Master is used for arming/disarming the alarm, this condition should not occur.
• If the areas are independently operated, the user is reponsible to maintain synchronism between the areas. If independent operation is desired, usage of the Master Alarm is not recommended.

Arming / disarming the master will cause the action to be propagated to all areas.

If the arming of an area fails (due to blocking sensors), the arming procedure will be aborted and all areas are disarmed.

The available arm modes for the Master Alarm are determined from the areas. Only arm modes which are in common for all areas are available for the Master Alarm.

Currently Alarmo supports sensors of type binary_sensor. Alarmo will check the device class of each sensor, and only supports sensors that are related to security.

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.

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:

The following table summarizes the configuration options available per sensor.

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.

This functionality is aimed to reduce the risk of false triggers in your house, which are (unfortunately) a reality - especially with PIR motion sensors.

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.

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.

A code can be a sequence of digits (4 or more) or contain a mix of letters, characters etc. Make sure to use a code that matches with the code format setting in the codes tab. This setting is detected by the alarm panel card, and will automatically show either a number pad or a text field.

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!)

Alarmo supports MQTT for external control of the alarm. This function is intended for third-party alarm panels (such as a touch screen in the hallway).

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

The state topic is used to publish state changes of the alarm_control_panel entities.

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.

The event topic is used for publishing additional status updates of the alarm_control_panel entities.

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):

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
    {
      "entity_id": "</