Currently working on figuring out what I’m doing wrong with supporting Celsius. If I tell HASS the climate device operates in C, and I try to raise the temperature to 20C, the value passed in is -6.666666 … which would be 20F converted to C. Clearly, I’ve missed a value that needs to be set so the UI operates correctly (it shows that things are of C but it is converting them as if the backend needs C but frontend is operating in F and doing the conversion for me … )
Well, apparently I’m trying too hard. I was implementing support for choosing C / F individually for thermostats and sensors and so on, but it seems this doesn’t dictate behavior but just what HASS thinks you’re operating in, and it then changes things on the frontend (but not all things) only based on the master setting of metric vs imperial.
Not sure if there’s a way to choose to mix metric and imperial but if not then I’ll just undo all the changes I made to implement this myself … 
I just published the latest code. Hopefully it doesn’t halt and catch fire for anyone 
- Increased required PyElk version to match latest PyElk
- Added settings and counters as sensors
- Fastloading via saved state
- Scanning for changes (on startup or after ElkRP disconnects) occurs on a dedicated thread so that HASS can continue running
- Avoid creating entities for disabled / excluded entities when possible
- Fixed friendly names for newer versions of HASS (the new entity registry)
- Climate control UI should work with ‘Auto’ mode
- Climate is compatible with metric units setting in HASS config
- Climate extended attributes will include Omnistat additional temperature sensors if available
- Lots of various bug fixes
To install, simply overwrite the existing elkm1 files (if any) with the latest ones from Git.
Let me know if I created any new bugs or missed fixing any. I’m going to be strictly in bug-fix mode for anything that comes up right now.
You can either download the release from https://github.com/BioSehnsucht/ha-elkm1/releases/tag/v0.2.0 (keep in mind Git puts the actual files inside a folder in the archive so you’ll have to extract them then copy them over) or by cloning / pulling the repo itself.
If I broke something terribly for you, you can go back to the previous release by replacing the files with those in https://github.com/BioSehnsucht/ha-elkm1/releases/tag/v0.1.0
Ok,
Based on the issues i had with the 0.1 release, I spun up a new Hass.io on a PI3 (Production runs on a Intel NUC). On this device I enabled only your ELK driver, on which i am interested only in Zones (About 180 Active), Outputs (about 8), Areas (1). Keypads (1) Users (4).
To acomplish this i have implemented the following configuration which i am happy to report appears to be parsed without issues now.
elkm1:
host: socket://172.16.1.253:2101
fastload: true
area:
exclude: 2-8
zone:
enabled: true
autohide: false
output:
exclude: 1-32, 41-208
task:
exclude: 1-32
x10:
exclude: a1-p16
thermostat:
exclude: 1-16
counter:
exclude: 1-64
keypad:
exclude: 2-16
setting:
exclude: 1-16
user:
exclude: 5-200
However, there are issues; for example many zones do not get thier friendly names, depsite turning off auto-hide, zones are not presented back, events are not being processed, and on random restarts I may not see any zones at all.
I have traced some debug logs, and opened an issue; I am happy to offer you SSH to my test PI, and the ELK to help debug this configuration.
Hello - Just installed this in my hassio system version: 0.65.6. Placed the files directly in the /config/custom_components folder, edit the config YAML file:
elkm1:
host: /dev/ttyUSB0
fastload: true
area:
exclude: 2-8
zone:
enabled: true
autohide: false
output:
exclude: 1-208
task:
exclude: 1-32
x10:
exclude: a1-p16
thermostat:
exclude: 1-16
counter:
exclude: 1-64
keypad:
exclude: 2-16
setting:
exclude: 1-16
user:
exclude: 5-200
and it appeared to load my zone names. So I thought it kind of worked, I restarted hassio and they zones didn’t appear… When hassio starts up I see allot of these errors:
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.alarm_control_panel] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.climate] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.light] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.alarm_control_panel] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.climate] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.light] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.alarm_control_panel] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.climate] Setup of platform elkm1 is taking over 10 seconds.
2018-03-28 01:11:04 WARNING (MainThread) [homeassistant.components.light] Setup of platform elkm1 is taking over 10 seconds.
But this could be because its running a a raspberry pi?
This is the errors I’m seeing in the log file are as follows:
TypeError: ‘>’ not supported between instances of ‘NoneType’ and ‘int’
2018-03-28 01:01:32 ERROR (MainThread) [homeassistant.components.alarm_control_panel] Error while setting up platform elkm1
Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py”, line 82, in async_setup
SLOW_SETUP_MAX_WAIT, loop=hass.loop)
File “/usr/lib/python3.6/asyncio/tasks.py”, line 358, in wait_for
return fut.result()
File “/usr/lib/python3.6/asyncio/futures.py”, line 245, in result
raise self._exception
File “/usr/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/alarm_control_panel/elkm1.py”, line 58, in setup_platform
if node.area > 0:
TypeError: ‘>’ not supported between instances of ‘NoneType’ and ‘int’
After rebooting a few times, I can see the zones again. The status of the zones come in correct on boot, but then do not update. Any help would be awesome.
Yes, it looks like TL;DR is that on Raspberry Pi the new “fast” semi-async threaded startup / operation is hammering HASS so hard it interrupts itself to the point of timing out critical parts of the elkm1 startup. Works fine on my 8-core desktop PC even inside a docker inside a VM, but … 
I haven’t been testing against a Pi in the past and I’ll probably set one up locally to do so in the future, but hopefully tomorrow I’ll get out a performance patch to solve it. I’ve got at least a bad / hacky solution working currently on a Pi that @DamianFlynn gave me SSH access to, so if nothing else I’ll clean that up and release it tomorrow if I don’t manage to polish up a more elegant solution.
The long version is that the old code would go step by step scanning everything on the Elk, and at the end would then return to HASS (this whole time ALL of HASS would be stalled - you’d get a “taking longer than 10s message”). This was slow, but at least didn’t fall to pieces on low end hardware. The new version loads previous saved state if it exists, returns to HASS and creates the known entities in HASS from the saved state, while on another thread kicking off the rescan process on the Elk for changes and even within that process some of the work is done in an in-order manner like before and everything that can be is fired off in bulk and then handled via the main event loop. On a faster machine, all three things can be happening at once (loaded saved state being turned into entities, rescanning, and all the events firing from the rescan triggered events that are causing entities to update and/or be created at the same time) without any problems, and it’s quite quick to start up. On a Pi… things go a bit sideways. If this was all implemented with “proper” Python asyncio style functionality instead of threads it would probably not be so messy, but that is not a thing I’ve learned yet, and am not planning to do so until after the Elk integration is more-or-less feature-complete-ish.
1 Like
Upgraded to new version 0.2 - running in a docker image on a PC.
Seems like about half of my zones are missing now. I believe it’s just hardwired ones.
Why don’t we need an access code anymore?
Also getting this error:
2018-03-28 16:23:48 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform elkm1
Traceback (most recent call last):
File “/usr/src/app/homeassistant/helpers/entity_platform.py”, line 82, in async_setup
SLOW_SETUP_MAX_WAIT, loop=hass.loop)
File “/usr/local/lib/python3.6/asyncio/tasks.py”, line 358, in wait_for
return fut.result()
File “/usr/local/lib/python3.6/asyncio/futures.py”, line 243, in result
raise self._exception
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/src/app/homeassistant/components/sensor/elkm1.py”, line 77, in setup_platform
device = ElkSensorDevice(node)
File “/usr/src/app/homeassistant/components/sensor/elkm1.py”, line 217, in init
self.update()
File “/usr/src/app/homeassistant/components/sensor/elkm1.py”, line 318, in update
state = self._device.voltage
AttributeError: ‘Zone’ object has no attribute ‘voltage’
The access code in the config was never used by anything, so I finally removed it from the optional options.
The error you posted looks like I forgot to add a property for voltage (previously I was probably accessing the “private” data in _voltage directly rather than going through a property voltage). Oops. That’s quick fix…
All my zones are seen now - not sure what changed, just a few restarts.
Why are the zones just updating on hassio load but then don’t continue to refresh? Also what are the pin settings required for the ELK-M1XSP Serial Port Expander to work?
@matthewjohn I don’t believe it will work with an XSP. You must use the serial port onboard the M1 mainboard or use an M1XEP / C1M1 (which both provide serial-over-ethernet).
Zones not working under hassio is possibly due to problems starting on a Pi, assuming you’re running on a Pi. I’m working on that.
I may have misdiagnosed the issue we’re seeing on Damian’s Pi (and just gotten lucky that it appeared to work once), so for now if you’re having problems, go back to the previous release of ha-elkm1. It may be a few days before we figure this out.
Okay do you need special settings for directly connecting the cable? There are lots of options for the serial port.
IIRC the default port options should “just work” if you’ve never changed them in the Elk. The default will be (I think) 9600 baud, 8 bits, No parity, 1 stop bit.
You can try to set options in the HASS configuration like below but I haven’t tested this yet, for example 19200 baud and even parity
elkm1:
host: /dev/ttyUSB0?baudrate=19200&parity=E
(On windows hosts this would be something like host: COM3?baudrate=... - no /dev/)
Basically you pass in the options you want to change after ? separated (if more than one) by &, with the following be possible:
baudrate : any valid baud rate (i.e. 9600, 19200, 115200, etc)
bytesize : 5, 6, 7, 8 (anything other than 8 is unlikely)
parity : N, E, O, M, S (None, Even, Odd, Mark, Space - anything other than None is unlikely)
stopbits : 1, 1.5, 2 (anything other than 1 is unlikely)
Thank you! I got it working! My question was more along the lines of the configuration within ELK. You can choose to have the serial port export zone changes, task changes, alarm changes and I wondered if all those needed to be turned on or not. Currently mine are all turned on.
The default is for all those to be on, you want to leave them on, otherwise the HASS component won’t see them.
My RCS thermostat was getting flagged as node.enabled == false. I had to comment out part of line 50 in climate/elkm1.py
if node.included is True: # and node.enabled is True:
discovery_info.append(node)
I tried adding thermostat: enabled: true to the config to force it but it didn’t work.
Interesting. Does it appear to work normally otherwise once it shows up in HASS? I’ve only got an old Omnistat to test with currently, so I haven’t been able to test it with any other thermostat setup.
I see the right data, temps/mode show up. And I can select the thermostat mode. I couldn’t figure out how to change set points.
Some other stuff, the custom settings all show up as unknown. And it looks like all my Elk events stop firing after a period of time, not sure if that is related to my thermostat hack or not. The logs don’t show anything interesting.
So still troubleshooting. Still kinda new to HASS, so not sure how to dig in deeper, but I did do some development on the CQC Elk driver so am familiar with the ASCII protocol.
I have created an ElkM1 Python library. https://github.com/gwww/elkm1
Comments, suggestions, pull-requests welcome.
It uses asyncio for communicate with the ElkM1 Panel. Most of the elements of the panel are supported (no thermostats though - yet).