Add offset criteria for self-regulation when in over_climate which underlying that have a temperature sensor

[ikoz]

Version of the custom_component

5.2.2

Configuration

hvac_modes:
  - auto
  - heat
  - "off"
min_temp: 7
max_temp: 35
target_temp_step: 0.5
preset_modes:
  - none
  - frost
current_temperature: 17.5
temperature: 19.2
hvac_action: idle
preset_mode: none
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: false
last_central_mode: null
frost_temp: 5
eco_temp: 0
boost_temp: 0
comfort_temp: 0
frost_away_temp: 7
eco_away_temp: 7
boost_away_temp: 7
comfort_away_temp: 7
power_temp: null
target_temperature_step: 0.5
ext_current_temperature: -3.31
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: none
saved_target_temp: 19.2
saved_hvac_mode: null
window_state: "off"
motion_state: null
overpowering_state: null
presence_state: null
window_auto_state: "off"
window_bypass_state: false
security_delay_min: 60
security_min_on_percent: 0.5
security_default_on_percent: 0.1
last_temperature_datetime: "2024-01-18T09:23:38.671679+00:00"
last_ext_temperature_datetime: "2024-01-18T09:15:23.759238+00:00"
security_state: false
minimal_activation_delay_sec: 10
device_power: 1
mean_cycle_power: null
total_energy: 0.13
last_update_datetime: "2024-01-18T09:23:38.676592+00:00"
timezone: Europe/London
window_sensor_entity_id: null
window_delay_sec: null
window_auto_enabled: false
window_auto_open_threshold: null
window_auto_close_threshold: null
window_auto_max_duration: null
motion_sensor_entity_id: null
presence_sensor_entity_id: null
power_sensor_entity_id: null
max_power_sensor_entity_id: null
temperature_unit: °C
is_device_active: false
ema_temp: 17.45
is_over_climate: true
start_hvac_action_date: null
underlying_climate_0: climate.wiser_dinning_room
underlying_climate_1: null
underlying_climate_2: null
underlying_climate_3: null
is_regulated: true
regulated_target_temperature: 22.1
auto_regulation_mode: auto_regulation_strong
regulation_accumulated_error: 28.109999999999992
auto_fan_mode: auto_fan_none
current_auto_fan_mode: auto_fan_none
auto_activated_fan_mode: null
auto_deactivated_fan_mode: null
friendly_name: Dinning Room Thermostat
supported_features: 17

If it is releveant to regulation performance or optimisation some curves are needed

I'm attaching the following picture to show the problem. In this plot:

• PURPLE line: My desired target temperature (this has been set as target temperature in VTech climate entity)
• DARK BLUE line: The accurate temperature of the room (external zigbee sensor). This is the sensor set in VTech as external sensor.
• LIGHT BLUE line : The internal TRV temperature sensor - takeng from the TRV climate entity.
• ORANGE line: The TRV setpoint, configured by VTech (regulated temperature).
• DARK ORANGE vertical bars: the duration where the TRV was open and heating

Describe the bug

I'm was trying to heat the room to 17.2C and then 19.2C (from 6:30AM onwards) (purple line - vtech entity target temperature) The real temperature of the room dropped below 17.2C around 3:00AM. (dark blue line) You can see in the graph that around 3:00AM, Vtech started raising the TRV setpoint (regulated temperature - orange line).

However, the TRV did not actually open to let heat into the room, because the internal TRV temperature (light blue line) was higher than the regulated TRV setpoint (orange line) - or it jumped to immediately be higher after heating for a few minutes.

Then I raised the target temperature to 19.2C around 6.30AM. The same thing happened.

So Vtech has been trying to heat the room since 3.00AM and it is now 10AM and the room has not been heated, because the TRV has not actually opened for more than a few short bursts that each lasts a few minutes (vertical bars). These short bursts are also happening at "low demand %", since the demand % is the difference between regulated temperature setpoint and internal trv temperature. This is important, because I am using opentherm: Low demand % means low flow temperature, meaning very slow heating response.

I believe the Vtech self-regulation algorthm should take into account the internal TRV temperature of the climate entity, and calculate an "offset" based on the current value of the internal TRV temperature, so that the regulated temperature is above the internal TRV temperature, and the TRV lets water to flow.

For example I'd expect that if real room temperature is 16C, target temperature is 19C and internal trv temperature is 22C, then Vtech should set the regulated temperature to 25C (a lot higher than 22C, since 19C target is much higher than the 16C real temperature)

Let me know if you need a debug log, but it is fairly obvious what is happening here. VTech calculates the regulated temperature based on external room sensor, completely ignoring the internal TRV sensor. Even in 'hard' self-regulation mode, it cannot work. I am not sure it would work in expert mode either.

