TRV doesnt reach Temp

[TicT4x]

Prerequisites

• TRVs: Kasa KE100 (via Tapo integration by petretiandrea)

Description

This is the Graph wich shows my Temps in the Bedroom of our Flat. In all 3 Rooms the same Problem, so i just use the Bebroom as an example:

It does not reach the Target 21°C and settles around 19-19,5°C. I realy dont know, if this is a BTT Problem or with the Tapo Integration or the TRV itself but it worked prior to using them in HA. Does anyone has a clue why that is ? Maby something i could try to get rid of the Problem ? I would love to hear back from you.

BTT Settings:

[folfy]

Which version of BT are you running currently? Did you try switching back to v1.6.1?

Without corresponding statistic graphs of your TRV in HA (setpoint temperature, actual temperature of TRV sensor, offset-value and ideally also valve position, if reported), it's hard to say anything about your issue.

[bassie1995]

Hey @folfy, I can try to provide this info in my case. I am also seeing the valves (Tado) slow down to mid-thirties heating percentages while a degree under the setpoint, then never really speed back up to hit it. This happens both in 1.7.0-b1 and 1.6.1, but only in certain rooms.

Two questions:

• I haven't been able to find offset value in HA, where should I find it? I assume this is very important and the rest means little without this graph.
• Is the heating percentage for Tado the valve percentage, or linearly related to it? It seems so, but I have never found an explicit confirmation.

I can elaborate a bit more about the setup here: I think part of this is the fact that the radiators in the rooms this is happening are seemingly underpowered and in badly-isolated rooms.

[folfy]

• Offset value usually would be an attribute/entity of your TRV device, called something like "local calibration" (just check your thermostats device page in ZHA).
• Idk about "heating percentage", but if that's the only percentage your valve provides, I'd assume it's the actual valve setpoint / percentage that we'd wanna know/see also.
  If you need more help, maybe make a screenshot of your thermostats device page in HA.

It very well could be an issue of BT, but usually I know it's over-compensating/heating, but the opposite (you're 1°C under setpoint) is very odd, so that's why I'd love to see what BT actually is commanding to your TRV from the TRV's statistics graphs.

[bassie1995]

Hey @folfy,

A quick screenshot of what I could gather (no offset to be found in anything, I guess that's a Tado thing...). I can see if I can get it working with HomeKit, but then we might lose part of the other data.

BamiCharginStation is the Tado TRV's data, Sleep Room is BT.

Let me know what you think, or need!

[folfy]

Oh, might be that the local calibration attribute is not exposed / visible in the UI with Tapo I guess :/

I'd have to see the corresponding graph for the BT entity as well for that timeframe to rly say more, but on first sight it looks like maybe you're limited by the max. offset that is supported by the entity. I think ZHA limits it to +/-2.5°C, which often isn't enough.

a) Please downlaod/provide the diagnostic data for the affected BT thermostat, so we can say if that's the case (this export is broken in v1.6.1 and 1.7.0b1, so use b2 for this; also b2 has a bug with offset calibration not working, PR #1555 is pending, so you'll want to switch back again after, sry):
diagnostic data
IMPORTANT:
Download and paste the diagnostic data from your Better Thermostat Entity(s) below.
https://www.home-assistant.io/docs/configuration/troubleshooting/#download-diagnostics

