Coder Social home page Coder Social logo

alarmo's Introduction

Alarmo

hacs_badge

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.

Introduction

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.

Features

  • 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.

Preview

Installation

Open your Home Assistant instance and open a repository inside the Home Assistant Community Store.

Click to show installation instructions
  1. Install files:
    • Using HACS:
      In the HACS panel, go to integrations and click the big orange '+' button. Search for 'Alarmo' and click 'Install this repository in HACS'.
    • Manually:
      Download the latest release as a zip file and extract it into the `custom_components` folder in your HA installation.
  2. Restart HA to load the integration into HA.
  3. Go to Configuration -> Integrations and click the big orange '+' button. Look for Alarmo and click to add it.
  4. The Alarmo integration is ready for use. You can find the configuration panel in the menu on the left.

Updating

Click to show updating instructions
  1. Update the files:
    • Using HACS:
      In the HACS panel, there should be an notification when a new version is available. Follow the instructions within HACS to update the installation files.
    • Manually:
      Download the latest release as a zip file and extract it into the custom_components folder in your HA installation, overwriting the previous installation.
  2. Restart HA to load the changes.
  3. (Optional) Verify the version number.
    • Verify version of the backend:
      In HA, go to Configuration -> Integrations. In the Alarmo card, you should see a link with '1 device', click it. In the table click the 'Alarmo' device, and you should see the Device info. The 'firmware version' represents the installed version number.
    • Verify version of the frontend:
      In the Alarmo configuration panel, the version number is displayed in the top right. If the version does not match with the backend version, your browser has an outdated version stored in the cache.
      To clear the cache, you should do a force refresh of your browser.

Uninstalling

Click to show uninstall instructions
  1. Remove Alarmo from HA:
    In HA go to Configuration -> Integrations. In the Alarmo card, click the button with the 3 dots, and click 'Delete'.
  2. Remove the files:
    • When installed with HACS:
      In the HACS panel go to integrations and look for Alarmo. Click the button with the 3 dots and click 'Uninstall'.
    • When installed manually:
      In the custom_components directory, remove the 'alarmo' folder.
  3. Restart HA to make all traces of the component dissapear.

Usage

Alarm functionality

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

Arm modes

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.

Alarmo entity

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.

States

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

State Description
disarmed The alarm is disabled/off.
arming The alarm is arming.
After the leave delay has expired, the alarm will be armed.
armed_away The alarm is armed in away mode.
armed_home The alarm is armed in home mode.
armed_night The alarm is armed in night mode.
armed_vacation The alarm is armed in vacation mode.
armed_custom_bypass The alarm is armed in custom mode.
pending The alarm is pending.
After the entry delay has expired, the alarm will be triggered.
triggered The alarm is triggered.
unavailable
unknown
Something is wrong.
Check the logs for more information.

Attributes

The Alarmo entity defines the following attributes:

Attribute Default value Example value when set Description
arm_mode null armed_away The current active arm mode.
Defined in all states except disarmed.
next_state (same as current state) armed_away When alarm is in state arming: next_state is equal to the arm_mode.
When alarm is in state pending: next_state is triggered.
When alarm is in state triggered: next_state is triggered (if no trigger time is configured), disarmed (if 'disarm after triggering' setting is enabled) or equal to the arm_mode (otherwise).
In other cases, the next_state will be equal to the current state.
changed_by null Niels User who last armed or disarmed the alarm.
Detected from the entered code.
Cleared when alarm is armed or disarmed without a code.
open_sensors null {binary_sensor.backdoor: on} Dictionary of sensors with their entity-ID + state, that caused the alarm to change state.
Set when arming attempt failed (due to one or more sensors).
Set when alarm is triggered (only first sensor that caused the triggering is stored).
bypassed_sensors null [binary_sensor.backdoor] List of sensors that are temporarily excluded from the alarm, due to arming in force.
delay null 30 Duration of the exit or entry delay. Only set in the arming and pending states, null otherwise.

Commands

The Alarmo entities support the following commands:

Command Description Conditions
ARM_AWAY Arm the alarm in mode armed_away. - The entity has the mode away enabled.
- The current alarm state is disarmed, armed_home, armed_night, armed_vacation or armed_custom_bypass.
ARM_HOME Arm the alarm in mode armed_home. - The entity has the mode home enabled.
- The current alarm state is disarmed, armed_away, armed_night, armed_vacation or armed_custom_bypass.
ARM_NIGHT Arm the alarm in mode armed_night. - The entity has the mode night enabled.
- The current alarm state is disarmed, armed_away, armed_home, armed_vacation or armed_custom_bypass.
ARM_VACATION Arm the alarm in mode armed_vacation. - The entity has the mode vacation enabled.
- The current alarm state is disarmed, armed_away, armed_home, armed_night or armed_custom_bypass.
ARM_CUSTOM_BYPASS Arm the alarm in mode armed_custom_bypass. - The entity has the mode custom enabled.
- The current alarm state is disarmed, armed_away, armed_home, armed_vacation or armed_night.
DISARM Disarm the alarm. - The current alarm state is not disarmed

