alarm_control_panel STATE_ALARM_* states and their intended uses?

[BioSehnsucht]

Continuing from home-assistant/home-assistant-polymer/pull/1549

Currently, the UI only allows disarming when state is one of the armed states or STATE_ALARM_PENDING or STATE_ALARM_TRIGGERED. There also exist STATE_ALARM_ARMING and STATE_ALARM_DISARMING.

What are these states intended for, and why can't you disarm during them? Which states should represent entry and exit timers ?

[gwww]

STATE_ALARM_PENDING when arming a system seems misleading. No alarm is pending when arming. The only thing pending is the system being armed.

STATE_ALARM_PENDING when disarming could be argued to be valid. I would argue though that STATE_ALARM_DISARMING better represents the intention.

STATE_ALARM_ARMING and STATE_ALARM_DISARMING already exist and appear to have the correct intention. What was the reason for those being added if not to represent arming and disarming a system?

[BioSehnsucht]

1) To represent that the alarm is in entry/exit timer state, some state other than ARMED or DISARMED should be used. That was the original intent of this issue was to determine that (since not all states can be disarmed from in the UI, and if you've armed it and are in exit timer state, or have entered the house and are in entry timer state, you should be able to disarm). It's not entirely clear what the ARMING/DISARMING states are intended for (just temporary states while API calls are made and not intended for exit/entry timers?) and unclear if PENDING should be used as alarm siren is about to go off or if it can be used for entry/exit timers, etc.

2) We need more states defined for Elk M1 integration and probably others could use them as well (i.e., arm vacation mode, or arm instant home/away versus regular home/away with exit timers)

@balloob Is there anyone else we should include in this discussion?

[abarbaccia]

I agree with the states being named poorly. The simplest in my mind would be DISARMED, EXIT DELAY, ARMED, ENTRY DELAY, TRIGGERED. Every alarm system has this same basic functionality but it seems to be implemented differently in each platform. For example, envisalink currently uses armed / disarmed / triggered, and then has separate attributes to signal the entry / exit delay.

For the second point, arm_night is already in the entity. This would be arm home + no exit delay. Vacation mode (or arm max as some panels call it), which is arm away + no exit delay, has an open architecture issue and PR referenced here: https://github.com/home-assistant/architecture/issues/60

Let me know if you agree based on what you see on Elk M1

[gwww]

Having had a month or so to ponder this, another idea came to mind.

Yes, tweak the alarm states. In addition I was wondering is substates make sense? For example, the state is "armed" and the substate is "away", or "vacation", or...

I understand that there are reasons for standardizing state. I'm hoping we can achieve that goal and achieve the other goals. Substate might accomplish that. Perhaps there's a better idea.

[abarbaccia]

Substates could indeed also work. However we have a finite number of alarm states and they are mutually exclusive ... so ideally we can avoid the extra complexity.

If it's helpful, I can lay out a proposal for the alarm states and then we ask maintainers of the different alarm_control_panel components to weigh in. Similar to the climate architectural review recently conducted.

[BioSehnsucht]

Regardless of states vs states w/ substates ...

I will admit perhaps we can simply map all the Instant variants to the non-Instant types, if we have to, functionally Instant just means no exit delay. Though it's possible someone would want different things to trigger depending on instant or not.

@abarbaccia It seems not all alarms use terms similarly, based on your descriptions.

For the Elk M1:

Vacation mode is just another flavor of Away intended to trigger automation rules or allow those rules to operate differently if in Vacation mode (i.e., you can have them not do things because you're not home, or you can have them do things because you're not home)

Night is different from Stay Instant (which would be Stay without an exit delay), it allows arming of interior zones even in Stay mode, some zones can be indicated to be specifically night zones, so you can have some zones trigger in Stay Night and others not trigger in Stay Night. You might for example not have the upstairs or most interior zones active during Night, but the interior zones by all the doors and main floor windows would be.

(from Installation & Programming Manual)

Vacation mode is primarily for use with the Whenever/And/Then Rules programming of Elk-RP for long term energy savings.

Since interior zones are automatically excluded once the Stay mode is activated, the M1 allows this key to Stay arm even while one or more interior zones are violated, provided they are programmed for “force arming”. The Stay Night mode re-activates any interior night zones. To prevent a false alarm the control will not allow change to the Stay Night mode when a interior night zone is violated unless it is programmed for “Force arm”.

