ELK M1 Interface

Third party integrations
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.

162

To work around this for now, you can setup a cron job to restart HASS. I do mine every day at 3pm:

sudo crontab -e

add entry:

0 15 * * * /home/homeassistant/restart-hass.sh

then create /home/homeassistant/restart-hass.sh with contents:
sudo vim /home/homeassistant/restart-hass.sh

#!/bin/bash
systemctl restart [email protected]

make it executable:

chmod +x /home/homeassistant/restart-hass.sh

163

Unfortunately, I don’t believe hassio has that capability (based on ResinOS and not having access to the /homeassistant folder), but maybe it will be possible to program an automation event into hassio to create a daily restart.

164

Would it be feasible to implement support for UPB ? Elk supports UPB power controls and I was thinking it would be nice to control UPB lights elk controls through HA. Thanks.

165

First off, thank you for taking the time to create the interface for the Elk.

I am also having a problem with the reader thread dying every few hours. The writer thread seems to be running still so I can turn on a light but can’t turn it off or vice versa. I’m running it on the pi. It looks like it might be timing out. Perhaps you can restart the reader/thread if there is an error?

Here’s the error output:

2017-10-25 01:05:38 ERROR (MainThread) [homeassistant.core] Error doing job: Fatal read error on socket transport
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/selector_events.py", line 723, in _read_ready
    data = self._sock.recv(self.max_size)
TimeoutError: [Errno 110] Connection timed out
166

@BioSehnsucht Is anyone using this successfully on a Windows PC running HA? I have a few questions:

  1. I have Python 3.6 installed on my PC. Will the elkm1 component still work properly? I don’t see why not, but just wanted to double check.
  2. What format should the serial port format be in the .yaml file? My Elk M1 is plugged into a PCI serial card, specifically port COM5. I currently have as follows and I am getting a lot of errors:
elkm1:
  host: COM5     #<--------is this the correct format for a PC running home assistant? Or should it be /dev/ttyCOM5

Any help would be much appreciated.

167

BioSehnsucht@ still no luck on using any code except the one I’m supplying in the config file to control the system. The newest issue is that HA sometimes doesn’t track the alarm status. I’ve posted an issue over on github for better tracking.

168

Hopefully a lot of these weird issues people are seeing will be fixed once I have time to update the Elk integration for the work I did on PyElk, just been swamped with work. Lots of weird code oopses and unintended bugs found, and I’ve added output buffering with rate limiting and it will not try to communicate with the Elk when ElkRP is connected (which won’t work anyways). Probably going to be a week before I have time, at best, unfortunately.

@DetroitEE: I’m not sure if anyone has actually tested it in direct serial mode, most of us are using it via M1XEP (which is serial over ethernet basically), and I now realize I don’t have any code path to set baud rate or anything. Assuming the defaults work, I think for windows you would set ‘COM5’ and right now it will default to 9600, 8-bit, No parity, 1 stop bit. If your panel isn’t already configured for 9600 8N1 you should be able to set this on the Elk to make it work for now. I’ll plan to enhance PyElk and ha-elkm1 to allow setting port speed & etc via config, so you can choose other settings.

169

UPB is supported. Even thought the config is referencing X10, they use the same naming convention and the panel controls them the same. I have UPB and it works good, it just stops updating the status and cant turn the lights back off with the the switch until system is rebooted.