The fan setting is working now, thanks! And I’m able to confirm that I can change the heating and cooling set points as well.
One thing that surprised me is that all of the elkm1 entities seemed to default as “hidden” and didn’t show in the hass UI. Is that expected?
Anything that has been named in Elk, or can be detected as being “really there” via some other means, should be shown by default. You can override this by using config like :
elkm1:
host: ...
...
output:
show:
- 70-92
- 193-208
hide:
- 85-87
...
In addition to include/exclude override, you can use show/hide override. Default is the automatic behavior unless you specifically show something or hide it. Show will only override what you list (vs include which changes the default from include all to just what you list). This is useful because for some things you can’t name them in Elk and have no other way to indicate in Elk they really exist (such as outputs 65-208)
What is included but hidden currently? What’s your config look like?
Direct serial should work just fine, I just goofed when testing it.
The problem I had with testing direct serial was running in a docker and forgetting to create it with --device=/dev/ttyUSB0 passed in during docker run .... Since the device didn’t exist in the container, it couldn’t be connected to … probably you need to do this for any serial device, not just USB ones, but I’m not sure of that. A gotcha is that once you do this, if it disappears or moves around (i.e. becomes ttyUSB1) you get to remove and recreate (docker run ...) the container again because docker refuses to start when the device is missing on the host.
There’s a minor bug that I’m sure we’ll have fixed shortly where if using serial and it fails to connect, when it tries to reconnect automatically it errors. Fix is known (I just tested it), @gwww just has to get it pushed out to PyPi and then I have to push out an update to use that new PyPi release. Normally, nobody should even hit the bug … only discovered it by accident due to my discovering the docker problem the hard way.
friendly_name and not friendy_name. Duh. Chasing cut-n-paste ghosts!
Haven’t had a chance to further investigate show:/hide: defaults; I just explicitly did a show: in the config initially to get stuff working again before my wife noticed the “outage” 
So I thing that I did to try to further integrate the Elk keypad function keys into HASS, and further prune back the rules in the Elk to pretty much nothing…
In the ElkRP2 configuration, I define each key (F1 … F6) to activate a unique automation task with the single-press option. You don’t actually have to define that automation function action in an Elk rule. Each of these Elk tasks show up as HASS switches that turn on briefly when the automation in the Elk fires. You can of course define a HASS automation looking for the state change of that switch.
The other thing I did was define each function key button LED to track a (virtual) output on the Elk. The “Illumination Event” is set to a unique Elk output number for each button. Of course, the actual output doesn’t need to physically exist to do this… The Elk outputs also show up as switches in HASS. When you turn on the switch, the LED behind that F button on the Elk keypad will illuminate. They’re not very bright, and also not terribly response, taking a second or three before the LED changes to follow the output state change. But something you can do “for free” as another simple annunciator.
I make extensive use of the various motion detectors connected to Elk zones for various purposes; sure is nice to be able to take advantage of those for room occupancy detection.
By now, the only tasks that I have left configured on the Elk are 5 of them to chirp the outside speaker 1 … 5 times. There doesn’t appear to be any way via the API to perform this operation directly.
Thanks again for all the hard work to make the Elk integration continue to work well. Now I just need to clean up my configuration and get it a bit more organized.
So I’m ready to jump to the new version, but wanted to make sure I do it right. Do I just copy the repo onto my Pi in the custom_components folder and it takes care of the rest, or do I need to install anything for Gwww’s library as well?
Gwww’s library will be installed automatically by HASS when you use the Gwww branch of my ha-elkm1 repo. You will have to update your configuration as noted in previous posts as well. You may have to restart HASS a second time if it doesn’t install the Gwww library before trying to start the elkm1 code - I’ve had this happen occasionally.
Hi All. Using this with a pi3b running hass.io. I’m using a serial to usb interface. I get all of the zones and lights etc. come through but there’s no status for anything and I can’t control anything (including arming / disarming, lights etc.) I had this up and running bout 6 months ago fine, but i’m not sure if it’s just this version that i’ve got an issue with. Any ideas?
Also… thanks for all the good work.
Everything seems to be working perfectly with my serial to usb adapter. I’m using the Insignia NS-PU99501 adapter. The zones are coming through great, we’ve got an Omnistat hooked to the Elk panel that is working fine, and I haven’t encountered any bugs yet.
I was able to use USB enumeration to use /dev/elkm1 in my configuration instead of /dev/ttyUSBx because I wanted to be sure that if the USB port number changes, Home Assistant still can find the USB adapter. I used this guide here, very helpful.
Many thanks to those who worked on this.
Thanks for that mate.I’ll take a look. I have noticed that every second reboot or so there seems to be an issue seeing the usb device as /dev/ttyUSBx inside hassio. I’ll let everyone know if i find the root cause.
Check the homeassistant log file for errors - it sounds like it starts up but then part way through crashes.
also, be sure you’re using the new branch not the old one, if you’re on the master branch that is probably your problem on a Pi. Use the https://github.com/BioSehnsucht/ha-elkm1/tree/gwww-elkm1-lib branch
Yup. So that was it. Was using the wrong branch. Thanks so much for the help.
Does anyone have any unresolved issues with the gwww-elkm1-lib branch?
I’ll wait a few days for anyone to chime in, but if there’s no known issues I’m going to merge it to master so that anyone new who discovers it won’t run into the same confusion many of our recent new users have with needing to use a non-master branch
No issues here. The system has been running perfectly so far.
Only issue I had so far is I had a “Burlar alarm” in the “Alarm” attribute.
This is clearly a typo but I am not sure if this comes from your code of gwww’s.
Otherwise it is working well!
Please make sure this gets corrected…I’ve got automations that look at that attribute, and the trigger is looking for “Burglar Alarm”.
@mathd @DetroitEE LOL oops. Yeah, that’s in the lib. I never noticed - must have mentally “auto corrected” whenever looking at it!
Typos fixed. 0.4.5 uploaded to PyPi
I’ve pushed an update that uses the new gwww version (fixes the ‘burlar’ typos).
Just updated to the new gwww version on my Raspi3. Connecting to ELK via the M1XEP Ethernet module. Working great, very fast and responsive. Updated my config files to reflect the new naming scheme and I was off. I downloaded the new files about week ago, and after install saw the post about the recent update. Will the files update automagically, or do I need to re-download and apply the new files?