[jmcollin78]

Hello,

First thing, many thanks for respecting the template. I have all information in one post. This is great.

2nd thing, I guess VTech is VTherm in your post.

So I see you have an over_climate with Strong regulation activated and the target temperature is not reach. We can see that self-regulation works (the setpoint of the TRV is above the target temp) but this is not enough because the internal temp of the TRV is reacting very quickly and turns off the valve.

If I am right in this analysis, the solution is too have more self-regulation. What we want is that is interal temp of the TRV don't turn off. This can be done by sending a higher target, which is done by self-regulation algorithm.

Because you are already in Strong regulation mode, you should configure the expert mode (cf. readme) and add configuration like that in your configuration.yaml file:

versatile_thermostat:
     auto_regulation_expert:
         kp: 0.5
         ki: 0.08
         k_ext: 0.0
         offset_max: 10
         stabilization_threshold: 0.1
         accumulated_error_threshold: 70

I suggest to augment the kp (try 0.1 step) and offset_max to 10 and accumulated_error_threshold to 70.

I believe the Vtech self-regulation algorthm should take into account the internal TRV temperature of the climate entity, and calculate an "offset" based on the current value of the internal TRV temperature, so that the regulated temperature is above the internal TRV temperature, and the TRV lets water to flow.

Many people asks for this and if I understand this is the way BetterThermostat works. I continue to believe that self-regulation should do the trick because it does exactly the same (increase the target setpoint) but dynamically.

Try this and let me know.

EDIT: please read this also: https://github.com/jmcollin78/versatile_thermostat/blob/feature_234-add_central_boiler_helper/README.md#the-radiator-heats-up-even-though-the-setpoint-temperature-is-exceeded-or-does-not-heat-up-even-though-the-room-temperature-is-well-below-the-setpoint

[ikoz]

@jmcollin78 Thank you very much for the detailed response. Yes I meant VTherm! I am testing out expert mode now to see how it responds to my TRVs. So far from testing it looks like VTech eventually gets there and can heat the room but the response is very slow (more than 30 minutes until TRV opens for more than a minute). VTech keeps increasing the regulated temperature by small amount at the start, but the internal trv temperature also increases so the TRV closes and the room temperature does not increase. I'll try with higher kp so that it responds more quickly.

Many people asks for this and if I understand this is the way BetterThermostat works. I continue to believe that self-regulation should do the trick because it does exactly the same (increase the target setpoint) but dynamically.

I understand this point, yes it should eventually work.

However I am worried about the response time; the TRV internal temp jumps too quickly in response to heat and I wonder if there's a way to account for it in the PI algorithm, e.g. to add an extra offset parameter similar to k_ext for external temperature, so that the regulated setpoint increases further to account for the trv internal temperature.

Another way to go would be to let the algorithm check if the underlying thermostat is indeed 'heating' when VTherm is supposed to be heating. If VTherm calls for heat but the underlying algorithm does not call for heat, then perhaps an extra offset can be added, to respond more quickly. I think _async_climate_changed() tries to do something similar.

[jmcollin78]

k_ext for external temperature

k_ext mean outdoor here. But I agree that the temperature raise can be slow since to have to wait for the cumulated_error to take the precedence. It's seems a good idea to speed up the algo using the delta between external and internal temperature. I will study that for the future.

If you want to give it a try with a PR we can try that and I will help you. This is not very difficult to implement. It is more complex for testing this. And because you have TRV, you will be able to test it on a real env unlike me.

[michielbeijer]

Also interested in this solution. Had the same issues as Ikoz, and "fixed" these by setting up my VTherm as a switch and setting the TRV to 16C (switch is off) or 30C (switch is on). This way the TRV doesn't close because the local temperature maxes out at 28C or something (it's in a small closet where the heat exchanger for the underfloor heating is). Temperature in the house is very stable, but my TRV switches on/off very often (drains the batteries) and I'm not sure whether the boiler likes this behaviour (and whether it is energy efficient).

[jmcollin78]

Hello @michielbeijer, @ikoz, @maia

I have release an alpha release to test the algorithm with the improvement. The release is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/5.4.0.alpha3

What I do is:

1. calculate a device offet as device internal temp - room temp,
2. add this offset each time, VTherm sends a new temperature on the device.

So, the regulation should very quick depending of the offset and progressively will be refined at each cycle with the cumulated_error (the PI algorithm). On the paper, it will work, but I need more feedback to be sure. I have only one heat pump in a small room to test.

Please give me regulation graphs as feedback (before and after if possible). Plotly is a wonderful for this if you want. See in the README to install and configure it.

