@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 
Does that mean the two entities have no operation mode support?
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.
Hmm, never heard about such a thermostat 
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.
Yeah, that makes sense. I’ll look into this further… Thanks
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.
@DamianFlynn Please install it in a virtualenv as so:
sudo apt install python3-venv
python3 -m venv hass
pip3 install --upgrade setuptools wheel homeassistant
And then a second one for appdaemon + heaty:
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 1Sorry, I’m not running HA in docker.
But I installed as follows:
git clone https://github.com/open-zwave/openzwave
cd openzwave
git checkout -b Dev origin/Dev
cd ..
git clone https://github.com/open-zwave/python_openzwave
cd python_openzwave
git checkout v0.4.3
pip install . --upgrade # just to install the dependencies without --install-option
ln -s $(realpath ../openzwave) openzwave
pip install . --upgrade --install-option="--flavor=dev"
You also could, of course, only merge the relevant commits on top of the stable openzwave 1.4 tag if you don’t want to use dev… Works both.
Hi all,
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.
Best regards
Robert
Hi! Any updates on the HADashboard component? PS. Dates in the last 4 updates in changelog are incorrect (hass-apps.readthedocs.io/en/stable/apps/heaty/CHANGELOG.html) - wrong month
@bartaspoz No, no progress on the widgets. I find the widget framework of AppDaemon a bit ugly to develop with… Hence there’s also no due date.
Not with the same setpoint, because on a day like today where it got warmer in the house because of the outside temp (and not the heater), Cool would kick in to cool down to the set point, right?
Here’s what the manual says.
Thermostats with support for fan modes or different operating modes, will be handled like a HVAC device and will also be detected as one. If the thermostat support different operating modes, you will get one thermostat entity for each mode. These can be hidden with settings using the customize setting in the configuration.yaml file.
This describes how mine is working–one entity for each mode–and then hide the one I generally won’t use because of the season. Which is fine for most of the year, but it would be nice to set it once and leave it alone.
@gohassgo I don’t understand what you try to achieve. How would you set the cooling entity in winter?
Well, I guess I’m an idiot. What I needed to do all along was to set the mode to Auto and set both of the set points, like this…
Although I can’t see what’s on the picture (I’m blind), that is how I would have done it