@dragonsoul84, thanks i was able to play around and get things going. I’m just starting out with hass io and home automation so i’m still new to things. with that said, i think something like the sonoff with mqtt can help you with rebooting the pi. you can set up an automation to reboot around 3 am or when something isn’t detected. you can watch a video from bruh automation to get more details.
good luck and thanks for the tip.
@dragonsoul84 @delunar So putting it into config/custom_components/ actually works now? When I first started working on this, it wouldn’t work because the top level elkm1.py couldn’t find the others to load them (i.e. when trying to load sensors/elkm1py HASS would only look in the built-in components directory, not custom_components). If that works now, that makes installation much easier.
Seems to work, been using for a few months now this way. When I go into /custom_components it has folders for lights, sensors, etc. I don’t think those were there before I put in the module. It didn’t work right away (the first couple hours of trying to install it) and I made a couple posts here about it, but then it just started working. The constant restarting is a pain though, I don’t know if that is a symptom of the module not being 100% or a problem with how hassio interacts with it. Every so often it also needs a host reboot through the terminal or just pulling the power cord if I don’t want to load up a computer.
I’ve had the ha-elkm1 files in config/custom-components since Oct and it’s always worked.
Anyhow, it is working again on 0.60.1. I tried to downgrade and HASSIO auto upgraded it back to the latest. After that, everything worked again. Not sure why it didn’t work before even though there was no config changes at all.
Sorry for the late reply. So I followed the instructions given and it pretty much started to work after a reboot. I do see some errors in the logs. I’m still going through them and seeing if it’s something I can clean up.
Just wanted to drop by to say thanks for all the hard work on this. I’m new to HA, but was able to set this up with ease.
Thanks!!
Any updates on the next version? I have to reset HA a few times a day, otherwise the sensors don’t report. Happy to test out the new version.
The large amount of changes under the hood of PyElk lead to some major breakage in ha-elkm1 and I haven’t had the time yet to fix it.
please let us know if there is anything that we can do to help out! I’m a bit of a noob when it comes to python, but I’m happy to help test things out if you need a guinea pig!
I am also willing to test. The Elk interface seems to be getting less reliable, lots of HA reboots needed to keep the sensor state current.
Sorry, reasons and things, but I’m back at it today and have mostly gotten things working as good or better than they were, on the new fancy-pants PyElk that allows for faster startups and such.
Working on some weird (timing?) issues with talking to the Omnistat (not always getting replies to data requests, possibly just slamming the Elk too hard, so playing with the padding intervals between requests).
Have not yet address every little quirk / bug I wanted to get done for a next release (i.e., everything people had reported), but if I don’t get that done before the end of the weekend, but it’s otherwise as functional as before (i.e., nothing is MORE broke) I may go ahead and release an update. At least your restarts will be faster. 
Awesome news! Since I’m a newb at HA, what is the process for updating it once you release?
Pretty much same as installing the first time, you just put the new files in place of the old.
That’s great news! I am anxious to test it out.
Waiting anxiously to test it as well. Tremendous development effort and huge potential.
I am just getting a status of Unknown on all the items polled right now. Waiting to try with the new release. Hoping my issue will be resolved.
knock on wood I think I’ve got the Omnistat thing solved. Well, worked around. I implemented some new logic to support auto-retrying messages if the expected response doesn’t arrive. Don’t want to retry everything, since that could cause bad behavior (if responses aren’t coming back for some reason but the Elk is receiving the messages, you don’t want to keep telling the Elk to activate thing X repeatedly), and also because not everything has an expected response (or partial response) that we can wait for.
Right now just the Omnistat thermostat support is using it, but there are some other places that it could be used safely (basically just anything that involves querying is safe, but trying to make changes to state is not something you want to blindly auto-retry).
I need to merge the changes from my debugging-filled version to my regular code, and then test all functionality to make sure I didn’t break something else, then once I’ve checked off both those things (and made any necessary fixes) I can push out the updated PyElk and ha-elkm1.
Well, I was almost ready to start working on verifying the reported bugs were fixed, then somehow I introduced a weird race condition where if things start too quickly, they then hang… but throwing in a sleep fixes it. Trying to figure out the exact cause, but probably the solution is simply to block updates until a certain point in startup has occurred. Figuring out that point though… not sure what it is.
@BioSehnsucht thanks for all the work, this is really awesome. i’m starting to poke around and set up some automations. One entity I did not find was the Elk M1 “counter”. I do see it in the log but I do not see a folder or an “init.py” for it. Did I download an older version of ElkPy or was it excluded purposely? I can’t seem to get the counters to show up.
There’s two halves to this integration:
The part in the ha-elkm1 repo : This code provides the HASS components and does high level stuff, and uses PyElk to talk to the Elk / do the heavy lifting.
The part in the PyElk repo : This code is doing most of the work, and implements the low level stuff.
HASS doesn’t have any specific component class for a counter, so I’ve implemented as a sensor currently. So you’ll see for example sensor.elk_counter_01 , rather than something like counter.something_else. If you want to see the code for it, that is in the sensor folder. Some things are a bit more complicated than that, for example currently both climate and sensor read values from thermostat (the thermostats’ temps appear as sensors) though I may change that and if someone needs a sensor for the thermostat they can template it. However, it made sense at the time since you can also have temperature zones as sensors and keypads can have temp sensors too… Keypads themselves aren’t currently represented directly, instead you get a single “alarm control panel” per elk area, but if you input a code that information will be available (and also which keypad was used) as attributes on the alarm control panel entity.
Interesting thanks for the info. I don’t see the sensor Elk counter. I’ll have to play with my logging or other settings. Maybe I’m omitting them somewhere.