ELK M1 Interface

Congratuations on the 0.81 milestone; This has been a fantastic journey to watch.

I have dumped my customer components and moved the configuration over to the integration in 0.81; and this has as expected broke a few odds and ends with the refactoring.

I have also my Lovelace alarm card updated - this also is now in the core, so not using the external JS file any longer, the ui-lovelace.yaml extract looks like this now.

  - icon: mdi:security
    id: security
    title: Security
    cards:
      - type: alarm-panel
        entity: alarm_control_panel.area001
        title: Home Alarm
        states:
          - arm_home
          - arm_away
        auto_enter:
          code_length: 4
          arm_action: arm_home

I also have failed to find the attributes for System Readiness; for example an alarm has tripped and needs to be reset, or a zone is violated and is blocking arming; this was an attributed called readiness as part of the area entity. The entity is now called arm_up_state and was the bug breaking the lovelace page, all sorted and good again.

Nice that you have it figured out!

Everyone… I have two bug fixes in the wings that were reported in this thread. Both on to do with configuration not being initialized meaning that you would have to specify all the config entries.

Everything else working for people?

Ignore this post! - its not you its me i fear!

Actually No!

For some reason the automation which are linked to the ELK are not firing! I had to change the sensor from .elk_zone_001 to read the new name of .zone001 and if i manually trigger the zone to be Violated, i will see it change as expected in the UX from Normal to Violated and Back, but for an unknown reason the automation’s linked to this not working - and have been since your first code release.

It of course could be something beyond ELK, but the timing is odd.


  - alias: Notify Backdrive Vehicle
    initial_state: true
    hide_entity: false
    trigger:
     - platform: state
       entity_id:
         - sensor.zone001
       to: 'Violated'
    action:
      - service: script.notify
        data_template:
          tell: "everyone"
          message: >
            {{ ["we have vehicles on the back drvice.",
              "there appears to be traffic on the back drive",
              "i sense someone approaching on the back drive!"]|random }}
          image: !secret backdoor_camera_image_url

zone001

Looking in the logs i found the request was processed - with a damn long delay - but processed none the less.

419-85-507 @ 2018-10-31T23:51:03.646038+00:00>, <state persistent_notification.sys_info=notifying; title=System Information, message=10:45 - - Hello, i sense someone approaching on the back drive! @ 2018-11-01T10:45:49.045242+00:00>]}

Are you sure that you have the entity_id right? I thought it would be zone_001. BTW, I’m away from home for a few days, so can’t test anything and don’t have ready access to a computer.

The ID is right - i have turned up the logging to debug; as i still have a feeling its not working correctly - for example i just tried the door bell; which is a short on zone 159; and should trigger an automation but that is not firing either.

Going to sort this log and see if i can get a snippet out.

Ok,

Its got to be gremlins and goblins, as this was not firing last night, but its working perfectly fine today. Odd stuff indeed.

2018-11-01 14:46:23 DEBUG (MainThread) [elkm1_lib.elk] got_data '0AZC159B00B1'
2018-11-01 14:46:23 DEBUG (MainThread) [homeassistant.core] Bus:Handling &lt;Event state_changed[L]: entity_id=sensor.zone159, old_state=&lt;state sensor.zone159=Normal; index=159, physical_status=open, logical_status=normal, definition=non_alarm, area=1, bypassed=False, triggered_alarm=False, friendly_name=BTN - Doorbell B, icon=mdi:alarm-off @ 2018-10-31T23:37:45.392034+00:00&gt;, new_state=&lt;state sensor.zone159=Violated; index=159, physical_status=short, logical_status=violated, definition=non_alarm, area=1, bypassed=False, triggered_alarm=False, friendly_name=BTN - Doorbell B, icon=mdi:alarm-off @ 2018-11-01T14:46:23.683362+00:00&gt;&gt;
2018-11-01 14:46:23 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140403800261800] Sending {'id': 35, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'sensor.zone159', 'old_state': &lt;state sensor.zone159=Normal; index=159, physical_status=open, logical_status=normal, definition=non_alarm, area=1, bypassed=False, triggered_alarm=False, friendly_name=BTN - Doorbell B, icon=mdi:alarm-off @ 2018-10-31T23:37:45.392034+00:00&gt;, 'new_state': &lt;state sensor.zone159=Violated; index=159, physical_status=short, logical_status=violated, definition=non_alarm, area=1, bypassed=False, triggered_alarm=False, friendly_name=BTN - Doorbell B, icon=mdi:alarm-off @ 2018-11-01T14:46:23.683362+00:00&gt;}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 11, 1, 14, 46, 23, 683429, tzinfo=&lt;UTC&gt;), 'context': {'id': '39de1abbd0b64e31b3c08f061ecd3b3f', 'user_id': None}}}
2018-11-01 14:46:23 INFO (MainThread) [homeassistant.components.automation] Executing Notify Backdoor Visitor
2018-11-01 14:46:23 DEBUG (MainThread) [homeassistant.core] Bus:Handling &lt;Event logbook_entry[L]: name=Notify Backdoor Visitor, message=has been triggered, domain=automation, entity_id=automation.notify_backdoor_visitor&gt;
2018-11-01 14:46:23 INFO (MainThread) [homeassistant.helpers.script] Script Notify Backdoor Visitor: Running script
2018-11-01 14:46:23 INFO (MainThread) [homeassistant.helpers.script] Script Notify Backdoor Visitor: Executing step call service
2018-11-01 14:46:23 DEBUG (MainThread) [homeassistant.core] Bus:Handling &lt;Event call_service[L]: domain=script, service=notify, service_data=tell=everyone, message=there appears to be guests at the backdoor, image=http://x.x.x.x/ISAPI/Streaming/channels/101/picture, service_call_id=9cf0b5138e91482ea00749b51ed2ee17&gt;
2018-11-01 14:46:23 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140403806227424] Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'sensor.zone159', 'old_state': &lt;state sensor.zone159=Normal; index=159, physical_status=open, logical_status=normal, definition=non_alarm, area=1, bypassed=False, triggered_alarm=False, friendly_name=BTN - Doorbell B, icon=mdi:alarm-off @ 2018-10-31T23:37:45.392034+00:00&gt;, 'new_state': &lt;state sensor.zone159=Violated; index=159, physical_status=short, logical_status=violated, definition=non_alarm, area=1, bypassed=False, triggered_alarm=False, friendly_name=BTN - Doorbell B, icon=mdi:alarm-off @ 2018-11-01T14:46:23.683362+00:00&gt;}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 11, 1, 14, 46, 23, 683429, tzinfo=&lt;UTC&gt;), 'context': {'id': '39de1abbd0b64e31b3c08f061ecd3b3f', 'user_id': None}}}
2018-11-01 14:46:23 INFO (MainThread) [homeassistant.helpers.script] Script notify: Running script
2018-11-01 14:46:23 INFO (MainThread) [homeassistant.helpers.script] Script notify: Executing step call service
2018-11-01 14:46:23 DEBUG (MainThread) [homeassistant.core] Bus:Handling &lt;Event call_service[L]: domain=script, service=message, service_data=no_show=, no_say=, who=notify.debug, media_player=media_player.sonos_kitchen, image=http://[email protected]/ISAPI/Streaming/channels/101/picture, message=You asked me to inform you when there appears to be guests at the backdoorI have an intersting fact for you

