{"action":"created","issue":{"url":"https://api.github.com/repos/home-assistant/architecture/issues/54","repository_url":"https://api.github.com/repos/home-assistant/architecture","labels_url":"https://api.github.com/repos/home-assistant/architecture/issues/54/labels{/name}","comments_url":"https://api.github.com/repos/home-assistant/architecture/issues/54/comments","events_url":"https://api.github.com/repos/home-assistant/architecture/issues/54/events","html_url":"https://github.com/home-assistant/architecture/issues/54","id":348611193,"node_id":"MDU6SXNzdWUzNDg2MTExOTM=","number":54,"title":"alarm_control_panel STATE_ALARM_* states and their intended uses?","user":{"login":"BioSehnsucht","id":135569,"node_id":"MDQ6VXNlcjEzNTU2OQ==","avatar_url":"https://avatars3.githubusercontent.com/u/135569?v=4","gravatar_id":"","url":"https://api.github.com/users/BioSehnsucht","html_url":"https://github.com/BioSehnsucht","followers_url":"https://api.github.com/users/BioSehnsucht/followers","following_url":"https://api.github.com/users/BioSehnsucht/following{/other_user}","gists_url":"https://api.github.com/users/BioSehnsucht/gists{/gist_id}","starred_url":"https://api.github.com/users/BioSehnsucht/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BioSehnsucht/subscriptions","organizations_url":"https://api.github.com/users/BioSehnsucht/orgs","repos_url":"https://api.github.com/users/BioSehnsucht/repos","events_url":"https://api.github.com/users/BioSehnsucht/events{/privacy}","received_events_url":"https://api.github.com/users/BioSehnsucht/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-08-08T07:43:18Z","updated_at":"2018-09-28T03:50:53Z","closed_at":null,"author_association":"NONE","body":"Continuing from home-assistant/home-assistant-polymer/pull/1549\r\n\r\nCurrently, 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`. \r\n\r\nWhat are these states intended for, and why can't you disarm during them? Which states should represent entry and exit timers ? "},"comment":{"url":"https://api.github.com/repos/home-assistant/architecture/issues/comments/425312859","html_url":"https://github.com/home-assistant/architecture/issues/54#issuecomment-425312859","issue_url":"https://api.github.com/repos/home-assistant/architecture/issues/54","id":425312859,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNTMxMjg1OQ==","user":{"login":"BioSehnsucht","id":135569,"node_id":"MDQ6VXNlcjEzNTU2OQ==","avatar_url":"https://avatars3.githubusercontent.com/u/135569?v=4","gravatar_id":"","url":"https://api.github.com/users/BioSehnsucht","html_url":"https://github.com/BioSehnsucht","followers_url":"https://api.github.com/users/BioSehnsucht/followers","following_url":"https://api.github.com/users/BioSehnsucht/following{/other_user}","gists_url":"https://api.github.com/users/BioSehnsucht/gists{/gist_id}","starred_url":"https://api.github.com/users/BioSehnsucht/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BioSehnsucht/subscriptions","organizations_url":"https://api.github.com/users/BioSehnsucht/orgs","repos_url":"https://api.github.com/users/BioSehnsucht/repos","events_url":"https://api.github.com/users/BioSehnsucht/events{/privacy}","received_events_url":"https://api.github.com/users/BioSehnsucht/received_events","type":"User","site_admin":false},"created_at":"2018-09-28T03:50:53Z","updated_at":"2018-09-28T03:50:53Z","author_association":"NONE","body":"@abarbaccia \r\n\r\n1-3)\r\nAh, 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.\r\n\r\nWhich 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).\r\n\r\nAs 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. \r\n\r\nForce 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:\r\n\r\n> 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.\r\n\r\nSeparately, 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:\r\n\r\n> 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.\r\n\r\nI 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.\r\n\r\nSo it sounds like we need _INSTANT and _MAX (or renamed equivalents, depending on the prevailing nomenclature, and appropriate patches to all the things).\r\n\r\n4-6)\r\nI 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?\r\n\r\nFrom 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.\r\n\r\n7) 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.\r\n\r\nTL;DR : \r\nI've edited my previous post to reflect misunderstanding of INSTANT\r\na) We 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\".\r\nb) Add attribute for vacation mode (boolean). \r\nc) 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...\r\nd) Possibly add attribute for exit timer running (boolean), entry timer running (boolean), or added states can substitute for these instead..\r\ne) Don't remove ARMING and DISARMING as one platform uses it, but add states for entry and exit timers running ?\r\nf) 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?"}}
{"actor":{"display_login":"BioSehnsucht"}}