To work around this for now, you can setup a cron job to restart HASS. I do mine every day at 3pm:
sudo crontab -e
add entry:
0 15 * * * /home/homeassistant/restart-hass.sh
then create /home/homeassistant/restart-hass.sh with contents:
sudo vim /home/homeassistant/restart-hass.sh
#!/bin/bash
systemctl restart [email protected]
make it executable:
chmod +x /home/homeassistant/restart-hass.sh
Unfortunately, I don’t believe hassio has that capability (based on ResinOS and not having access to the /homeassistant folder), but maybe it will be possible to program an automation event into hassio to create a daily restart.
Would it be feasible to implement support for UPB ? Elk supports UPB power controls and I was thinking it would be nice to control UPB lights elk controls through HA. Thanks.
First off, thank you for taking the time to create the interface for the Elk.
I am also having a problem with the reader thread dying every few hours. The writer thread seems to be running still so I can turn on a light but can’t turn it off or vice versa. I’m running it on the pi. It looks like it might be timing out. Perhaps you can restart the reader/thread if there is an error?
Here’s the error output:
2017-10-25 01:05:38 ERROR (MainThread) [homeassistant.core] Error doing job: Fatal read error on socket transport
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/selector_events.py", line 723, in _read_ready
data = self._sock.recv(self.max_size)
TimeoutError: [Errno 110] Connection timed out@BioSehnsucht Is anyone using this successfully on a Windows PC running HA? I have a few questions:
elkm1:
host: COM5 #<--------is this the correct format for a PC running home assistant? Or should it be /dev/ttyCOM5
Any help would be much appreciated.
BioSehnsucht@ still no luck on using any code except the one I’m supplying in the config file to control the system. The newest issue is that HA sometimes doesn’t track the alarm status. I’ve posted an issue over on github for better tracking.
Hopefully a lot of these weird issues people are seeing will be fixed once I have time to update the Elk integration for the work I did on PyElk, just been swamped with work. Lots of weird code oopses and unintended bugs found, and I’ve added output buffering with rate limiting and it will not try to communicate with the Elk when ElkRP is connected (which won’t work anyways). Probably going to be a week before I have time, at best, unfortunately.
@DetroitEE: I’m not sure if anyone has actually tested it in direct serial mode, most of us are using it via M1XEP (which is serial over ethernet basically), and I now realize I don’t have any code path to set baud rate or anything. Assuming the defaults work, I think for windows you would set ‘COM5’ and right now it will default to 9600, 8-bit, No parity, 1 stop bit. If your panel isn’t already configured for 9600 8N1 you should be able to set this on the Elk to make it work for now. I’ll plan to enhance PyElk and ha-elkm1 to allow setting port speed & etc via config, so you can choose other settings.
UPB is supported. Even thought the config is referencing X10, they use the same naming convention and the panel controls them the same. I have UPB and it works good, it just stops updating the status and cant turn the lights back off with the the switch until system is rebooted.
@BioSehnsucht Thanks for your help and for all your work. Per the Elk M1 manual, baud rate and handshake are selectable, but all serial communication must be 8 bits, no parity, and one stop bit, so you are all set there. I’ll adjust the baud rate and see if I have any luck.
“Soon” will release an update that adds Elk counters and custom settings visible to HASS (with being able to make changes to them from HASS on the to-do list - it’s supported in PyElk already), among other things. Should also be a fair number of odd bugs fixed, so hopefully those of you with weird problems will have fewer of them.
I was gifted a used Omnistat 2 and M1XSP a while ago so I could try to diagnose thermostat related issues with real hardware (as it’s one of the few things that isn’t easy to fake for testing). Discovered either a weird bug or communications problem with the serial cable between the Omnistat 2 and M1XSP, I’m not sure which. Sometimes the Elk reports an invalid temperature (0 F - the valid returned ranges from the Elk’s normal thermostat calls are 1-99 F).
I implemented (partially) the Omnistat “PC” serial protocol, over the Elk serial protocol (yes, this is a thing) and discovered some interesting results. If I directly request just the current temperature from the Omni using the Omni protocol, I get a valid result. If I request the “group 1” data (which includes heat and cool set points, system mode such as heat/cool/auto, fan mode, hold mode, and current temperature) I get no response at all - I assume the M1XSP is consuming it as this is the same way it queries this data from the Omni 2. If I make a request for “group 2” data then I get a valid response which gives me indoor humidity, dehumidify setpoint, humidify setpoint, outdoor temp, filter days remaining, and energy level.
I’ll try re-making the serial cable connection again to see if it’s just some combinations of bits that are unreliable leading to the invalid temp being reported from the regular Elk response…
But regardless I may go ahead and keep this Omni 2 implementation in place as for no other reason it allows me to report humidity, which is supported in HASS, supported by the Omni 2, and even theoretically supported by the Elk - but while the call that returns temperature / setpoints / etc from Elk includes a value for it, it’s “not supported” and just returns 0 always. I’ll use some logic in PyElk to detect if the thermostat is an Omni and if so use the Omni protocol to get these things to ensure reliability / make humidity actually work, and use the Omni protocol values in place of the Elk ones where applicable. Plus, we can see temperatures outside of 1-99 F … and possibly add outside temperature reporting, etc, if you’ve got the additional sensors hooked up for it.
@BioSehnsucht - Trying to figure out how to get this to work with HASS in docker. I was hoping it would work to put the elk files in the custom_components folder (since that lives in my config folder) but that didn’t seem to work. Where is the /srv/homeassistant/lib/python3.4/site-packages/homeassistant/components equivalent when HASS is running from a docker?
Thanks!
The way I have it set up (my testing instance is Docker container too), I have created a custom_components-symlink directory in the config folder, then gone in to the docker container (‘docker exec -it ‘home-assistant’ /bin/bash’ should do the trick) and created symlinks from …/homeassistant/components/elkm1.py to /config/custom_components-symlink/elkm1.py, and then …/components/sensor/elkm1.py to …/custom_components-symlink/sensor/elkm1.py etc, with the files from the ha-elkm1 repository in the config/custom_components-symlink/ folder . Somewhere in this thread should be a complete list of symlink commands, I think.
Because reasons, just placing them in config/custom_components doesn’t work…
@BioSehnsucht Ok, I tried making a folder /home/jason/homeassistant/elk/ to store the original files from your build, and made the following symlinks (inside docker /bin/bash):
ln -s /home/jason/homeassistant/elk/elkm1.py /usr/src/app/homeassistant/components/elkm1.py
ln -s /home/jason/homeassistant/elk/switch/elkm1.py /usr/src/app/homeassistant/components/switch/elkm1.py
ln -s /home/jason/homeassistant/elk/sensor/elkm1.py /usr/src/app/homeassistant/components/sensor/elkm1.py
ln -s /home/jason/homeassistant/elk/light/elkm1.py /usr/src/app/homeassistant/components/light/elkm1.py
ln -s /home/jason/homeassistant/elk/climate/elkm1.py /usr/src/app/homeassistant/components/climate/elkm1.py
ln -s /home/jason/homeassistant/elk/alarm_control_panel/elkm1.py /usr/src/app/homeassistant/components/alarm_control_panel/elkm1.py
It gives this error on HASS start
2017-11-25 10:34:06 ERROR (MainThread) [homeassistant.loader] Unable to find component elkm1
2017-11-25 10:34:06 ERROR (MainThread) [homeassistant.setup] Setup failed for elkm1: Component not found.
I assume I missed a step? Do I need to do anything with PyElk manually or will it be used/installed automatically? Do I need any links to .gitignore?
is /home/jason/homeassistant created inside docker or outside? If outside, it needs to be the directory that is mapped to /config inside Docker, where your config files / log files are stored.
Yes - I create the docker with:
docker run -d --name=“home-assistant” -v /home/jason/homeassistant:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/home-assistant
and /home/jason/homeassistant had configuration.yaml etc created within it once HASS docker was started.
Update - tried to install pyelk both outside and inside the HASS docker - still get “unable to find component elkm1”.
Inside the docker container, if you run ‘cat /usr/src/app/homeassistant/components/elkm1.py’, do you get an error, or the contents of the file?
(if I run from inside the docker):
cat /home/jason/homeassistant/elk/elkm1.py
cat: /home/jason/homeassistant/elk/elkm1.py: No such file or directory
cat /usr/src/app/homeassistant/elk/elkm1.py
cat: /usr/src/app/homeassistant/elk/elkm1.py: No such file or directory
ls -la: (of /usr/src/app/homeassistant/components)
lrwxrwxrwx 1 root root 38 Nov 25 10:30 elkm1.py -> /home/jason/homeassistant/elk/elkm1.py
However, cat /home/jason/homeassistant/elk/elkm1.py works fine outside the docker.
Seems like it’s something broken with my symlink. It doesn’t seem to work pointing from inside to outside the docker file structure.
This is how I created them - from inside the docker -
docker exec -it ‘home-assistant’ /bin/bash
ln -s /home/jason/homeassistant/elk/elkm1.py /usr/src/app/homeassistant/components/elkm1.py
UPDATE:
Ok, figured out the issue, inside docker /home/jason/homeassistant is actually /config. So my links need to look like this:
ln -s /config/elk/elkm1.py /usr/src/app/homeassistant/components/elkm1.py
ln -s /config/elk/switch/elkm1.py /usr/src/app/homeassistant/components/switch/elkm1.py
ln -s /config/elk/sensor/elkm1.py /usr/src/app/homeassistant/components/sensor/elkm1.py
ln -s /config/elk/light/elkm1.py /usr/src/app/homeassistant/components/light/elkm1.py
ln -s /config/elk/climate/elkm1.py /usr/src/app/homeassistant/components/climate/elkm1.py
ln -s /config/elk/alarm_control_panel/elkm1.py /usr/src/app/homeassistant/components/alarm_control_panel/elkm1.py
I also run inside the docker:
python -m pip install pyelk
which seems to work (Successfully installed pyelk-0.1.9.dev23 pyserial-3.4)
Now HASS does boot and sees my sensors, switches on the elk.
I am seeing this error in the log though, not sure if it’s interfering at all with operations:
2017-11-26 07:41:42 ERROR (MainThread) [homeassistant.setup] Error during setup of component elkm1
Traceback (most recent call last):
File “/usr/src/app/homeassistant/setup.py”, line 193, in _async_setup_component
component.setup, hass, processed_config)
File “/usr/local/lib/python3.6/asyncio/futures.py”, line 332, in iter
yield self # This tells Task to wait for completion.
File “/usr/local/lib/python3.6/asyncio/tasks.py”, line 250, in _wakeup
future.result()
File “/usr/local/lib/python3.6/asyncio/futures.py”, line 245, 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/elkm1.py”, line 145, in setup
import PyElk
ModuleNotFoundError: No module named ‘PyElk’
try uninstalling PyElk in docker, and letting HASS install it automatically. It should automatically install version 0.1.8.dev3 into /config/ somewhere which is the version currently expected by the HASS elk code on github.
Soon will be releasing an update which will use latest PyElk, but maybe that’s the problem.
Making progress on next update. Have got a mechanism in place that can save the current state of known Elk configuration and reload it on next start, combined with moving the rescanning process to a dedicated thread, should allow for very fast startups. Just need to bring the HASS side of things up to date with the PyElk changes and figure out how I want to implement notifying HASS code of changes in Elk with regards to things being removed or added to it due to a rescan (which can happen in the first minute or so after HASS startup as a scan will start then, or in response to the system exiting installer mode or ElkRP mode, which can happen any time).
Wow, that sounds like wonderful work! Would you also kick off a background scan after programming mode is exited? That would be handy to pick up changed configuration as well as state changes that happened during that time in limbo.