Wiser TRV temperature 'sticks' until restarted

[coffeepowered]

I've noticed that some of my Wiser TRVs sit just under the setpoint for a long time, sometimes seemingly struggling to hit that last 0.5 degree required to turn off and constantly calling for heat despite the room feeling warmer than I expect it to be. When I restart the TRV by taking the batteries out and recalibrating, the temperature is around 2 degrees higher than before the restart and way above the setpoint. (and may have climbed higher if I had not intervened)

For example:

Setpoint 18

TRV temperature 17.5, calling for heat

Take batteries out for ten seconds, replace, hold - symbol for two seconds to rejoin and calibrate

TRV temperature 21.5, stop calling for heat

Does anyone know why this might be the case? I'm not sure how often the TRV measures and reports the temperature back to the app but it doesn't feel right.

TRV Firmware 000ea64

HubR Firmware 3.10.8

App version 6.1.5 (Build 22)

[PhilHornby]

---

@coffeepowered wrote:

I've noticed that some of my Wiser TRVs sit just under the setpoint for a long time, sometimes seemingly struggling to hit that last 0.5 degree required to turn off 

---

It could be there is an innocent explanation for this (though I have no proof for this)...

The 'flame symbol' in the app. seems to indicate that the Setpoint has not yet been reached - but it doesn't necessarily mean that the system is still calling for heat; it shuts off early and expects the room temperature to continue to rise (because of heat still in the radiator). When there is no Roomstat, this algorithm is probably complicated by the corrections that are being made to compensate for the less than ideal positioning of the temperature sensor (next to a radiator).

As for the reported temperature  being higher after the battery swap, this might be just due to its temporary re-positioning, or even just your body heat 🤔

I think you need Roomstats for the rooms you really care about, preferably situated somewhere close to where you spend your time in the room...

[coffeepowered]

> The 'flame symbol' in the app. seems to indicate that the Setpoint has not yet been reached - but it doesn't necessarily mean that the system is still calling for heat;

I guess that's part of my concern as the room temperature has very obviously risen beyond the setpoint but the TRV sometimes doesn't register it, I've moved my only roomstat into one of the affected rooms to see if this resolves the behaviour, though it doesn't help that adding two devices to one room means you're no longer able to see the individual temperatures for each device.

For the other room I noticed this happening, if it happens again I'm going to point a hairdryer at it to see if it registers a change.

Body heat won't be an issue, and I'm not removing or moving the device to pop out a battery and replace. I don't want to have to spend yet more money on roomstats just to make the TRVs behave, maybe they're still figuring things out and will settle over time.

[PhilHornby]

---

@coffeepowered wrote:

though it doesn't help that adding two devices to one room means you're no longer able to see the individual temperatures for each device.

It is still possible, but only via the (undocumented) API, rather than the app.

Body heat won't be an issue, and I'm not removing or moving the device to pop out a battery and replace. I don't want to have to spend yet more money on roomstats just to make the TRVs behave, maybe they're still figuring things out and will settle over time.

---

Perhaps 'popping the batteries out' resets the compensation algorithm? (With the room cold, there won't be a massive difference between the temperature at the side of the radiator and where you're sitting, but it develops into one as the radiator heats - and has to be allowed for by the system).

Even with further development, I'm not convinced they'll ever reach a degree of control that is sufficient for a living space, but I've found them good enough for the Downstairs Loo and such like. There's a nice graph of Roomstat vs two iTRV's (in the same room) in this thread 

(I do appreciate that the costs soon mount up - but apparently, Wiser is a cheaper option than competing systems, when 'fully-specced')

[PhilHornby]

---

@coffeepowered wrote:

When I restart the TRV by taking the batteries out and recalibrating, the temperature is around 2 degrees higher than before the restart and way above the setpoint.

App version 6.1.5 (Build 22)

---

I thought I could test my theory (about the algorithm resetting) by taking the batteries out of one of my iTRVs.

I'm not sure it's proof of the theory, but I did reproduce what you saw :-

BEFORE

{
      "id": 8,
      "MountingOrientation": "Vertical",
      "SetPoint": 210,
      "MeasuredTemperature": 217,
      "PercentageDemand": 71,
      "WindowState": "Closed",
      "ExternalRoomStatTemperature": 208
    },

AFTER

{
      "id": 8,
      "MountingOrientation": "Vertical",
      "SetPoint": 210,
      "MeasuredTemperature": 231,
      "PercentageDemand": 71,
      "WindowState": "Closed",
      "ExternalRoomStatTemperature": 208
    },

Temperature reported (via API) changed from 21.7° to 23.1°

Roomstat (and therefore Room) temperature was unchanged at 20.8°

[SAtewart]

Are any of these parameters user settable via the API? (I'm attempting to do some  background work on using this and interfacing with Python). PercentageDemand seems to indicate that the TRV can drive from fully closed to fully open in 100 steps. That would be a useful parameter to be able to control. I wonder also if there is a horizontal option for MountingOrientation? that could yield better measurement accuracy perhaps.

[PhilHornby]

---

@SAtewart wrote:

Are any of these parameters user settable via the API?

All I know about the API, is that which was documented originally  and stuff I've reverse-engineered from the App. (no doubt in breach of various licence agreements, that I verbally modified 😉 )

If the App can't/doesn't do it, there's no easy way to know if it's possible or not. I've tried some educated guesses, to do things like adding an end-time to a 'Moment' (which failed) and altering Setpoints to a finer granularity than 0.5° (which worked). I think you'd need to capture an image of the firmware to explore deeper (or see if there's a serial debugging interface on the Hubᴿ)

PercentageDemand seems to indicate that the TRV can drive from fully closed to fully open in 100 steps. That would be a useful parameter to be able to control.

I don't think it means that, though I see where you're coming from. To achieve 'analogue' control (or at least finer digital control), it would need a detailed knowledge of the flow characteristics of the valve body. (I understand there can be some major differences between them.)

I think 'PercentageDemand' probably pertains to the 'pseudo proportional control' that is used to control the Boiler On time (or the real proportional control when Opentherm is available). I could be wrong 🙂

I wonder also if there is a horizontal option for MountingOrientation? that could yield better measurement accuracy perhaps.

---

Yes, it would seem logical that horizontally mounted valves would be less affected by the actual radiator heat - but there doesn't (currently) seem to be any way to tell the system about them. It might just be a future planned enhancement.