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).
There are also people in the OpenHab forum complaining about the same issues: https://community.openhab.org/t/eurotronic-spirit-unsupported-mode-type-31/57265/54
The zigbee variants seem to suffer from the same issue as well:
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?