Areas

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.

Alarm Master

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.

States

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

Condition Master Alarm state
One or more areas have state triggered triggered
One or more areas have state pending pending
One or more areas have state arming, others have state armed_away, armed_home, armed_night, armed_vacation or armed_custom_bypass arming
All areas have state armed_away armed_away
All areas have state armed_home armed_home
All areas have state armed_night armed_night
All areas have state armed_vacation armed_vacation
All areas have state armed_custom_bypass armed_custom_bypass
All areas have state disarmed disarmed
Otherwise (previous state is kept)

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.
Commands

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.

Sensor configuration

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.

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

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.

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

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.

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

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

MQTT

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".

State topic

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.

Event topic

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

Event Description Parameters
ARM_AWAY The alarm has been armed in mode armed_away - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming).
ARM_HOME The alarm has been armed in mode armed_home - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming).
ARM_NIGHT The alarm has been armed in mode armed_night - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming).
ARM_VACATION The alarm has been armed in mode armed_vacation - delay: exit delay (in seconds) configured for the operation (i.e. time during which the alarm is in state arming).
ARM_CUSTOM_BYPASS The alarm has been armed in mode armed_custom_bypass - 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).
FAILED_TO_ARM 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).
COMMAND_NOT_ALLOWED 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.
NO_CODE_PROVIDED The command was rejected because no code was provided, while the operation requires a code.
INVALID_CODE_PROVIDED 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
    {
      "entity_id": "binary_sensor.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>"
}

If Alarmo does not require any code for the command, the command can be sent directly as text/string value.

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.
  • Alarmo provides the option to accept MQTT commands without requiring a code. By disabling the "Require code" setting in the MQTT configuration, the internal code check is skipped. This setting should be used with care as it may compromise the security of the alarm.
  • The command is treated as case-insensitive.

Multiple area usage

The MQTT functionality can be used in combination with a multiple area configuration.

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

For targeting an arm/disarm command to a specific area, the JSON payload can be extended with the area property:

