[SOLVED] Eurotronic Spirit Z-Wave Plus & external temperatures

Hey guys,

I got the Eurotronic Spirit Z-Wave Plus and am currently trying to feed it with an external temperature. I am running Openhab 2.4.0 (latest snapshot) and am using a Z-Wave USB-Stick. Inclusion, confiuration and everything else works fine - what I am struggling with is sending it a temperature reading from an external sensor.

I have the temperatures etc. in OH, so now I just want to send them to the thermostat - how do I do that? I have a rule set up a la:

rule "Temperature Living Room"
    // Temperature Change detected //
    // Send Temperature to thermostat //

but I have no clue what command to send here. I tried to change the current value of the channel “External Temperature” but that got reverted almost instantly:

2018-11-03 20:01:55.640 [ome.event.ItemCommandEvent] - Item 'ZWaveNode002SpiritThermostaticValve_ExternalTemperature' received command 25

2018-11-03 20:01:55.647 [nt.ItemStatePredictedEvent] - ZWaveNode002SpiritThermostaticValve_ExternalTemperature predicted to become 25

2018-11-03 20:01:55.655 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_ExternalTemperature changed from 19.02 to 25

2018-11-03 20:01:57.251 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_Dimmer changed from 20 to 21

2018-11-03 20:01:57.373 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_ExternalTemperature changed from 25 to 19.02

What am I doing wrong here?

Happy for suggestions,

I don’t have one of these devices, so I’m really not sure. But, looking at the database, the Current temperature channel looks like the channel to which you should send the temperature?

Doing that has the same result as changing the external temperature - it gets overwritten by the devices reading almost instantly.

The question is really, how I should send the temperature to the device? Doing something like


really does not work - is there a way of using SENSOR_MULTILEVEL to send the readings? The manual states that this is how you do it, I have no idea how to do that though.


Using HABmin, in the config parameters for this node, you would set config parameter 8 to 128.

However, reading this post, it appears that the binding currently doesn’t support sending the temperature to the device.

@chris Is this still the case?

No - I think it’s the “External Temperature”. This is the one that is configured to send the report by the looks of it.

This was tested recently by someone, and it is confirmed as working in the latest snapshot (I had forgotten to merge it previously).

Thanks. Yes, you’re right, I see the code uses the sensor_report channel, which is External Temperature.

He’s running the latest 2.4 snapshot, so it should have this PR.


First set config parameter 8 to 128 using HABmin.

Then send the external sensor temp to the item linked to the sensor_report (External Temperature) channel.

Hey mhilbush and chris,

thank you for the insight - yes, I updated to the latest snapshot yesterday because you mentioned fixing this in another thread.

However, if I send a new temperature to an item linked to sensor_report it behaves like this:

2018-11-04 12:16:06.352 [ome.event.ItemCommandEvent] - Item 'SensorReport' received command 25

2018-11-04 12:16:06.356 [nt.ItemStatePredictedEvent] - SensorReport predicted to become 25

2018-11-04 12:16:06.362 [vent.ItemStateChangedEvent] - SensorReport changed from 20.34 to 25

2018-11-04 12:16:08.055 [vent.ItemStateChangedEvent] - SensorReport changed from 25 to 20.34

I did change the config parameter 8 to 128 beforehand:

2018-11-04 12:16:01.322 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=config_8_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]

I wonder why it’s being so stubborn - any ideas?


For clarification, this is how I send the temperature to the item:

rule "Temperature Living Room"
    Channel "homematic:HG-HM-PBI-4-FM:c29c40e4:OEQ1191875:1#PRESS" triggered SHORT

And this is the item itself:

Number SensorReport "External temperature" {channel="zwave:device:512:node2:sensor_report"}

The item and rule look correct.

I’m not sure why it’s sending the old value. Maybe in response to a command repoll, since it’s about 1.5 seconds later?

@Max_Berger Can you shed some light since you’re familiar with how the device handles the temperature from an external sensor?

The internal temperature sensor seems to still be working - and it’s linked to the external sensor somehow:

2018-11-04 12:42:36.221 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_CurrentTemperature changed from 20.34 °C to 19.63 °C

2018-11-04 12:42:36.231 [vent.ItemStateChangedEvent] - SensorReport changed from 20.34 to 19.63

2018-11-04 12:42:36.235 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_ExternalTemperature changed from 20.34 to 19.63

2018-11-04 12:58:36.210 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_CurrentTemperature changed from 19.63 °C to 19.19 °C

2018-11-04 12:58:36.221 [vent.ItemStateChangedEvent] - SensorReport changed from 19.63 to 19.19

