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.
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 
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.
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.
Max
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.
Hi,
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.
I think the same thing is going here @dinuk - the external temperature is being overwritten by the actual temperature reading. This seems to happen every time the temperature is being refreshed or is getting a new value, no matter what triggered that. It should be fixed when the external temperature-channel becomes read only.
This issue has been fixed.
sensor_report channel should be write only #1054
I did a short test and it worked as expected (openHAB 2.4.0~20181108202519-1 (Build #1417)).
Fantastic! I’ll just have to update openhab now, right?
You are using the snapshot version, right? Then an update should be enough.
Otherwise: ZWave binding updates
It works as well for me now - thanks for your help guys!
I carefully studied this threat - unfortunately it is not working yet. What I did:
Did I miss something?
I think the device has a very bad PID controller algorythm implemented.
I see a fully open value even if the room is hotter the target temperature.
popp radiator controller looks more better. Read somewhere here.
Thanks for the update. That’s a pitty - but helpful information so I don’t spend more time with it.
I also use the Eurotronic Spirit with external temperatures. In principle everything works, however, when I monitor the valve positions I get the impression that the Eurotronic Spirit only uses the integer values of the external temperature.
For example, when I set the target temperature to 21 °C it only starts to react once the temperature goes above 22°C.
Here is example data (target temperature 21°C):
12:24:05.443 [INFO ] [smarthome.event.ItemStateChangedEvent] - temperature_out changed from 22.49 to 22.38
12:24:05.468 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'SensorReport' received command 22.38
12:24:05.476 [INFO ] [arthome.event.ItemStatePredictedEvent] - SensorReport predicted to become 22.38
12:24:05.484 [INFO ] [smarthome.event.ItemStateChangedEvent] - SensorReport changed from 22.49 to 22.38
12:24:05.484 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:d9fe0ed9:node2:sensor_report --> 22.38 [DecimalType]
12:24:05.493 [DEBUG] [ass.ZWaveMultiLevelSensorCommandClass] - NODE 2: Creating new message for command SENSOR_MULTILEVEL_REPORT, Set TEMPERATURE to 22.38 with scale 0
12:24:05.498 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY NOT required on COMMAND_CLASS_SENSOR_MULTILEVEL
12:24:05.504 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 2: Command Class COMMAND_CLASS_SENSOR_MULTILEVEL is NOT required to be secured
12:24:05.509 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Bump transaction 15236 priority from Set to Immediate
12:24:05.513 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Adding to device queue
12:24:05.519 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Added 15236 to queue - size 1
12:24:05.525 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
12:24:05.532 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0D 00 13 02 06 31 05 01 42 08 BE 25 25 24
12:24:05.539 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 31 05 01 42 08 BE 25 25 24
12:24:05.544 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - Message SENT
12:24:05.547 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
Does anyone observe a similar behavior?
@TobiasLemke I am not so far with my SPIRIT to judge its efficiency yet.
It is very interesting observation. This could also explain lower price of the Thermostat on the market in reference to others.
However in this thread I got an answer on how to use external temp. sensor.
I understood. if the External Temp is being provided. SPIRIT does not require any rule to steer the vale and keep the temp in the room.
Correct me if I am wrong, please.