[abarbaccia]

Good points both. I think to move this forward we should lay out the different states and align on those first. This would help tease out things like MAX vs. Vacation mode. Next we can align on how to implement (seems primarily to be around what goes in the state vs. attributes). What do you all think? I'm happy to take a first pass at the states based on what i've posted before. Andrew

On Thu, Sep 6, 2018 at 4:15 PM BioSehnsucht notifications@github.com wrote:

Regardless of states vs states w/ substates ...

I will admit perhaps we can simply map all the Instant variants to the non-Instant types, if we have to, functionally Instant just means no exit delay. Though it's possible someone would want different things to trigger depending on instant or not.

@abarbaccia https://github.com/abarbaccia It seems not all alarms use terms similarly, based on your descriptions.

Vacation mode is just another flavor of Away intended to trigger automation rules or allow those rules to operate differently if in Vacation mode (i.e., you can have them not do things because you're not home, or you can have them do things because you're not home)

Night is different from Stay Instant (which would be Stay without an exit delay), it allows arming of interior zones even in Stay mode, some zones can be indicated to be specifically night zones, so you can have some zones trigger in Stay Night and others not trigger in Stay Night. You might for example not have the upstairs or most interior zones active during Night, but the interior zones by all the doors and main floor windows would be.

(from Installation & Programming Manual)

Vacation mode is primarily for use with the Whenever/And/Then Rules programming of Elk-RP for long term energy savings.

Since interior zones are automatically excluded once the Stay mode is activated, the M1 allows this key to Stay arm even while one or more interior zones are violated, provided they are programmed for “force arming”. The Stay Night mode re-activates any interior night zones. To prevent a false alarm the control will not allow change to the Stay Night mode when a interior night zone is violated unless it is programmed for “Force arm”.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/architecture/issues/54#issuecomment-419226374, or mute the thread https://github.com/notifications/unsubscribe-auth/AAd9ak2V4X2t6Zn6wpd9Os36tzcYGynwks5uYYJRgaJpZM4Vzbwl .

-- Andrew Barbaccia

[gwww]

I'd happy to review, comment, edit, ...

Thanks Andrew!

[BioSehnsucht]

I believe, for Elk M1 system:

Disarm : Disarmed. Armed Away : Exit Entry timer enabled. Arms all zones. Armed Vacation : Exit Entry timer enabled. Arms all zones. Identical functionally to Armed Away, and exists solely that rules running on the system and devices integrated with the system can behave differently (i.e., randomly turn lights on and off, change thermostat setbacks, etc) Armed Stay : Exit Entry timer enabled. Arms all perimeter zones, excludes interior zones. Armed Stay Instant : No exit entry timer. Otherwise same as Armed Stay. Armed Night : Exit Entry timer enabled. Arms all perimeter zones and 'night' interior zones, excludes other interior zones. Armed Night Instant : No exit entry timer. Otherwise same as Armed Night.

I think we can represent them as follows:

Elk Name	HASS Name	Exit Entry Timer	Perimeter Zones Armed	Interior Zones Armed	Night Zones Armed	Note
Disarm	STATE_ALARM_DISARMED	n/a	N	N	N
Armed Away	STATE_ALARM_ARMED_AWAY	Y	Y	Y	Y
Armed Vacation	?	Y	Y	Y	Y	N1
Armed Stay	STATE_ALARM_ARMED_HOME	Y	Y	N	N
Armed Stay Instant	?	N	Y	N	N	N2
Armed Night	STATE_ALARM_ARMED_NIGHT	Y	Y	N	Y
Armed Night Instant	?	N	Y	N	Y	N3

N1 : Exists only to enable integration and rule changes due to Vacation mode. Perhaps we just set a vacation flag on the sensor entity for the panel and use STATE_ALARM_AWAY ? N2 : Treat as STATE_ALARM_ARMED_HOME, or add STATE_ALARM_ARMED_HOME _INSTANT _MAX (or similar) ? N3 : Treat as STATE_ALARM_ARMED_NIGHT, or add STATE_ALARM_ARMED_NIGHT _INSTANT _MAX (or similar) ?

