ELK M1 Interface

I am new to HASS and raspi, but certainly not new to Elk and did a bunch of development for the M1 when it was first released many years ago. I’m excited to get back into the HA stuff after a several year hiatus.

Can somebody please tell me which USB to Serial adapter(s) work with the pi to connect with the M1?

I just want to make sure I get the correct one so I can get this up and running without headaches and I’m not willing to spend the money Elk wants for their ethernet interface esp since it is little more than a RS232 to IP gateway in the grand scheme of things.

I want to get the USB to Serial connection working first and then I think it would be pretty simple to throw together a quick and dirty Wi-Fi interface to the M1 using a couple of ESP8266 and essentially accomplish the same thing as the Elk ethernet adapter for the most part.

Thanks in advance!

I have noticed that the Elk ethernet interface is slightly more clever than just a dumb TCP connection to serial port translator. It’s smart enough to support multiple simultaneous clients. And when it has multiple clients, it sends responses to some commands intimated by a client back only to that client

That said, probably not a reason to do as you described…

Any progress on the zone bypass or other features? I’d still love to migrate this from ISY994i. Thanks!

Remind me, what exactly are you looking for?

The ability to bypass and unbypass zones through HA would be first and foremost. Secondly the ability to modify user codes (example below). The rest of my wish list from last year is below. FYI the integration has worked splendidly, thanks!

  • Display Text On LCD Screen (dm)
    My Elk keypads display Trash Day on Monday’s until the gate where the trash cans are has been opened, indicating the trash cans are taken to the curb.

  • System Word Messages (sw/sp)
    If one of my gates is left open for more than 60-sec, the internal Elk speakers/keypads announce via voice “Warning gate left open” every 5-minutes until they are closed.

  • Zone Bypass Request (zb)
    Every Thursday, the gates are bypassed during certain hours so the pool cleaner can come

  • Request Change User Code (cu)
    The housekeeper’s code is only enabled when they are scheduled

  • Zone Trigger (zt)
    This allows me to expand the system to include zones not native to the Elk (Insteon sensors) and trigger the virtual zone numbers.

  • Keypad KeyChange Update (KC/kf)
    Nothing yet for these but it would be cool to be able to use the Elk keypad as an interface to HA. This would also allow changes to chime

You can do this with the current version of the Elk integration. See the elkm1.speak_word and elkm1.speak_phrase service calls. Additionally, you can display keypad messages using the alarm_control_panel.elkm1_alarm_display_message service.

It’s easy to play around with these using the Developer Tools / Services panel in home assistant. I also found it handy to use hass-cli to do the service calls from a shell script to piece together words and phrases.

Fantastic. Thanks for pointing out those integration points. Did I miss the zone bypass as well?

You did not miss the zone bypass. Zone bypass, zone trigger, and KeyChange are coded in the Elk base library. They did not make it into hass service calls. cu is just plain not coded in base Elk library.

When I get some time I’ll take a look at these. However, if someone wants to take a shot at them sooner… :slight_smile:

I have had a ELK M! system for 10 years. I just started to explore the Home Assistant. Is it practical to integrate the ELK with HA? I can’t seem to find any recent documentation on how to get started. Any help would be appreciated.

Thanks,
Dave

Absolutely, I’ve had my Elk about the same time, and put it on Hass about a year ago. I’ve never had a problem. I suggest you run hass.io on something greater than a rPi. Mine is on an unRaid VM and it works perfectly. Here is my elk config in my configuration.yaml YMMV

Ask and there are a lot of people here who will help.

Cheers, Richard

elkm1:
  host: elk://192.168.xxx.xxx:xxxx
  area:
    include: [1-2]
  counter:
    enabled: false
  keypad:
    include: [1-6]
  output:
    include: [3, 24-46, 100-101]
  plc:
    enabled: false
  setting:
    enabled: false
  task:
    enabled: false
  thermostat:
    enabled: false
  zone:
    include: [1-80]

It works great, and has been very reliable for me. Having access to the PIR motion detectors on the Elk zones is a great tool to control lighting. And of course, on perimeter doors and stuff to help detect people arriving and leaving.

And for fun, you can have the Elk speak funky words/phrases though the inside speakers, display text on the keypads. Oh, and arm and disarm the panel if you like, too!

I also use the Home Assistant to control the RCS thermostat that’s connected to my Elk. Looks like a generic “climate” entity as far as Home Assistant is concerned.

I think you’ll also find that doing automations in Home Assistant is much easier to manage than on the Elk. That was one of my early efforts was migrating thermostat set-backs, controlling the X-10 lights (since replaced with Z-Wave, but no matter…), etc. from Home Assistant rather than the limited capabilities on the Elk. Really powerful when first introduced on the Elk years ago, but hasn’t really kept up, plus using Home Assistant, I can integrate all the other stuff I have not connected via the Elk.

