Ha ha, yes I understand since “working” is better than “wtf is going on?”
Also, I can thank you for scaring my wife as she happened to be coming up on the porch while I was testing the invocation of the “Chirp Twice” Task in the Elk. Seems to work just fine! Yay!
Of course, after saying every works Just Fine after a restart some of he zones didn’t successfully get their states updated. Worked on the next try, though… I need to find a way to get the logging turned up again; maybe turn off my 8 state updates per second coming from my power measurements…
The issue with task staying ‘on’ even though it isn’t on (states in developer tools shows off, but UI shows on, and even if you click on it to show the more info card with a history it will show off for however long but still the toggle slider is ‘on’) is quite frustrating. It seems that the UI assumes the state has changed, but even trying to fire an update manually to make it reflect it being off doesn’t seem to work…
@lmamakos Well, I’ve updated Github/PyPi and Tasks should switch off now - also should not (hopefully) have any more issues with things being None (the previous bug you reported and fixed locally).
For Tasks, I had to resort to the dirty hack of having the event handler for the task activation event (that Elk sends out after you trigger the task) switching the status on, then triggering the update callback, sleeping for 1 second, then switching status off, and triggering update callback again.
For whatever reason, this makes the UI update and switch the task back off, even when the actual state history was tracking correctly before without it. It might lead to some weird issues of it’s own, if nothing else might cause a general 1 second stall of processing Elk events, but if you’re not spamming tasks it probably won’t matter. Eventually when things go asyncio there won’t be any downsides other than it simply being inelegant.
Elk M1 Interface team,
I wanted to provide some encouragement and thanks for your time on this project. I’m heavily invested in my Elk M1 Gold and I recently started with HA to control my lights via zwave. I’m excited to see that this project is so far along and I’m eagerly awaiting the release of the first main stream version.
Thanks for doing great things!
Not so much a team; this is all about @BioSehnsucht who’s done all the heavy lifting here. I’ve just been testing and tweaking here and there, but can’t claim any credit for the wonderful work that he’s done here.
He’s done a wonderful job so far with his code, better than the path i started down (and subsequently abandoned.) I also join you in thanking him.
@Tripple_T : Let me know if there’s any specific feature you don’t see already implemented or planned to be implemented that you have a need for (I made a big post a while ago on the state of things, if you start there and then read more recent posts you should have an idea what’s in there currently).
@lmamakos : Have you had a chance to test the latest Github/PyPi builds? The Tasks should turn off automatically now as well as baking in the fix for things that are None. I want to know if I accidentally caused any breakage elsewhere 
I went back to post #1 and read the whole thing this weekend. It looks like the primary features that I need will be in this release. Starting off I’m looking to use the status of the Elk and sensors for triggers and automation.
Here are the ideas that I have right now:
@BioSehnsucht, the new version seems to be working well. I occasionally restart HASS and the zones will be missing their names, but infrequently. Certainly nowhere near the problem I had before the fixes for the “None” initialization. I am guessing this is must another timing related issue, based on my HASS configuration and fast CPU that provoking this. If you’re still intending to implement the asyncio capability, that will certain changing timing things around enough that it’s not worth chasing that elusive weirdness now.
I’ve not yet installed the most recent HASS released a few days ago.
@BioSehnsucht, Well, I have an actual Heisenbug at work since I’ve added some z-wave multisensor devices, and apparently changed the timing around some. Now, when I run HASS in the normal mode I use, with stdout and stderr directed to /dev/null, the elkm1 start-up gets pushed out of shape. The reliable indication of this is that the Elk zone names are missing; possibly something else is amiss too. When I actually have stdout/stderr connected to a file, it seems to work. Ha!
The homeassistant.log file doesn’t ever show anything out of the ordinary when the failure happens, even with debug turned on. So no obvious hint there. I’m about to be away on a business trip, so don’t want to start fiddling with debugging code in it now, since I’ve got some buy-in from my wife I don’t want to lose 
So I have it running with the output directed to a file at the moment. I’m going to see about getting to run under supervisord so it can capture stdout/stderr into log files that get rotated as a longer-term work-arouind.
Sorry for the non-specific/unhelpful bug report; it’s one of those things…
Nothing obvious/useful appears on stdout/stderr when its not redirected to /dev/null. i only seem to have the problem when those are sent to /dev/null… and can’t see what if anything pops out there with DEBUG level turned on. I’ll see if I can catch something with various restarts to see if I can trigger it.
@BioSehnsucht - as a relative HASS newbie, can you give some basic instructions on how to get your Elk add-ons installed? I’ve downloaded your github repository and the two required other repositories, but I’m not sure where to place the files so that HASS can see them.
Thanks!
The current master commit of ha-elkm1 may have some issues. You’ll probably want to switch to commit cd8ce9d0315d3ca1b4e35d0196f5c589acd24a18 if you run into weirdness. I’m in the middle of doing a lot of code cleanup which in the process may have introduced some new bugs I’m ironing out, I’m not sure off hand whether what I’ve pushed to Github is already broken or not (I’m a few commits ahead in my local copy vs what is on Github).
As for setup… copy all the files to the (home assistant root)/homeassistant/components/ directory, including paths (i.e. light/elkm1.py becomes (home assistant root)/homeassistant/components/light/elkm1.py
Once HASS is restarted, it should in theory grab the correct PyElk version that matches the version of ha-elkm1 you copied into the HASS components.
You’ll need to actually configure it though.
At minimum:
elkm1:
host: socket://1.2.3.4:2101
Where host can be either a TCP IP:port (as above) or a serial port (i.e. host: /dev/ttyUSB0) if using a direct serial port connection instead of using M1-XEP / C1M1. Currently only supports “unsecure” port which is 2101 (if you’ve put it on another port some how, that’s fine, just specify it, but it doesn’t implement the “secure” communications mode)
You can further set optional settings to limit what devices get included/excluded, i.e.:
elkm1:
host: socket://1.2.3.4:2101
area:
exclude: 5-8
zone:
exclude: 35-98, 105-183
output:
include: 1-10
x10:
include: a1-a16
task:
include: 1-4
This would exclude areas 5-8 (including 1-4 by default), exclude zones 35-98 and 105-183 (including everything else in the default 1-208 range), include only outputs 1-10 (because 11-208 are not specified as included, they are excluded), include only x10 devices a1-16 (excluding b1-p16), and include only tasks 1-4 (excluding the rest).
you can specify both include and exclude for a given option, the logic is to start with the include list (if not specified, it defaults to all items of that type), then exclude those excluded (defaults to no exclusions). Additional types of ‘thermostat’ and ‘keypad’ should also work, they’re just not in the example. Areas coincide with the “alarm panel” control in HASS, one per detected (and included) area.
The whole point of all this inclusion/exclusion nonsense is to try and reduce the number of devices that get created in HASS (otherwise you might have for example, 208 outputs, and corresponding toggle switches in the HASS GUI in the default view, for example), as well as reduce the startup time by trying to skip as many unnecessary things as possible (though most of the time is spent waiting on the Elk to respond to requests for information during startup).
@jruben4 Can you quote which part you’re referring to, that you want more explanation on ? (I’m not sure if you mean the entire post, or a specific paragraph, and if so which one …)
Also, for the needed other repositories (GitHub - BioSehnsucht/pyelk: This is abandoned. Please use https://github.com/gwww/elkm1 / https://pypi.org/project/elkm1-lib/ / PyElk · PyPI), should these also go in the (home assistant root)/homeassistant/components/ directory?
From the git repo, you’ll want to switch to an earlier commit, identified by that long horrible hexadecimal identifier. I’m not sure offhand if you can get github go produce a tar/zip file at that revision directly, or if its easier to just clone the repo and do it locally.
You shouldn’t need PyElk; the home assistant component will fetch the right version automagically.
@jruben4 You might be able to ignore that - I was saying that if you have some weird / broken behavior, then you might need to use the previous commit. You can download that version using this link : https://github.com/BioSehnsucht/ha-elkm1/archive/cd8ce9d0315d3ca1b4e35d0196f5c589acd24a18.zip
As @lmamakos said, PyElk will be automatically installed by HASS, you only need to worry about installing the files from the ha-elkm1 repo.