[TS0601/SEA801-Zigbee] 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:

Same for the TS0601/SAE801-Zigbee as for the TS0601_thermostat in #1472.

Related issue (check one):

• fixes TS0601_thermostat overheats the room exceeding the setpoint. Because better_thermostat sets a too high setpoint #1471 for TS0601/SEA801-Zigbee
• 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.
• Not tested due to not having this hardware, code however is the same as in TS0601_thermostat remove not working fixes #1472.

Test-Hardware list (for code changes)

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

New device mappings

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

[KartoffelToby]

But thats the hole purpose of the model fixes, because some devices has slower reactions more tolernace etc. in fact i use the SEA801 myself and i haven't any issues at all with overheating or something else since the fixes is implement, before the TRV overheat all the time in calibration mode. I can't say anything about the TS0601 but i think all the fixes and work isn't usless at all

[RubenKelevra]

@KartoffelToby thinking about this a bit. I think we need to formulate some kind of testing procedure for those thermostats. So we can see how they perform without Better Thermostat in some kind of standardized way.

I would suggest the following, based on my testing:

• Select a large room in your home, like a living room or a bedroom.
• Make sure it's at least once in 24 h cycle down to 6 °C outside (coolest time of the day).
• Heat it for one day to 21 °C setpoint, no venting - to make sure the walls are at the same temperature.
• Turn the thermostat off.
• Vent the room down to 16 °C (according to an independent room thermometer - which is far away from the windows), quickly.
• Close the windows.
• Turn the thermostat on again, setpoint again 21 °C.
• Wait 6 hours after the temperature has reached 21 °C in the room (according to an independent room thermometer)
• Then export the graphs for the last 24 hours of:
• • thermostat valve position (if available)
• • hvac_action of the thermostat
• • hvac_modes of the thermostat
• • the room temperature according to the thermostat
• • the room temperature according to the independent room thermometer

Then repeat the same thing for a small room, like a bathroom or a WC.

[KartoffelToby]

@RubenKelevra let us discussed this with a lager group, @wtom @folfy

[wtom]

I'm sorry, but I think it's not going to work.

My Hama thermostats will never reach the 21 degrees without this fix. It would stop at 19 degrees.

Also it all depends also on the boiler temperature and the temperature that actually reaches the heater and the size of the heater itself in comparison to the room.

I have to say, I'm very happy with my setup, the only thing I would also like to add, to have the thermostats a little open, when the room temperature is reached. I tested around with a Homematic IP TRV, but that's overheating too much, because of it's own algorithm. I changed the offset on that based on the room temperature.

[folfy]

