So am I correct in assuming that the new build is ready for daily driver usage and its safe to update? I am still stuck on the version just before the update that caused the raspberry pi to halt and catch fire. After I update my configuration.yaml with the new format to connect to ELK, do I have to edit any of my other .yaml files, or do all the groups and entity changes work with the new setup? Is there an easy way to set this up in HassIO or still just replace elk.py with the new version?
in the new build, the elk keypads aren’t showing their temperature anymore:
sensor.elkm1_keypad_001 state is “unknown”
Also, is it necessary to change the naming scheme of the zone sensors? This is going to cause me to have to re-write a bunch of automations, floorplan.yaml, etc. If you just get rid of the “m1” it should match.
Old version: sensor.elk_zone_001
new version: sensor.elkm1_zone_001
thanks!
@BioSehnsucht and @gwww - Absolutely fantastic work, thank you! I’ve just implemented but it looks great so far.
For anyone who finds a few hundred lights and the X10 exclude no longer working:
elkm1:
host: elk://192.168.1.1:2101
plc:
exclude:
- a1-p16@dragonsoul84 There’s still some things either not implemented or untested. But it shouldn’t halt and catch fire - if you haven’t been using the old version then you’re not going to miss anything yet (as something is better than nothing), but if you’re using the old version then it’s up to you.
@jruben4 I’ll check in to that
@jshank Thanks for mentioning that, forgot to mention I had changed the name of the x10 / lighting config option. Was going to call it ‘light’ (since that is what it’s called in the new library by @gwww) but HASS doesn’t like it, expecting some pre-defined ‘light’ definition in the configuration.yaml … so called it plc (since it can be any form of supported PLC not just X10)
@gwww @BioSehnsucht I have moved from testing to production, and i just wanted to take a moment and say a super big thank you.
Initial run looks very good; I have some more scenarios to address, including arming and disarming the alarm; but outputs, and zones all look good so far.
For reference to others, i have used the following configuration, to mask the entities which i am not interested in integrating with Home Assistant
elkm1:
host: elk://10.10.10.10:2101
area:
exclude:
- 2-8
user:
exclude:
- 5-200
plc:
exclude:
- a1-p16
output:
exclude:
- 1-32
- 34-35
- 41-208
task:
exclude:
- 1-32
thermostat:
exclude:
- 1-16
counter:
exclude:
- 1-64
keypad:
exclude:
- 2-16
setting:
exclude:
- 1-20
Thank you again, Ill update the thread once i have some more real-life drives complete
Damian
@jruben4 / all The naming change was to be more consistent with the name of the actual platform/component itself. I was hoping nobody had too many automations/etc to change just yet. Careful use of search and replace should solve the problem but I understand it’s annoying… 
Also, all the numeric parts are padded to 3 places rather than only as many as needed, because that’s how Gwww’s lib implements default names and to make things simpler and have less complex voodoo in my HASS code I’m using the default names when generating the entity names. That’s another thing to watch for when changing configuration over to the new code.
Does anyone besides jruben4 have temp sensors on their keypads, to test? Gwww and I are flying blind on why they don’t appear to work (show as ‘Unknown’) for jruben4 …
edit: also, some attributes for things have changed (been renaming them to be more human readable i.e. ‘last_user_at’ became ‘Last User At’ on alarm_control_panel). If you have a script / template sensor referencing them you may need to update them.
I have temp sensors in two keypads, plus a temperature sensor on one of the zones. I will try the new version over the next few days, and then promptly leave for a business trip next week. What could possibly go wrong 
I’l report back what I find…
If your middle name isn’t “Danger” then you could try it in a VM or something?
Keep in mind if you have a bunch of automations and such you may have to do a lot of config editing (see above posts)
A warning: current commit of the new branch is dependent on Gwww lib version not yet in PyPi, so you’ll have to manually overwrite the version that is installed by HASS with the latest Gwww from Github.
Alternatively, stick to commit 4824af979e09be17daf64f32ae896238f2374621
I just switched to the new version with gwww lib and it work great so far.
However, while working with template sensors I get issues trying to get value from attributes. I get errors in my sensors because of the spaces in the elk specific attributes names (“Arm Status” or “Physical Status” for example).
alarm_state:
friendly_name: 'Alarm State'
value_template: "{{ states.alarm_control_panel.elkm1_area_001.attributes.Arm Status }}"
If I look at the attributes from my other components all of them replace the “space” character with an underscore.
Is there a elk specific reason why it is not done this way?
I know I probably need to figure out my how to correctly escape that space character in my jinja template
Try this pattern:
value_template: "{{ states.alarm_control_panel.elkm1_area_001.attributes['Arm Status'] }}"
You will need to install the python module by running the following on your home-assistant:
pip install elkm1
The steps may vary depending on your setup (docker, hassio, virtualenv, etc).
I am running on docker and use the following docker file to build an image with the modules
FROM homeassistant/home-assistant:latest
#Add gwww/elkm1 library
WORKDIR /usr/src/app
RUN pip3 install elkm1
CMD [ "python", "-m", "homeassistant", "--config", "/config" ]Mine is a bit different. I thought pip3 relied on pypi thus the need to use git below. I’d love to know if @mathd method works as well since it’s much easier.
1 FROM homeassistant/home-assistant:latest
2 # Modification to support Elk M1 Component
3 RUN set -x && apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y \
4 git \
5 && git clone https://github.com/gwww/elkm1.git \
6 && cd elkm1 \
7 && python setup.py install \
8 && rm -rf /var/lib/apt/lists/*@jshank your comment made me doubt that I was using the correct library so I went back and got the latest files from https://github.com/BioSehnsucht/ha-elkm1/tree/gwww-elkm1-lib and took a look at https://pypi.org/project/elkm1/, rebuilt my image and everything is working fine on the elk side so I guess my dockerfile should be fine.
Now I am wondering if I still need to include it in my dockerfile since the library is on pypi? I am not very familiar on how the autoloading of the lib from pypi work in home-assistant so we may not even need to install it with pip anymore. @BioSehnsucht any thoughts on this?
Normally you do not need to pip install elkm1, HASS will do this for you (though sometimes you may have to restart HASS a second time if it doesn’t install before it tries to start the HASS elkm1 code). In fact, currently, that won’t get you the latest code (which is in Github but not yet relasesed to PyPi)
If you are using the latest commit on my gwww-elkm1-lib branch of the HASS code, then you should use the latest commit from @Gwww’s Github, or some things might not work properly. You can download that with this link : https://github.com/gwww/elkm1/archive/master.zip . You would then copy the files from the elkm1/ subfolder of Gwww’s library to the location where HASS normally installs it, overwriting the version HASS installed (you’ll need to let HASS install it first). For Docker installations, this would be in config/deps/lib/python3.6/site-packages/elkm1/ - where config is the config directory mapped as /config in docker. Off the top of my head not sure the equivalent for HassIO or other non-Docker setups.
Other methods of getting it installed into the Python path may work too, but may also result in updates to the lib not working when installed by HASS.
You don’t need to include anything in the Dockerfile if you’re using Docker.
Glad to hear people are starting to use this!
I just updated PyPi to ElkM1 version 0.4.3. Changelog is up to date on https://github.com/gwww/elkm1. @BioSehnsucht can now update HASS.
What is not done yet:
- Support for entry/exit timer message (EE). It is top of my list.
- Support for OmniStat (t2 message). Not a priority for me. If someone want to improve their Python skills this would be a great opportunity
- There are no constants for the speak word/phrase messages. Also not a great priority. But I may feel inspired to figure out a cool way to do this.
What is missing? What would you like to see?
Thanks @gwww. I’m not getting user data from the alarm_control_panel.elkm1_area_001 object. Is this feature not yet implemented or do I have a bad install?
"Last User Number": null,
"Last User At": 0,
"Last User Name": null,
"Last Keypad Number": null,
"Last Keypad Name": nullSorry this hasn’t been documented yet. Those attributes should work, but you’ll have to make sure the relevant keypads are enabled. The ways this works now in the HASS side of things is the keypad entity gets that data and sends a message on the HASS bus that the alarm_control_panel entity receives and updates that information for the area.
You can leave the keypad entities hidden but if they’re disabled then those attributes on the alarm panel won’t ever update.