Problems/experiences with Eurotronic Spirit radiator valves


since a few days, I own four Eurotronic Spirit radiator valves. Till now, I am not so happy with them, but I am not sure if the occurring problems are caused by the spirits or are related to OpenHAB. It seems that quiet a few people around here are using them, so I am interested in your experience.

Mine are: With the OpenHAB V2.4.0 snapshot, the core functions like setting temperatures and reading sensor states are working well.

The worst thing is the sometimes relay bad working temperature control. Example: Target temperature is set to 18°C. Temp measured by the spirit is around 21°C. Valve is opened for 50%. Absolute waste of energy. Remarkable is, that two of the devices (which are in the same room) are affected more of the problem than the other two. But for none of them I would say, the temperature control is good.

Other problems are: The output values of the internal temperature sensor often are 1°C to 2°C below the values of other thermometers in the room (except the radiators are hot). This would not be a problem, if the external sensor channel (sensor_report) would work. By default, the item linked to it shows the value of the internal temp sensor. If another value is set either by a rule or via paperUI, the logs show, that the item received the command, but seconds after it restores its default value (external temperature is activated in the things settings).

Same happens, if the mode is set to “Manufacturer Specific”. The item is restoring its previous mode within seconds. Also, some settings seem to be resetted after some time. Yesterday I set the “window open detection sensitivity” to high, today there were back do medium (default).

So, what are your experiences with the device?



1 Like

Hi Alexander,
I made similar experiences with my three Spirit Z-Wave Plus radiator thermostats and openHAB 2.4.0~M4-1.

Sometimes my thermostats behave the same way. In that case setting the thermostat mode to “Off” (0x00) leads to a valve position of 0% as expected. A few seconds later the valve opens to a position of about 20% even the thermostat mode is still “Off”. This strange behavior can be reproduced by setting the thermostat mode to “Off” via Basic UI, Paper UI and minus button of the Spirit and I guess it is caused by the thermostat (no openHab issue).

I have no experience with “external temperature”. Maybe this will help you:

This mode is not supported as you can see in the log