@wtom HmIP TRVs work great for me in big and small rooms with the "linear calibration" (I think now part of v1.7.0b2, although parameters for it can't be adjusted yet; no need for overheat protection even):

(small room; the erratic, big and steep jumps above are just me showering / using a space heater to boost the room to 24C and running the dehumidifier after; first heatup slow because the door to the cold living room was open)

(big room; not many eTRVs, so kind of underpowered / very slow to heat up)

So my idea for them would be, to update config flow to default to linear calibration for HmIP / in general make it an option to change the default mode for certain TRVs (in the fixes), and also add more options (as mentioned in PR #1522) for limiting the max. offset applied and having a "scalar" factor for the aggressiveness of our corrections. These could then have reasonable "defaults" for the user (based on the TRV), with a guideline on how to adjust them for smaller/bigger rooms (over-/undercompensating).

The hardcoded "fixes" like for the TS0601 here are not rly a solution in my view. What may work in your room with your temperature sensor, may not work for someone else in a bigger/smaller room, or someone with faster/slower sensors. Looks more like the algorithm needs to be tuned for those devices, or even overall (like the "ai" algorithm just doesn't rly make sense for me for example). Since the fixes itself cannot be changed/disabled, they should only be used for absolutely necessary adjustments, that should apply to almost every usercase.

@KartoffelToby, @RubenKelevra, @wtom Can we maybe have a brief discussion about this / algorithms on Discord at some point? Might be easier.

[KartoffelToby]

I'm open for a Discord discussion :)

I think it depends on the device itself. I have some SEA801, and without the "fix," there will always be overheating or underheating. In my case, the "fix" forces the TRV to really close or open if the target temperature is reached. They have some internal algorithm that doesn't work for me as I think it should, and I know a lot of people have the same problem with this device. That's the reason why I implemented it.

I have heard from others that the TS0601 and other devices have similar problems too.

I'm running mine with the "AI Calibration" mode since a year, and its works great for every room, and i have big and small ones.

[folfy]

@KartoffelToby Hmm, I see, like I'm surprised this "AI" algorithm (without any fixes overriding it's behaviour afterwards) is actually even rly working properly in some case, cause it just doesn't make sense to me at all. Could you maybe please provide me a statistics screenshot of the BT thermostat, TRV thermostat and TRV valve setpoint/position and local-compensation (if available/used) from a few days, just to understand this a bit more and how it is supposed to work? If the algorithm rly makes sense, I'd love to document what it's suppoed to do / how it works, but so far I never saw it rly "working". Thanks!

@wtom Could you provide the same data (as written above in italic) for how it's currently working for you with the fix (and maybe without the fix too, but if it's in AI mode I think it's not necessary and I understand your problem anyway)? I need to see what's working for you, to see how the same behaviour could maybe be modeled in a more generic/understandable manner that can be applied to other usecases as well.

Based on Tobys feedback and what used to be implemented as a fix here, I feel like the "linear compensation" mode (with an even bigger gain maybe) would be more suitable, and also benefit some other TRVs, but before making any clear judgement or decision, I rly need to have more understanding of some "good" behaviour of the existing mode and/or fix. With that I might come up with some "better" idea that could suit you both more than the existing solution(s).

[folfy]

@RubenKelevra You're having a "TS0601_thermostat", and you were/are probably using local calibration mode, right? Because the "fix_local_calibration" in TS0601 and TS0601_thermostat looks messed up in my view, only for SEA801 it seems somewhat reasonable at least. From TS0601:

    if (_cur_external_temp + 0.1) >= _target_temp:
        offset = round(offset + 0.5, 1)
    elif (_cur_external_temp + 0.5) >= _target_temp:
        offset -= 2.5

First part increases the offset (apparent TRV temperature), if we exceeded the target temperature (no more heating), so actually should be helping ya prevent overheating, ok, but the second part is then suddenly drastically lowering it, if it's more than 0.5°C warmer in the room than target (i.e. making the TRV think it's colder, as far as I understand?).

I would assume all these three device models should have the same logic, and also ofc local calibration and target_temp mode should be doing kind of the same thing. As far as I got from @wtom, the TRV won't start heating, if the setpoint isn't at least 2°C above the TRV temperature, so how are things working for you without the fix? Can you provide a graph of the BT thermostat, the TRV thermostat, valve position, and which configuration/modes you're using for BT?

Based on what I got so far, my proposal would be making sure consistently that t_trv_setpoint is at least 2°C above t_trv + offset in the fix (but only more, if it was requested by the algorithm), and if heating is assumed to be requested (if t_trv_setpoint > t_trv + offset). That would be way better than adding a fixed value, which is sometimes 1.5, sometimes 2.5°C. If this still causes problems for you, and your TRV works better without such fix, it'd be really interesting to figure out why first, as clearly this fix is necessary for some.

[RubenKelevra]

You're having a "TS0601_thermostat", and you were/are probably using local calibration mode, right?

Nope I'm using target temperature mode on them. Local calibration seems to mess the TRVs calibration too much.

I'm also used a script to turn off the TRV if the temperature is close to the setpoint and the TRV is not turning off quick enough.

That's for example a big issue in the morning, if the heat was off over night (Nachtabschaltung) and the TRV is stuck for hours on 100% valve to heat up the room and suddenly it gets hot water in the radiator.

But it's also an issue on normal day operation, as it won't react fast enough in some instances.

The code for this is rather simple:

[RubenKelevra]

Here's how how a day with a high setpoint, high heating demand and cutoff of the heat over night looks like:

[RubenKelevra]

And another a lot more messy example with window openings for venting and changing setpoints for better thermostat:

[folfy]

Uff, that looks pretty bad, I mean also the behaviour of the TRV just slowly ramping up all the time... But like what temperatures the TRV climate entity is getting for setpoint and reporting in terms of it's own temperature, during those times? I mean in my view, your TRV should be turned on even more frequently, to avoid cooling down so much in between.

Overall I think the main reason why you wouldn't want the fix applied for your TRV, unlike most others, is the expectation that apparently for you the room temperature never should exceed the setpoint, like do I get this right? I mean, usually control loops are designed to keep the error as small as possible, maintaining a state around the setpoint, not under it. Most ppl expect to have 20°C +/- x in their room, if they set it to 20°C, while you expect it to have a window of [20°C - 2x, 20°C] -> Did you consider just setting your target temperature for example ~half a degree lower, to achieve what you want?

I mean, it looks like you replaced "overswing" with "underswing", essentially shifting the whole oscillation just under the setpoint, but this doesn't rly improve things in my view. If I see what your TRV is seeing in terms of values, and how it's behaving in your setup, we can maybe still improve things slightly, without removing the whole fix for the TRV (unless that data would show that the fix actually rly isn't necessary, but I doubt that).

@wtom Could I maybe also ask you for an example from your TRV / setup for comparison? So BT parameter config, BT climate entity graph, TRV climate and valve setpoint graphs? Would be a great help!

A more general issue:

BT will never have the perfect behaviour for everyone - Some ppl want things to be acting slower, with less open-/close cycles, or even need it to be more graduate (because otherwise their boiler will be cycling more), while others want it to be fast and just maintain the temperature properly. I think some linear tuning knobs (for example a simple control amplification factor k) and a more elaborate guide will be unavoidable, but I'll try my best to get some things set up and done here. If I look at those graphs above, seeing how slow/delayed the TRV acts, this valve might rly need some even more special handling tbh, to get at least somewhat more decent behaviour, if possible (a bad actuator or sensor in the control loop ofc means there's only so much that we can get out of this system, no matter how amazing the algorithm).

[RubenKelevra]

Uff, that looks pretty bad, I mean also the behaviour of the TRV just slowly ramping up all the time...

Well, most of the time this behavior is exactly what I'm expecting. The issue is more, that without the dampening, the TRV will start equally slow to ramp down once the setpoint is exceeded.

So say if the setpoint is 20.0°C it would start ramping down over half an hour if the local temperature reading of 20.1°C is reached.

This obviously does not work if Better Thermostat is used. The reason for this is, that normally the TRV will measure the local temperature close to the radiator and ramp up/down depending on the reading very close to the heat source.

The benefit here is, that it will detect quickly if a lot of heat is pumped into the room, and shut off.

Better Thermostat overrides this assumption by forcing higher and higher setpoints until the room temperature is met.

But as the thermometer is ideally on the other side of the room, away from the heat source, there's no direct coupling between the heat source and the thermometer of the TRV anymore. The TRV can therefor no longer realize quickly, how much heat is actually just put into the radiator.

This will lead to a lot of heat being stored in the radiator before Better Thermostat letting it shut off, and thus it will overheat by 1.5 °C in scenarios where a lot of heat is required.

The Overswing Protection I've added will shut off the valve to the radiator and delays that further heat being pumped into the radiator. Thus allow the heat in the radiator first to radiate to the room, before the TRV is slowly adding more heat.

If you look at my examples, this works extremely well. The temperature will either be steady or just rise for around 0.5 °C after the overswing protection stopped the TRV to add heat.

[RubenKelevra]

Ah and I forgot: The reason the TRV is so slowly opening is simple: There's no defined “percentage” at which the real valve will let water in. On my radiators that's around 20% or so, but on others that may be 5% or 40%.

So the TRV knows that it needs to heat a bit, and slowly opens the valve and waits for a sudden rise in temperature compared to the setpoint, which never comes, because Better Thermostat corrects it away.

[folfy]

Well, most of the time this behavior is exactly what I'm expecting. The issue is more, that without the dampening, the TRV will start equally slow to ramp down once the setpoint is exceeded.

This will lead to a lot of heat being stored in the radiator before Better Thermostat letting it shut off, and thus it will overheat by 1.5 °C in scenarios where a lot of heat is required.

What about using overheat protection instead, how did that look, like even then it overshot by 1.5°C?

I mean, even during the day, looking at your first graph from 2nd of January, you're also still dropping as low as almost 1°C under setpoint, so not rly amazing (not blaming you, more the TRV). Did you consider just using an aggressive way of setting the max / min setpoint temperature, like would that allow you to immediately turn the valve up to max at least? Or is your radiator rly that extremely oversized for your room, that either way your radiator will keep heating up the room by another 1.5°C after it's turned off?

The Overswing Protection I've added will shut off the valve to the radiator and delays that further heat being pumped into the radiator. Thus allow the heat in the radiator first to radiate to the room, before the TRV is slowly adding more heat.

I get the idea, totally makes sense, but this should work either way, no matter if the current fix here is applied or not?

I mean as said, I'd have to see the TRV climate entity graph in comparsion for the timeframe you sent the other graphs, to fully understand the current behaviour in your setup (and idally same from someone else's setup).

Ah and I forgot: The reason the TRV is so slowly opening is simple: There's no defined “percentage” at which the real valve will let water in. On my radiators that's around 20% or so, but on others that may be 5% or 40%.

Yeah I understand that, but it's rly awful behaviour. The TRV would be supposed to learn this setpoint during initial calibration / valve adaption (and optionally also gradually recalibrate during runtime). Like figure out once, and use that value as the initial target setpoint for whenever starting heating, then start your normal regulation loop from there after. The issue is, if the valve would be at least more "dumb", we could implement this easily in BT, but since it tries to be "smart" in a rly dumb way, one would have to compensate for that first. The TRVs fixed "integral only" control-behaviour, together with the valves uncompensated "thershold" level of opening up, acts like a rather big, fixed dead time (delay) from outside, which is one of the worst things to have in a control loop. You can't properly compensate for dead times though, and like getting a loop stable with that is a true pain in the ass. -> TL;DR: It's the reason why regulation with this TRV never will be rly great, as in it will never be as stable, accurate and fast as others. Anyway, that better be discussed on Discord, here I primarily wanna get some insight on how the TRV behaves and reacts to control inputs (TRV climate entity graph), so I can give a proper opinion on if or if not this existing kind of fix in BT is rly "bad" / harmful to the issue.

[RubenKelevra]

What about using overheat protection instead, how did that look, like even then it overshot by 1.5°C?

Makes no difference. The issue is that you need to get ahead of reaching the setpoint to turn it off. Overheat protection will only act once the setpoint in Better Thermostat is reached, which means the valve is open at 100% at the time the setpoint is reached.

So I got a 80°C radiator while the room is at the right temperature.

I mean, even during the day, looking at your first graph from 2nd of January, you're also still dropping as low as almost 1°C under setpoint, so not rly amazing (not blaming you, more the TRV).

Well, I'm pretty sure that's because a different window was open at that time. I grouped all windows and doors (with a delay) into one boolean and use this for each Better Thermostat.

So once the other window was closed the TRV was allowed to ramp up again to keep the temperature in the room at the setpoint.

Nope, I've looked it up, that's the normal swing of the room. So yes, you were correct, the temperature may drop 0.9 °C below the setpoint before the TRV is heating.

But this is likely due to the rounding error (#1475) and the temperature updates not properly processed at some times (#1474), not the TRV itself, as it will happily heat even when 0.5° to the setpoint.

[wtom]

Here is an example from my heating. That's the stronges heater in the house and it's the worse room, because it's in the basement.

I will remove the fixes today, to try if the heating result is similar, because with the "heating power mode", i think it should open the valve enough to get the same result maybe.

[RubenKelevra]

@wtom this may be actually the best room for not seeing any issues. The largest issue with overswing you'll see in a room with the largest heater vs room size
In my case that's the bathroom.

Also note that the better the insulation of the room is, the worse this result will become, as the heating demand is in these case even lower, so a "full" radiator will exceed the setpoint even more.

[folfy]

Here is an example from my heating. That's the stronges heater in the house and it's the worse room, because it's in the basement.

That looks good, but yeah, seems to be a way bigger room (thermal mass wise), and that's probably the main reason. Tbh, it looks a lot like what my simple proportional controller does (and would/should do in your casse as well, if the "add 2°C when heating" fix here is left in place). I wonder if the boost in the beginning actually is rly offsetting / changing the TRV behaviour -> @wtom Could you add a screen of the valve position as well pls?

[wtom]

The Hama device doesn't show any value position.

[folfy]

In my case that's the bathroom.

I mean even I can get my room to overshoot the target, and no algorithm in the world can prevent it, unless I'd limit the heating power of my radiator (even though demand is high):

You see I'm .5°C below setpoint with essentially full power, because the hallway is cold and the door is fully open. I close it, it takes ~4min for the temparture sensor to pick up the rise and 2min more for the TRV to report it's off. I still reach 22.1°C within half an hour, it's unavoidable - Even improving upon those 6min (that's ofc possible), it still won't rly save much, maybe it'd be "just" 21.9°C, but the root issue stays, as you say it's a simple matter of thermal mass.