Functionally we (Elk M1) don't really need a vacation mode though someone might want the alarm state reflected in the logs accordingly, as we can just set an attribute to reflect it. Seems like a minor effort to add a corresponding constant, but we need to be sure it's not confused for "Arm Max" since it appears that not all Vacation modes are created equal.

Further, when armed, any of the following can be true (calling them "sub-states" for lack of a better term):

Elk Sub-state	HASS Name	Entry Timer	Exit Timer	Note
No Alarm Active	n/a	n/a	n/a
Exit delay active	?	N	Y
Entrance delay active	STATE_ALARM_PENDING ?	Y	N
Alarm Abort delay active	?	n/a	n/a	N4
Alarming	STATE_ALARM_TRIGGERED	N	N

N4 : Optionally, alarm reporting can be delayed to allow more time to disarm before a false alarm is sent to the central station. We can probably treat this the same as Alarming / STATE_ALARM_TRIGGERED, I'm not sure if there's value in adding a state for this.

Further states that don't seem to have a useful correlation for Elk at the moment :

HASS Name	Note
STATE_ALARM_ARMED_CUSTOM_BYPASS	Actually, we can arm with a bypass, but it's a sub-state ...
STATE_ALARM_ARMING	Appears to only be intended for transitioning from a disarmed to armed state - we don't use this for Elk as it's not a synchronous operation, we send the arm command and if it arms we get an event telling us it's armed
STATE_ALARM_DISARMING	Same as above for STATE_ALARM_ARMING

To further explain how the Elk exposes it's arming state, there is 'arming status', 'arm up state', and 'current alarm state'. So you can have various combinations, such as armed to night instant, force armed with a zone violated, and an entrance delay active.

Arming status: Disarmed, Away, Stay, Stay Instant, Night, Night Instant, Vacation Arm up state : Not ready to arm, Ready to arm, Ready to arm w/ violated zone that can be force armed, armed with exit timer working, armed fully, force armed with a force arm zone violated, armed with a bypass Current alarm state : No alarm active, entry delay, abort delay, full alarm (actually 16 or so variations one for each type of alarm that may have triggered it i.e. fire, burglar, etc)

A lot of the resulting matrix of those substate combinations are not necessary to convey in the dis/arming UI, and can simply be attributes, but a few of them can be relevant.

To wrap up : Maybe we should add _MAX (and also _INSTANT) variations for AWAY, HOME, and NIGHT states. I'm not sure if we should add vacation (vs attribute), and if so we need to make an effort to not having implementations confuse the meaning with 'arm max' flavor that has no entry delay. Though I suppose _INSTANT meaning instantly armed might be confused with 'arm max' type of arming for other implementations that arm with zero entry delay (arming instantly vs instant alarming). Perhaps a standardized attribute to indicate whether entry delay is enabled (separate from whether it is currently, at the moment, actively occurring) would cover these 'Arm Max' situations. We could add _MAX flavors as well instead, though if you can INSTANT and MAX then we're getting to a large number of possible states (though I'm not sure it matters - each implementation can expose/address only the relevant ones, and adding them to the UI side of things only has to be done once).

(edit: fixed up according to further discussion below)

[BioSehnsucht]

Looks like home-assistant/home-assistant-polymer#1549 got merged so STATE_ALARM_ARMING can now be disarmed in. So perhaps we can use it for exit delay?

[abarbaccia]

Thank you for writing this up. Most of it is in line with my experience on Honeywell / Ademco and probably most DSC panels.

A few questions / thoughts to refine this further:

• Can you confirm that INSTANT on the Elk M1 is indeed on the exit delay, and not the entry delay? I looked online but could only find forum responses .. but these suggested it is on the entry delay. If this is the case, it runs identical to Honeywell and most others I've seen. This would allow us to consolidate _MAX and _INSTANT since they are the same state. Agree _INSTANT is confusing but introducing another term is probably worse.
• What I was calling "night mode" is equivalent to your ARM_HOME_INSTANT. It's actually called "INSTANT" on the physical panel so i think we are fine using that here (although the Honeywell instructions use both name interchangably)
• We dont have a NIGHT mode separate from HOME_INSTANT. It actually sounds functionally similar to "custom bypass" in Honeywell ... but it seems you have both in the Elk M1. Would like to understand how custom bypass works within Elk. I dont use it personally use this model so no insight on my side beyond instruction manual.
• Vacation makes sense as an attribute since it is functionally equivalent to Arm_Away for the alarm
• Agree we should have an attribute to expose entry_delay; we would maybe also want it for exit_delay depending on the answer to first bullet above; not sure about other attributes we would want
• STATE_ALARM_ARMING and STATE_ALARM_DISARMING seem a bit weird to me. I think it's more useful to have states for STATE_ALARM_EXIT_DELAY and STATE_ALARM_ENTRY_DELAY, unless I am misunderstanding their intent.
• One additional thing to consider, and not sure how it works on other panels, is that while the system is disarmed, it can be either ready, or at fault. Fault usually means you have an alarm that wasn't cleared (eg., after it goes off, you have to clear it twice), or something is open.

[BioSehnsucht]

@abarbaccia

1-3) Ah, you might be correct. I haven't actually used the Instant modes and looking at it now, there is no explanation either way (beyond the name being "Instant") in either the User Guide or Installation & Programming Manual. After some Googling myself it seems all evidence points to it being as you say, it seems Elk's "Instant" modes are more akin to the "max" mode you described. I'm not an alarm installer by trade, so it's entirely possible for me to get things wrong.

