The “failed to arm” event is not a state. In fact, the alarm will stay in disarmed.
If you want to use external automations for capturing this event, you should trigger on changes to the attribute open_sensors of the alarm panel entity.
This attribute also has the details of the sensor that blocks the arming (entity_id + state).
I think I could write an automation based on a state change of an entiy_id. But an attribute?
This is an example of an automation I wrote:
- id: alarm_armed_away
alias: ARMED AWAY
trigger:
- platform: state
entity_id: alarm_control_panel.alarmo
to: armed_away
action:
- service: tts.cloud_say
entity_id: media_player.casa
data_template:
message: La alarma se ha conectado correctamente. Adiós.
language: es-ES
Where and how should I insert that “attribute” in that case?
Sorry for my noob questions.
Just jumped on to see if this feature was integrated.
I recently made the jump to Alarmo from Bwalarm, and with Bwalarm I could input the code as “override” in data and this would do the same thing without having to setup another user with an override code.
EDIT: I actually used this feature to bypass the “pending” time and immediately arm the alarm. This was useful when using the remotes in our cars to arm the alarm, and we don’t require the exit time.
I’ve now realised this does not instantly arm the alarm. Is there a function that will allow this? Or perhaps something that could be added please?
It is on my to-do list, but it will work a little bit different.
My previous DIY-alarm would abort the leave delay time as soon as I close the frontdoor, and proceed directly to armed state.
So the plan is to add a option where you can define which sensors are your entrances, and a open->close transition would skip the remaining delay (ofcourse only if all other sensors are closed as well).
The next step is to add some check when arming, that all sensors are closed and closing of the entrance was the last event, and if so, skip the delay as well.
I don’t feel much for adding specific codes for skipping delay. In my own usage, arming does not require a code, so it wouldn’t be a useful functionality.
Maybe a quick workaround for you:
you could configure the “armed custom bypass” mode as duplicate of your “armed away” mode, but with delay set to 0/none.
I think I have found how to use the attributes of an entity to trigger an automation.
But what I see at developer tools is that that attribute only changes after the arming time and that avoids the alarm to be armed and goes to the disarmed state.
So, I will only know if a sensor is open after the leaving time is finished. And, probably I would have left the house by that time. That makes no sense.
Or am I doing something wrong?
During the leave delay period it is allowed for sensors to be open still (unless they are configured as triggering immediate).
Such sensors will not show up in the 'open_sensors` attribute since this attribute only contains the entities that caused failing of the arming.
It is not desirable to have the alarm panel entity updating its state+attributes to HA every time a sensor changes.
Let me explain with an example.
My wife is alone and is going to leave the house. She tap the “arm away” button at the lovelace card and the leave time starts. Before the end of the leave time, she goes away. That is the expected procedure.
But the back door, that has one of the “away” sensors, was open and finally the alarm was not armed. But when that happens, she has been gone.
So, I think that the “open sensor” should be populated when going from disarmed to arming for HA to be able to notify the user before she leaves.
I use my wife as an example because I have to explain her the solution: WAF.
Hi,
I would like to add conditions to the alarm automation, like a condition with an input boolean.
So I tried to set manually differents automations with the alarmo custom component.
For one of them I have multiple triggers for the doors on the ground floor (Aqara sensor magnet) and one input_boolean in the conditions to trigger the alarm.
But… if I try to open one door of the ground floor when the night mode is activated the action of the automation don’t trigger the alarm.
- alias: '[ALARM] NIGHT Mode - Ground Floor'
initial_state: true
trigger:
- platform: state
entity_id: !secret Main_Door
to: 'on'
- platform: state
entity_id: !secret Garage_Door
to: 'on'
- platform: state
entity_id: !secret Living_Room_Left
to: 'on'
- platform: state
entity_id: !secret Living_Room_Right
to: 'on'
condition:
condition: and
conditions:
- condition: state
entity_id: alarm_control_panel.alarmo
state: armed_night
- condition: state
entity_id: input_boolean.alarm_night_mode_doors_ground_floor
state: 'on'
action:
- service: alarm_control_panel.alarm_trigger
entity_id: alarm_control_panel.alarmo
data: {}
Can you tell me if this kind of automation can be possible with this component ?
Thanks for your help.
Currently you can only perform arm/disarm operations by command.
Triggering the alarm is done from within Alarmo.
The idea of Alarmo is to eliminate the need for such automations.
It looks like you want to configure an optional extra zone.
There is an open request for supporting zones, which can be armed/disarmed separately.
I guess such functionality would help you as well?
Is there a way to know that the alarm will not be armed because of an open sensor before I leave the house?
By checking the states of the sensor entities.
While the alarm is disarmed, it does not keep track of the sensors states (only the sensors which are marked as always-on).
In my opinion, a back door should be immediately checked if not used to leave the house.
I guess you need to configure those sensors as immediate (https://github.com/nielsfaber/alarmo#immediate)
I see. The “open sensors” attribute holds the sensors that triggered the alarm. I do not know why I also thought that it will change too with the open sensors that will prevent the arming.
So, I will need to take care of that situation outside the component.
I will try to write an automation and share it if it works.
Thanks.
First lets say, great component. Ofcourse a question as well. In made my own automation ( bases on the original alarm panel) that with a delay i will get a message of all the sensors that are triggered within that timeframe of the delay. do you have this option in future? Also I would like to change the text of open_sensors will I would not like to see the state but only the friendly name.
Thanks for sharing your feedback in advance
It does also change when arming failed.
But what you seem to be looking for is information ahead of arming.
This attribute is set when the arming failed, which could be either:
- After the leave delay there are still sensors open
- Upon arming there are sensors open which are marked as immediate responders
Please read about the attributes in the documentation.
Currently the sensor that initially triggered the alarm is stored, and you get a notification of the triggering (with the sensor that caused this) after the entry delay has expired.
There is currently no logging of subsequent events, as they are not relevant for the behaviour of the alarm.
The functionality you are looking for is user/taste specific, that’s why it’s best to keep it as an external automation.
It will not be possible to satisfy the needs of all users with a generic implementation.
The current implementation is very basic, my intention is to expand it for better readability.
I saw that HA provides built-in translations for sensor trigger events, so my plan is to use these for formatting the message.
IMO it would be more appropriate/informative to mention:
Alarm is triggered because sensor X detected motion
Than to mention:
Alarm is triggered by sensor X
So I will aim to format the text as such.
I’m not sure if I could make this user-configurable, since it’s all handled by the backend. Perhaps I could allow some templating, but I have no experience with this.
Yes, that is what I am looking for. I could not find out which is the utility to know which sensor caused a failed arming when I have left the house. As you said, I need that information ahead, in order to solve that situation before I go.
I am just finishing an automation to handle that, but I think that this is a very common situation that should be handled by any alarm system.
@flbderks, this template will give you a list of the open_sensors in their frendly names. I use it in my scripts as well.
{% for open_sensor in state_attr("alarm_control_panel.alarmo", "open_sensors").keys() |list %}
at {{ state_attr(open_sensor, 'friendly_name') }}
{% endfor %}
thnx for that one 
thats then a seperate automation/script ( like i do now) apart from the component? or not? would be great if a seperate automation/script then was not needed
Could you share your example
Hi @Sam_Van_Herzele
And how do you use that information? I guess that you want to notify someone about what triggered the alarm.
Could you share a little more of your script?
This is the automation I am going to use to alert the user that the alarm will not be armed because of an open sensor.
When the alarm goes to the “arming” state, it checks if two sensors are open. If one of them is open, it warns the user with a TTS notification and an alert is displayed at the wall mounted tablet where he is trying to arm it. Then it sets the alarm back to “disarmed” state.
I think that with this last addition, I will get my family approval 
, and the alarm can go live for initial tests.
Keep up the good work, @neliss
- id: alarm_failed_arming
alias: FAILED ARMING
trigger:
- platform: state
entity_id: alarm_control_panel.alarmo
to: arming
condition:
condition: or
conditions:
- condition: state
entity_id: 'binary_sensor.door_window_sensor_xxxxxxxxxxxx’
state: 'on'
- condition: state
entity_id: 'binary_sensor.door_window_sensor_yyyyyyyyyyyy’
state: 'on'
action:
- service: media_player.volume_set
data_template:
entity_id: media_player.home_mini_cocina
volume_level: 0.8
- service: tts.cloud_say
entity_id: media_player.casa
data_template:
message: The alarm could not be armed because the back or the side door are open
language: es-ES
- service: mqtt.publish
data:
topic: alarmpanel/command
payload: '{"alert": "The alarm could not be armed because the back or the side door are open."}'
- service: xiaomi_aqara.stop_ringtone
data:
gw_mac: zzzzzzzzzz
- delay: 00:00:07
- service: alarm_control_panel.alarm_disarm
data:
entity_id: alarm_control_panel.alarmo
code: ’1234’
1 Like