Any reason why calling the service alarm_control_panel.alarm_arm_home doesn’t seem to arm the ELK?
I have been running the new release of last week and so far no problem at all!
Pushed new version. The git commit message, linked below, describes the change. When I first mentioned this on this thread I believed that this was a breaking change since entity_id’s would change. entity_id’s have not changed, but you have the ability to configure them as described in the commit message.
Please try it out and post back you experience.
AFAIK there are no outstanding bugs. I believe we are ready to integrate into hass distribution. The only bit left is to edit the docs to make sure that they match the current code.
In a case of bad timing, I missed the most recent commits, but got a version from the refactor branch earlier today. Seems to work!
One weirdness I noticed is some minor differences in temperature sensor entities. On my Elk, I have a thermostat, 2 keypads with temperature sensors (and one without) and temperature sensor attached to a zone.
Only the zone sensor has a °F unit attached to it; while the thermostat sensor and keypad sensors have no unit_of_measurement units displayed…
The climate.elkm1_thermostat_001 sensor has these attributes:
current_temperature: 73
min_temp: 1
max_temp: 99
temperature: 73
target_temp_step: 1
target_temp_high: 73
target_temp_low: 65
fan_mode: auto
fan_list: auto,on
operation_mode: cool
operation_list: idle,heat,cool,auto,fan_only
aux_heat: off
name: Thermostat
mode: 2
hold: false
fan: 0
current_temp: 73
heat_setpoint: 65
cool_setpoint: 73
humidity: 0
index: 1
state: unknown
unit_of_measurement: °F
friendly_name: Thermostat
supported_features: 2246
One of the keypads: sensor.elkm1_keypad_002 has these attributes, missing unit_of_measurement:
index: 2
state: 78
area: 1
temperature: 78
last_user_time: 2018-09-18T20:20:58.543420+00:00
last_user: 0
code:
last_user_name:
friendly_name: MBR
icon: mdi:thermometer-line
Curiously, the zone temperature sensor.elkm1_zone_015
index: 15
state: 73
physical_status: unconfigured
logical_status: normal
definition: temperature
area: 1
bypassed: false
triggered_alarm: false
temperature: 73
unit_of_measurement: °F
friendly_name: Basement temp
icon: mdi:thermometer-lines
has a unit_of_measurement, but it doesn’t show up in the UI…
I don’t have any customize: entries for these entities present. This is just a cosmetic thing that I happened to notice today. I mostly just bring this up now as it seems that merging this work into Home Assistant is approaching.
Hey @lmamakos,
Keypad was missing unit_of_measurement. So was the sensor.thermometer. Those have been fixed and pushed.
Confused by your sensor.elkm1_zone_015 curious comment. It has the units showing in the image you shared and the code seems correct.
Yes, I was confused; I looked at the climate entity fo the thermostat and not the associated sensor. And than I stupidly mentioned the zone temperature sensor by mistake.
Amazingly, you could still make some sort of sense from my ravings… thanks! I’ll try the new version later tonight.
I think I might have seen it mentioned elsewhere, but the hide: / show: default in the configuration changed… only really an issue for current users… I don’t think the default behavior was really documented before.
I’m still hoping there’s a way to get user info, whichever method was used to arm or disarm.
Currently, I only get user name if armed or disarmed via a physical keypad. If I use the Android app M1 Touch for example, the correct state is shown in HA, but not which user performed the arming or disarming.
The Elk logs however show the correct user, so the data is there somewhere. Any chance of looking at this in more detail? Thanks
I just submitted a PR to integrate into HASS. There’s some documentation work to do still which needs to be complete before the PR can be accepted. I’m sure that there will be some comments that will need addressing. Here’s the PR if you want to follow along on the comments.
2 Likes
Maybe I missed this, but my elk-controlled X10 lights disappeared on one of the recent upgrades. It used to be “light.elk_light_001”, but I can’t seem to locate it now.
@jruben4, the naming scheme changed a while back for consistency. Try looking for light.elkm1_light_001 instead. I believe all the entities how have that elkm1 prefix.
I think I found it under “light.outdoor_front”… must have gotten a friendly name somewhere.
I believe at one time I was able to change the temperature setting of my Elk thermostat in HASS. I noticed today this feature doesn’t appear to be available. I should note that I did a new install of HASS the other day. I’m running Ubuntu 18.04 and HASS in Docker
Does anyone have a thermostat connected to their Elk system, can you adjust the heat/cool settings from Home Assistant?
Yes, I have a thermostat on my Elk alarm. You can adjust the heat and cooling setpoints, and the mode from the “state card” of the thermostat entry in the UI.
In the Home Assistant UI, I have a Climate entity the looks likes this:
and then when you click on that entity, you’ll see:
You can see the current set points for heating and cooling, the mode, and the current temperature, etc. You can click in the UI to change the set points. Using the Home Assistant service calls ought to work, too, if you want to fiddle them from an automation.
I have an HAI RC-80B thermostat that’s serially connected via an Elk M1-XSP serial adapter.
Thank you for getting back to me… Yes, I now see what I was doing wrong. 
@BioSehnsucht First off thanks for all the hard work. I am trying to get a couple of notifications setup using the documentation from
I must be missing something because I get a configuration error when trying to use the below statements. I copied it from the documentation then modified it. I also did some research and it looks like there are a couple of single quotes instead of backticks.
value_template: {% raw %}'{{ states.alarm_control_panel.elkm1_area_001.attributes.["Last User At"] }}'{% endraw %}
I am still very new to HA as in 2 days new so I could have something else wrong as well.
Thanks
That hasn’t been updated in a while… things got renamed. Documentation hasn’t all been updated to reflect this really.
You’ll need to use attribute names like in this post : ELK M1 Interface
I noticed in watching the commits into the Home Assistant repo that there’s a change in how Elk Tasks are being handled. Previously, they were exposed as switch entities in Home Assistant. You could invoke the task by turning the switch on. (And then a bit later, the switch would reset itself.) Now it appears that the Elk tasks are mapped to scene entities, and you activate the scene to invoke the task. That seems OK.
However, I’m not sure with this new scheme if there’s an event that fires in Home Assistant when the Task is invoked on the Elk (possibly via the keypad or it’s own automations.) I think that when I first started to integrate the Elk with Home Assistant, I still had a bunch of automations implemented on the Elk, and would use tasks firing there to also kick off stuff in Home Assistant. I’m no longer doing this as I migrated all the smarts out of the Elk into Home Assistant. So I don’t think this change to scenes is going to be a big impact to me (other than updating some automations to activate scenes rather than turn on switches.)
(My remaining use of Tasks on the Elk is to chirp the external speakers 1 … 5 times with 5 different tasks. I don’t think there’s any other way to do that via the API.)
TL;DR because HASS devs said so 
Basically, we were using an ugly hack to emulate momentary action with a non-momentary entity type, because neither Gwww or myself had yet discovered a more appropriate alternative. During PR review, HASS dev pointed out we should use scenes or a custom service instaed. Scenes are not a perfect match in terms of nomenclature but they do seem to be a good match in functionality. They have a turn on, but no turn off. I wouldn’t have given them a second glance originally because my first thinking of a scene would be like in Insteon, where you can turn a scene on and off and so and you can follow their state, etc. HASS scenes are more like presets you can activate, and once they’re activated and set the included devices to the defined preset states, they’re done - they have no persistent state of their own.
Though… at the moment it seems like detecting when a scene turns on (i.e., to respond to tasks activating on the Elk’s side) requires some hacky work arounds. So it’s not ideal, but …
There is going to be a lot of other little changes too, but we’re probably two PRs away from having Elk integration in mainline HASS. At the moment waiting on one PR to be accepted, and then I think we need one more PR for climate (thermostat) devices.