2018-11-03 14:43:51.643 [ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 2: Unsupported mode type 31

2018-11-03 14:43:51.648 [WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 2: Generating message failed for command class = COMMAND_CLASS_THERMOSTAT_MODE, endpoint = 0

I had no issues with the configuration parameters so far. My settings remain.


The “valve open in OFF-state” failure wasn’t observable with my spirits… at least, I am not aware of it. But I might take a closer look on that, sometimes there are valve positions around15% in the middle of the night, but mostly only if temperatures are close to a threshold where the valves are supposed to open.

For dealing with the bad temperature control I created a “three-point controller” via OH rules. For this, I use the average measured temp from the spirits plus an external sensor as reference temperature. If the reference temp drops below a set threshold, the sprits are set to a target temp of 28°C, which should open the valves for 100% in most cases. Above the threshold the spirits are set to the actual target temperature and the spirit’s internal control can do its job. If temperature rises above a second threshold, the spirits are set to OFF-mode and again back to “internal controller mode” when temperatures are dropped below a third threshold, which is in between the first two.

This seems to work well, although lack of low outside temperatures prevented me from testing it in detail.

Thanks for the external-temperatures link. I’ll give it a try.

Since setting my config parameters a third time, this issues are here also gone. Maybe the overnight network-heal did help.



Thanks for sharing your workaround for the “bad temperature control”. Maybe I will implement something similar. Before that, I will continue to observe the behavior of the Spirits by using InfluxDB & Grafana.
Here is a small snapshot of one thermostat.

Regarding external temperature: Latest information is here:


You’re welcome.

Your snapshot looks well to me. Valve is opening when temperature drops under target temp and closing when temperature rises.

External Temperature is still not working for me, using the 2.4.0-snapshot Docker image from last Saturday. I’ll update to the latest image and investigate further next weekend.


How can I read the valve position?

Edit: I found it - it’s the Dimmer value.

With the latest image, external temperature is working fine.

I’ll have to rectify this statement. Yes, by setting target temp to 28°C the valves should open by 100% in most cases. But as the controller is total rubbish, they don’t.

This is the Grafana-Chart from the last hour. If the temperature drops below 20°C (red line), the Spirits are set to 28°C. Actual temperature is around 19°C.

I should not have kept them…


Maybe the thresholds are too close to each other…
Do you still think that your “three-point controller” is needed?
The result of my observation in terms of “bad temperature control” (Spirit heats even when the target temperature is exceeded) is that it occurs about once a week and only for a few minutes.
I have no problem with that.

The thresholds are:
High temp turn off: +0,2°C
Return to self-regulated mode: -0,5°C
Set to 28°C: -1°C

All relative to the target temperature. But I do not see how they should interferer each other. The actual temperature was way below the lowest threshold. Settings in OpenHAB were properly set to 28°C.

In terms of overheating: I observed the behaviour about one day (or a little less, at some point I turned of the Spirits because of high room temperature). The radiators were warm on a mostly constant base, although room temperature was (way) above the set target temp.

Since then I implemented the self-made controller which fixed the problem, so there are no real long-term observations. So yes, I don’t see a way to use the Spirits without additional controlling. At least with my heating system.

Workaround to persuade the spirits to open the valves: Set the external temp to 0°C. Worked for the last hours.


Could you share somehow with your solution. I’m fighting with those regulators and I think I need similar approach it shutting those down completely. Maybe there is no need to invent the wheel again.

The dimmer stats are green in my case. It seems it’s very slowly dropping down but in the same time temperature in the room is still rising (both Xiaomi Aquara and internal one). Setting the dimmer off doesn’t seem to cause dropping the prediction. What I see also is that the dimmer is turned down like 1% every 3-6 min.

Apart from that look at the difference in the readings. I doubt that those regulators can actually work properly without external temperature.


The system contains multiple rulesets. First one is for controlling the target temperature. This is manly done via Outlook and the CalDAV binding in combination with motion sensors to adjust the temperature if someone is present. The so given target temp is stored in the item “SolltemperaturXX” (XX for the respective room).

The second ruleset is for actual temperature regulation. At first there is calculated es mixed temperature from all sensor (two Spirits an external Sensor). I’m not using the average, as the temperature from the external sensor is more weighted than the information from the Spirits. The result is stored in the item “MixedTempXX”

rule "Externe Temperatur für Thermostate erzeugen"
	Member of Temperatur changed
	var Temp_SensorMixXX = MultisensorDachgeschoss_Temperatur.state as Number
	Temp_SensorMixXX = Temp_SensorMixXX * 2
	Temp_SensorMixXX = Temp_SensorMixXX + TH_XX1_TempIST.state as Number
	Temp_SensorMixXX = Temp_SensorMixXX + TH_XX2_TempIST.state as Number
	Temp_SensorMixXX = Temp_SensorMixXX / 4

	MixedTempXX.sendCommand(Temp_SensorMixXX) as Number

And at last the actual temperature regulation. At first the thresholds are defined depending on the item “Heizungssteuerung”. It from the first ruleset and codes scenario information. “3” stands for “resident is absent, but will come soon, so start heating up”. “4” is “resident at home”. Plus, distinction between someone being present in the room or not. The two variables Comparator1 and 2 are upper and limit, where the heating is switched off, and lower limit where the heating is forced to 100% vent opening.

rule "Heizungsregelung XX"
	Item SolltemperaturXX changed or
	Item MixedTempXX changed or
	Item Heizungssteuerung changed or
	Member of MotionPresence changed or
	Time cron "0 */5 * * * ?"
	var PositiveThreshold = 0.2			// Grenze zum abschalten bei Überschreitung Soll-Wert
	var NegativeThreshold = 12.0		// Grenze zum anschalten bei Unterschreitung Soll-Wert

	// Anpassung der Variablen je nach Heizungszustand
	if(Heizungssteuerung.state == 3) {
		PositiveThreshold = 0.2
		NegativeThreshold = 1.0
	if(Heizungssteuerung.state == 4 && AnwesenheitXX.state == OFF) {
		PositiveThreshold = 0.2
		NegativeThreshold = 0.6
	if(Heizungssteuerung.state == 4 && AnwesenheitXX.state == ON) {
		PositiveThreshold = 0.2
		NegativeThreshold = 0.4
	var Comparator1 = SolltemperaturXX.state as Number		//Oberer Grenzwert
	Comparator1 = Comparator1 + PositiveThreshold
	var Comparator2 = SolltemperaturXX.state as Number		//Unterer Grenzwert
	Comparator2 = Comparator2 - NegativeThreshold
	ObererGrenzwertXX.sendCommand(Comparator1) as Number
	UntererGrenzwertXX.sendCommand(Comparator2) as Number

First of the three if-blocks is for the case when the MixedTemp is in between the two comparators. The item “HeizungsmodusXX” is linked of the heating-state-channel off the spirits. “KomforttemperaturXX” is the channel “Setpoint Heat”. So in this mode the actual target temp is given to the spirits and their internal regulation can do it’s job. External Temperature is sending every five minutes (with “TempUpdateXX” the expire-binding is used) or a temp update is forced when coming from another state.

Second if-block is for turning off. External temp is set to 50°C a target temp to 10°C. Additionally there is some kind of “shutdown sequence”, where the spirits are set to “Energy heat state” first, before turning them off. Without this, I had the problem that the valve channel showed 0% opening but was still open for 100%, which was pretty annoying.

Last Block is for forcing 100% valve opening. External temperature is set to 0°C and target temp to 28°C.

	//Heizkörper XX bei Messwert über Hysteresegrenze ausschalten
	if(MixedTempXX.state >= Comparator1) {
		// Externe Temperatur auf 50°C setzen
		if(TH_XX1_ExTemp.state != 50 || TH_XX2_ExTemp.state != 50 || TempUpdateXX.state == ON) {
		// Solltemperatur auf 10°C schalten
		if(TH_XX1_Heat_Hi.state != 10 || TH_XX2_Heat_Hi.state != 10) {
		// Heizung Ausschalten
		if(TH_XX1_Mode.state != 0 || TH_XX2_Mode.state != 0) {
	//Heizkörper XX bei Messwert unter Hysteresegrenze Einschalten und auf 28°C setzen (Vollast)
	if(MixedTempXX.state < Comparator2) {
		//Heizung Einschalten
		if(TH_XX1_Mode.state != 1 || TH_XX2_Mode.state != 1) {
		// Solltemperatur auf 28°C schalten
		if(TH_XX1_Heat_Hi.state != 28 || TH_XX2_Heat_Hi.state != 28) {
		//Externe Temperatur auf 0°C setzen
		if(TH_XX1_ExTemp.state != 0 || TH_XX2_ExTemp.state != 0 || TempUpdateXX.state == ON) {

Hope I could help!



You might want to check out the following post:

Thanks - that seems like a breakthrough with all the problems we have.


there is a special thread for the problem I have with the devices. But probably people watching this one have some input and the subject is quite generic so it still fits.
What are your experiences about temperature reporting from the device. It just does not work for me when it should be initiated by the device. Only when a command is sent it also reports back new values.
Any feedback?

Unrelated to that it seems the device database is not fully correct: (@chris)
as it says “Supports security: No” while in the manual (only found a german one
it mentions to support security and even “for full feature set it requires security”.

The best way to see if the device supports the security class is to look at the list of command classes - if security is listed, then it supports security. The tickbox that you refer to is a different issue at the protocol level.

Thanks for your investigation! Although the solution I posted above is working well here for the last (cold) months, being able to control the valve state directly would be much more elegant.

@Wolfgang_Rosenauer: Have you set “5: Measured Temperature report” to 1? For me this worked.

ah, sorry for the noise

1 Like

@AlexW I had it on 1 for some time, currently on 2 but without any success. Will set to 1 again for now.
So others can really confirm that temperature reports work for you guys? I have no idea why two devices behave the same way and just do not work. I’m on openHAB SNAPSHOT but as outlined in the other thread I do not believe that openHAB has its part in that?