I am having issues with setting up the “Failure to Arm” notification.
I have setup actionable notifications before. I am receiving actionable notifications now. However the action I select doesn’t do anything because there is no actual automation tied to the notification.
I feel like the directions on the GitHub are missing some steps (or I’m not following along). What setting forces the alarm to arm?
I’ve tried to setup Failed to Arm, I get the push notifications with both actions but the actions aren’t tied to anything. The documentation just stops and doesn’t describe what the automation should be to Retry Arm or Force Arm. Is it just set the automaton to arm? If so what’s the difference between Retry and Force?
If you set up the notifications as described in the documentation, you should get the “retry” and “force” buttons with the push message.
What happens when you press such a button, is handled by Alarmo internally (no automations required).
The buttons do pretty much what they say, “retry” has the same effect as arming it again yourself (in the same mode), “force” will cause the alarm to ignore sensors that are still open.
I suggest you check whether there is any sensor that is preventing you from setting arm night mode: is the open_sensor attribute filled in with one or more sensors after you click arm night?
If that doesn’t work, one thing that could help you debug the issue is to set a delay. Does the alarm then go from disarmed->armng->disarmed, or does it not even go into arming mode when you set the arm night mode?
Whoops
Well, this is exactly why an Alarmo-card for Lovelace is a good idea.
I wish I could provide better feedback for the user (without the notifications)…
Can imagine the frustration and head scratching.
Has anybody discovered a way to override the set exit delay with an automation?
I have the delay set for when I use the wall tablet to arm before exit (usually for guests), but our Alarm is mainly armed via automation when my wife and I leave the house.
The issue is, the delay is still active, and if we have left a door/window open, we won’t get notified until we’re down the road.
It would be great if there was an override command when arming that I could implement into the automation.
I’d prefer to not have to use the custom alarm option, because that means I have to duplicate all my settings, and if I make any changes to one, I need to make it to both.
Any ideas or suggestions on a solution please?
EDIT:
This was a feature in BWalarm, it could be added to the service call.
hmmm, I WAS using the notify feature to create a TTS MP3 file using Google_Say for certain alarm scenarios where I wanted to alert the house to an event or situation.
I wasn’t immediately broadcasting that MP3 to a media player, I was using it as a file and passing it on down the line.
Recently that’s stopped working which I’ve written about here. If I directly use google_say the MP3 is generated, if I do the same thing using notify, it fails. This worked a fortnight ago, I’m sure of it, I tested it and it was reliable.
Anyone know what’s changed or if there’s any way to mitigate the change?
If anyone knows how I could get access to the same information as the open_sensors attribute I can work around this.
This feature exists in Alarmo.
You can create a user/code combination and assign it as “override code”.
But in Alarmo override means that sensors that are open will be bypassed, it has no effect on the delay (override is not the same as immediate).
For skipping delays, I recommend you to configure a door sensor.
Closing a door will cause the (rest of the) arming delay to be skipped.
So if sensors are still open, you would be notified at once.
This seems to be the behaviour you’re looking for.
I’m wondering the same.
In my opinion, the notify platform should be used for all notifications (both text and speech).
I’m surprised to hear that suddenly it stopped working for you.
Did you check the changelogs of recent updates you made to your HA?
Anyway, there probably is a solution, the question is: what should be changed in Alarmo to accommodate your use-case?
Unfortunately it’s not the behaviour I’m after. As I mentioned earlier, our alarm is often armed via automation based on presence. So all the doors are already closed when we have left the house.
With the door closing trigger, it seems that door needs to have been open when arming and THEN be closed.
I’d love an “immediate” command that I could send via Arming data that I could implement via automation or service.
Does anyone know if this is possible? Like maybe how to set a variable or something based on the fleeting state of (pseudo sensor) cannot_arm_because_open_sensors
Then let’s do it.
Unfortunately I cannot extend the alarm_control_panel.alarm_arm_away service, since it’s capabilities are managed by HA.
But I could introduce an alarmo.arm service with whatever customization could be useful.
Give me a week or two and I will release an update with it.
I mean is there any way for me to create an automation using the ‘open sensors’ attribute? I can’t work out how to capture what sensors are open when the arm cannot arm in a regular YAML automation.
Hello. Is there any way to use service: tts.cloud_say as an action or notification in alarmo? I would like to know e.g. when in the night the alarm starts from which sensor it triggered and have my google home telling it to me.
I could use a dummy switch or sth like this to start an automation but this way I can’t grab the sensor name. Any other idea on this?
Another question: Are there more commands like: ALARMO_FORCE_ARM and ALARMO_RETRY_AR? I would like to disarm my system by my phone.
Yes, you can always create your own custom automations and use the list of open sensors. See an example here:
It wouldn’t be a problem to add it.
But these commands are (as far as I know) only available as buttons with a push message.
So for disarming the alarm, I wonder how this can be of practical use (you would need to trigger the alarm to get a message first).