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
Kinda have the same problem with handling open windows and doors (mostly windows in practice) while arming.
My alarm arms automatically using an automation that triggers when my car leaves the driveway (there’s a BLE scanner at the gate). So if something was still open, I would have to turn around and drive back in. And I have a very long driveway. And it usually happens when I’m already in a hurry…
Not too sure how to solve this in an elegant way tbh. An external automation like the one @tremebundo uses can work, maybe even triggered before the alarm is armed. Like when locking the front door. But it’s a bit annoying to have a second place where you need to add all your door and window sensors (Alarmo and that automation) and keep them sync’ed if / when you add more.
Would it be possible to add a service call to Alarmo that would check all door and window sensors that are registered with Alarmo and notify you if one is in a state that would prevent arming ? That service call could be used in an automation (for example when locking the front door) and would avoid all the redundancy in sensor listing.
Hi all,
Experience ( I think) issues. I added 3 sensors, for testing purpose. I armed alarm and. i created an automation with delay of 30 seconds to inform me which sensors are triggered. after walking towards 3 sensors its only giving me the feedback of the first activated sensor in the automation. also in the states of the arlo alarm panel at the open_sensors attributes its only showing 1 activated sensor. is this normal behaviour??
Sure, this is my full script. It plays an alarm siren on an Amazon Echo and announces which sensor triggered it.
alias: Alarm Siren
sequence:
- service: media_player.volume_set
data:
volume_level: 1
entity_id: media_player.echo_downstairs
- service: media_player.play_media
data:
media_content_type: sound
media_content_id: amzn_sfx_scifi_alarm_04
entity_id: media_player.echo_downstairs
entity_id: media_player.echo_downstairs
- service: notify.alexa_media_downstairs
data:
title: Intruder Alert!
message: >
Intruder Alert! {% for open_sensor in state_attr("alarm_control_panel.alarmo", "open_sensors").keys() |list %}
at {{ state_attr(open_sensor, 'friendly_name') }}
{% endfor %}
data:
method: all
type: announce
target:
- media_player.echo_downstairs
- service: media_player.volume_set
data:
volume_level: 0.3
entity_id: media_player.echo_downstairs
mode: single
I added an Action in the Alarmo settings that triggers this script like this:
name: Alarm Triggered Siren Alexa
modes: []
triggers:
- state: triggered
actions:
- service: script.turn_on
service_data:
entity_id: script.alarm_siren
3 Likes
Hi @neliss
Can you add a customisable view to the Alarmo dashboard so we can add it cameras and alter it to show an overview of our sensors. Even maybe another view that is solely a Alarm Panel Card
Thanks
No… The panel is intended for configuring the alarm. Not as a GUI for everyday use.
You can use the existing alarm panel card and entities card for creating your own GUI.
Hi @neliss just wanted to say a HUGE thank you for your working on this project. I came over from bwalarm and while I haven’t dug into all of what Alarmo can do, I’m VERY impressed with what you’ve put together. Lots of features, easy to navigate, intuitive. Please keep up the great work, I know there are lots of others who use it and haven’t had a chance to thank you.
Would gladly send you a beer/coffee if you have a link to do so.
Please don’t abandon this, there are those of us who rely on it!
1 Like
@jfdid Thanks a lot for your positive feedback!
I must say the development is going to a bit of a rough phase, because quite some users seem to be bothered by the limitations, rather than appreciating the features, and at the moment I don’t really have the time to work on further expansion and improving stability.
Considering that this project is only ~6 weeks old, you can assume it will grow better over time
The success of this project is (besides my availability) a bit depending on the community, I would like to keep hearing about various use-cases to grow ideas for improvement.
One of the new features I’m considering is to allow configuring multiple zones, which can be armed independently and with their own timings/actions.
This could be especially useful for larger homes which have a garage and such.
Would like to hear from you and others whether this would be useful, or not a priority right now.
2 Likes
I don’t know a lot about software development. But I do know that Home Assistant and Paulus lean more and more toward configuration via the UI as we approach 1.0, which is what you’ve done well.
Alarmo is already pretty feature-rich for an alarm for the average user. Zones would be handy for some but not imperative for most.
My 2 cents is to focus on reliability: keeping it bug free allows us to use it full time, which builds up a user base. From there, you can build out the requests, if they make sense.
You don’t want to complicate the code so much that it’s too much work to maintain - that’s what happened last month with Custom Header. Bwalarm and some other custom components often suffered breaking changes which made them less enjoyable to use as us users had to set aside troubleshooting time for each HA upgrade.
There will always be users asking for features for some edge case, it’s up to you to decide whether it’s worth adding. (that’s not to discredit the folks who have contributed ideas thus far to make Alarmo what it is already today).
Lastly, something like this is desperately needed as a part of the Home Assistant project and may even get adopted one day(like configurator/file editor), another reason to keep the code manageable.
Again, I’m not a developer and don’t much about the software world, I just want to see this project succeed!
The docs show that it supports an Alarm siren, but I can’t find where I would configure such options?
One of the new features I’m considering is to allow configuring multiple zones, which can be armed independently and with their own timings/actions.
I think this would be good. It would solve the problem I have where the garage door sensors need to have a 4 minute entry time. Currently I can’t really use alarmo because if I open the garage door from the car the will alarm go off well before I even get into the garage. So I think your solution would fix my problem, could have 4 mins for that zone and 1 minute elsewhere.
As others have said, really appreciate what you’ve done. You’ve achieved a lot in a very short time and it’s getting very close to being usable for most people.
Stefan
This is definitely something that would be great to have.
It would be good though if you could change the naming convention to match that of commercial alarm systems. Generally they are like this:
Area= An independent alarm group, as per what you have mentioned above (you called zone).
Zone= Input / sensor connected to the alarm
Entry Delay= Time set by the user for which the selected ‘entry’ zones will detect a change (motion/opening etc.) but only fire the alarm after this time.
Exit Delay= As per above but for leaving the house.
Obviously it’s your component and you can call things whatever you want, I don’t mean to tell you how it should be done, but those would line up with industry practice.
1 Like
I’ve now had the alarm running for over a week now, and trying to tweak it to my liking/use case.
I’ve been able to reuse many of my automations from Bwalarm, which is great.
However, I’ve been trying to work out the “failed to arm” system. I think it would be great if the system checked if any of the sensors were open prior to the exit delay. That way, it would skip the countdown and notify me immediately of the opened sensor.
This would be especially useful when leaving the house. I could be half way down the street before I get a notification that I forgot the back door open. But also, I don’t see the point of waiting 30-60 seconds before knowing that the alarm failed to arm.
What are your thoughts?
1 Like
You can create actions for switching on a siren entity/device when the alarm is triggered.
Example:
Ofcourse it’s wise to also create an action for switching it off when the alarm is disarmed.
This is the typical use-case for multiple zones areas.
It will take a couple of weeks before I can release such functionality, but it seems to solve quite some limitations.
I kindly ask for some patience in the mean time 
Thanks, this is useful feedback. I am a bit struggling with terminology (as you can see), I’m not really a fan of the definition of HA. I would rather keep things consistent with what’s common, so I will take this into account.
The way I use it: I configured my frontdoor + motion sensors in the hall to have entry/leave delay.
All other sensors are configured as immediate (since I won’t arrive by climbing through a window or through my garden door).
In my case I do the arming and disarming right before leaving (from the hall), so for me the leave delay is very short.
The functionality that’s currently in place is intended for using it in this way.
One feature that is on my to-do list, is to give the ability to mark a sensor as “entrance”.
The idea is that the leave delay will be stopped as soon as you close your frontdoor, so the feedback of failed sensors would come way earlier. It seems such functionality would help you as well.
Ofcourse I could also create an option to notify the user of open sensors upon starting the arming, if this would be helpful.
I have some questions about this, as I would typically arm when I’m still standing in the hall, so at least some motion sensors would be active, and optionally my frontdoor as well.
I would prefer the notifications to only be sent if something is wrong, and this seems hard to achieve this way.
How would you picture this?
In your sensor settings you have
“Allow open - Allow this sensor to remain active shortly after leaving.”
I figured this was the setting to ignore this sensor during arming, so if there was a motion sensor in your entry way (which we have) or the front door was open, it would ignore these as “open sensors” when the arming timer begins.
I guess maybe two check options might be useful. That way you have the option for one, both or none (Automatic force mode).
O - Check for open sensors before leave time.
O - Check for open sensors after leave time.
A possible solution for all the fail-to-arm scenarios being described above is adding an extra lovelace card above/below the card that arms the alarm.
Like this:
type: entity-filter
entities:
- binary_sensor.ground_front_door
- binary_sensor.ground_sliding_window
- binary_sensor.ground_side_windows
- binary_sensor.ground_kitchen_window
- binary_sensor.ground_bathroom_window
- binary_sensor.upstairs_bedroom_1_window
- binary_sensor.upstairs_bedroom_2_window
- binary_sensor.upstairs_bedroom_3_window
- binary_sensor.upstairs_bathroom_window
- binary_sensor.ground_motion
- binary_sensor.upstairs_motion
state_filter:
- 'on'
card:
title: Alarm Issues
show_empty: false
3 Likes
Is there a way to arm/disarm through node-red without using mqtt? I am trying to use the call_service node but it doesnt seem to be sending the command.
That looks very intuitive.
But it only works if you do the arming manually through Lovelace. A lot of people will probably arm the alarm automatically based on presence, never actually seeing a UI anywhere in the process.