Which means currently we're using the wrong states for the Elk integration (and/or, everyone else is - as with many things in HASS, implementations are left to figure out meaning of states / constants on their own for the most part by guessing at context clues from other implementations).

As for Custom Bypass ... I don't really know how any other panels operate. I know you can force arm which will bypass any zones marked as bypassable (which is separate from defining them as being perimiter, night, etc), and perhaps custom bypass means something else. If it is a custom mode where you can set which zones can be bypassed, then that probably matches Night better - since in the Elk, you can arm just exterior (stay), exterior + night (stay night), or exterior + night + interior (away). But for all those arming modes, you can force arm too or temporarily bypass manually before arming.

Force arming, which is available when specially marked zones are violated will temporarily bypass them until they become secure then they are included in the armed zones:

If the Ready light is flashing, it indicates the system can be armed even though one or more zones are violated. This only occurs if the violated zones are programmed as force-armable. Arming will temporarily exclude these violated zones from the system. If a force armed zone becomes secure while the system is armed, it will automatically become live, meaning that it can activate an alarm if violated. This feature is handy for a garage door. The system can be armed while the door is up. After backing out of the garage and closing the door, the garage door will become normal and it will be re-included into service.

Separately, you can bypass the zones temporarily from the keypad before arming, and it will stay bypassed for the entire time the system is armed until it is disarmed/re-armed:

When the Ready light is off, one or more zones are violated. The display will show "Not Ready x Zn" where the x represents the number of violated zones. The system cannot be armed until you secure or bypass the violated zone(s). ... If a zone is programmed as bypassable, you may bypass it (permanently exclude it) for the immediate arming cycle by pressing the Bypass key + zone number + the Bypass key again. The display will show "Ready w/ Bypass" once the system is ready to be armed.

I had thought this last was what was referred to as a "custom bypass" but perhaps "custom bypass" is a preset, versus this temporary manual bypass.

So it sounds like we need _INSTANT and _MAX (or renamed equivalents, depending on the prevailing nomenclature, and appropriate patches to all the things).

4-6) I agree about adding attributes. Add a vacation attribute, something along the lines of 'entry delay enabled', 'exit delay enabled', and perhaps also 'entry delay running' and 'exit delay running' - though these last two might be better as states?

From the (previously) lack of being able to disarm during ARMING, I suspect the ARMING and DISARMING were meant for temporary states while waiting on API calls to complete (i.e., user clicks arm in HASS, component sends command to arm, sets ARMING status, waits for API call to complete, then sets corresponding ARMED or DISARMED state depending on result). For the Elk's case, we just fire off arming requests and if it succeeds we'll get a separate message telling us. Nothing about the API is really stateful, you just fire commands or requests for information and either get a result (nearly instantly but not guaranteed at all) or don't, so we don't have any "in progress" states. As far as I can tell, the only system currently using these ARMING and DISARMING states is the Total Connect system.

