BTW, the HomeKit component docs explain how to pass a code to the alarm_control_panel. It’s so obvious, I’m not sure how I missed it the first time. 
This is awesome guys, great work devs! I added this to my system today and it took me about 15 minutes or so. The only issues I ran into was having to explicity define every single entry, which I think is a bug. So here’s my hass config -
security system
elkm1:
host: serial:///dev/ttyUSB1
temperature_unit: F
area:
exclude: [2-8]
zone:
exclude: [8-208]
counter:
enabled: false
keypad:
enabled: false
output:
enabled: false
plc:
enabled: false
setting:
enabled: false
task:
enabled: false
thermostat:
enabled: false
Nothing fancy. I just want to see my zone status and be able to arm/disarm the system. As you can see, I’m using serial, and it works just fine. I don’t know if anyone else has tested it, but I can confirm it works.
Now to set up some automations and UI enhancements. I see that there’s a card for lovelace, and I also see that people have already looked into automating arming/disarming. Can’t wait to try it out. But I’m very happy with what I can see already.
GREAT WORK!!
can you share how you did this if you don’t mind? I would like to add an automation that would allow me to execute an arm/disarm without entering a code manually.
Thanks!
Yeah, the config thing is a bug. Should be fixed in next HASS release (it’s already in, just need the release to be … released), or you can get the fixed version from gwww’s repo I believe if you know how to do that.
If I understand correctly the config fix will be released in the 0.82 release that comes out today. There are two config fixes for ElkM1. Nothing else has changed.
Thank you for the feedback on the serial port stuff. You are the first person I know of who has used it! Whoop!
Hisma, sorry for the delay in responding. Here you go:
homekit:
entity_config:
alarm_control_panel.area001:
code: 123456789
filter:
include_domains:
- alarm_control_panel
1 Like
I was hoping updating to 0.82 would solve my problem, but I can’t seem to see any of my sensors since migrating from the github code to official support. My sensors are 17-28. I’ve tried a few different ways (i.e. i did exclude 29-204 and I end up seeing 1-16 and 204-208, but not 17-28). My current config has include 17-28 and I see no sensors. I’m able to connect and see my area1 status without issue. I can arm and disarm, etc.
Here’s my config.
elkm1:
host: elk://ip_address_erased_for_privacy_reasons
temperature_unit: F
area:
exclude:
- 2-8
counter:
exclude:
- 1-64
keypad:
exclude:
- 2-16
output:
exclude:
- 1-208
zone:
include:
- 17-28
task:
enabled: false
thermostat:
enabled: false
plc:
enabled: false
setting:
enabled: false
-Keith
What type of sensors are they?
Are you using Lovelace or old UI?
By the way, when pasting config pls use start and end it with 3 backticks or use the </> formatting.
The entity_ids all changed in the move to hass proper. You can see all the entities configured under “Developer tools”, “States”.
BioSenhnsucht: Window/Door alarm sensors. Nothing fancy.
Gwww: OK, so i did some searching on that page and looks like they are there, but don’t use the zone number. They show up as sensor.friendly_name. The zone number just show up for zones that aren’t configured/not in use on the M1. That’s why I was confused.
Thank you both for your incredible work!
I have the M1 communicating through the M1XEP IP-network interface and it works fine with HA - I’m showing arm/disarm status, network connection status, door sensors, keypad temp sensor, and a remote temp sensor in HA. I just updated to 0.82 Hass.io and have enabled the keypad card in Lovelace. I’m in process configuring the M1 and haven’t actually armed the system yet…
One question, I have the Elk M1XSLZW Z-Wave interface connecting the M1 data bus to the Leviton VRC0P-1LW Z-Wave secondary controller to integrate the Z-Wave network devices into the M1. Has anyone done this with HA? I can’t figure out how to replicate the Z-Wave network from HA to the Leviton secondary controller.
You won’t see them as specifically “Z-Wave” devices in HASS, if they’re connected to the Elk. The Elk will expose any PLC system (X10, Insteon, UPB, ZWave, …) the same way, which is basically like X10. It will map the other sysetms into a space of 256 possible devices (basically equivalent to X10’s A1 … P16). If you’ve named the devices in the Elk then you should see them by their names in HASS though.
If you’re using the Elk as a secondary controller, and HASS is primary (or integrated with whatever the primary is), most likely you’ll get a better experience by simply disabling the “light” portion of the Elk M1 integration and using whatever the other method that HASS is connected to your ZWave devices. Alternatively, if you have multiple PLC interfaces connected to the Elk, you can just exclude the device range associated with ZWave or anything else that is also in HASS to prevent confusion. You can still activate tasks to trigger Elk automation rules to do things with the ZWave devices in the Elk, but otherwise if you have them accessed by both Elk and something else you’ll end up at best with duplicated devices (i.e. two devices for each light, one from Elk and one from whatever the other ZWave integration is).
Hassio hosts my primary z-wave network controller and devices.
I’m hoping to indirectly add the z-wave lights to the Elk M1G to initiate or monitor lighting related security actions from the Elk panel through the Elk-connected serial VRC0P z-wave controller residing as a secondary controller in HA. However, I’ve learned today that HA does not support secondary controllers - and I’ve submitted a feature request for HA to support secondary controllers.
The Elk Lighting section has node mapping to the serial device (VRC0P) and I’d assumed if I got the Z-wave network replicated to the VRC0P that I’d be able to manually create my devices in the corresponding Elk lighting nodes and issue commands or act based on the lighting device states from Elk using its Rules engine. I think it will work if I can get the HA network replicated to the VRC0P.
TL;DR : If both Elk and HASS are connected to Z-Wave, probably no point in including Elk “lights” in HASS, everything should be achievable without it, would just lead to redundant entities.
Even if HASS supported secondary controllers, it probably wouldn’t work how you want since AFAIK the Elk doesn’t expose anything Z-Wave specific, it’s just a bunch of generic “lights” (which might be dimmable or might be simply on/off - the latter includes non-light things like appliance modules and such, and I suspect things like motion detectors appear as lights that magically turn on and off to signal motion, though I don’t recall how it handles such things off hand).
There’s nothing wrong with having the Elk also control Z-Wave devices and using it’s automation engine to do things, just that trying to include the “lights” from Elk into HASS when it already has a higher fidelity Z-Wave integration is not particularly useful.
You can still set up Z-Wave devices on the Elk, and then set up automation rules to control them (you can use either activation of tasks via HASS or changing the state of outputs that aren’t in use for anything else to trigger the automation rules, without having the devices loaded as duplicate “lights” in HASS). If you don’t care about the duplicate “light” devices in HASS (you could just not have them appear in the UI to avoid confusion of duplicate devices), you can certainly control them directly via HASS automations and such - but if the goal is to control the actual Z-Wave devices from HASS, it’s simpler to do so via HASS’s primary controller connection.
If you want a mix of Elk automation and HASS automation, and only that (i.e., not using HASS automation to trigger Elk automation via the lighting interface of the Elk), then there’s no need to load the “light” section of Elk into HASS at all. In fact, I’m not sure if there’s a difference in the Elk rule engine between reacting to a light state change via the Elk API and via sensing what HASS has done via the primary controller (i.e. HASS > Elk API > secondary zwave > device vs HASS > primary zwave > device > device update to secondary zwave > Elk - I think from the Elk automation rules these would appear identical)?
Maybe I’m not being clear. For example, in the event of a fire event, I want to turn on all the lights in the house. I have my zwave network defined and generally managed by HA. I also have a secondary controller (VRC0P) connected to the M1G that looks like a serial device to the panel via the Elk the Elk M1XSLZW Z-Wave interface board.
I then map all my lights in the Elk Lighting section to the Device corresponding to the HA zwave Node id, the Format as Serial Expander, and the Type to dimmer or On/Off. Then, I create a rule that on a Fire Alarm event, turn on all lights. I think that all I need to make this work is for HA to publish and replicate its zwave network to the VRC0P controller and then the M1G will be able to map to the zwave nodes and act accordingly. I don’t think I’ll get any duplicate devices in HA.
Why not just have the logic to turn on all the lights in the house in Home Assistant? You could have a virtual output on the Elk be turned on by an Elk automation rule. The inside of Home Assistant, have an automation that triggers on the state change of that Elk output (which will appear as a switch in Home Assistant) to do whatever is necessary. In this way, you’re not need to keep the configuration on the Elk aligned with the secondary z-wave controller on the Elk.
Perhaps this reflects my own experience with the Elk, where I migrated all of the automations out of the Elk platform into Home Assistant since it was much easier to manage there. And there’s much more flexibility, including accessing lighting on other automation/control platforms.
When I moved all that stuff away from the Elk, I could also control (in my case) the non-X10 lighting that Home Assistant managed, in response to Elk sensed activity. It enabled me to seamlessly managed the Elk-attached X10 lighting as well as the Z-Wave and Wi-Fi controlled lighting only connected to Home Assistant. Eventually, that led to expunging all the X-10 lighting and there was much rejoicing.
Sorry for the delay, traveling again.
I just updated to 0.82 and tried to filter for the system_trouble_status entity, but I am not getting lucky
If your asking if it would help to add that’s a really massive yes please. Encoded is ok, I have JS code that I can try to redo as python, but I will not say no to having the data decoded by the driver either
Thanks again for an excellent component guys
Damian
Is there a way to trigger in HASS if someone presses an F key on an Elk keypad?
I like this. Maybe this will work for @hagak as well and the keypad function key press.
Looks like I have an orphan Elk Zwave interface and its paired Leviton controller. Live and learn.