{
  "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.
  • <area_name> is a slug of the name that is given to an area. This means that the name shall be in lowercase and all non-alphanumerical characters are replaced by underscores (similar to the entity_IDs in HA).
  • 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

Alarmo can send a push message to your phone when the alarm is armed, disarmed, triggered, something went wrong, etc. For using this, you first need to install the HA app on your iOS or Android device.

Procedure for setting up a notification

  1. In the Alarmo configuration panel, click "Actions" in the top menu.
  2. In the panel labeled "Notifications", click on "New Notification".
  3. 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.
  4. Now Alarmo should start sending you messages 🎉

Example of the notification editor:

Wildcards

The alarmo notifications editor contains some wildcards which can be used to provide adaptive info to your push message. By adding the wildcard in a message (including the brackets) it will be automatically be replaced by the applicable text.

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

This function adds buttons to a push message, that can be clicked to interact with Alarmo.

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
ALARMO_RETRY_ARM Repeats the command that failed before.
Will only succeed in case the issue blocking the arming before has been restored.
Failed to arm
ALARMO_FORCE_ARM 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
ALARMO_ARM_AWAY
ALARMO_ARM_HOME
ALARMO_ARM_NIGHT
ALARMO_ARM_VACATION
ALARMO_ARM_CUSTOM_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: ALARMO_RETRY_ARM
        title: Retry Arm # feel free to change this text
      - action: ALARMO_FORCE_ARM
        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

  1. In the Alarmo configuration panel, click "Actions" in the top menu.
  2. In the panel labeled "Actions", click on "New Action".
  3. 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.
  4. Now the device should automatically be triggered together with the alarm 🎉

Currently the following HA entity types are supported: switch, input_boolean, light, script.

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

Advanced actions

In case the built-in Actions panel does not offer the flexibility you are looking for, you can set up more flexible automations in HA.

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

Example:

trigger:
  - platform: state
    entity_id: alarm_control_panel.alarmo
    to: 'triggered'
action:
  - service: switch.turn_on
    target:
      entity_id: swich.my_siren

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

trigger:
  - platform: event
    event_type: alarmo_failed_to_arm
condition:
  - condition: template
    value_template: '{{ trigger.event.data.reason == ''open_sensors'' }}'
action:
  - service: notify.mobile_app_my_phone
    data:
      message: >
        Could not arm because of the following problems:
        {% for entity_id in trigger.event.data.sensors %}
          - {{ state_attr(entity_id, 'friendly_name') }} is {{ states(entity_id) }}
        {% endfor %}
      title: test

Structure of the event data:

{
  "reason": "open_sensors", //other options: not_allowed, invalid_code
  "sensors": [ //only applicable if reason = open_sensors
    "binary_sensor.balcony_door"
  ],
}

Automatic arming

If you want to control the state of Alarmo through an external device (e.g. a keyfob, button panel, or phone with geofencing), you can do so by means of a HA automation.

This kind of automation cannot be made from the Alarmo "Actions" panel, you should use a HA automation instead (Configuration -> Automations).

Example of HA automation for arming with a remote button:

trigger:
  - platform: state
    entity_id: switch.my_remote
    to: 'on'
action:
  - service: alarmo.arm
    data:
      entity_id: alarm_control_panel.alarmo
      code: '1234'
      mode: away 
      skip_delay: true

Alarmo-card

After setting up Alarmo, it can be used for securing your house.

For controlling the alarm through the HA frontend, you can set up a Lovelace card. There are two cards available:

  • Lovelace Alarm Panel card which comes with HA. This offers basic arm/disarm functionality and displays the current state.
  • Alarmo-card which is intended as a companion for Alarmo. It offers some extra functionality on top of the standard alarm panel card, such as countdown timer for exit / entry delay and feedback messages with sensor(s) causing the alarm to be triggered or unable to arm.

Third party platforms

This section is intended to give a starting point for users who want to operate Alarmo outside of HA.

Android MQTT Alarm Panel

Alarmo is designed to be fully compatible with the Android MQTT Alarm Panel project.

This project provides a GUI for you to operate your alarm via a tablet which you could (for example) mount on the wall at your main entrance.

For using Alarmo with the Android MQTT Alarm Panel, make sure to enable the MQTT interface. For additional instructions on how to set up MQTT to be compatible with The MQTT Alarm Panel, see here.

Apple Homekit

Alarmo can be operated via Homekit. Follow the instructions on the Home Assistant page to establish a gateway between HA and Homekit.

Alarmo entities are of type alarm_control_panel, so make sure to configure the homekit gateway in HA have these included. The alarm should now automatically become visible in Homekit, with the current state visible together with the possibility to arm and disarm.

In case you have Alarmo configured to require a code for arming/disarming, you need to setup homekit in yaml mode (instead of via the integrations page).

Example of minimal setup in configuration.yaml:

homekit:
  - filter:
      include_domains:
        - alarm_control_panel
    entity_config:
      alarm_control_panel.alarmo:
        code: 1234 # should be identical to a user in Alarmo as well

The Homekit gateway has the following limitations:

  • The arm modes custom and vacation are not visible in Homekit.
  • Alarmo allows enabling/disabling arm modes 'on the fly', however it is needed to restart HA (or reconfigure Homekit via HA) before this becomes effective in Homekit.
  • In case arming fails, the alarm tile in Homekit will stay in 'arming...' state indefinitely.
  • Homekit will not show the pending state, so it is not possible to identify when the entry delay is effective.

Google Home

Alarmo can work together with Google Home. The first step is to set up the Google Assistant integration in HA. For Nabu Casa subscribers, this requires just a few clicks, other users need to register a project in Google cloud first (see instructions in HA docs).

Example of minimal setup in configuration.yaml:

google_assistant:
  project_id: <your project ID>
  service_account: !include <path to account json file>
  secure_devices_pin: 1234 # should be identical to a user in Alarmo as well
  report_state: true
  expose_by_default: false
  entity_config:
    alarm_control_panel.alarmo:
      expose: true
      room: Home

For arming and disarming the alarm, you can use voice commands like:

  • Arm the security system to armed away
  • Disarm the security system

Obviously the exact commands are depending on your local language setting.

It is also possible to arm/disarm the alarm as a step in a routine (e.g. the 'Good Morning' routine):

  • For arming in a routine: select 'adjust home devices' followed by action 'arm security system'
  • For disarming in a routine select 'try adding your own' and enter 'disarm the security system'.

Remarks

  • Since anyone can wake up your device and speak to Google Assistant, it's highly recommended to set up a pincode for disarming.
  • In case you have a pin set up, the Google Assistant will ask you to speak the pin. In some devices, like the Nest Hub, it is also possible to enter the pin via the keypad on the screen.
  • The Google Translate text-to-speech service can be very useful to provide additional feedback (e.g. when arming fails) for the members of your home. You can set up a notification action via Alarmo.

Say thank you

If you want to make donation as appreciation of my work, you can do so via PayPal or buy me a coffee. Thank you!

alarmo's People

Contributors

ajtudela avatar albinmedoc avatar alkorin avatar allkorolev avatar bobvmierlo avatar callebridholm avatar chpego avatar dtalens avatar faintghost avatar fensoft avatar g1za avatar giacomocarrozzo avatar herrfrei avatar jokerigno avatar jpbede avatar knsjensen avatar marlo461 avatar matthieumorvan avatar mccoy88f avatar mineiwik avatar newlund avatar nielsfaber avatar patrick44fr avatar repsionu avatar taixmiguel avatar tomer-w avatar tosko4 avatar vinhtantran avatar wrt54g avatar zbuh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

alarmo's Issues

time duration and interval sound siren

hello could you include a setup menu for the siren entity (switch) with the times to set? I ask this because in Italy there are rules that regulate the activation times of the siren.

in fact, to avoid breaking the laws relating to alarms, an intrusion alarm must not sound more than 3 minutes in total, which is the maximum duration allowed.

Localization/translation?

I know that this superb project is still in early beta stage :-)
But for everyday use by family it would be nice to have native language setup (OK thanks to lokalise we have a frontend native language for Alarm Panel at least)- as some of them are smart enough to add/delete something (with permissions but not enough English knowledge :-( )
That would make a great WAF effect :-)
Best, JR