I forgot to mention that you have to select the "use device temperature" into the configuration of the VTherm (in the self-regulation configuration section). If something goes wrong, just unselect the option and everything should go as usual.

Thank you in advance for your help !

[jmcollin78]

Hello, you have a pre-release that is working with my heat pump : https://github.com/jmcollin78/versatile_thermostat/releases/tag/5.4.0.alpha5

With my heat pump, the internal temperature is growing very fast when it is on. So the offset between my device and the room temperature can grow up rapidly (+10° in 5 min). So this can lead to heavy regulation +10° when this occurs. Considering the algorithm this is normal, but in my case (heat pump) this is not expected.

I would like someone have a test for TRV which would be much more significant I guess.

See the post just above for the instructions.

[ikoz]

@jmcollin78 So far, with some tuning, expert mode generally worked, although the control was not great (either overshoot due to large error accumulation or too slow to heat). I've pulled the alpha5 version and testing it.

[michielbeijer]

Changed the VTherm back to 'over_climate' with the old software and got some data to compare (it put the TRV in idle mode when the internal temperature got to 25C). Now running the new alpha5 software and immediately it set the TRV to 27.6C (internal temperature of the TRV is 25.1C now). Room temperature is 20.2C and target set at 20.5C.

It will be interesting to see how it holds and heats during the night. It's not really cold here at the moment (+2C).

[jmcollin78]

It works fine with my heat pump despite the fact that the internal temp sensor increase rapidly to 30°. When the target is reach I stop considering the offset. Then I don't have anymore the high overshoot I've got earlier:

I switch to target=19° at 9h29:

Note: the blue line decreasing to 13° is due to overpowering (it is cold today and many heaters are fully heating)

[jmcollin78]

Just now, the regulation turns on and because internal temp was 26°, this set the target to 26,2 ° which is forcing a heating period. So that is what is expected (but can seems weird because the target is 19°). Threre is some logs showing that, if you need to have a look:

VersatileThermostat-Thermostat chambre - Regulated temp have changed to 19.0. Resend it to underlyings
VersatileThermostat-Thermostat chambre - The device offset temp for regulation is 7.20 - internal temp is 26.00. New target is 26.20

then the heat pump starts:

[jmcollin78]

One important thing:

the set-point temperature send to the device is no more the "regulated temperature" but the "regulated temperature + offset"

This is done end device by end device. Supposed you have a VTherm connected to 3 TRV: the target set-point will be different for each TRV depending of its internal temperature sensor.

This can be confusing and there is no possibilities in VTherm to get each TRV target set-point. I don't have entities for each underlying TRV.

So the only way to get the target set-point is to look in the underlying climate of each TRV.

[maia]

Installing it now. I assume beta2 is newer than alpha5?

[jmcollin78]

Installing it now. I assume beta2 is newer than alpha5?

No. Alpha 5 is another branch. This is confusing but I have many update in //.

[ikoz]

@jmcollin78 i'm facing an issue that i'm not sure if related to the alpha5 version - i think it is. Here i'm using alpha5 and expert mode. Look at this plot:

• light blue line: internal TRV temperature
• dark blue line: real room temperature
• purple line: my setpoint on VTherm
• orange line: the calculated TRV setpoint by VTherm
• vertical orange bar: when heating turned on and off at 6.10am

You can see in this chart that

• VTherm setpoint changed from 16C to 18C at 11pm. At that point both the real room temperature and the internal TRV temperature were higher than the setpoint.
• You see that while real temperature is higher than vtherm setpoint, vtherm drops the TRV setpoint gradually, corresponding to changes in the internal TRV room temperature.
• At some point the TRV setpoint drops to 12C
• At about 3am, the real room temperature fell under the vtherm setpoint
• At that point, Vtherm started raising the TRV setpoint. But it is raising it from 12C !
• It took 3 hours for Vtherm to raise the TRV setpoint enough (from 12C to above the trv internal temperature) so that the TRV turns on and lets some heat in
• You see that once TRV turned on, the internal TRV room temperature jumped widely, and the TRV turned off again.
• Vtherm continued to raise the setpoint - later in the day it managed to keep the TRV on for sufficient time. - after the vtherm setpoint was raised even more

I think that when VTherm needs to call for heat, it should set the TRV setpoint above the internal TRV temperature (instead of raising from the current calculated TRV setpoint), so that heating starts straight away.

[jmcollin78]

@ikoz,

(I will separate into 2 discussions, because there is 2 points in your post)

First point:

• It took 3 hours for Vtherm to raise the TRV setpoint enough so that the TRV turns on and lets some heat in

