I spent a little time today reading about the HA platform, and i will admit its very impressive. My two sample Sprit TRV also arrived; and I have taken your advice, and ordered a AeoTec Z-Stick Gen 5 for the PI which i will install the framework on.
I grabbed a spare PI3 and installed the HASS.io image. Not sure if that was the right call or if I should have done a manual install on Raspbian or other similar os. Comments welcome also.
Hardware due next week so I have time to learn the platform before hand
I started looking at the comments in the code (very nice!) and it looks like Heaty will work with my single zwave thermostat that has one climate entity for heating mode and another for cooling mode. Is this correct?
@DamianFlynn I’d use raspbian with a manual HA installation, it’s really simple and from what you’ve written before I’d expect you to appreciate the more control you get with a manual installation, compared to the docker setup on hass.io.
@gohassgo Yes, Heaty works with hass.io, there is a note about it in the Getting started docs, please read that. However, Heaty doesn’t know anything about cooling right now. What happens if you turn both entities (heating and cooling) on together?
@DamianFlynn But wait, do you mean the Eurotronic Spirit Z-Wave thermostats? If yes, you’ll have to install manually, because they aren’t supported by stable openzwave right now.
You can’t–it’s really just a single mode switch on the zwave thermostat with four options: off, heat, cool and auto. Pick any one option at a time.
I think what makes the two entities necessary is that there are two set points on the thermostat, one for heating and one for cooling. If in heating mode, the cooling set point doesn’t do anything. And vice versa, if in cooling mode, the heating set point doesn’t do anything. If in auto mode, it can switch to heat or cool as needed to keep the temp between the two set points.
As it works now in the front end, you need both entities on a card, depending on the weather/time of year. There isn’t support for auto, at least that I’ve been able to figure out. I guess for a front end change to support auto there needs to be some logic behind it, and that’s where I was hoping Heaty would come in
They do have a drop down for operation mode as well as a fan mode drop down.
But if you are in the heating entity and you change mode to cool, you have to then back out and go to the cooling entity if you want to change the cooling set point.
I don’t see the point of having both a cooling and heating setpoint. Why not just a single setpoint and let the thermostat decide how to reach that…
I’d probably configure both entities in Heaty, set opmode_heat: Auto for both and then let Heaty set both entities’s setpoint to always the same temperature. This should work, shouldn’t it?
@DamianFlynn Just switched from openzwave stable + spiritz fixes by tobiasgraf to openzwave Dev branch, with python_openzwave 0.4.3, had to reload and rename all entities again, but so far it seems to work great. Maybe you’ll want to try it yourself when your spirit trv’s arrive.
Good tip
I have not received form Amazon my Z-Stick, but I have sent HASS.io the way of the dodo. Just deployed a clean Raspbian with HA using PIP and also the AppDaemon environment with dashboard. Super simple and nice and clean.
I will install the OpenZWave branch suggested as the primary devices on the protocol will be the spirit TRV. I installed one on a rad and it’s smaller and I personally think tidier looking than Honeywell HR92’s
Next stop is MQTT as this protocol will allow me hook to my existing automation base and also connect my CBus system.
I will install your modular branch of heaty tonight to get aquatinted
Hello @DamianFlynn - I am a newbie heaty user too (though STILL waiting for my plumbing to be fixed @roschi !!).
Just thought I’d mention that I use HA with C-Bus/MQTT - there’s not that many of us - so feel free to message me direct if you are having any set up issues. That said, the online guides are pretty good.
python3 -m venv ad
pip3 install --upgrade setuptools wheel appdaemon==3.0.0b3
That way you prevent possible conflicts in versions of dependencies that both appdaemon and hass use and keep your system-wide python environment clean.
@PianSom Wow, still not working properly? Hope that they get it fixed for you soon!
Hi @roschi,
would you mind sharing your Dockerfile?
I’ve adapted the one from tobiasgraf to use the HA image I normally use but it seems to be quite different. Not even apt-get is available in this one because it seems to be based on Alpine.
This is what I have so far:
FROM homeassistant/raspberrypi2-homeassistant:latest
RUN apk update && apk add git make g++ coreutils linux-headers eudev-dev python3-dev \
&& cd /tmp && git clone https://github.com/OpenZWave/open-zwave.git -b Dev \
&& cd open-zwave && make && make install \
&& ln -s /usr/local/lib64/libopenzwave.so /usr/lib/ \
&& ln -s /usr/local/lib64/libopenzwave.so.1.4 /usr/lib/ \
&& pip3 install --no-cache-dir python_openzwave==0.4.3 --upgrade --no-deps --force-reinstall --install-option="--flavor=shared"
It fails on the last step, though, with:
<command-line>:0:0: note: this is the location of the previous definition
src-lib/libopenzwave/libopenzwave.cpp:551:21: fatal error: ValueID.h: No such file or directory
#include "ValueID.h"
^
compilation terminated.
error: command 'gcc' failed with exit status 1
Since there have been no complaints about the modularized version of Heaty, I now merged it into master and you’ll all have to live with it from next release on.
The heaty-modularization branch no longer exists. Please revert to master when testing.