Not all MQQT commands work

I am trying to set up Mqtt at Alarmo.
I can get the state with several clients and disarm the alarm, but I can not arm_away or arm_home with them.
I have tried with MQTTLens, which is an addon for Chrome and some kind of Mqtt sniffer and lets you to send commands to the subscribed topics. I have also tried with the Android app MQTT Alarm Control Panel and I get the same behaiviour.
It works for disarming but not for the two disarming modes.

Issue with arming when "allow open" sensor is active

Currently if I have sensor which is configured to "allow open" and it is active while trying to arm the alarm the arming will fail.
This is because of the following logic in validate_event function

           sensor_config = self._config[entity]
            if event == EVENT_LEAVE and not sensor_config[ATTR_IMMEDIATE]:
                continue
            elif event == EVENT_ARM and sensor_config[ATTR_ALLOW_OPEN]:      
                continue          #<--- We expected this continue statement to execute and skip the validation of this sensor but the state is EVENT_LEAVE and not EVENT_ARM so we skip this if statement.

I think the fix should be:

            sensor_config = self._config[entity]
            if event == EVENT_LEAVE and not sensor_config[ATTR_IMMEDIATE]:
                continue
            if event in [EVENT_LEAVE, EVENT_ARM] and sensor_config[ATTR_ALLOW_OPEN]:
                continue

I tested it on my setup and it seems to do what I would expect but maybe i'm missing something.

Inverted functionality

I have something strange going on (i did a hard refresh this time!) and with the new version the functionality for requiring a pin for arming/disarming is inverted for me.

E.g. if i turn on the require pin for arming, then it doesn't require pin for arming, but instead for disaming. Same thing happens if i turn the other one on, disarming becomes arming.

I hope all this makes sense.

I dont know if i should open a new issue, but also, if the leave time is set to None, the alarm will not Arm. (tested for arm home/arm night)

HACS deployment copy lot of unneeded stuff to HA custom_components folder

HACS installation works but it copies lot of source files into your HA deployment which are not really needed.
Specifically, I see lot of files in the frontend subfolder compared to what you get with manual installation.
Nothing really broken by that, but this is just something which can get cleaned-up eventually.

Error while saving entry time. (0.117.0b6)

Logger: homeassistant.components.websocket_api.http.connection.139909452651920
Source: custom_components/alarmo/alarm_control_panel.py:465
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 2:28:11 AM (2 occurrences)
Last logged: 2:28:17 AM

'leave'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1448, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1483, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 573, in handle_service
await service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 482, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 519, in _handle_entity_call
await result
File "/config/custom_components/alarmo/alarm_control_panel.py", line 465, in async_edit_config
self._config[ATTR_DELAYS][event][mode] = val
KeyError: 'leave'

Different pending states

Hi,
I have a feature request. I would like to have different events for pending to armed away and pending for armed night. Something like "pending_away" or "pending_night".
The reason is that I automate this changes with some different actions like tts.say, switch on different lights, that are not the same in both cases.
The same request for warning states make sense too, I think.

YAML Editor appears to lose edits?

Love your creation, thank you for your efforts. I'm a user, not developer, so "operator error" is likely, but I am having trouble getting my messaging edits to "stick". Simply trying to add "type: tts" in YAML editor. It works (messages make it to ECHO device) but the addition seems to disappears in next edit. Am I missing something?

Error when changing code

I'm testing with 1.1. Looks like I may have added my user with the wrong pin code, because I can't arm currently.

So tried to change the code (entered what I think was the old code, but most likely wrong code, and new code x2) and got the following error:
Something went wrong!

Response error: 500

Please report the bug.

Log details:
Logger: aiohttp.server
Source: custom_components/alarmo/init.py:155
First occurred: 9:21:32 AM (3 occurrences)
Last logged: 9:31:46 AM

Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/aiohttp/web_protocol.py", line 418, in start
resp = await task
File "/usr/local/lib/python3.8/site-packages/aiohttp/web_app.py", line 458, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.8/site-packages/aiohttp/web_middlewares.py", line 119, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 18, in request_context_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 72, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 127, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 129, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 60, in wrapper
result = await method(view, request, *args, **kwargs)
File "/config/custom_components/alarmo/websockets.py", line 190, in post
coordinator.async_update_user_config(user_id, data)
File "/config/custom_components/alarmo/init.py", line 138, in async_update_user_config
elif not self.async_authenticate_user(data[ATTR_OLD_CODE], user_id):
File "/config/custom_components/alarmo/init.py", line 155, in async_authenticate_user
if not user[ATTR_CODE] and not code:
TypeError: 'UserEntry' object is not subscriptable

Lost translation file