2018-11-04 12:58:36.236 [vent.ItemStateChangedEvent] - ZWaveNode002SpiritThermostaticValve_ExternalTemperature changed from 19.63 to 19.19

Whenever sensor_temperature is changed, sensor_report is also getting set to the same value. I suppose that’s why sensor_report gets reset once I feed it with a different value?

Hi, sorry for not seeing this earlier.

I have my external temperature sensor which reports the temperature to openhab, and from there I pass it on to the spirit zwave to the sensort_report endpoint.

I can also confirm that (almost immediately) after I send the report that the spirit then sends an update.

But: this external temperature (in conjunction with the setting to 128 as indicated above and the recent patch) seems to do the right thing, the valve opens and closes based on the external temperature (this can be verified because the spirit is in a narrow edge and therefore locally has different temperature). So I am happy with the behavior.

My assumption is that the sensor_report I get is still the temperature locally at the spirit, whereas the we sensort_report I set is the the one used for the heating control. Since this is actually what I want I am happy

Hope this makes sense


Hi Max,

do you have a snippet from your logs from when your sensor sends a temperature to the Spirit? I don’t think it stores the temperature correctly internally and the external temperature is overwritten by what the Spirit measures instantly. If I set a way lower external-temperature the valve closes for a second, but when it gets overwritten it goes back to what it did before.

@Flynxify - Can you provide a debug log of what is happening on your system as well please?

Sure, I sent it over.

… what’s weird is that I think @Max_Berger might be onto something. Not that this would be weird in general, I just didn’t expect this to work like this :slight_smile:

I tried sending really low and really high temperatures if the valve state would change - it seems to do that. It might actually be possible that the external temperature you send via sensor-report is being stored internally - the actual value of that channel is getting overwritten constantly though. So this might be behaviour from the binding while it’s doing what it should.

What you sent is not the debug log - it looks like it’s probably the event log.

If it’s working though, then that’s fine.

There is the possibility that the “report” channel is being updated with the devices own internal temperature which could be a bug in the binding - maybe this should be a write only channel that is not updated by the device data.

Oh, sorry about that - yeah that’s my event-log with Z-Wave set to debug-level.

If that channel is read-only for the device then that would solve a lot of issues - there’s no way of querying the current external temperature the device stores. This would be a good fix.

My Spirit behaves the same as @Max_Berger stated.
@chris I can provide a debug log if you want

I think that this channel is just being updated by the main (internal) temperature, and it shouldn’t be. I will update this so that it’s a write only channel and I think that will resolve the issue.

If anyone disagrees, please yell, otherwise I will make this update tomorrow.

I would be fine with the write-only, as said, this is how I treat this channel anyways.

One thing I can add: without the recent patch, my heater was always heating (with 8 set to 128). The internal temperature sensor would report something like 27 degrees, the temp would be set to 20, and the valve would still be open. Once the patch was in, the valve started closing. So I can’t vouch for the absolute correct behavior, bit it does roughly the right thing.

I don’t have the logs available at the moment, but if it helps I can try to dig them out later.


I played around with it a little bit yesterday. My set temperature was 22 and I changed the external temperature to 26 - the valve closed and stayed closed. I set it to 10 and it opened wide and stayed like this as well. So it seems to work - I’m just lacking any kind of long-term experience with it.


Just to add to this thread, I just implemented today similar logic (setting external temperature for a eurotronic TRV). It was all working as expected until I sent an update to the setpoint through, at which point I got:

2018-11-11 18:42:23.835 [ome.event.ItemCommandEvent] - Item ‘TV_Room_TRV_Setpoint’ received command 22

2018-11-11 18:42:23.836 [nt.ItemStatePredictedEvent] - TV_Room_TRV_Setpoint predicted to become 22
2018-11-11 18:42:23.839 [vent.ItemStateChangedEvent] - TV_Room_TRV_Setpoint changed from NULL to 22.0 °C
2018-11-11 18:42:25.467 [vent.ItemStateChangedEvent] - TV_Room_TRV_Temperature changed from NULL to 23.19 °C
2018-11-11 18:42:25.467 [vent.ItemStateChangedEvent] - TV_Room_TRV_External_Temperature changed from 22.22 °C to 23.19

Interpreting the above, when I set the setpoint, the TRV transmitted the current TRV temperature, but also changed the external temperature value to be the same as the TRV’s temperature.

This seems consistent with the reports above but in a slightly different scenario: the TRV is transmitting values for the sensor_report field which are actually for the TRV’s temperature sensor.