Like my other post you could create a Rule in the ELK M1 that performs a bypass based on the state of an Output. You can control the state of the Output within HA. This does require a rule in the Elk but it is a simpler rule and then you have the more complex logic within HA.
Does this integration report phone line trouble or elk low battery? I’m not finding it.
Thanks, Richard
Yes. The entity typically named sensor.elkm1 contains an attribute called system trouble status. It is formatted as a comma separated string of all the troubles. For example:
AC Fail, Security alert zone 4
The complete list of troubles, from the code are here: https://github.com/gwww/elkm1/blob/078d0de30840c3fab46f1f8534d98df557931e91/elkm1_lib/panel.py#L55
New to HA and the forum - thank you all of you Elk fans for this HA, Elk M1 integration. Really cool!
I am a 20 year Elk customer, just installed HA on rpi B+. HA Elk alarm panel interface UX was working great for 2 days, then one of my 2 alarm panels - which correspond to two different areas in my Elk system - in the HA interface stopped allowing me to Arm Away or Arm Home.
When I enter the arming code and press Arm Home or Arm Away, the user experience does not change, and alarm is not armed. occurred day after I changed the order position of my alarm panels (alarm_control_panel.area_001, alarm_control_panel.area_002) in the lovelace default view config file, although the system was working fine immediately after I made that change.
Running Elk 5.3.10, HA 0.103.5, hassos 3.7, Nabu Casa cloud.
Turned on logging and discovered that although it appears HA Elk interface is sending the right ASCII commands to the Elk via XEP interface to arm, the Elk M1 is not “taking” the command, and instead returns back that the panel is still disarmed, and I receive an email alert from Elk just saying that the panel is disarmed, despite having pressed the Arm Home or Arm Away buttons on the HA UX.
Note HA log data below - which is the result that I get when my alarm panel in my Elk Area 2 is successfully armed through HA. HA reports back a status update (see positions highlighted in red) showing that Alarm has been armed, and HA UX for that alarm panel shows the area as armed. Bytes highlighted in red below are, I believe, the bytes Elk returns showing that area 2 is armed to stay (home) mode:
Below is the image of the log data showing what I see in the logs when I try to arm my Area 1 through the HA interface but it fails to arm. although the arm command sent to the Elk by HA looks correct, note that the bytes coming back from the Elk highlighted in red which should be showing an updated arming status for Area 1 are not - the status remains disarmed / no change to the arming status for Area 1 on the Elk side.
thank you in advance for any ideas about what I might have wrong in my configuration.
Interesting! The only thing that comes to mind is to look at how the panel is programmed. Look for differences, in particular between how area 1 and 2 are setup. Also look at user 2, which is the user number that you appeared to enter the code for. Is there anything special about that user? If that doesn’t result in anything then you’re going to have to go deeper. How good are you with python? I’ll point you to the Elk library next to see if something more can be learned.
Also, if you can share how you configured ElkM1 in HA that would help. In theory two areas work just like anything else, but there might be something going on and you’re the first.
Anyone else out there have multiple areas? I don’t have that in my setup.
Thank you very much for the ideas and quick reply! By the way, really appreciate the level of debugging information and return values passed back from the Elk that has been put into the HA logs, super helpful.
Yes, have been spending the afternoon and evening looking at what is different between area 1 and area 2 - not seeing anything obvious yet in the elkrp (elk remote programming app) configuration for the panel.
Interestingly, I am invoking the HA interface while I am sitting near one of the elk keypads which shows a status of Ready and I simultaneously have the ELKRP remote programming software open and it also shows a status of Ready, yet am still seeing that result back from the elk panel indicating that it’s not Ready, (assuming I am reading the status bytes accurately in the bytes returned from the elk and then passed back in the debug logs).
Also will look more at user 2, but first glance not seeing anything unusual there vs other users.
Again, it did all work fabulously right after I set it up, but then something obviously changed.
Also deleted the database in case there was some glitch there, did see a few databaseerror messages, but those are gone now.
When you suggest I share how I configured the Elk M1 in HA, please let me know what all I can share that might be helpful.
To get started, I just deployed HA on a raspberry pi on my network, and then gave it the static IP for my elk panel, and it discovered my elk. HA automatically created the entities alarm_control_panel.area_001 and alarm_control_panel.area_002, and then I cut down the number of other entities enabled in the HA UX by setting most of the flags to “enabled: false” in my configuration file.
Here is my configuration file:
Here is my UX config:
thanks again!
Hi - just thought I’d give an update. Integration started working normally and reliably soon after I made my last post, and has been up and running fine for a couple of days now. Was pretty careful not to change things, but yet it’s clear something changed 
Glenn - Return values from elk panel coming back to the logs through your / HA team’s excellent integration make it clear that my panel was not in a “ready” state when I was trying to arm it through HA, I will continue to do monitor to see if I can get to root cause. thanks!
FYI if ElkRP is connected to the Elk, most commands from other systems (such as Home Assistant) will be ignored until ElkRP disconnects. HASS will still receive various status updates but if ElkRP is connected that may prevent commands from being accepted from HASS.
Hi - Just upgraded from 0.103.x to 0.104.3. It appears that the exclusions in my configuration file are not recognized after the upgrade - all the Elk M1 entities are showing in Home Assistant. Any ideas appreciated.
I think you might have something else wrong with your config - the include/exclude is working for me in 0.104.3. do you have your config on github you can link to?
Thanks for your help Jon. Here is the link: https://github.com/MaxK99/HomeAssistant/blob/f4a3be880d96b53392ca0d43aacb638d0724256b/configuration.yaml
hm, this looks identical to mine. are all exclusions not working or just some? Can you screenshot some entities in the UI?
Maybe run a hassio homeassistant check just to make sure your config is parsing correctly?
Already did - it’s ok. Also restarted server and rebooted entire system (a few times).
I think those were historic ones. Maybe you ran it without filters the first time or something? In the configurator, you’ll find the list of entities here: /config/.storage/core.entity_registry
Carefully delete all of extra ones. That’s what I had to do. After restarting the system it didn’t end up with the mess of entities, which is what makes me think that they were historic.
I think there was a recent change in 0.104 related to restoring the state of entities upon start-up. It’s mentioned near the top of the release notes https://www.home-assistant.io/blog/2020/01/15/release-104/
Update: I edited the configuration.yaml file to selectively remove or add the elkm1 filters. This changed the state of the entities in Home Assistant from “available” (filter off) to “unavailable” (filter on).
I also read the release notes about elkm1 entities but assumed the filters would prevent entities from being loaded - bad assumption. I deleted the unavailable entities in the configurator and all is well.
Thanks everyone for the help!
I deleted the unavailable entities in the configurator…
Where exactly did you delete them from?