So for your scenario, what your autoamtion is doing is exactly this, like unless the t_delta is 0.6°C or above, it will limit your radiators power artificially (considering the quirks of the TRV). I stand behind what I said before, to judge if this fix here rly is a problem in your case, we would have to see at least the matching TRV graphs (to determine it's regulation model/behaviour). I mean are you rly sure the fix is a problem in combination with your automation applied, or how big is the difference even in regulation accuracy in your room?

What's rather certain in my view - Most scenarios (users / rooms) for sure will benefit from the fix (although they will need to be corrected, because currently offset mode works very differently, and also the three device fixes are not even fully identically).

The Hama device doesn't show any value position.

Ohhhh, damn, oki, still thanks, that would have been rly interesting 😐

[wtom]

As expected, some rooms don't reach the target temperature anymore. But i have to say, it's not as bad as i was thinking, some rooms are 0.2 degrees below the target temperature. I think this might get even fixed, when the heating power gets corrected over time and it's putting more "power" into each 0.1 degree in the calculation. I will keep testing.

[folfy]

@wtom You're testing without the fix? I'd still rather see @RubenKelevra's problematic case with the fix, to see what's so bad about it. I mean I get his issue with the small room, but that should be there almost the same either way, with or without fix. 😅

Overall, sure the algorithm can (partially) compensate for the error introduced by the TRV. This never will be working as good as actually properly, statically compensating for this though. Static loops like PID will always have a bigger residual control error due to this, while adaptive models like your "AI" calibration might be able to partially compensate for this.

In my opinion, let the fix "fix" (i.e. correct as a good as possible) for the TRV's error model, and then instead improve the algorithm as needed, to work better with small rooms overall.

[wtom]

@folfy Yes, but what would be good is to add something like this:
temperature += 2.0 - (temperature - cur_trv_temp)
So it's not always adding 2.0 to the already higher temperature, but just the maximum of 2.0 if the difference is below 2.0.

I will test it on the weekend, i just added this to my local setup.

[folfy]

@wtom I'm aware of that issue, already started implementing this yesterday, as in:

• just add an offset to get up to 2°C above at least (similar to you)
• considering rounding
• having unified all three quirk fixes in one file

Your code always limits the offset to a fixed 2°C, as in, if the algorithm requests +3°C, you would still set it to 2°C, so you need to use e.g. min like I did. Actually your proposal is temperature = 2 + cur_trv_temp (just reducing redundant terms).

Just been still thinking about offset calibration mode, and how to correctly implementing that, so not done with that part yet. But if you wanna test it already, I could push my branch here later on or tomorrow morning. So don't bother with fixing this from scratch now :D