Yesterday I localized et.json, submitted but no I can not find it anywhere- forgot to save/publish? :-(

Error while enabling mqtt

Version used: 1.2.0
Going to settings, enable MQTT, save:

Response error: 500

I'm using MQTT in several other devices, without any issue.

Error reported in the log:

Logger: aiohttp.server
Source: custom_components/alarmo/alarm_control_panel.py:228 
First occurred: 8:15:58 AM (4 occurrences) 
Last logged: 8:17:55 AM

Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/aiohttp/web_protocol.py", line 422, in _handle_request
    resp = await self._request_handler(request)
  File "/usr/local/lib/python3.8/site-packages/aiohttp/web_app.py", line 499, in _handle
    resp = await handler(request)
  File "/usr/local/lib/python3.8/site-packages/aiohttp/web_middlewares.py", line 118, in impl
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 172, in forwarded_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 18, in request_context_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 127, in auth_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 129, in handle
    result = await result
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 60, in wrapper
    result = await method(view, request, *args, **kwargs)
  File "/config/custom_components/alarmo/websockets.py", line 98, in post
    await coordinator.async_update_config(data)
  File "/config/custom_components/alarmo/__init__.py", line 107, in async_update_config
    await self.config_callback()
  File "/config/custom_components/alarmo/alarm_control_panel.py", line 228, in async_reload_config
    await self._unsubscribe_topics()
TypeError: object NoneType can't be used in 'await' expression

Feature request: geofencing for arm/disarm?

I'm enjoying the integration thus far (thank you for your efforts!), and as I'm a recent convert from SmartThings one thing I did like was being able to trigger alarm states based on geofencing of my mobile devices. Is this something possible to add as a way to arm and disarm? Also any thoughts on when we'll be able to trigger a siren within this integration? I use Konnected for my devices and that one isn't working yet

Different sensor activation options

As discussed on the Home Assistant forum, there should be some different options around each sensor. My existing alarm system is really good for this. So you can set a sensor to be:

  • Immediate
  • Entry/Exit
  • 2x Entry Delay
  • 4x Entry Delay
  • Fire

Immediate is as you currently have, whilst entry/exit allows the current delays. 2 and 4 times are useful for things like garages where the garage door opens but you don't necessarily get in to turn it off quickly enough.

Fire will always cause the alarm to go off whether the alarm is activated or not.

Hopefully you can implement something like this - would be great!

{{open_sensors}} shows wrong sensor

Hey,

at first, thanks for this great integration.

I got an Alarm with Push Notifictions in which i use {{open_sensors}}.
But the variable {{open_sensors}} is always the first sensor that triggers the Alarm.

e.g.

  • I open Window 1 and the Notification is correct. "Window 1 is on"
  • I dissarm and arm again
  • I open Window 2 and the Notification is wrong. "Window 1 is on"

-- Restarting Home Assistant --

  • I open Window 2 and the Notification is correct. "Window 2 is on"
  • I dissarm and arm again
  • I open Window 1 and the Notification is wrong. "Window 2 is on"

Any ideas?

Thanks again!

Cannot open the UI behind a reverse proxied HA

This is with the new version of alarmo.

Opening the UI locally works as expected. I have websockets support enabled in the Nginx Proxy Manager, and HA also does not have issues establishing websockets. However, if accessed externally, this is what i get in the dev console when i try to open the UI:

alarmo:1086 Uncaught (in promise) TypeError: Cannot convert undefined or null to object at Function.entries (<anonymous>) at HTMLElement.render (alarmo:1086) at HTMLElement.update (alarmo:186) at HTMLElement.performUpdate (alarmo:148) at HTMLElement._enqueueUpdate (alarmo:148) render @ alarmo:1086 update @ alarmo:186 performUpdate @ alarmo:148 _enqueueUpdate @ alarmo:148 async function (async) _enqueueUpdate @ alarmo:148 requestUpdateInternal @ alarmo:148 set @ alarmo:148 (anonymous) @ chunk.6291eb9f40d952ac49d9.js:1 l @ chunk.6291eb9f40d952ac49d9.js:1 _setProperties @ chunk.6291eb9f40d952ac49d9.js:1 value @ chunk.6291eb9f40d952ac49d9.js:1 performUpdate @ app.8efb5ced.js:10288 _enqueueUpdate @ app.8efb5ced.js:10288 async function (async) _enqueueUpdate @ app.8efb5ced.js:10288 requestUpdateInternal @ app.8efb5ced.js:10288 set @ app.8efb5ced.js:10288 value @ app.8efb5ced.js:43529 value @ app.8efb5ced.js:39299 performUpdate @ app.8efb5ced.js:10288 _enqueueUpdate @ app.8efb5ced.js:10288 async function (async) _enqueueUpdate @ app.8efb5ced.js:10288 requestUpdateInternal @ app.8efb5ced.js:10288 set @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 update @ app.8efb5ced.js:10288 __commitTemplateResult @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 a @ app.8efb5ced.js:10288 H.render @ app.8efb5ced.js:10288 update @ app.8efb5ced.js:10288 performUpdate @ app.8efb5ced.js:10288 _enqueueUpdate @ app.8efb5ced.js:10288 async function (async) _enqueueUpdate @ app.8efb5ced.js:10288 requestUpdateInternal @ app.8efb5ced.js:10288 set @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 update @ app.8efb5ced.js:10288 __commitTemplateResult @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 update @ app.8efb5ced.js:10288 __commitTemplateResult @ app.8efb5ced.js:10288 commit @ app.8efb5ced.js:10288 a @ app.8efb5ced.js:10288 H.render @ app.8efb5ced.js:10288 update @ app.8efb5ced.js:10288 performUpdate @ app.8efb5ced.js:10288 _enqueueUpdate @ app.8efb5ced.js:10288 async function (async) _enqueueUpdate @ app.8efb5ced.js:10288 requestUpdateInternal @ app.8efb5ced.js:10288 set @ app.8efb5ced.js:10288 value @ app.8efb5ced.js:41533 (anonymous) @ app.8efb5ced.js:41533 s @ core.bcfce4ca.js:1 (anonymous) @ core.bcfce4ca.js:1 (anonymous) @ core.bcfce4ca.js:1 _handleMessage @ core.bcfce4ca.js:1 (anonymous) @ core.bcfce4ca.js:1

Alarmo does not find renamed sensors

I renamed a number of my sensors, but Alarmo still refers to their original names. I completely remove Alarmo and restarted HA, then re-installed Alarmo, and it still refers to the sensors by the old names, and does not find them by their new names.

Alarmo Features

Again, an incredible tool! Thank you very much!

A suggestion, and maybe this is already in process, but having each action have it's own duration could be good. I have my alarm set up to run the siren for 5 minutes, but leave the lights on for 20 minutes (if lights and siren go off at the same time, it might not be enough of a deterrent, at least that's my logic).