7) The Elk can also be in a faulted state after disarming. From memory sending the disarm command with a valid user code a second time will clear it, but I haven't tested this recently. I am pretty sure this is exposed to us in the Elk's API via the system trouble status updates, so we can detect and expose this condition appropriately, but there isn't really a good state to set in HASS other than remaining in the TRIGGERED state. So perhaps we need another state for FAULTED. Or maybe two, depending on whether any given system can be faulted and still armed (i.e., it was silenced but stayed armed) vs faulted and disarmed.

TL;DR : I've edited my previous post to reflect misunderstanding of INSTANT a) We (HASS project, not Elk alone) need both INSTANT (no exit delay) and MAX (no entry delay) states, possibly including a combination of them (though I'm not sure if any of the systems implement both no exit delay and no entry delay at the same time, is probably sensible to have them pre-defined). "MAX" might not be the most clear naming scheme, but off the top of my head I can't think of one that isn't too easily confused with "INSTANT". b) Add attribute for vacation mode (boolean). c) Possibly add attribute for exit time enabled (boolean), entry timer enabled (boolean), or perhaps a combination of INSTANT and MAX states can substitute for these, and we probably need those anyways... d) Possibly add attribute for exit timer running (boolean), entry timer running (boolean), or added states can substitute for these instead.. e) Don't remove ARMING and DISARMING as one platform uses it, but add states for entry and exit timers running ? f) Add state for disarmed with fault (i.e., it was triggered then disarmed), possibly two states (one for armed and one disarmed). Alternatively, an attribute?

[abarbaccia]

Thanks!

a) I think we're still a bit mixed up.

INSTANT = no entry delay. This is for both Honeywell and Elk, and the other panels i was able to find online. MAX is the same thing and can be consolidated so we just use INSTANT going forward. From what I could find online it seems exit delay is set for each zone during initial configuration, and if you arm those zones then a exit delay is provided for you. b, c, d, e) Agreed f) Faults are tricky. I would want to see how systems handle them. For example, on honeywell we have at least 3 disarmed states ... ready = ok to arm, fault = door might need to be closed before trying to arm, hard fault = alarm was triggered (not just entry delay) and needs to be cleared using your code before going back to ready state. I think we save this for another ticket :)

If we agree on the armed states, what is the process to get this aligned with other platforms and moved forward?

[BioSehnsucht]

a) So there aren't any panels that have a no exit delay mode that would need some other setting then? In that case we just use INSTANT for MAX I guess since it already exists.

f) So perhaps there should be an attribute that can indicate arming readiness - I don't think we have this standardized currently?

As for moving forward.. I guess we need to formalize the proposed changes and then get the attention of one of the "adults" to sign off on it, at which point we can submit a PR to implement it ... ?

[abarbaccia]

a) I do not think so at this point. I think we should ping the owners of other alarm_panel components, and see if they are aligned.

f) I think we may want them to be different states vs. attributes. I confirmed in a disarmed - failed mode you cannot arm the honeywell system, so it is indeed acts as a different state.

Formalized changes: (please add / let me know if you agree)

• Add the following states:
  1. ARMED HOME INSTANT - armed home no entry delay
  2. ARMED AWAY INSTANT - armed away but no entry delay
  3. DISARMED READY - disarmed and ready to be armed
  4. DISARMED FAULTED - disarmed but alarm not ready to be armed
• Add the following attributes:
  1. Exit delay active
  2. Entry delay enabled
  3. Entry delay active
  4. Vacation mode active

[BioSehnsucht]

f) Also add ARMED_NIGHT_INSTANT.

[gwww]

Around the "armed" states. I don't see the need for instant.

Instant, as is vacation, is a type of arming action, i.e.: a service. The panel is armed home (or day), night, and away. Instant is just how quickly it gets there.

Related, how would entry_delay_enabled be used?

Does that make sense?

[BioSehnsucht]

@gwww Actually it seems instant means no entry delay (instant alarm), not no exit delay (instantly armed). Unless you have experienced differently? Regardless, other Alarm systems have instant (no entry delay) modes.

[gwww]

Ahh, right you are! I just reread the Elk manual.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck