TS0601_thermostat remove not working fixes

[RubenKelevra]

• removes "fix" which leads too high set points and significant overheating of rooms

Motivation:

• Not transparent to the user, why Better Thermostat calculates "wrong" values.
• Does lead to overheating of rooms.

Changes:

Removes not working fix.

Related issue (check one):

• fixes TS0601_thermostat overheats the room exceeding the setpoint. Because better_thermostat sets a too high setpoint #1471
• there is no related issue ticket

Checklist (check one):

• I did not change any code (e.g. documentation changes)
• The code change is tested and works locally.

Test-Hardware list (for code changes)

HA Version: 2024.11.1
Zigbee2MQTT Version: 1.41.0
TRV Hardware: TS0601_thermostat

New device mappings

• I avoided any changes to other device mappings
• There are no changes in climate.py

[KartoffelToby]

Need some more users with a TS0601 to verify that BT works without the device fix, if so the hole fix file can be removed.

[RubenKelevra]

Well it's the TS0601_thermostat, not the TS0601. I'm not sure those devices act the same. Maybe the fix applies just to the TS0601 and not the TS0601_thermostat?

Anyway, with this "fix" applied in setpoint mode the rooms will overheat by around 3.5-4 °C above the setpoint. Without it one room will overheat by 1.6°C and the others by 0.6°C.

This overheating is expected and not a flaw of the thermostat. The reason for this is the delay between the external temperature probe:

The TRV's algorithms are designed to work with a large variety of radiators and room sizes, but they all expect that the temperature probe is close to the radiator.

We basically void this assumption and overwrite the fast reaction of the temperature probe close to the radiator, with a much slower room temperature probe far away from the radiator.

This is what's causing the issue some people are seeing here.

IMHO the current approach may fix individual use cases, but is not a good general fix, as it's too specific.

The better option is to implement my fixed from 3 years ago, which are more generalized and did work in a 200 year old poorly insulated building I've lived in 3 years ago and also work fine in my new home, which is very well insulated with modern radiators.

Let me outline how these work:

Fix one

First we check how the temperature in the room progresses. If the room heats up too quickly, we assume that the radiator is either extremely powerful, or the room very well insulated. In both cases the radiator stores much more energy than the TRV algorithm expects and we give the radiator 15 minutes time to give off the stored heat and let the TRV algorithm again.

Second fix

Around half of the models offer a percentage value of the valve opening, the rest offers a binary valve open or not open value. Both should be enough to do the following:

We check if the temperature is rising, and if that's true and we reach the first measurement within 0.5°C of the setpoint, we turn off the valve. And then restart the TRV again one minute later.

This resets the valve to closed and avoids that the TRV algorithm is too slow in closing the valve and thus pumps too much energy into the room.

This fix is needed because we, as explained above, are tinkering with the fast response the TRV usually gets from the temperature probe next to the radiator.

As this is just applied if we heat up from 0.5°C below the setpoint, this usually just triggers if we heat up from a lower temperature, or from venting the room, where in both cases the TRV usually has trouble doing it's job correctly with our temperature corrections send to them.

However, it usually does not affect the TRV in any way holding the temperature in the room, because the room temperature should not drop 0.5°C below the setpoint, if the TRV is working.

LMK if I should implement those overswing protections instead?

Feel free to describe me how your TRV exactly behaves if you run it by itself - without BT, and I look into that.