I have no explanation, ill monitor it more close, it might have to do with system reboots. and I see 0.81.2 is ready to download, so ill do that and see how long it takes for the system to come back up with full debug enabled, and automation to fire (intel NUC so should be cool)

/d

Hey @gwww. For entity alarm_control_panel.area001, it looks like the changed_by attribute is still there but always stays null for me. I see changed_by_entity_id working correctly and can follow the chain to the keypad and find out who disarmed but wanted to see if it the missing changed_by was working as intended.

changed_by is not used by ElkM1. It is a hass attribute so it will show up.

Thanks for the clarification. I fixed it as follows (thanks for the guidance earlier in the thread)

message: "{{ state_attr(states.alarm_control_panel.area001.attributes.changed_by_entity_id, 'last_user_name').split(' ')[0] }} disarmed the alarm"

So yesterday I was at a wedding when my alarm tripped. The alert was a burglar event, and I then realized that this component is not actually reporting the zones which caused the event which is reported in the status notices adding violations to the report until such time that the alarm is acknowledged and then reset.

Is it possible to exposed this data?

The root cause was a window not properly closed and the wind opened it in a gust. I was Able to verify from my iridium driver the status detail.

Thx
Damian

Further feedback.

Low battery alerts on zones with wireless devices like smoke detectors, or missing keyfobs. Any hope of exposing this data from the status reports also?

Is there a way to provide a default code to use for arm/disarm? I’m trying to export my ElkM1 as a HomeKit component, and it shows up in the Home app, but arming/disarming does not work.

Thanks!

system_trouble_status on the panel sensor? It’s not decoded, just the string that comes from ElkM1. Is that OK?

I have no HomeKit experience and cannot help there. Why not connect directly with HASS? The front end handles the arming/disarming. A default code would be a feature request against the GUI, not, as far as I understand a Elk-M1 component feature.

FYI I have submitted a PR for the configuration bugs that people reported in the 0.81 release. https://github.com/home-assistant/home-assistant/pull/18154

I’m not sure what you mean by connecting directly with HAAS. I suspect that what I want to achieve has nothing to do specifically with the Elk component, but I’m not sure. Is it possible add configuration to alarm_control_panel? The Elk M1 component docs don’t mention it. Thank you.

I guess I have no idea then what you mean to export your Elkm1 as a homekit component :blush:

There is no alarm_control_panel config for default code. Perhaps something you could explore is the creating a custom version of the Lovelace alarm_card.

If I wanted to programmatically arm/disarm the system with an automation, is that possible? Currently I don’t see a way to even arm the system without a code, for example, even though I have “easy arm” enabled in the M1.

I have a custom automation system written in Go built around my M1, and HA is super close to being able to replace that. I had started to refactor my code into an MQTT to M1 bridge and then the Elk component showed up in HA, so I’ll likely abandon my own efforts. :slight_smile:

Call a HASS service. You can pass a arm code.

Not sure how to do it with easy arm, the Elk-M1 protocol document doesn’t say anything about easy arm. You could try arming with 0000 to see if that works.

Yeah, easy arm isn’t anything special in the protocol, it’s just a special user ID and a configuration flag. I’d have to boot a Windows VM and launch ElkM1RP to find the details.