@jshank @jruben4 @mathd @DamianFlynn
Since PyPi was updated with Gwww’s latest commits I’ve pushed an update to my HASS code as well, so HASS will now auto-install the necessary version of Gwww’s library (no manual installing of newer Github version required).
Will auto update I think you mean.
Oops, meant to say NOW not NOT 
Assuming nobody finds any show stopper bugs in the next few days, I’m going to likely merge this branch of my code to master and start doing basic cleanup / formatting / etc stuff to prep it for starting the process to PR into HASS itself. The remaining features to add (such as exit timer reporting, Omnistat extra temp sensors) aren’t forgotten, just will be added later now that the important stuff is more or less done.
Those of you with keypads w/ temp sensors please let us know if they appear to work or not.
…and test serial interfaces too! I’ve tested the library serial code with a pseudo tty on my MacBook and expect it should work when connecting to a real panel but have not tested with a real panel.
I switched to the gwww version of the elkm1/ library and my thermostats are now reporting temperature correctly.
For those using docker manually, this is how I did it:
copied https://github.com/gwww/elkm1/archive/master.zip to the directory mounted by docker as /config
docker exec -it ‘home-assistant’ /bin/bash
cd /config/deps/lib/python3.6/site-packages/elkm1/
rm -rf *
cp /config/elkm1-master/elkm1/* .
looks like my x10 lights names were switched from
light.elk_x10_a_01
light.elk_x10_a_02
to:
light.elkm1_light_001
light.elkm1_light_002
Also, the temp sensor (keypad) changed from
sensor.elk_temp_k_01
to:
sensor.elkm1_keypad_001
All elements are named elkm1_<element-type>_<ddd>
where element-type is light, keypad, zone, … and ddd is a 0-padded index starting at 1.
Sorry, this name change is intended behavior, though I understand it’s annoying to update your various automations and such. Also I realize it is not reflected in the documentation yet… nothing is. That’s probably my next to-do is to update all the documentation on Github according to the actual implementation…
If you need to figure out the new names for a given X10 light (if it was really X10 with house codes and device numbers), take the letter of the house code’s position in the alphabet (i.e. A is 1, P is 16) as housecode, and use this formula: number = ((housecode - 1) * 16) + devicenumber). A1 is 1, P16 is 256.
The naming changes are combination of normalizing some things internally and simplifying some code (I removed probably close to a hundred lines of code that was just creating the names previously, reduced to a few lines per platform/component and making use of the default names coming from Gwww’s lib)
No problem, I was just giving a report in case others were looking for old device names.
Sorry, ended up traveling on business this week, and don’t want to torture my wife remotely by fiddling with the Home Assistant installation from a few hundred miles away 
I’ll try the temperature sensors in the keypads when I return home.
Just pushed a new commit that may resolve some weirdness with areas not being detected depending on what is likely a race condition between HASS startup and entity creation and Gwww’s library scanning the elk. Depending on the order of events, it was possible for HASS to be too slow creating entities and the area attributes didn’t get set appropriately (I was only setting them when Gwww’s lib picked them up, and not checking them after).
I’ve pushed updated documentation to a separate branch on my fork of the home-assistant.github.io repo, and updated the links in README.md of the ha-elkm1 repo to point to them.
Let me know if anyone spots an error.
Is anyone connecting the Elk directly to the RPi with an RS232 to USB adapter? If so, did you have any issues doing so, and do you have any tips or tricks for getting this setup to work properly?
Have you tried it? Looking for feedback on the implementation. I wrote it and tested it locally through a psudo tty but have not tested against a panel.
@BioSehnsucht tried it, ran into problems, but we don’t have logs yet.
I’ll be trying it out this weekend. I’ll let you know how it goes.
I just had a chance to try the new library, and I do see temperature measurements from 2 of my keypads (that have temperature sensors) as well as an Elk temperature sensor connected to one of the zones. I have a third keypad with no temperature sensor, and it still shows up as a sensor with an “unknown” value.
Also a nice touch is that the custom values return type-appropriate representations (Times, etc.)
I’ve also got an HAI Omnistat thermostat connected to the elk. The new code seems to be able to fetch the current temperature, mode and set points. Trying to modify the “cooling” set-up updates the UI, but doesn’t change state on the thermostat. When I try to change the fan mode from “auto” to “on” I get this error logged:
2018-05-25 01:49:39 ERROR (MainThread) [homeassistant.core] Error executing service <ServiceCall climate.set_fan_mode: fan_mode=on, entity_id=['climate.elkm1_thermostat_001']>
Traceback (most recent call last):
File "/Users/louie/homeassistant/lib/python3.5/site-packages/homeassistant/core.py", line 1002, in _event_to_service_call
await service_handler.func(service_call)
File "/Users/louie/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate/__init__.py", line 373, in async_fan_mode_set_service
await climate.async_set_fan_mode(fan)
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/futures.py", line 381, in __iter__
yield self # This tells Task to wait for completion.
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/tasks.py", line 310, in _wakeup
future.result()
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/futures.py", line 294, in result
raise self._exception
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/Users/louie/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate/elkm1.py", line 309, in set_fan_mode
self._element.set(ThermostatSetting.FAN.value, ThermostatFan.FAN_ON.value)
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/enum.py", line 274, in __getattr__
raise AttributeError(name) from None
AttributeError: FAN_ON
Now to convert the entity ids…
Interesting, I thought I’d tested changing all the various settings on the thermostat.
I’ll look into that.
Looks like I updated the constant names in all but two lines and managed not to test the relevant code.
I’ve hopefully fixed it now, try the latest commit I just pushed to Git.
Just updated to your latest commit, and still rock solid. Great work