Eurotronic Spirit Thermostats firmware issues

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:

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:
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?

Hello jo-me,

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?

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.