b) Try target temperature calibration (this can avoid the limits stated above, ofc assuming that's actually the problem)

[folfy]

See also #1545 (comment) - to be put in FAQ

[folfy]

@KartoffelToby / @wtom RFC
I think we should automatically default to target based mode, if the offset is limited to just +/-2.5°C (i.e. less than lets say at least 5°C)? I dunno how big offset rly is needed for some cases, but if the TRV is somewhere enclosed, even 5°C can be very limiting.

Maybe also again generate a (acknowledgeable) repair indication for proposing switch modes, if we for example detect being bound by the limits too much. I.e. soemthing like offset == - offset max & (t_trv - t_sensor) > 0.2 for more than half an hour -> reached max offset, but trv still reading too high, so probably failing to heat properly over this

[isibizi]

I'm back to version 1.6.1. I use Hama TRVs with the following details:

Zigbee Model: TS0601
Zigbee Manufacturer: _TZE200_h4cgnbzg

After updating to versions 1.7b1, b2, and b3, I experienced issues with some TRVs. In my bedroom, the TRV did not reach the set temperature. Similarly, in my bathroom, the TRV had the same problem and failed to heat up in the morning.

It seems that while the TRVs received the command to turn on, the calibration did not work correctly, preventing the rooms from heating as expected. However, with version 1.6.1, the TRVs work perfectly without any issues.

[isibizi]

TRV's in a group seems that have not this issues, only single TRV's

[folfy]

@isibizi Thanks, but without graphs and debug logs this information isn't rly helping us much. Lacking data from your system, we can't analyze any such issues. I'm still trying to find and fix the most critical issues in b3 atm, so there is still a chance to get things fixed for you.

If you need guidance/info, how to get this data, have a look here

[isibizi]

BT Thermostat

Hama Thermostat MQTT Z2M

[isibizi]

I don't know why, but i can't download the diag, i see an error when i try that.

FYI

I have changed the calibration now to aggresive, previously i had configured AI Time Based . Maybe the other calibration working better

[folfy]

@isibizi Yeah, diagnostic data export is broken in v1.6.1, 1.7.0b1 and b3 unfortunately (and in b2, offset calibration is broken btw, so avoid that one)

Diagnostic data can be neglected for now, but without debug logs (that also match your graphs, meaing you have to enable it before making the screenshots), I have no idea what's going on in your setup.

[isibizi]

That means, i must waiting for an update of BT to download a log? Seems many things are broken after the last updates.

[folfy]

No, debug logging is working fine. Those are beta/test versions, so things might be broken, yeah.

[isibizi]

I hope this screenshots and logs help to find the issue. Badezimmer BT is a single TRV and Wohnzimmer BT is a group of TRVs

home-assistant_better_thermostat_2025-01-17T05-39-34.773Z.log

[bassie1995]

Hey @folfy,

Sorry for the delay, life got busy :(

Sleep Room is a BT entity in my graph here, are you missing anything?

We are using Tado, not Tapo. They are not connected via ZHA, but an integration and otherwise their own network/config. I could technically try HomeKit if needed?

I noticed that with 1.7.0 b1 and b2, don't think I tried b3, I would have them just not turning on at all. I decided to roll back, since that would be another issue, and I am again seeing it not reach target temperature. Though Tado is modulating them below 100% (top graph), BT should be able to use the offset and set temperature to go high enough, right? I've tried multiple combinations of settings (Hybrid/offset-based targets, different calibration methods) and though I have gotten different results, I don't think any have been successful in actually getting these rooms up to the desired temperature.
They are currently set to offset/agressive, both of them, but I don't remember what they were set to before.

For posterity, a new screenshot is included! Let me know if you want me to split/remove things for clarity, show you the other room or just if you need me to try something :)

(Wild idea, by the way, but I could try if needed, is to use the one Tado thermostat I have from them, or another valve possibly, and see what happens when I use a sensor of their making and their ecosystem, removing BT.)

[folfy]

@bassie1995 BT sees a setpoint 3-4°C above the actual measured temperature, even compared to the TRV. So also with the aggressive preset, I'm not sure if the algorithm is supposed to add even more offset to your TRV than it does already, like would have to check the source for it.

Anyway, looking at the end of the graph, your TRV running 100% all the time, I'm not seeing much difference here in the behaviour - Your radiator could run 100% all the time, right from the start of heating, sure, but it's barely gonna have an impact on your room heating up faster anyway. Your problem is letting the room cool down too much and then expecting it to heat up with a tiny radiator within a few hours - BT can't fix that, sry 😅

Linear calibration #1522 might gonna help you, by just adding a static, configurable offset based on t_target - t_sensor, and then you will have your more constant 100% maybe, but otherwise I'm not rly sure what's your problem even / what you're expecting BT to do about it now?

[isibizi]

Hey @folfy do you had the opportunity to check my log?

[folfy]

@isibizi No, it's very time consuming unfortunately to check all the logs. What I can see is that the algorithm in BT would request a new local calibration since 5 AM, but it never gets applied, so the TRV is stuck thinking it's too warm:
2025-01-17 06:36:08.645 DEBUG (MainThread) [custom_components.better_thermostat.calibration] better_thermostat Badezimmer BT: climate.thermostat_badezimmer - new local calibration: 5.0 | external_temp: 19.200000000000003, trv_temp: 20.8, calibration: 2.
So here we would wanna try to change it from +2 to +5 (that's after the setpoint was reduced again, till around 6AM it was trying to set it to -6), but local calibration seems to be stuck at +2 forever.

The last time the update actually got sent to the TRV, was here:
2025-01-16 22:57:43.174 DEBUG (MainThread) [custom_components.better_thermostat.utils.controlling] better_thermostat Badezimmer BT: TO TRV set_local_temperature_calibration: climate.thermostat_badezimmer from: 3.0 to: 2.0
Since then the update loop doesn't trigger anymore for some reason, so clearly looks like a BT bug. Similar problem has been reported for example in #1410.

Unfortunate there are a lot of major bugs like this, and this is yet another one to be added to the #1568 list - Might have to rewrite the whole event handling, it's rly erroneous. Sry, won't have a quick fix for it :/

Update @isibizi: I'll keep tracking and analyzing your issue in #1410 from now on.

[isibizi]

Thank you very much for you for you analysis of this issue. I’m going back now to 1.6.1, on this version the calibration seems right

[folfy]

@bassie1995 @TicT4x Please provide feedback/data about your issue, or we will have to close this ticket. Without sufficient info and logs we can't analyze the cause.

[isibizi]

FYI

I have also the same issue with Wohnzimmer BT Group what is described here #1410 see my log

[bassie1995]

@bassie1995 BT sees a setpoint 3-4°C above the actual measured temperature, even compared to the TRV. So also with the aggressive preset, I'm not sure if the algorithm is supposed to add even more offset to your TRV than it does already, like would have to check the source for it.

Anyway, looking at the end of the graph, your TRV running 100% all the time, I'm not seeing much difference here in the behaviour - Your radiator could run 100% all the time, right from the start of heating, sure, but it's barely gonna have an impact on your room heating up faster anyway. Your problem is letting the room cool down too much and then expecting it to heat up with a tiny radiator within a few hours - BT can't fix that, sry 😅

Linear calibration #1522 might gonna help you, by just adding a static, configurable offset based on t_target - t_sensor, and then you will have your more constant 100% maybe, but otherwise I'm not rly sure what's your problem even / what you're expecting BT to do about it now?

It looks better here, and it is indeed. However, you'll see that it lowers the heating (also in the screenshot earlier) before getting to the target temperature. I think this is what we've been looking at here and though I get that it's a sub-optimal setup, I don't think we are supposed to see the TRV lower the heating percentage when we are so far away. Normally, even when it's warmer outside and the radiator is struggling less, I see the same thing.
In my earlier screenshot, you can see that it was even lowering heating percentage far before the setpoint was ever reached. That would lead me to believe that BT thinks it'll "coast" to the setpoint? But this also happened with a number of combinations of settings, even the "AI" one that I assumed would compensate by learning from the room.

Yesterday, I also encountered the issue of the BT setpoint having changed by itself, but that's not something that happens too much, luckily.

For some reason, 1.7.0 seems to sometimes not turn the TRV on at all, so I can't switch to it now to try that out.

[folfy]

@bassie1995 Sry, I didn't get that the other graph in your screenshots is supposed to be the TRV. Doesn't rly make sense looking at it in the first one, because the setpoint of your TRV is constantly so much lower, which I never saw. I don't have any info which configuration you had used even, so not gonna try to dig too much into that now.

Looking at your last update, things look fine from BT side, I mean it's compensationing as it's supposed to. Dunno if "aggressive" should be more aggressive, would have to check the code, and overall BT could adjust a bit more frequently, but your main problem is your TRV. It closes down the valve while you're still far from it's setpoint, yeah, so what exactly you'd expect BT to do about it?

What might help you in the future is linear calibration #1522 as an alternative, as it's more aggressive (at least at bigger offsets), and I also plan on including a "gain factor", so you can overall adjust the amount of compensation added.

Regarding the setpoint changing, you'd have to enable cilhild lock in BT as a prevention.

1.7.0 has more issues with offset calibration and TRV's not responding to updates, see known issues:

#1410 - Local calibration sometimes stops updating till TRV temperature changes again (if TRV doesn't respond to the changed calibration value, e.g. common bug observed in SONOFF TRV with Z2M)

For any proper analysis, please also include debug logs, see the reporting template how-to's: #1568 (comment)