Thank you very much for these integrations! They are a huge upgrade to YAML-based config.

Brandon

[feature request] {{open_sensors}} as friendly_name array

Hi,
As the name suggests, I propose an extra state attribute with the friendly names of the current {{open_sensors}} attribute.
Use case: this way smart speakers can announce the reason for the alarm trigger (in case they don't like the notification component or to build bigger trigger scripts).
Thanks

Low battery notification

Alarmo is working great here. I moved HA alarm related notifications to Alarmo notifications. I tried them and I think they're working nice. Armed, disarmed, leaving, opened sensor and so on. It seems there's only one kind of notifications I can´t get rid of: "Low battery sensor". I have fire sensors and door sensors that send a specific 433MHz code when low batt reached. I know I could assign them as "always" but they should trigger alarm as hard as it home were burning, which can be heart dangerous. I would suggest a feature request to another "always" sensor category to assign a low level notifications service as target . In my case it is a telegram group with only a bip sound.

User Management now very slow

After the change to the new model trying to add users is now very slow. Not sure if there's anything that can be done about it but I thought I would just note it. I ended up pressing save twice and saving the new user twice

Exception while trying to arm on version 1.2.0

Alarm get stuck in arming state. Investigating the log shows the following error:
2020-11-22 20:53:57 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/alarmo/alarm_control_panel.py", line 459, in async_initialization_timer_finished
await self.async_arm(self.arm_mode)
File "/config/custom_components/alarmo/alarm_control_panel.py", line 408, in async_arm
res = self.sensors.validate_event(event=EVENT_ARM, bypass_open_sensors=bypass_open_sensors)
File "/config/custom_components/alarmo/sensors.py", line 128, in validate_event
open_sensors[entity] = state.state
AttributeError: 'NoneType' object has no attribute 'state'

Sensor "Allow open" option should not be disabled when "Immediate" option is on

Today you can enable the "Allow open" sensor option only if you first disable the "Immediate" option. This should not be the case IMHO.
I have a corridor with motion sensor which is leading me to my entry area. If I walk out fast it could be that I will fail to arm the alarm as the sensor is still active. The way to allow me to ignore it is to set the "Allow open" option (which is I love) but then I have the side effect that I also need to mark it not immediate which is not accurate. I want the alarm to trigger immediately if someone get to the hallway without first disabling the alarm.
So, I think these 2 options should get separated and allow me to set "Allow open" to sensors even if I do want them to trigger the alert immediately if they turn on later.

Android display issue

Opening the alarm panel settings page on the android HA app you can't actually see all the settings when it's in portrait mode - page is too wide.

Prevent re-executing of actions for initial alarm state after restarting HA

Logger: homeassistant.components.alarm_control_panel
Source: core.py:1401
Integration: Alarm control panel (documentation, issues)
First occurred: 10:35:51 AM (2 occurrences)
Last logged: 10:35:51 AM

Error adding entities for domain alarm_control_panel with platform alarmo
Error while setting up alarmo platform for alarm_control_panel
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 316, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 530, in add_to_platform_finish
await self.async_added_to_hass()
File "/config/custom_components/alarmo/alarm_control_panel.py", line 356, in async_added_to_hass
await self.async_update_state(STATE_ALARM_DISARMED)
File "/config/custom_components/alarmo/alarm_control_panel.py", line 393, in async_update_state
await self.automations.async_handle_state_update(state=state, last_state=last_state)
File "/config/custom_components/alarmo/automations.py", line 71, in async_handle_state_update
await self.async_execute_automation(automation_id)
File "/config/custom_components/alarmo/automations.py", line 117, in async_execute_automation
await async_call_from_config(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 97, in async_call_from_config
await hass.services.async_call(*parms, blocking, context)
File "/usr/src/homeassistant/homeassistant/core.py", line 1401, in async_call
raise ServiceNotFound(domain, service) from None
homeassistant.exceptions.ServiceNotFound: Unable to find service notify/alexa_media

open.sensors is not populated with active sensor

I have a number of Sensative Strip Guards that I use to monitor doors open / close state. Since these report a value 22/23 back for the open/close state, I have wrapped them in a binary sensor to allow them to be used in Alarmo.

The issue observed is that although Alarmo does pick up that a sensor changes state to open (= alarm is triggered), the correct sensor is not listed in open.sensors. In fact a completely unrelated sensor is sent along when this state change occurs (despite that sensor is actually in an off state - a verification has been made, and did confirm that this is the case when the event is triggered).
The effect is that notifications sent by Alarmo do not accurately depict what actually has occurred.

Allow different sensors to be used?

I'm trying to add a motion sensor that is attached to a light switch (the Jasco Motion Sensor Switch) to use with my alarmo config... it doesn't show up as a sensor when configuring. Is this a bug or needs to be added as a feature?

Two (or more) kind of push messages

Not sure if people do, but I use two categories for push messages. Both with Telegram groups. One "triggered alarm", very loud sound and another low sound notification to rest of notifications like armed, no armed, etc. Push messages "when something changes in the alarm" could be heart dangerous IMHO. I would like two targets for push messages at least and the possibility to choose among them. By now I have a workaround with automations.

Manual automation not working

I am trying to make an automation to disarm the alarm when a NFC tag is read.
In automations I have a call to this service:

  - service: alarm_control_panel.alarm_disarm
    data:
      entity_id: alarm_control_panel.alarmo

But the service is not executed.
Also, if I check with the service developer tools, no disarm is made.

Captura de pantalla 2020-11-27 a las 18 38 25
May be I am doing something wrong?

Cannot arm

Hi,
This is with ver. 1.1.0
I have only two sensors configured: one entry door sensor and a movement one.
When I try to arm, I get this in the log:

2020-11-16 18:02:42 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.139730749224128] 'NoneType' object has no attribute 'items' Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service await hass.services.async_call( File "/usr/src/homeassistant/homeassistant/core.py", line 1448, in async_call task.result() File "/usr/src/homeassistant/homeassistant/core.py", line 1483, in _execute_service await handler.job.target(service_call) File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service await self.hass.helpers.service.entity_service_call( File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 482, in entity_service_call future.result() # pop exception if have File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call await coro File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 519, in _handle_entity_call await result File "/config/custom_components/alarmo/alarm_control_panel.py", line 265, in async_alarm_arm_away await self.async_arm(STATE_ALARM_ARMED_AWAY) File "/config/custom_components/alarmo/alarm_control_panel.py", line 428, in async_arm await self.async_update_state(STATE_ALARM_ARMING) File "/config/custom_components/alarmo/alarm_control_panel.py", line 393, in async_update_state await self.automations.async_handle_state_update(state=state, last_state=last_state) File "/config/custom_components/alarmo/automations.py", line 71, in async_handle_state_update await self.async_execute_automation(automation_id) File "/config/custom_components/alarmo/automations.py", line 108, in async_execute_automation changed_by_string = self.async_format_sensor_info(changed_by) File "/config/custom_components/alarmo/automations.py", line 127, in async_format_sensor_info for (entity_id, status) in open_sensors.items(): AttributeError: 'NoneType' object has no attribute 'items' 2020-11-16 18:02:48 WARNING (MainThread) [custom_components.alarmo.alarm_control_panel] Cannot go to state armed_away from state arming. 2020-11-16 18:02:52 WARNING (MainThread) [custom_components.alarmo.alarm_control_panel] Cannot go to state armed_home from state arming.

If you need more data, please ask me.

Thanks for your interest.

1.3.0 ERROR 'bool' object is not subscriptable

Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/alarmo/alarm_control_panel.py:289
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 12:19:19 PM (3 occurrences)
Last logged: 12:19:48 PM

[140178131266768] 'bool' object is not subscriptable
[140178161299408] 'bool' object is not subscriptable
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1451, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1486, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 499, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 536, in _handle_entity_call
await result
File "/config/custom_components/alarmo/alarm_control_panel.py", line 305, in async_alarm_arm_home
await self._async_handle_arm_request(STATE_ALARM_ARMED_HOME, code, skip_code)
File "/config/custom_components/alarmo/alarm_control_panel.py", line 289, in _async_handle_arm_request
elif res[ATTR_IS_OVERRIDE_CODE]:
TypeError: 'bool' object is not subscriptable

I can't disable push messages

I enabled push messages and now I can't disable them. I tried to refresh cache browser, etc but push messages are enabled each time I check them. Doesn't mind if I vary "target for push messages" option.

Kind of sensors permanently armed

Beside armed away, night, etc. IMHO there should be a permanent armed state for all time alarm sensors like smoke, gas, water leak, etc that should trigger always, no matter if away, night, home, etc are armed or not.

[feature request] multi-partition

Hi.
I my previous domotic system I was able to define multiple alarm partitions, individually configurable and usable: I was able to define wharehouse / house1 / house2 partitions, each with its sensors/users/settings.

This feature could be so useful in a large installation.

ios actionable notification - action not working

The notification is received but when I push the "Retry Arm" button on ios an error occurs in HA core. I've set up the actionable notification as follows and the error is below.

ios:
  push:
    categories:
      - name: Alarm Arm Failure
        identifier: alarmo_arm_failure
        actions:
          - identifier: ALARMO_RETRY_ARM
            title: Retry Arm # feel free to change this text
            destructive: true
          - identifier: ALARMO_FORCE_ARM
            title: Force Arm # feel free to change this text
            destructive: true

2020-12-08 11:43:53 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/config/custom_components/alarmo/alarm_control_panel.py", line 598, in async_handle_event elif event.data["action"]: KeyError: 'action'

Request feature override

Hi,

Can we please implement a feature allowing certain users or codes perform a master-override when arming?
Master-override means that any sensors that are either active or failed will not block arming the alarm nor trigger the alarm, instead they would be bypassed and set as disabled for the session. Active or failed sensors that block arming is troublesome for me as the alarm is to arm automatically when I leave and as I leave by car I can't stop in the middle of the highway because a sensor is failed or delibarately left active and the alarm won't arm. This means the alarm is left disarmed far longer than I want.

Scenario is f.ex.:

  1. Window in the bathroom is left open to air out, window is usually not left open.
  2. User leaves house, alarm tries to arm automatically.
  3. Alarm notices window is left open over the allowed time, but since it's asked to arm anyways it does.
  4. Alarm bypasses the sensor, logging this and then arms the alarm.
  5. User can then be notified that alarm is armed, but that sensor is bypassed due to active/error.

Failed to arm not showing up as a notification anymore

I'm using the latest 1.1.2, just wondering if there was any change on notifications (on purpose or not) as I haven't been able to see the failed to arm notifications anymore, other notifications look ok ie: If I try to arm the alarm with a sensor open, it doesn't work and it also doesn't show me anything even though I have a notification set.

Can't add users when alarm is on

Turn the alarm on from the overview page. Then try and add a user in the alarm panel page and click save and doesn't save. Turn the alarm off and it will save. The behaviour is probably correct it's just a bit confusing, so would be good if there was a message to say it wasn't able to be added.

Install Failure

Hi mate, I have tried all the install methods given but "AlarmO" does not show on the left panel once HA is restarted. I had a manual alarm setup in configuration.yaml which I commented prior to installing "AlarmO"

I am running the latest version of HA
Operating System
Ubuntu 20.04.1 LTS
Docker version
19.03.12

most likely I am doing something wrong, but any help will be great

What Siren?

Hello
What Siren do you use?
I have gateway xiaomi, which could not be directly triggered, but just put alarm on or off, it can't command and play siren directly
Thanks
Michael

Can't see all binary sensors

For some reason this alarm panel doesn't see all my binary sensors. E.g: binary_sensor.sm_g988b_is_charging. May be a good reason for this, but I can't see it because the text in the section for adding sensors is cut off. It gets as far as this "There are no available HA entities that can be configured for the alarm. Make sure to include ent":
image

Provide support to send passcode and custom outgoing MQTT messages

For Alarmo to interface with and control an external alarm system there is a requirement to send outgoing MQTT messages to the external alarm. Since the external alarm is a security device it requires a passcode. Doing so allows HA to control the external alarm system such that HA and the external Alarm system remain synchronised.

Please provide support to allow sending of passcodes in the outgoing MQTT messages.

Please also allow for subcommands to be sent in the MQTT message.

ie:

JSON Payload template
   {
    "password":"1234",
    "Command":"arm",
    "Subcommand":"0"
   }

Having subcommands will also allow for controlling multiple 'Areas' in future.

Alarm activates and deactivates automatically

I installed alarm and have set it up as I wanted. But sometimes the system armes itself and triggers without any one of us arming the system before.

Very annoying when all of a sudden the sirens go off at home.

[feature request] trigger time (and siren duration) less that a minute

Hi.
As subject says, could be useful to let the user to choose a siren duration under the minute.
I use an interior siren and a 1min duration is too much (imagine during the night a false alarm that turn on the siren for a minute..) :D
The best this could be a base value available as entity that define the siren duration, so we can change the duration with an automation (armed night set duration to 15s or less, armed away to a minute).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.