I own 6 of the mentioned Eurotronic spirit thermostats - the Z-wave version of them (there is also a Zigbee version). They show erratic behavior to a point where you have to say they just don’t work properly. So, if you’re planning on using them be aware that they might not work as expected (or advertised).
Main issue is the internal logic of the “comfort” mode that is supposed to reach and hold a certain setpoint temperature.
You would expect a thermostat to close the valve once the setpoint temperature is reached and especially if it is already vastly over the setpoint (e.g. 23°C instead of 18°). But the thermostats may only go from 100% to 80% (valve position) and then stay there for hours causing the rooms to overheat massively. I understand that they are not supposed to go to 0% directly on the setpoint to prevent oscillation, but the current behavior is totally useless. Apparently a similar issue occurs in the other direction as well, the valve does not open quick enough, but I’m more concerned with the overheating part.
If I’d have to guess I’d say that they try to optimize for the rooms and wind up with a totally useless control logic and apparently without any fallbacks that turn off the valve if the difference is too big.
Unfortunately, the optimization logic cannot be disabled afaik (like on non-smart Honeywell HR25 thermostats that I used in a previous life).
One way to circumvent the issues is to control the valve position externally, but you’d have to program the logic yourself (or with a PID library). In FHEM, there is such a logic component (“PID20”),
Home assistant seems to have something similar albeit simpler in the Generic Thermostat (Thermostat with PID controller) but it seems to be only suitable for On/Off devices (e.g. air conditioning) not for continuous (0-100% type) values.
I’d rather not go downs this road because then the thermostats are not working autonomously anymore. If HA (or the server controlling the valves) goes down there is no fallback.
I would try it out though to see how good such a solution works.
In case you’re looking to control the valve position manually: HA unfortunately does not expose this currently. But you can enable by following the description in the associated github issue: https://github.com/home-assistant/home-assistant/issues/14526
This will produce cover entities for all thermostats which will have the current valve position and allow modifications (in a specific preset mode).
The other way to circumvent this is to get rid of them and find good ones that have more respect for a setpoint. It is a shame really, the thermostats are really nice otherwise. They look ok have a quiet motor, a quick response and are comparatively cheap.
Do you have similar experiences or do yours just work fine?
in my flat i have installed 5 Zwave Eurotronic Spirit Z thermostats on normal radiators since last year. The one in the bathroom was installed 2 years ago for testing purposes. They are connected to HomeAssistant via an Aeotec Zwave USB stick.
All of the thermostats run application_version 0.16, except the slightly older one in the bathroom which seems to run on 0.15.
I just installed them via the normal Zwave integration process. Although the way the climate component and the nodes offered by the thermostats worked together was somewhat unintuitive in my opinion, i got everything working in my automations.
Here everything is working as it should. I do not have any data from this heating period, since we did not start heating yet, i can’t remember a behaviour as described by you. For a selected “hvac_mode” (off, heat) i just set the target temperature an then the thermostat adjusts itself accordingly. No extreme overheating or otherwise erratic behaviour.
But i do have to admit i don’t really know about the valve positions. Nothing in all settings tells me about the valves, although i slightly remember having read about revealing the valve attributes/postion 2 years ago, when first starting with these thermostats.
On the other hand i can just tell you from my experience last season when staying in the living room / on the couch. The radiator is positioned right beside the sofa so i can hear the device adjusting. On starting to heat up the room, of course the valve opens to heat up and when the target temp is reached it adjusts down to hold the temp, but it doesn’t close completely. And from time to time i can hear a very small adjustment in the valve to compensate the target temperature. So it is neither switching between boost (100%) and off all the time nor is it powering at 15%, as one of your linked articles mentioned.
Maybe you could help me out and tell me what you mean by “comfort” mode?
Summary:
Despite strange entities and logic (climate.furnace, climate.heat, climate.heat_eco and so on) and a change in the offered services somewhere this year (hvac_modes did not exist with this device last year) the thermostats in version 0.15 and 0.16 do what they should do in the way i expect them to do it. Here i do not control valve positions directly but rather go with target temperature and let the thermostat do the rest.
Thanks for your lengthy reply. This is very helpful.
What I’m seeing is different in that it vastly overshoots the setpoint, though.
If you look at the graph below you can see the current temp (delivered from Eurotronic) in red, setpoint in blue and valve position in grey. In the last third you can see that the temperature reaches the setpoint but the valve is not closed. In this example, it remained at 71% for over 3 hours leading to a very hot room.
@jo-me
I understand what you’re trying to show. But for me, I can’t confirm this. I have two of these and the actual temperature is just 0.5° off the target temperature.
As you can see, the blue line is the target temperature. Red should be the actual measured temperature. They are just 0.5° off. I think I could set an offset for this. But since HA changed the way zwave is configured I don’t know how to access these settings.
I am pretty new to home assistant, I got the thermostat to work but fighting with the automations.
Would you be so kind to post an example of your automation with setting the temperature?
I have 8 of these Spririt thermostats operational. I observed that the valves are opening too slow. As a result, the target temperature is not reached or it takes too long before the target temperature is reached. I fixed this by introducing controlling intelligence in home Assistant.
This is done by comparing the current temperature with the target temperature. If difference is large, home assistant increases the target temperature in the Spirit to 28 degrees which result in valve being opened completely. By contionously finetuning the target temperature, I reached exactly the temperature that I want and in the fast possible manner.
I use appdaemon and programmed this in Python. Works quite well.
I would have prefered to command the valves directly, but I do not know if this is possible. By setting a high or low target temperature, I obtained the same result.
I would like to learn about other approaches for this issue if people have similar experience.
I am having the same and few issues with my Spirit TRV.
I have no “cuurent_position” even after enabling the valve reporting.
and few of the TRV sensors are not working; the battery is not reporting and few others as shown in the pic.
even that the battery reporting is enabled; I am an old user of HA, but this is my first run with Z-wave; so I don’t know how to get a configuration file for the device or how to modify it and whether there is custom configuration for this device on the community or not.
Just got couple of these and main issue for me is that when I set them to Off sometimes it’ll not close the valve and radiator is still heating. I found that if I set it to 28C and then off (sometimes I need to repeat On/Off cycle) it will eventually shut the radiator completly. I’m considering sending them back to Amazon if I’m not going to be able to remedy this issue.
@artkrz I have the same issue.
Directly after installation it seems to work fine (when its freshly calibrated) but after a while it loses orientation apparently.
Even with manual valve control setting it to 0% does sometimes not close it completely. The motor turns on but not long enough until the valve is closed (you hear it in the motor noise because it becomes harder to close the last bit) Only after setting the valve to 100% and then back to 0% a couple of time it works.
Same here - the problem seems to occur mainly if the valve is already almost closed (<10% or so) when turning it off, it then seems to get confused how much further to close it. I think I’m going to make an automation that shortly switches it to boost mode before turning off, that seems to help…
Not that happy with it’s temperature regulation anyway, it closes the valve way to quickly before reaching target temp, or doesn’t open it at all (combine that with overshooting if the valve opens because it thinks it closed it but didn’t, as described), even when the wanted temp is 1.5 degrees higher then the current temp measured by the device, so was thinking of regulating it with automation anyway.Good thing is that in case of computer outage it can then still be controlled manually with the buttons, and still have “some” intelligence in temp control
So has anyone built something to work around the overheating issue?
What is even a reliable way to get the thermostat to acknowledge that the setpoint is reached and act accordingly? Turn Off and On? Boost, Off, On?
I was thinking about using a PID controller (there are python implementations in github and even on the forum here) that runs in HA / AppDaemon at first, but I just don’t trust Zwave to deliver all commands reliably. Same goes for the “Boost-to-Turn-off” workaround. If the “off” command is lost the thermostat will stay on “boost” forever.
Even having the logic part in HA is a very bad design choice (single point of failure) but I’m not aware of alternatives solutions (aside from returning /selling the thermostats asap)
Btw. I found Zwave to not be reliable at all - at least in HA - to trust basic node connectivity data let alone reliable command transfer - especially for the nodes not directly communicating with the controller. A custom component would need to keep track of the commands sent and repeat it if necessary (and alert eventually).
No, because boost auto deactivates after (I think) 3 minutes (the manual says 5, but I’m quite sure it’s shorter) - it then returns to it’s previous state. So either boost-off (shortest period of extra heating) or off-boost (but then it stays in boost for 3 minutes) or off-boost-off (most paranoia proof, but extra commands and extra valve activation, so worse for the battery) should work. I haven’t yet implemented this though.
For me z-wave is pretty reliable, so I don’t have too much issues with having the logic in HA. If HA fails, the thermostat will still have it’s own setpoint (and it isn’t so terrible that it will let the room freeze over or get massively hot - it just isn’t good enough maintainig comfort on it’s own) and can then still be controlled manually through it’s buttons if need be.
So, are you doing this boost-off action every day to keep up the calibration?
Does that affect the overshoot issue at all - in other words: does it keep the setpoint better if a daily calibration is happening via boost-off?