This is not related to alpha release and is "normal" (ie conform with what is implemented in the algorithm). You have accumulated what is called accumulated_error which is I part of the PI algorithm. That is why the target setpoint is going down. And because you are in strong regulation mode, the target can be 5° under the target (17° - 5° = 12°). This accumulated_error is resetted upon target temperature changes but not in continuous operation. I agree with you that this is not totally satisfiying. Initially I reset the accumulated_error when the target is reach but this have been removed. I need to have a though on was can be done for this point. If someone have an idea, I will take it.

I think that when VTherm needs to call for heat, it should set the TRV setpoint above the internal TRV temperature (instead of raising from the current calculated TRV setpoint), so that heating starts straight away.

This is a good proposition.

[maia]

@jmcollin78 Thanks, I'm testing the new option in 4 rooms now. Meanwhile I realised that the prior version (5.3.3) I was using until 15 minutes ago has an issue with temperature regulation, as any change in the target temperature resets the regulated temperature. See this room, which is always warmer than necessary (because that's where the boiler is), see the blue line. At 22:00 the target temperature (purple line) was lowered by 1°C, and at that moment the regulated temperature (light blue line) which was already down at 16°C jumped up, reset to the new target temperature, causing the valve to open a bit and start heating, even though the change reduced the target temperature:

I'm going to report how the alpha5 works in a few hours.

EDIT: I'm using the expert mode with the following settings:

versatile_thermostat:
  auto_regulation_expert:
    kp: 0.1 # 10% of the current internal regulation offset are caused by the current difference of target temperature and room temperature
    ki: 0.003125 # 0.9 / 288.0 = 90% of the current internal regulation offset are caused by the average offset of the past 24 hours
    k_ext: 0 # disable for now
    offset_max: 4.0 # limit to a final offset of -4°C to +4°C
    stabilization_threshold: 0.0 # this needs to be disabled as otherwise the long term accumulated error will always be reset when the temp briefly crosses from/to below/above the target
    accumulated_error_threshold: 1152 # 3.0 * 288 = this allows up to 4°C long term offset in both directions
  short_ema_params:
    max_alpha: 0.13
    halflife_sec: 300
    precision: 2

[jmcollin78]

@ikoz

This is the second point:

• Vtherm continued to raise the setpoint - later in the day it managed to keep the TRV on for sufficient time. - after the vtherm setpoint was raised even more

This is the alpha4 improvement which shows it is working for me. Is that an issue for you or you are just reporting the fact it is working ?

What is important here is to verify that after the target has been reach, the heating stops and the offset goes to 0.

[jmcollin78]

as any change in the target temperature resets the regulated temperature

Yes. This is exactly what I explain above to @ikoz: when the target change, the accumulated_error is reseted. This is normal and logical: the error is the difference between target et current temp. If you change the target, the error is no more valid. Else we will have what is described by @ikoz: when target change, the heating take 3 hours to occurs (waiting for the accumulated error to decrease). You the exact opposite requirement as @ikoz in fact. 😉

I hope this will be fixed by the alpha4 release. The offset should be negative and then the heating should not occurs. This is a very interesting thing to observe.

[maia]

Hmm, I'm trying to view from a logical standpoint and not the code: If a room has been warmer than I want it to be for hours and if I then decrease the target temperature even more, I do not want the heater to start. That's not intuitive. And I thought that setting stabilization_threshold to 0 will disable that reset of the accumulated error.

Maybe that's exactly the issue between "regulated temperature" which has a short term goal and you programmed it for heaters that can change a room temperature within minutes and my issue of the TRV internal temperature (which controls the valve) differs from the room temperature over longer periods of hours and days.

Maybe I should disable the "regulated" temperature feature and only use your new feature of the difference between room temperature and TRV temperature.

[maia]

I cannot understand the reasoning for resetting accumulated_error in the other direction too. Imagine a room that is colder than the target temperature for hours. VTherm notices that and slowly increases the regulated temp. Now someone in the room thinks it's too cold and changes the preset from "eco" to "boost". By your logic, the accumulated_error would reset, the regulated temperature would drop and the valve would close – even though the goal with the preset change is to increase the temperature.

