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.
@TobiasLemke to be frank I don’t have any monitoring set up to graph the valve positions; if true, however, that’d be a bit of an issue. Do you think it could have something to do with “Measured Temperature report”?
@wiewior the thermostat doesn’t need any rule to steer the valve in the first place if you give it target temperatures. Am I misunderstanding you?
This is exact my understanding. No additional rules required to trigger or correct the valve.
@wiewior @Flynxify I just checked, somehow I don’t have the problem I described above anymore. I didn’t change anything in my setup so maybe it was fixed in some update of openHAB.
Yes I see the same issue. Have you been able to change the scale to 2 yet?