[Feature Request] Check Sensors and Entities prior to Arming

[Ltek]

Proposal

Feature to check Sensors / Entities in a given Armed mode to ensure they are ‘closed’ before setting the panel as armed.

User Settings to include:

1. Number of times to check for zones (sensors) 'closed' and ready :: check all Entities 3 times before attempting to arm alarm.
2. Number of seconds between each set of checks :: wait 30 seconds before performing next set of checks when a set fails.
3. Send Notifications after each set of checks letting the user know each specific Entity that failed :: Front Door lock is jammed, bedroom window is open, etc.

Checklist

• [ X] I checked for similar existing requests (both open and closed) before posting.
• [ X] My request is generic, other users may benefit from it too.

[Ltek]

bump

[nielsfaber]

You can use alarmo-card for this, or use the ready_to_arm_modes property of the alarm entity itself.
Both will indicate (before arming) whether the arming will succeed.
With this functionality in place, I don’t see a need for anything to be implemented.

[Ltek]

The ask it for it to programmatic, not visual. When the alarm is attempting to 'set' it may see sensors, switches, etc that are not clear / closed. Some sensors have delays on resetting to clear, locks sometimes delay in reporting or get jammed and use auto-relock, etc)

These two settings tell Alarmo to recheck the Areas automatically : N times, waiting N seconds between each set of checks.

This is a smart, and pretty easy, way to do this to reduce failures in arming the alarm

[bwarden]

use the ready_to_arm_modes property of the alarm entity itself

If I'm reading the history right, did you remove that property in afc93db?

[nielsfaber]

@bwarden Yes you are right!
It was changed into an event rather than entity attribute.
This is due to many complains I received from users who have automations in place that are triggered when the alarm_control_panel state changes (a change of an entity attribute is also considered a state change in HA).

[bwarden]

Would it be reasonable to add a separate sensor to indicate readiness to arm? This way automations could handle rectifying (locking doors) or alerting while alarmo itself prepares to arm.

[dpgh947]

I've just started looking at this out of curiosity because I (most of the time) set my alarm by asking alexa to do it as I walk out (this triggers a node red flow which does the arm call), and I was wondering what happens if there's a door open somewhere when I do this - answer is, of course, the arm fails. It seems a bit awkward if the only way to see if the system is ready to arm is to actually try and arm it and trap the subsequent disarm and then analyse why...

I don't understand the comment about "changed into an event" above - what event? When is the event fired? I agree that a separate sensor "ready/not ready to arm" would be useful for flows/automations to be able to check.

The attribute that was removed sounds perfect, it's a shame people couldn't figure out how to program around that instead of just complaining about it.

UPDATE - ok, I see the event in the notifications config, and also how to trap it in node red (alarmo_failed_to_arm)

[Ltek]

IMO, removing the attribute was unnecessary as people could have simply set a <> Condition in the automation.

But I think people are missing the largest benefit of this feature request: Timed Rechecks

Example... have Alarmo check 'readiness' of each Area up to three times in 60 seconds.

this provides robustness in case a sensor is lagging (motion sensor with a long reset time) or in case a door or window is open that need to be closed. Time to exit but also 'oops we forgot', lets go close that windows... without the system "failing" completely and requiring another manual arming.

[palves]

I came here looking for the same thing.

Would it be reasonable to add a separate sensor to indicate readiness to arm?

+1

It was changed into an event rather than entity attribute.

Any hint as how one can listen to the event, to reconstruct such a "readiness to arm" sensor?

I tried listening to "alarmo_event" in developer tools, and then I could observe the "ready to armness" changing in the alarmo card (the arm buttons change color), but I didn't see any event be triggered in the developer tools. I am probably doing something wrong.

[antworks-hub]

I'm pretty new to Alarmo, but so far the only limitation I've found is that when you arm the system and a delay is configured, you only find out that a door sensor is open after the delay. I understand that the delay is meant to give you time to leave the house, but once you're out, how can you know if, say, a window was left open?
IMO, Alarmo should ask me whether I want to bypass any open sensors before starting the countdown to arm the system.
That way, I’d be aware of any issues and could act accordingly.

[dpgh947]

In the advanced section of sensors, you can untick "use exit delay" and then the system won't begin the arm if that sensor is "on". It does seem odd to me that this defaults to on for any sensor you add. I think the default should be off, and then you can just turn it on for the sensors that you need to be ignored in order to leave the house (if you set it before leaving), like the front door sensor, any motion sensors near the front door etc.

[antworks-hub]

In the advanced section of sensors, you can untick "use exit delay" and then the system won't begin the arm if that sensor is "on". It does seem odd to me that this defaults to on for any sensor you add. I think the default should be off, and then you can just turn it on for the sensors that you need to be ignored in order to leave the house (if you set it before leaving), like the front door sensor, any motion sensors near the front door etc.

Shame on me, I haven't looked into the advanced section! I agree that the default should be off. Thank you for your help!

[dpgh947]

You're welcome 😊