Ho, quite a long topic. For someone to start using Elk integration in HA, where do we start for the modules download, installation, configuration and finally exploitation.

Support for the Elk is now integrated in Home Assistant. You can start at https://www.home-assistant.io/integrations/elkm1/ and see all the other elements https://www.home-assistant.io/integrations/#search/elk-m1

Thanks for this! I’ve tried many other combinations to get an automation to trigger when the alarm goes off and this is the first one that worked.

1 Like

Hi Jim,

Do you have any guidance on how we can use the triggered_alarm attribute in automation? Since it’s part of each sensor, do we have to do some sort of for each loop to walk through each of the sensors and check whether it’s true/false?

It’s been a while since I wrote this and I don’t believe it’s been tested (don’t want to annoy the neighbors) but here is what I have.

- id: alarm_triggered_zone
  alias: "Record zone that triggered alarm"
  trigger:
    platform: state
    entity_id:
      - sensor.front_door # Front Door
      - sensor.front_rm_motion # Front room motion
      - sensor.north_gate # North Gate
      - sensor.patio_door # Patio door
      - sensor.living_rm_motion # Living room motion
      - sensor.south_gate # South Gate
      - sensor.main_garage_door # Main garage door
      - sensor.south_lndy_door # South laundry door
      - sensor.garage_int_door # Garage interior door
      - sensor.garage_n_door # Garage north door
      - sensor.siren_tamper # Siren tamper
      - sensor.master_slider # Master slider
    from: 'Normal'
    to: 'Violated'
  condition:
      condition: or
      conditions:
        - condition: state
          entity_id: alarm_control_panel.area001
          state: 'armed_away'
        - condition: state
          entity_id: alarm_control_panel.area001
          state: 'armed_home'
        - condition: state
          entity_id: alarm_control_panel.area001
          state: 'armed_night'
  action:
    service: input_text.set_value
    data_template:
      entity_id: input_text.alarm_triggered_by
      value: >-
        {%- set sensors = [states.sensor.front_door, states.sensor.front_rm_motion, states.sensor.north_gate, states.sensor.patio_door, states.sensor.living_rm_motion, states.sensor.south_gate, states.sensor.main_garage_door, states.sensor.south_lndy_door, states.sensor.garage_int_door, states.sensor.garage_n_door, states.sensor.siren_tamper, states.sensor.master_slider] %}
          {%- for sensor in sensors %}
            {%- if sensor.attributes.triggered_alarm  == True %}
              {{ sensor.name}}
            {%- endif %}
          {%- endfor %}

- id: alarm_triggered
  alias: "Alarm Triggered Notification"
  hide_entity: true
  trigger:
    platform: state
    entity_id: sensor.alarm_status
    to: 'burglar_alarm'
  action:
    service: notify.hangouts_jim
    data_template:
      title: "Alarm Triggered!"
      message: 'Home alarm triggered by {{ states.input_text.alarm_triggered_by.state }} at {{ as_timestamp(now()) | timestamp_custom(''%H:%M'', true) }}'

2 Likes

Thanks Jim. Is sensor.alarm_status supposed to be sensor.alarm_state in the latest versions? I’m not seeing an alarm_status, but do see an alarm_state currently set to no_alarm_active.

I’m guessing @jshank has a template sensor to capture the alarm status. here’s an example from my config with my sensors. I called mine alarm_state, but seems like he called it alarm_status.

    armed_status:
      entity_id: alarm_control_panel.area001
      value_template: '{{ states.alarm_control_panel.area001.attributes["armed_status"] }}'
      friendly_name: "House Armed Status"
    arm_up_state:
      entity_id: alarm_control_panel.area001
      value_template: '{{ states.alarm_control_panel.area001.attributes["arm_up_state"] }}'
      friendly_name: "House Arm Up State"
    alarm_state:
      entity_id: alarm_control_panel.area001
      value_template: '{{ states.alarm_control_panel.area001.attributes["alarm_state"] }}'
      friendly_name: "House Alarm State"

@jon102034050 is correct, I have a template sensor to capture the status for history.

I had an alarm event today and this notification didn’t include the offending zone. I think there is a race condition between setting the name of the triggering zone and the notification. I see the correct zone in the alarm_status template sensor during the event but the alert doesn’t include the name. Still fighting this one.

- platform: template
  sensors:
    alarm_status:
      value_template: '{{ states.alarm_control_panel.area001.attributes["alarm_state"] }}'
      friendly_name: 'Alarm Status'
  • Keypad KeyChange Update (KC/kf)
    Nothing yet for these but it would be cool to be able to use the Elk keypad as an interface to HA. This would also allow changes to chime

A workaround method to make the keypad buttons be HA interface buttons is to have the buttons control an OUTPUT on the ELK within the ELK script. The OUTPUT is virtual and does not actually control anything other than hold state. Then use this OUTPUT status in HA as a trigger for whatever you want.