Probably you should only reset the accumulated_error if the new target temperature is "on the other side" of the room temperature (if it was too cold but with the new target temperature it's too warm). That's the only time it might be logical.

[ikoz]

I can see two different problems that I believe should be fixed somehow:

1. When Vtherm calls for heat (because the real room temperature drops below the vtherm setpoint), then VTherm should reset the TRV setpoint to be at least equal to TRV internal temperature, then apply any offsets needed. If that is not done, we have a very long delay where Vtherm calls for heat but TRV is not heating at all, for several hours. This may mean reseting the accumulated error. Trying to slowly raise the setpoint from 12C to 18C+ is very slow even with expert/hard modes and alpha5.

2. In the graph below you see in more detail what happened when TRV setpoint finally reached the internal TRV temperature: Heating started at 6.10am and stopped at 6.11am. It run for only 1 minute. The Internal TRV room temperature jumped from 17C to 19C due to this 1 minute of heat. However the room temperature did not move at all obviously. Vtherm setpoint did not "jump" - it continued to increase slowly.

   

[jmcollin78]

That's not intuitive

Yes. But if you look at the curve the internal TRV temp was UNDER the target. So from a TRV point of view, it should heat. This only thing that prevent him to heat is the regulation which lower the target. And because is regulation is resetted when the target change, it does this (which is not, I agree, totally satisfying also).

I don't see you have set the stabilization_threshold to 0. stabilization_threshold is not more used. It was used to reset the accumulated_error when target is reach but have been removed during our tests. So putting it to 0, doesn't do anything yet. The accumulated_error is now reseted only when the target change.

If I want to fix @ikoz issue, I will have to re-implement this or something like that, so keep your stabilization_threshold to 0.

[maia]

@jmcollin78 Let's re-analyse this screenshot:

1. The room temperature is always higher than the target. So the TRV should never heat.
2. The regulated temperature was 4° below the target temperature for that reason.
3. At 22:00 the target temperature is lowered by 1°C.
4. VTherm should say "oh, it was too warm in the room before and now you want it even colder? I'm going to decrease the regulated temperature even more."
5. But what it does instead is to reset the regulated temperature.
6. The TRV knows (Eve says, their TRVs "learn" by AI, I think its a simpler algo) that if the TRV temp and the target temp are close to each other (0,5°C), it's good to set the valve to e.g. 20%, so it opens the valve.
7. The TRV internal temperature rises, as the heater starts heating.
8. The room temperature rises. Although I wanted it colder in the room, not warmer.

[jmcollin78]

2. In the graph below you see in more detail what happened when TRV setpoint finally reached the internal TRV temperature: Heating started at 6.10am and stopped at 6.11am. It run for only 1 minute. The Internal TRV room temperature jumped from 17C to 19C due to this 1 minute of heat. However the room temperature did not move at all obviously. Vtherm setpoint did not "jump" - it continued to increase slowly.

This looks like not normal. How did you configure the regulation parameters and delay in this VTherm ? Please give me a screen copy of the end of the second page like this:

[ikoz]

@jmcollin78

I've set 1 minute period so that response is quicker. This also accumulates errors faster of course.

I'm also attaching the same graph as above, but this time without the internal TRV setpoint and room temperature. This is just the VTech climate entity, to make the first issue more clear. In the circled period (lasting 3 hours), TRV should be heating (at least for some periods), since the real room temperature was below the vtech setpoint.

[jmcollin78]

@maia, @ikoz I clearly understand the problem and I agree this is not satisfying. When the error sign change (the temp target or room temp change) I should do something with the previous accumulated_error.

I ask ChatGPT and here are its response to this problem (I am always surprise of the relevance of its response):

The choice of strategy depends on the specific nature of your system and your preferences for control behavior. However, here are some tips that might help you make a decision:

Anti-Windup:

Anti-windup is a common technique to mitigate integral error accumulation problems. It ensures that the integral error does not continue to grow when the output is saturated. This can be particularly useful if your system has strict physical limits on output.
Integral error reset:

Resetting the integral error when the proportional error changes sign can be effective in quickly reducing the integral error accumulation when there is a temperature reversal. This can help respond more quickly to changing conditions.
Progressive readjustment of the integral error:

Gradually reducing the integral error as the proportional error changes sign can be a balanced approach. This makes it possible to maintain a certain memory of the past without causing long delays during sudden changes.
To start, you could experiment with anti-windup, as it is a well-established technique. If this doesn't give the results you want or you want to further refine the behavior, then you might consider adding integral error reset or graceful readjustment.

Remember to test each modification under a variety of conditions to ensure the system performs robustly. Based on feedback, you can further adjust your approach if necessary.

I don't know what you are thinking about those responses but the second or the third are particularly relevant I think.

I will try the "gradually reducing the integral error" with a factor if the sign of error have change. This should accelerate drastically the time to revert the integral error (@ikoz issue) but avoid to reset the error which causes the @maia issue.

Then I will implement something like:

Progressive readjustment of the integral error: Add logic to gradually reduce the integral component when the proportional error (error) changes sign. This can be achieved by reducing the integral error accumulation by a fraction in each iteration.

self.accumulated_error *= self.integration_decay_factor
Here, self.integration_decay_factor is a value between 0 and 1 that controls the decay.

[ikoz]

@jmcollin78 Resetting accumulated (integral) error when the proportional changes sign seems like it should work.

By the way - it looks like the algorithm is PI and not PID right? I wonder if if using derivative factor would work better especially to avoid the overshoot issue. Need to think about it a bit more as well.

[maia]

@jmcollin78 Here are three rooms with the alpha5 feature running since 11:00, plus the expert auto-regulation parameters below. There's not much difference it seems. But it's hard to tell what is caused by the new feature and what is caused by the very slow auto regulation settings I use. So I now just switched from expert to "light" auto-regulation and will give you an update soon again.

auto_regulation_expert:
    kp: 0.1 # 10% of the current internal regulation offset are caused by the current difference of target temperature and room temperature
    ki: 0.003125 # 0.9 / 288.0 = 90% of the current internal regulation offset are caused by the average offset of the past 24 hours
    k_ext: 0 # disable for now
    offset_max: 4.0 # limit to a final offset of -4°C to +4°C
    stabilization_threshold: 0.0 # this needs to be disabled as otherwise the long term accumulated error will always be reset when the temp briefly crosses from/to below/above the target
    accumulated_error_threshold: 1152 # 3.0 * 288 = this allows up to 4°C long term offset in both directions

[jmcollin78]

Probably you should only reset the accumulated_error if the new target temperature is "on the other side" of the room temperature (if it was too cold but with the new target temperature it's too warm). That's the only time it might be logical.

Yes that is what ChatGPT calls "when the error sign change". And I think it is a good idea. If error sign change that means, we need to heat or stop heating and we should probable ignore the previous errors builds on old conditions.

[jmcollin78]

By the way - it looks like the algorithm is PI and not PID right?

Yes. The self regulation in over_climate is based on a PI algorithm which is much more easier to tune than the PID one.

[jmcollin78]

@maia with alpha-5 you should see than when the internal temp sensor is above the target but the room temperature is under the target, that the TRV should heat.

See at 15:15, 16:15, 17:00 for example:

[maia]

@jmcollin78 Is the offset calculation capped with the same value that the auto-regulation is capped? As I wanted to test the new feature, I switched the auto-regulation to "light" but now the regulated temperature seems to be limited to 1,5°C around the target temperature? Personally I'd need up to 3°C for the offset adjustment (room temp vs TRV internal temp) but probably don't need much (or any) auto-regulation, as that is rather for other types of heating than for radiators.

As an example see here: It's usually too cold in this room, as the radiator is too small. Ideally the regulated temperature is much higher than the target temperature. But since 16:30 using the "light" setting I'm seeing the issue that the TRV internal temperature rises above the regulated temperature and the valve closes. All while the room is still too cold. The new algo should have added the difference of the room temperature and the TRV temperature (about 3°) to the target temperature, causing the regulated temp to be much higher.

[ikoz]

One more interesting graph, expert mode with alpha5

• purple line: Vtech setpoint - fixed at 19.3C
• dark blue line: Real room temperature - around 18.8C (so TRV should be heating, since setpoint is 19.3C and room temp 18.8)
• light blue line: internal TRV temperature - 20.2C increasing to 21C and then to 21.4C
• orange line: TRV setpoint (calculated by Vtech): 20C, increasing slowly to 21C and then fast to 23.5

The interesting issue is this: From 8:25pm the TRV should be heating, but Vtech was increasing the TRV setpoint very slowly - +0.5C at 8.33pm, +0.5C at 8.50pm, +0.5C at 09.09pm. Then heating finally starts, and Vtech now starts increasing temperature much faster - every 3 minutes. Not sure why.

[maia]

@jmcollin78 The combination of the new feature plus the "medium" auto-regulation causes rooms to overheat. As energy is expensive, I do not want to have a room warmer than necessary. But unfortunately the regulated temperature stays above the target temperature even when not necessary:

[jmcollin78]

Is the offset calculation capped with the same value that the auto-regulation is capped?

no. The offset calculated from trv_temp - current_temp is just added to the regulated_temp (which is capped) to be sure the target is over the trv_temp and then force heating.

But since 16:30 using the "light" setting I'm seeing the issue that the TRV internal temperature rises above the regulated temperature and the valve closes. All while the room is still too cold. The new algo should have added the difference of the room temperature and the TRV temperature (about 3°) to the target temperature, causing the regulated temp to be much higher.

I think there is one important graph missing: the TRV target temperature. If you display it, you should have the target TRV = regulated + offset. See my graphes above.

To display the same graph you could use this Plotly configuration (which is much more clear than regular HA graph in my opinion):

type: custom:plotly-graph
entities:
  - entity: sensor.temperature_chambre
    name: Room temp
    yaxis: y1
  - entity: climate.trv
    attribute: current_temperature
    name: TRV Current
    yaxis: y1
  - entity: climate.trv
    attribute: temperature
    name: Clim Target
    yaxis: y1
  - entity: climate.vtherm
    attribute: temperature
    name: Target
    yaxis: y1
  - entity: climate.vtherm
    attribute: regulated_target_temperature
    name: Regulated
    yaxis: y1
layout:
  margin:
    r: 50
  legend:
    x: 0
    'y': 1.2
    groupclick: togglegroup
    title:
      side: top right
  xaxis:
    rangeselector:
      'y': 1.1
      x: 0.7
      buttons:
        - count: 1
          step: hour
        - count: 12
          step: hour
        - count: 1
          step: day
        - count: 7
          step: day
autorange_after_scroll: true
refresh_interval: 10
title: Regulation graphs
hours_to_show: 4

Of course you should install the Plottly HACS Front UI card.

[jmcollin78]

One more interesting graph, expert mode with alpha5 (so TRV should be heating, since setpoint is 19.3C and room temp 18.8)

Yes this is interesting. The delta temp is 0.5 which is near target. But it could heat, I agree. Then can you look at your regulation parameters: I think you have a threshold of 0.5 (new regulation is send only if the delta vs previous is > 0.5) and a long regulation cycle (15 min). So the regulation target is send each 15 min if the delta temp is > 0.5. That is what we see in the first part (8h00 -> 9h10).

But when a new target temp is send we should observe that TRV setpoint is set to internal TRV temp + delta temp. And that is not what we observe here (on the contrary of my graphs in which I observe this clearly).

There is something wrong. I wonder if you could install the Plotly configuration as explain just above to Maia. Then we will all have the same color and graphs (my brain is getting tired when looking all you different graphs and colors 😜 ).

[jmcollin78]

@maia, @ikoz Thank you all for the tests.

There is clearly something wrong. I guess you can reinstall the regular Versatile Thermostat integration to avoid weird regulation until I fix this.

I hope I will be able to do the fix for this week-end.

[maia]

@jmcollin78 Thanks for your work. Is this how you prefer the chart colorwise?

[jmcollin78]

@jmcollin78 Thanks for your work. Is this how you prefer the chart colorwise?

That is fine ! Thank you and we can see that TRV target is much over TRV Current when VTherm wants to heat.

[ikoz]

Yes this is interesting. The delta temp is 0.5 which is near target. But it could heat, I agree. Then can you look at your regulation parameters: I think you have a threshold of 0.5 (new regulation is send only if the delta vs previous is > 0.5) and a long regulation cycle (15 min). So the regulation target is send each 15 min if the delta temp is > 0.5. That is what we see in the first part (8h00 -> 9h10).

The interesting thing is that I have 1 minute regulation cycle, not 15 minute. I will continue to monitor the behavior.

[jmcollin78]

Hello, I have implemented what I think is the correct behavior of the accumulated_error which should fix @maia and @ikoz issues. The new behavior is to smoothly reduce the accumulated_error (divide / 2) when the error sign change. Example:

1. suppose you have accumulated many negative error because the room temp was > target temp for a long time. Let's say 20,
2. when room_temp goes under target change (@ikoz case), the accumulated error will be ajusted more quickly because at each cycle the accumulated_error is divided by 2 and the error (>0) is added to the result. 2bis. suppose now that the target temp change but is still under the room_temp (@maia case). Then the error sign is not change (is still < 0), so the accumulated_error is not resetted nor divided by 2. And so, the heater should not start heating.

The release is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/5.4.0.beta3

If you post some regulation graphs please use the Plottly so that each will have the same color. Thank you in advance.

[ikoz]

Thanks for the update! Downloading it now and will test.

For reference here is a recent graph using alpha5 from earlier today. I've added one more parameter to the graph - heating demand. This shows when the TRV was letting heat on (this is actually a percantage, not on/off). 1min cycle.

At about 8:15am the vtherm target changed from 16C to 19.3C. The real temperatute at that ime was 18.5C so heating should start immediately. However, heating started at 8:45am. It took 30 minutes for vtherm to raise the TRV target above the internal TRV current temperature. Another odd thing is that heating stopped around 9:40am, because the TRV current temp became higher than TRV target. It took a further 1 hours for Vtherm to raise the TRV target temp a bit more.

[jmcollin78]

Hello @ikoz

At about 8:15am the vtherm target changed from 16C to 19.3C. The real temperatute at that ime was 18.5C so heating should start immediately. However, heating started at 8:45am. It took 30 minutes for vtherm to raise the TRV target above the internal TRV current temperature.

This is exactly the case I have (hopefully) improve. I hope this will be much better. If have a short cycle it should not take more than 5 minutes to heat then. 🤞

Another odd thing is that heating stopped around 9:40am, because the TRV current temp became higher than TRV target. It took a further 1 hours for Vtherm to raise the TRV target temp a bit more.

I think the room temp is too close to the target. There is no more regulation here. If the threshold > delta temp no more regulation is applied. Not totally sure but I think this is the explaination.

[jmcollin78]

Here are new regulation graphs on my case. Installation have been done at 22:22:

[jmcollin78]

It seems to be very efficient:

[jmcollin78]

Another transition from "don't need heating" to "need heating this morning" after a long period accumulating errors:

At 8h35 I switch target from 17 to 20°. The room temp was 19°. We can see the regulated temp increasing very fast from 12° to 18.5° which starts the heater (target clim temp grows from 16° to 19° and then 23°) in less than 8 minutes.

Then the stabilization to the target seems very stable.

For me the algorithm works as expected. Let me know if the behavior is better on your side.

[maia]

Installed the new beta 2 hours ago and will report back on Monday, I have a very busy weekend ahead.

[maia]

As a quick update, I installed the new beta around 7:00 and am not seeing much additional regulation due to "Use internal temperature of the underlying". Would it help changing the "self-regulation" from "light" to "No auto-regulation" to better analyse the change? The green line is not visible most of the time. Maybe that's okay, because it's not necessary? Although, why did it keep the target temp in the upper left chart so high when the sun started heating the room at 12:00-16:00? Shouldn't the target temp sent to the TRV be reduced dramatically during this period, to prevent additional heating? The room temperature was up to 2°C higher than the target.

By the way, that simple checkbox at the bottom of the config panel does not feel like it's a completely separate thing, it feels like it's part of the "self-regulation". I suggest to somehow keep these two options apart as they do different things. One is to get the heaters react quicker, the other one is to adapt to long term offsets. I suggest to use different vocabulary for these two things ("short-term self-regulation" and "long term offset adaption") in the config panel.

[jmcollin78]

Would it help changing the "self-regulation" from "light" to "No auto-regulation" to better analyse the change?

No. The use of the internal temp sensor (for offset) just come above the regulation calculation.

The green line is not visible most of the time. Maybe that's okay, because it's not necessary?

Yes. When room temp is above target, there is no need of regulation nor offset calculation. I talk about Shlafzimmer.

Although, why did it keep the target temp in the upper left chart so high when the sun started heating the room at 12:00-16:00?

All seems normal here: The TRV target temp is equals to regulated temp because there is no need to heat. After 17:00 it could be interesting because room temp will be < target temp. It should heat rapidly due to change to accumulated error.

I guess the green line follows the regulated line. You can hide regulated line by clicking on it to be sure. All your curves are in one degre, so there is no need to strong regulation (but there is a little at 14h45 -> 16h00).

By the way, that simple checkbox at the bottom of the config panel does not feel like it's a completely separate thing, it feels like it's part of the "self-regulation"

Yes. It is in the "self-regulation" block. It complete the self-regulation, and does nothing if there is no need of heating.

I suggest to use different vocabulary for these two things ("short-term self-regulation" and "long term offset adaption") in the config panel.

This is not really true nor my vision. The both are part of self-regulation:

1. one part is to change enhance target temp,
2. the other part is to compensate the internal sensor offset to force heating when it is necessary independently of the internal temp sensor. There is not really short term or long term notions in that. All are calculated permanently.

This part is interesting. The room temp (21) is under the target (22). So self-regulation takes place and force the target to 23° adding +1°. But the internal temp is 25 (+4 ° over the room temp). So the final temp send to TRV is 27° forcing it to heat. At 11h00, room temp is very near the target temp, so regulated temp decrease to 22° and TRV target to 24°.

The green line should be over the orange line when heating is needed. That is exactly what I wanted to see. This is also visible in Küche Rechts around 17h00.

[maia]

Would it help changing the "self-regulation" from "light" to "No auto-regulation" to better analyse the change?

No. The use of the internal temp sensor (for offset) just come above the regulation calculation.

Unfortunately I do not understand what you're trying to say. Isn't the offset regulation something else than the self-regulation?

Yes. When room temp is above target, there is no need of regulation nor offset calculation.

Why? If it's too warm in a room, I want the TRV to have a lower target temperature set. I want to minimise my heating gas usage. So if a room is warmed by the sun or the oven, making the room temperature be higher than the TRV temperature, I want the climate entity to send a lower temperature to the TRV. I thought that's what this feature is about, no?