ELK M1 Interface

Third party integrations
142

Ah yeah, that’s the problem.

There’s two issues with having ElkRP connected:

  1. Apparently, the Elk just ignores commands from anything else (but continues to report statuses), including commands asking for information about zones and so forth (so if ElkRP is connected while starting up HASS for example, it will eventually time out everything and nothing will appear to have any status)
  2. The code on github might still be misinterpreting the “ElkRP connected” messages (I can’t remember if I pushed the fix for that yet) which would cause it to continuously try to re-scan the Elk thinking the ElkRP disconnected (since we don’t know what if anything was changed by ElkRP we have to rescan the Elk for changes). This doesn’t hurt the Elk but it can lead to a very long “outage” in HASS with regards to status updates and so on for the Elk while all the stacked up re-scans try to run one after another. I think I have this fixed but I can’t remember if that’s been pushed into PyPi / Github yet (and the HASS side of things updated to use the new version)
143

I installed home assistant using the new hass.io operating system, which doesn’t allow access to the /.homeassistant/components directory. Where do I place the files instead? Can I create a custom_components directory in the /config folder that I access through samba and put the files there, or do they still need a reference back to the main components folder?

144

One way or another you’d need access to the components directory, either to place the files directly there, or to create a symlink to something under the configuration directory. If hass.io doesn’t have a way to access that directory, then you may not be able to currently use hass.io. I’ve been using homeassistant in a docker container on my Linux machine or VM on my desktop, myself.

145

Well, not sure what happened, but I fidgeted around some more, didn’t really change anything, and now hass.io is seeing my alarm. The weird thing is that when I did the configuration check it always said “Valid”, but then on restarting home assistant I would get a message on the home page about not finding elkm1 and to check configuration. I did the basic socket connection only, so everything shows up. Time to exclude and hope it doesn’t break.

BTW, I am using UPB lighting (Pulseworx) through a M1XSP serial expander and HA is able to see the lighting even though the code references X-10. In case anyone else uses UPB and was reading this thinking it wouldn’t work for them.

Also noticed that turning individual lights on works, but the switch goes back to the off position and I can’t turn the light off from the interface. Also means that I don’t have an indicator to tell me which lights are on. Is this something wrong with my setup or a known issue? EDIT: as soon as I did my includes/excluded and reloaded HA, the switches are indicating correctly and allow me to turn off the lights.

Been waiting for this ever since I found out about HA, awesome work. All my lighting is controlled through my ELK and there hasn’t been a good home automation solution to bring that into a central place.

Now I just have to figure out why my radio thermostat doesn’t work either.

146

@BioSehnsucht:

Have you done any automation where you access the attributes of entity alarm_control_panel? I haven’t been able to get this to work, but basically when the alarm is triggered I want to turn on all the lights. Here’s what I’ve been experimenting with:

- alias: 'All Lights On @ Alarm Triggered'
  trigger:
    platform: state
    entity_id: alarm_control_panel.elk_area_1
    value_template: '{{ state.attributes.alarm }}'
    to: 'Burglar Alarm'

But it doesn’t like it:

2017-09-10 18:47:42 ERROR (MainThread) [homeassistant.config] Invalid config for [automation]: [value_template] is an invalid option for [automation]. Check: automation->trigger->0->value_template.

I could be wrong, but I don’t think the alarm triggering is registered as an event, is it?

147

In theory any attribute change should trigger but I’m no expert on how automations work, and always struggle to bend them to my will. To send notifications on access/disarm I had to create template sensors based on the attribute that gets the relevant timestamp value, trigger on that, and then from there reference the actual thing I was interested in.

ex:

sensor:
  - platform: template
    sensors:
      elk_area_1_last_user_at:
        value_template: '{{ states.alarm_control_panel.elk_area_1.attributes.last_user_at }}'
        friendly_name: 'ELK Area 1 last accessed at'
automation:
  - alias: 'Main Area Accessed'
    trigger:
      platform: state
      entity_id: sensor.elk_area_1_last_user_at
    action:
     - service: notify.hipchat
       data_template:
         message: "Main Area ({{ states.alarm_control_panel.elk_area_1.attributes.last_keypad_name }}) accessed by {{ states.alarm_control_panel.elk_area_1.attributes.last_user_name }}"
148

Thanks, I’ll experiment with this approach.

By the way, I plan to dig into this over the coming days but thought I’d post it here as well in case you’ve already seen it. But I think I’ve found two alarm states that may not be handled:

AttributeError: 'Area' object has no attribute 'STATE_ALARM_PENDING'
2017-09-10 21:49:37 ERROR (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 fails
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
    yield from self.hass.async_add_job(self.update)
  File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
    value = future.result()
  File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
    raise self._exception
  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/alarm_control_panel/elkm1.py", line 115, in update
    self._state = self._device.STATE_ALARM_PENDING
AttributeError: 'Area' object has no attribute 'STATE_ALARM_PENDING'

That one happens while the alarm is arming, and is in the entry/exit delay timer countdown.

There is a second one that happens (I lost the error message, will post it once I have it again) if the alarm has been triggered but not yet reset with a code.

149

I’m surprised nobody, myself included, has noticed this yet. Oops!

As a temporary fix you can just comment out lines 115-119 for now, until I can release an update that fixes this.

150

Home Assistant 0.53.0
PyElk 0.1.0 from github.com/BioSehnsucht/pyelk
ha-elkm1 7/17 (no version number)

@BioSehnsucht Everything works great except that I’m unable to arm/disarm the alarm. I looked around and I can’t find “bin/PyElk-test.py” anywhere. I’ve enabled logs:homeassistant.components.elkm1: debug but I’m seeing nothing other than the initial Elk Config “error” showing successful load. What’s the best way to troubleshoot?

Trying with the services interface -

Domain: alarm_control_panel
Service: alarm_arm_home
Service Data: {"entity_id":"alarm_control_panel.elk_area_1","code":1234}
151

Is there any error output when you try to arm? Have you tried simply using the UI instead of making a service call?

Try commenting out the lines 115-119 in components/alarm_control_panel/elkm1.py if you haven’t yet - it may be the same issue that scottro reported.

152

@BioSehnsucht - No errors when trying to arm and no difference using the UI vs a service call. I tried commenting out those line in alarm_control_panel/elkm1.py, it was more like 114-118 for my version of the file (different version)? Is there any way to get better debugging that might point me to the issue?

114         #if self._device.timers_active is True:
115         #    self._state = self._device.STATE_ALARM_PENDING
116         ## If alarm is triggered, show that instead
117         #if self._device.alarm_active is True:
118         #    self._state = self._device.STATE_ALARM_TRIGGERED
119         ## If we should be hidden due to lack of member devices, hide us
120         if (self._device.member_keypads_count == 0) and (self._device.member_zones_count == 0):
121             self._hidden = True
122         return
153

Disregard, I’m just stupid. I was using the wrong code. I didn’t realize that the code entered must match the code in the configuration file. I was trying a user code to arm.

154

The code should be a normal user code like you’d use on the actual physical keypad? The code option in the configuration.yaml isn’t actually used currently. I really need to update the “documentation” on github … :confused:

155

In other news, an illustration of something I just added in my Home Assistant / Elk integration. As I’ve been adopting more and more of Home Assistant, and have been adding some Z-Wave lighting switches and dimmer, I had to replication some functionality that I previously only implemented in the Elk.

I had a couple of Function Key buttons on Elk keypads dedicated to turn off a bunch of X-10 controlled lights. Some of these lights are now switched with the aforementioned Z-Wave switches. So, how to keep the wife happy? Lots of ways to do this, but one novel way is to watch for the Elk task invocation. The Elk tasks show up as switches, and the switches briefly turn on when the task execution starts.

So I added these automations:

- alias: elk Ext Lights On
  initial_state: True
  trigger:
    platform: state
    entity_id: switch.elk_task_009
    to: "on"
  action:
    - service: homeassistant.turn_on
      entity_id: group.outside_lights

- alias: elk Ext Lights Off
  initial_state: True
  trigger:
    platform: state
    entity_id: switch.elk_task_010
    to: "on"
  action:
    - service: homeassistant.turn_off
      entity_id: group.outside_lights

Of course, I could also look at the state of the X-10 lights as reported by the elk, but this really captures the action by the human pressing the keypad button that invoked the Elk task.

Neat stuff, been working well for me.

156

Now that some underlying things have been added/enhanced on Home Assistant, I’m going to get back into working on getting PyElk and the Home Assistant Elk integration up to snuff.

To start with, WIP documentation : https://github.com/BioSehnsucht/home-assistant.github.io/blob/elk-m1/source/_components/elkm1.markdown (this doesn’t quite format right when viewing directly in GitHub because it would normally get some extra parsing done by the HASS website… )

It’s WIP enough that it may be partially ahead of the code actually released :smiley:

157

I am having problems with Home Assistant not updating its status of devices connected through my ELK. It works after a reboot for several hours and then stops, all the statuses just freeze at their state. The services can still be called; for example, I can activate the toggle for a light and it turns on, but the slider goes back to off and it won’t let me turn the light back off because the system thinks it is off. Every time I reboot it starts working again, but I get an error in the homeassistant.log with the following:

2017-10-06 22:05:05 ERROR (SyncWorker_10) [custom_components.elkm1] Elk config : OrderedDict([(‘host’, ‘socket://192.168.1.50:2101’), (‘output’, OrderedDict([(‘enabled’, False), (‘include’, [‘1-3’]), (‘autohide’, True), (‘exclude’, [])])), (‘x10’, OrderedDict([(‘include’, [‘a1-a8’]), (‘enabled’, True), (‘autohide’, True), (‘exclude’, [])])), (‘task’, OrderedDict([(‘include’, [‘1-3’]), (‘enabled’, True), (‘autohide’, True), (‘exclude’, [])])), (‘area’, {‘enabled’: True, ‘include’: [‘1-8’], ‘autohide’: True, ‘exclude’: []}), (‘counter’, {‘enabled’: True, ‘include’: [‘1-64’], ‘autohide’: True, ‘exclude’: []}), (‘keypad’, {‘enabled’: True, ‘include’: [‘1-16’], ‘autohide’: True, ‘exclude’: []}), (‘thermostat’, {‘enabled’: True, ‘include’: [‘1-16’], ‘autohide’: True, ‘exclude’: []}), (‘value’, {‘enabled’: True, ‘include’: [‘1-20’], ‘autohide’: True, ‘exclude’: []}), (‘zone’, {‘enabled’: True, ‘include’: [‘1-208’], ‘autohide’: True, ‘exclude’: []})])

Then after a couple hours I get

2017-10-07 00:03:09 ERROR (Thread-2) [PyElk.Elk] elk_queue_process - removing stale event: ‘RR’

Is there a way to fix this? I’m running Home Assistant v.0.53.0 on HASSIO on Raspberry Pi 3

158

In the version of code that talks to the M1 from a couple of months ago, I think there is a race condition in there, somewhere that might be causing this. I find that if I turn on logging for Home Assistant to stdout/stderr (even when re-directed to /dev/null), the issue I had similar to what you described went away. These things are tricky to track down.

I believe that @BioSehnsucht had mentioned making some changes to the plug-in to use more of the Python asyncio stuff at some point; that will change the timing quite a bit. So I didn’t try to investigate any further since I found a state that seems to work very reliably for me.

What probably happened is that the receive thread that reads events from the Elk died somewhere along the way. At least that’s what I had noticed back when I was seeing a similar problem.

FYI, I’m running Home Assistant on a Mac Mini, so somewhat faster CPU and much faster I/O than on a Raspberry Pi. So my specific experience might not be directly relevant. Also, I’m talking to my Elk using the Ethernet widget, rather than over a serial conneciton.

The “error” message you indicated is really just debugging output and not indicative of a problem.

159

Thank you for the reply, I thought maybe the forst error was debugging since it basically just read back my settings, wasn’t sure if the second was indicative of my problems, and thought the readout of the first might shine light on a cause. How would I go about making the logging change you described to see if that helps me?

160

The first error containing the settings is just for debugging, as you guessed. I’ll remove that in a future update at some point before I submit a pull request to have it included in HASS proper.

I don’t think the error mentioning removing stale event ‘RR’ is itself an indication of a problem. Currently ‘RR’ events (real time clock updates) aren’t implemented (even to just discard them). Eventually an event in the queue that has been there for a while and not consumed gets discarded - if you’re only seeing that ‘RR’ events are being discarded, and nothing else, I think that’s not the actual problem.

One issue to watch for is whether you’ve used ElkRP to connect to the Elk while HASS is running - whenever connected with ElkRP, the Elk refuses any requests from any other devices (including HASS), which means that while it will update HASS with changes that occur, HASS can’t request changes. Once you disconnect ElkRP things “should” go back to normal.

Other than that, as @lmamakos mentioned, there does seem to be a phantom race condition someplace that he has experienced but I have yet to reproduce, but I am hoping to eliminate that in a future update when I make some changes to how it talks to the Elk (output buffering with rate limiting, and also move to using the async methods in Python).

161

@BioSehnsucht @lmamakos @dragonsoul84 :

I believe I have the same race condition as well. It happens quite frequently, I’d say about every 24-48 hours. HASS works fine, all other components still communicate, but I stop getting status updates from the ELK, which then breaks some of the automation triggers. My error log entries are:

2017-10-04 19:05:11 WARNING (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 is already in progress
2017-10-06 18:38:32 WARNING (MainThread) [homeassistant.helpers.entity] Update for sensor.elk_zone_006 is already in progress

Simply restarting HASS does the trick.