I must not be doing it right -
2017-07-15 23:58:06 ERROR (MainThread) [homeassistant.loader] Unable to find component elkm1
2017-07-15 23:58:06 ERROR (MainThread) [homeassistant.setup] Setup failed for elkm1: Component not found.
I put the entire github directory in both
/home/homeassistant/.homeassistant/components
/home/homeassistant/components
Because I wasn’t sure which was appropriate - but it still can’t seem to find the elkm1 component.
@jruben4 find this directory in your installation: https://github.com/home-assistant/home-assistant/tree/dev/homeassistant/components (you should see most of the same files, though maybe not identical since that’s the latest dev version of HASS rather than the release you’re running)
That is what everything in the ha-elkm1 Github should be relative to.
I’ve been running it in a docker container, so for me (in the container) it is at /usr/src/app/homeassistant/components
I think for you it should be /home/homeassistant/components/, but I’m not 100% sure
You should end up with …/components/elkm1.py , …/components/alarm_control_panel/elkm1.py, etc
@BioSehnsucht ok, found that directory.
I’m running the Hassbian build, and that directory is:
/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components
Ok, now I drop your build in THAT directory, and get this error:
(I can confirm there is now an elkm1.py in the root components directory, as well as in the sub-directories like alarm_control_panel, climate, etc)
2017-07-16 04:08:04 ERROR (MainThread) [homeassistant.loader] Error loading homeassistant.components.elkm1. Make sure all dependencies are installed
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.4/site-packages/homeassistant/loader.py”, line 141, in get_component
module = importlib.import_module(path)
File “/usr/lib/python3.4/importlib/init.py”, line 109, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File “”, line 2254, in _gcd_import
File “”, line 2237, in _find_and_load
File “”, line 2226, in _find_and_load_unlocked
File “”, line 1200, in _load_unlocked
File “”, line 1129, in _exec
File “”, line 1471, in exec_module
File “”, line 321, in _call_with_frames_removed
File “/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/elkm1.py”, line 23, in
import serial
ImportError: No module named ‘serial’
2017-07-16 04:08:04 ERROR (MainThread) [homeassistant.loader] Unable to find component elkm1
2017-07-16 04:08:04 ERROR (MainThread) [homeassistant.setup] Setup failed for elkm1: Component not found.
@jruben4
Interesting. Serial is present in the docker so I had made the assumption it was there by default.
Run the following command to install serial:
python -m pip install pyserial
That should hopefully fix it. I’ll fix that in a future update so it is done automatically and/or unnecessary.
sudo python -m pip install pyserial
/usr/bin/python: No module named pip
However, sudo python3 -m pip install pyserial
seemed to install pyserial into /usr/local/lib/python3.4/dist-packages
However, I still get this error:
2017-07-16 23:51:46 ERROR (MainThread) [homeassistant.loader] Error loading homeassistant.components.elkm1. Make sure all dependencies are installed
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.4/site-packages/homeassistant/loader.py”, line 141, in get_component
module = importlib.import_module(path)
File “/usr/lib/python3.4/importlib/init.py”, line 109, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File “”, line 2254, in _gcd_import
File “”, line 2237, in _find_and_load
File “”, line 2226, in _find_and_load_unlocked
File “”, line 1200, in _load_unlocked
File “”, line 1129, in _exec
File “”, line 1471, in exec_module
File “”, line 321, in _call_with_frames_removed
File “/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/elkm1.py”, line 23, in
import serial
ImportError: No module named ‘serial’
2017-07-16 23:51:46 ERROR (MainThread) [homeassistant.loader] Unable to find component elkm1
2017-07-16 23:51:46 ERROR (MainThread) [homeassistant.setup] Setup failed for elkm1: Component not found.
Addendum: Apparently pip is not installed in the hassbian image.
ran: sudo apt-get install python-pip
After this,
sudo python -m pip install pyserial
works.
However, I get the same error as above when launching HASS.
You have to make sure that you run pip and install the dependency within the HASS virtualenv.
So, from the shell, you probably want to do something like
. .homeassistant/bin/activate
Or whatever directory you have HASS installed in. (That’s ‘.’ to source a script into your bash session. If you’re using a different shell, you’ll need to do something different.)
Tried this, and it said pyserial was already installed.
Try the new version of ha-elkm1 I just put on Github. It will require a newer version of PyElk which in turn will require pyserial to be installed, and it should be all taken care of automatically for you now.
I think it works now - HASS is correctly showing all the ELK sensors, zones, etc. Thanks!
It is still giving an error (but seems to work anyway)
2017-07-19 02:40:29 ERROR (Thread-10) [homeassistant.components.elkm1] Elk config : OrderedDict([(‘host’, ‘socket://192.168.0.195:2101’), (‘code’, ‘XXXXX’), (‘area’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-8’]}), (‘counter’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-64’]}), (‘keypad’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-16’]}), (‘output’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-208’]}), (‘task’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-32’]}), (‘thermostat’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-16’]}), (‘value’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-20’]}), (‘x10’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘a1-p16’]}), (‘zone’, {‘exclude’: [], ‘autohide’: True, ‘enabled’: True, ‘include’: [‘1-208’]})])
@jruben4 That’s not an actual error, it’s just throwing it as error instead of debug because that is the only way to make it appear in the log with default settings (and trust me, you don’t want to set HASS to output all debug logging). Eventually that won’t be emitted, it’s just for debugging purposes so you know what configuration is being used (starting with defaults, and then applying what you set in configuration.yaml, this is the resulting configuration).
Let me know if you notice anything weird. Thermostats are the only thing that I can think of off the top of my head that are implemented but aren’t working 100%, part of that is my code (I’ve got some bugs I haven’t yet worked out), part is that the lack of support in HASS currently for thermostats that are in an ‘auto’ or ‘heat and cool’ mode, the UI only supports being in either heat or cool and having a single set point. The latter makes it difficult to deal with the former 
I’m not dead, though I’ve unintentionally taken a bit of a vacation - just too busy with work and life. Trying to figure out how to get a “proper” development environment set up so that I can actually submit code (first going to submit a single file, simple component, that is unrelated to this Elk work, just to learn the ropes though - and there’s a bit more polishing needed for the Elk stuff anyways).
Things have been going pretty trouble-free with my Elk usage. (At least after I turned on logging to avoid some race condition.) The only weirdness I noticed was on one occasion where there must have been some sort of network error to the Elk M1XEP and the connection failed. I think this happened during a power outage at home, but am not exactly sure. Of course, I was out of town on some business travel (which is when most weird stuff happens, disk drives crap out, plumbing leaks, etc.)
As I mentioned before, I think chasing after the race condition is pointless if you’re eventually going to shift to python asyncio…
In the mean time, it just seems to be working well for me! Thanks again for all your work on this. Having access to all of the zone state on the Elk, as well as being able to control the X10 stuff hung off the Elk has greatly contributed to the “wife acceptance factor” for all this crazy home automation stuff.
Hi @BioSehnsucht,
New HASS user here, just did a fresh install and installed your elk component. Here is my configuration file (basically I’ve excluded tons of stuff so I only have the Zone’s I’m interested in):
elkm1:
host: socket://XX.XX.XX.XX:2101
code: 1234
area:
exclude: 2-8
zone:
exclude: 18-48, 54-208
output:
exclude: 1-208
task:
exclude: 1-32
thermostat:
exclude: 1-16
And my home-assistant.log looks pretty healthy:
2017-09-01 02:34:40 ERROR (Thread-2) [homeassistant.components.elkm1] Elk config : OrderedDict([('host', 'socket://XX.XX.XX.XX:2101'), ('code', '1234'), ('area', OrderedDict([('exclude', ['2-8']), ('autohide', True), ('enabled', True), ('include', ['1-8'])])), ('zone', OrderedDict([('exclude', ['18-48', '54-208']), ('autohide', True), ('enabled', True), ('include', ['1-208'])])), ('output', OrderedDict([('exclude', ['1-208']), ('autohide', True), ('enabled', True), ('include', ['1-208'])])), ('task', OrderedDict([('exclude', ['1-32']), ('autohide', True), ('enabled', True), ('include', ['1-32'])])), ('thermostat', OrderedDict([('exclude', ['1-16']), ('autohide', True), ('enabled', True), ('include', ['1-16'])])), ('counter', {'enabled': True, 'autohide': True, 'exclude': [], 'include': ['1-64']}), ('keypad', {'enabled': True, 'autohide': True, 'exclude': [], 'include': ['1-16']}), ('value', {'enabled': True, 'autohide': True, 'exclude': [], 'include': ['1-20']}), ('x10', {'enabled': True, 'autohide': True, 'exclude': [], 'include': ['a1-p16']})])
2017-09-01 02:34:50 WARNING (MainThread) [homeassistant.setup] Setup of elkm1 is taking over 10 seconds.
2017-09-01 02:36:18 WARNING (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 is already in progress
2017-09-01 02:36:18 WARNING (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 is already in progress
2017-09-01 02:36:18 WARNING (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 is already in progress
2017-09-01 02:36:18 WARNING (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 is already in progress
2017-09-01 02:36:18 WARNING (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 is already in progress
However, whenever I click on any of the Zone’s the Status/Alarm/Definition/State are always Unknown/Disabled/Disabled/Unconfigured. Also, if I violate a zone it doesn’t seem to show any status change here.
What is the expected behavior? Should the Zone’s be able to differentiate violated/not-violated in the HASS?
By the way thanks for all the hard work you’ve put into this!
Strange, it should show their states. You’re sure there’s not an errors logged ? It sounds like it failed to fully communicate with the Elk (as those attributes are the defaults).
I assume you’re on the current version of HASS, I haven’t updated mine in a while and need to do so, it could just be that something broke during one of the HASS updates.
No errors in home-assistant.log. Is it possible to have logged them somewhere else?
Agree sounds like communication error. I don’t have the git commit handy as I stored the git clone in /tmp/ and have since rebooted (so it’s gone), however it was cloned as of this morning.
You could try running the bin/PyElk-test.py in PyElk (you can edit it to set similar options in the file) and see what sort of output you get. It will output way more information than you get from HASS (you could also change your HASS to output debug level output but then you’re going to have a giant pile of log to sift through).
Good idea, nice utility. It looks pretty good, lots of periodic output around checking events, however occasionally it does have:
DEBUG:PyElk.Elk:elk_event_scan : timeout
Do you see this after it does the initial startup and then just lists events as they happen, or during the initial startup? Startup is done when it prints out the version information (it then starts a loop where it outputs any events, then sleeps for 5 seconds, and repeats until you kill it with ctrl-c or whatever)
I commented out your while loop at the bottom and it still hasn’t returned on it’s own. Seems to be taking it’s time doing a bunch of these:
DEBUG:PyElk.Elk:elk_queue_process - checking events
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - rescan in progress, skipping: 'AS'
DEBUG:PyElk.Elk:elk_queue_process - Event.EVENT_INSTALLER_ELKRP
DEBUG:PyElk.Elk:handle_line: 08RP010035
DEBUG:PyElk.Elk:elk_event_scan : timeout
DEBUG:PyElk.Elk:Sending: '08tr1500EC'
I’m running the 2.0.42 firmware on the M1XEP – have you tested with 2.x ?
It finally returned, the last two print statements were:
None
None
Does seem to be communication issue related. I don’t have any issues with the ElkRP software communicating through the XEP.
Oh, I had the ElkRP connected and that appears to have been the issue. Once I closed it, the timeout issue was resolved.
This is awesome! Now all the zones are populated correctly, and can successfully arm/disarm.
Thanks again for putting the work into this!