Closed fireRoads closed 3 years ago
@fireRoads thanks for all the details here, unfortunately the Alarm control panel entity in HA does not allow that and I also don't know how universal this kind of behaviour is across all alarm systems. If we want to have this included natively for all alarm_control_panels we would have to create a architecture issue here. In order to support this behaviour by adding additional binary sensors like you have done here, will make the config a lot more complex and will def not be in the first official version (because the first submission of a new integration is only allowed to have 1 platform, so alarm_control_panel, but no binary sensors yet). Will give it some thought!
I've been thinking about this, what if the NP code resets the alarm to it's previous state (so whatever it was before night_mode), and I put the previous_state in the attributes, that would work for people like me, but might also be good enough for you? What do you think @fireRoads ?
Hi, yeah, I guess that would work for me as well. Or maybe if you could create a separate alarm panel "zone" for the night mode. That way you could read the status from all zones and the night mode independently.
I don't like that, because for me there is 1 alarm and it has 1 state (armed, disarmed, night) and if I then have to check two entities to see if it is in night mode or armed, that makes it needlessly complex for a simple install, while a more advanced setup can create a template binary_sensor or template alarm_control_panel combining the state and the previous_state attribute to reflect it the way you want. Let me see if I have time to set this up today!
Yeah I get that it is not perfect. The problem here really is the HA alarm component. It is not a great fit with the armed home and armed away states since the Ajax alarm only has one armed state = armed away and a complimentary night mode. Your suggestion would work and separate binary sensors could be setup from that manually. Thanks.
the current version uses the previous state when disabling night mode, have you had a chance to test that @fireRoads ?
Hi @fireRoads, I have just created a new beta release and this one uses events under the covers, this allows you to build automations just based off of the codes you want to listen to, so you have a lot more freedom, haven't updated the docs yet, but see here for the event_type: https://github.com/eavanvalkenburg/sia/releases/tag/v0.4.0-beta.1
Hi! That sounds really great. Good job! Could be really powerful for automations and even building custom sensors based on the events.
I currently have limited free time to play with this. Nice to see things going forward with the integration though. I will check it out when I have time.
I am closing this issue 👍
Thanks! Let me know once you find some time!
Is your feature request related to a problem? Please describe. As discussed here: https://community.home-assistant.io/t/ajax-alarm-system/62853/190?u=fireon The HA alarm component can only hold one state at a time, whereas the Ajax alarm can arm a zone and at the same time have the night mode turned on or off. This means that the HA alarm component does not truly reflect all the simultaneous state possibilities that can be seen in the Ajax app.
In Ajax, you can also choose to only have particular devices activated during night mode. For example, I have three zones, 1 for home, 2 for the storehouse/garage, and 3 for the patio. When I activate night mode it only spans across zone 2 and 3 but zone 2 is typically always armed. In HA I therefore want to be able to see if zone 2 is armed (by normal arming) and separately if the night mode is also armed. I can see that in the Ajax app but not with the alarm component in HA since it cannot be set to armed_away or armed_night at the same time.
I therefore risk to forget to properly arm zone 2 if I see that night mode is activated. Next morning when night mode is deactivated zone 2 will therefore be totally unarmed. Today I have a notification automation running when zone 2 has been unarmed for too long, just to remind me to arm it. That automation is not possible (or has to consider multiple states) with the alarm component since the night mode could interfere with the actual state of the zone, thereby tricking you into thinking that the zone is armed when it is only armed for night mode. This is a little bit hard to explain but I hope you understand what I am meaning.
Describe the solution you'd like The main part of the component could be kept as is but I would like to be able to include an individual binary sensor (with on as armed and off as unarmed) for each zone and for the night mode. This should not be too much of a change and it could also be an optional setting in the setup dialog if you want the additional binary sensors or not, In my case they would be named binary_sensor.ajax_zone1, binary_sensor.ajax_zone2, binary_sensor.ajax_zone3 and binary_sensor.ajax_night_mode. This also enables you to more easily write automations that listens to if the night mode or zone is armed or not.
Additional context I am still using CheaterDev's SIA component with some modifications to support multiple zones, additional SIA codes, and a change that actually resets the alarm state to "safe" upon disarming after a triggered alarm. I have attached the init.py I am using below for reference. Sorry for my coding skills, I am not a programmer :)
I do like the alarm component integration in this version and the fact that it is regularly maintained :) So I would really like to switch to this version but since I have a lot of automations listening to the different binary sensors I am hesitant on moving since I cannot separate the night mode state from the zoned states.