Why is coef_int limited to =<1?

[matevarga]

The algorithm looks like:

on_percent = coef_int * (target_temperature - current_temperature) + coef_ext * (target_temperature - outdoor_temperature)
Then, the algorithm ensures that 0 <= on_percent <= 1.

As coef_int =< 1, therefore if e.g. (target_temperature - current_temperature)==0.5 then the heater will only be turned on for apprx. 50% of the duty cycle. This is not that great for many slow heaters (like UFH). As a comparison, this is VTherm in a large badly insulated room with slow UFH (under wooden floor):

And this is another thermostat (SAT from HACS) -- I can only show you the error value (diff between target vs current as my data store is somewhat messy at the moment):

So SAT sometimes overshoots, mostly when we're eg. cooking or when there are many guests who warm the room up. But the error is so much smaller, and despite all my efforts, there doesn't seem to be a VTherm setting that would provide a better outcome. Not that it's bad now, but SAT usually kept the temperature within 0.2 degrees vs. the setpoint despite the very slow heater, and I was wondering if removing the limitatation on coef_int would help. Also because on_percent is bounded anyway I don't see any real point in restricting these coefficients.

Happy to raise a PR if you agree.

[jmcollin78]

Hello,

For regulation question I need, the attributes of your VTherm: https://github.com/jmcollin78/versatile_thermostat/blob/main/documentation/fr/reference.md#attributs-personnalis%C3%A9s

and the regulation curve like this: https://github.com/jmcollin78/versatile_thermostat/blob/main/documentation/fr/additions.md#courbes-de-r%C3%A9gulattion-avec-plotly

The limitation is there because no one need more until today. 0.5 or 0.6 is a good value for every one. 1 should be too much. Each tiem you have one ° of difference the heater will be fully open.

[matevarga]

Hello, the attributes of that particular VTherm:

hvac_modes: heat, off
min_temp: 12
max_temp: 23
target_temp_step: 0.1
preset_modes: none, frost, eco, comfort, boost
current_temperature: 21.5
temperature: 21.3
hvac_action: idle
preset_mode: none
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: true
last_central_mode: Auto
frost_temp: 10
eco_temp: 19
boost_temp: 21.5
comfort_temp: 20.5
frost_away_temp: 0
eco_away_temp: 0
boost_away_temp: 0
comfort_away_temp: 0
power_temp: null
target_temperature_step: 0.1
ext_current_temperature: 1.68
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: none
saved_target_temp: 21.3
saved_hvac_mode: heat
motion_sensor_entity_id: null
motion_state: null
power_sensor_entity_id: null
max_power_sensor_entity_id: null
overpowering_state: null
presence_sensor_entity_id: null
presence_state: null
window_state: off
window_auto_state: off
window_bypass_state: false
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
window_action: window_turn_off
security_delay_min: 60
security_min_on_percent: 0.5
security_default_on_percent: 0
last_temperature_datetime: 2024-12-27T21:57:57.924808+01:00
last_ext_temperature_datetime: 2024-12-27T21:53:41.571412+01:00
security_state: false
minimal_activation_delay_sec: 300
device_power: 1
mean_cycle_power: 0.19
total_energy: 33.75
last_update_datetime: 2024-12-27T21:57:57.925472+01:00
timezone: Europe/Redacted
temperature_unit: °C
is_device_active: false
nb_device_actives: 0
ema_temp: 21.5
is_used_by_central_boiler: false
temperature_slope: -0.15
hvac_off_reason: null
max_on_percent: null
have_valve_regulation: false
is_over_switch: true
is_inversed: false
keep_alive_sec: 0
underlying_entities: switch.aqara_smart_plug_eu_switch_3
on_percent: 0.19
power_percent: 19
on_time_sec: 2076
off_time_sec: 8723
cycle_min: 180
function: tpi
tpi_coef_int: 0.6
tpi_coef_ext: 0.015
calculated_on_percent: 0.19
friendly_name: Nappali padlófűtés
supported_features: 401

I've tried with the default coefficients too.

1 should be too much. Each tiem you have one ° of difference the heater will be fully open.

Maybe -- just it seemed like an artificial limitation, because there are scenarios where it might be necessary. For example, if the heater can barely heat up the room, then a limit of 1 might mean that the thermostat will never-ever heat up the room properly, because e.g. whenever it is approaching the target temperature, it starts to decrease the duty cycle.

Example: badly insulated room, coef_int = 1, setpoint = 25 degrees. Assume that the room would stay at 25 degrees if the heater is constantly running. If coef_int = 1, then it means that above 24 degrees the heater will start to turn off, so the temperature will drop -- you'll end up floating around 24 degrees.

This is not an unrealistic scenario because it is often more economical to set the flow temperature of the boiler to a lower value and keep it running more than using a higher flow temp. So I want to be able to decrease the flow temp to the minimum, even if that means that the boiler needs to run more (overall I'll have lower gas consumption). But in order to use lower flow temperature, I'd need to set coef_int to a higher value.

[jmcollin78]

ok. You can try setting coef_int to 0.7 this will change the behavior. If still not enough try 0.8.
Try also to increase the coef_ext to 0.03 because the stable part of the curve is under the target.
The objective is that the percent heating (on_percent) goes to 100%.

Edit: ooooh I see your cycle is totally wrong: 3 hours will not work. Set it to 15 min. The on_percent will not vary during 3 hours and then you have no regulation at all.

[matevarga]

Edit: ooooh I see your cycle is totally wrong: 3 hours will not work.

Is it? Genuinely unsure -- heating this UFH loop doesn't have any effect on the room in 1-2 hours. (Seriously, the thermal mass is just very high.) I used to use 30 mins before. So by using a very long cycle I wanted to avoid massive oscillations.

I'll try though.

Still curious of what you think of my other points, but I understand that it's not your job to discuss stuff like this -- so only if you think this discussion is relevant.

Thanks for developing this add-on.

[jmcollin78]

I understand that it's not your job to discuss stuff like this

of course it is my job and I answers to all messages. You can check it.

My opinion is that many and many uses this VTherm for 2 years now and all of them reach the target temperature. Just have a look on the regulation curves in the readme to convience you. So you are certainly right and you think what you want but I stop reading here: the thermostat will never-ever heat up the room properly, because e.g. whenever it is approaching the target temperature, it starts to decrease the duty cycle.

Some example at home now:

With TPI the coef_ext is there to adjust the stable level. Augment it if you don't reach the target, reduce it if the target is exceeded.
With PI (over_climate) there is self regulation mecanisms in VTherm that are here to ensure the target will be reach.

Sadly you don't read the README, don't try but have some certainties.

[matevarga]

Ah yes, coef_ext helps there, thanks. (I've read the README I swear, I'm just more used to PID-like behaviour.) Thanks again.

[0h41]

I was looking for the answer to this question exactly, so I won't create a new discussion. But I think I have a valid use case for coef_int being allowed to go over 1.0: low temperature heat sources with built-in temperature regulation based on external temperature.

I have floor heating set up with a heat pump. Heat pump efficiency goes down as water temperature passed to the heating loop goes up. So to be as efficient as possible, floor heating water temp should be as low as possible. Additionally, many heat pumps (including mine) don't heat water to a constant temperature, but have outdoor temperature compensation built in - so increasing coef_ext isn't exactly ideal. As opposed to high temperature heating sources, the valves should be OPEN most of the time, because temperature delta between floor heating loops and room temperature is small.

Now let's say the actual room temp is 0.3°C lower than the set point, and coef_int is already at 1.0. 30%(+coef_ext component) duty cycle may be too low to increase the temperature any higher. And please remember, that increasing coef_ext isn't ideal, as it would double the functionality of the heat pump itself.

What do you think? Would it be fine to relax this limitation for such use cases? I guess there could be some note that would say "coef_int should only go above 1.0 for low temperature heat sources".

[jmcollin78]

Hello @0h41 ,

I really don't know if it is relevant. The power-percent (or on_percent) cannot go beyond 100%. So it does nothing if you set the coef_int to a high value.
And the principle of regulation is to adapt the power considering the temperature difference. So it will adapt itself if the water temperature is higher.

Concerning the coef_ext, you can set it to 0 if you think it is not relevant in your case. You are the first one to propose this behavior.

If you are a bit developper, you can easily change the upper value of coef_int. This is in the file config_model.py. Set it to 2 or 3 and make some tests.

[0h41]

I really don't know if it is relevant. The power-percent (or on_percent) cannot go beyond 100%.

I don't want to go beyond 100%. But I do want to get high values for low temperature deltas - for example coef_int set to 2.0 and temperature delta of 0.3°C will result in a 60% duty cycle - which is totally reasonable in my use case.

Concerning the coef_ext, you can set it to 0 if you think it is not relevant in your case. You are the first one to propose this behavior.

Well, it sounds like the proper approach when the heat source regulates itself against external temperature. I was also thinking about creating a dummy external temperature sensor with a constant value, which would result in a temperature-independent "base" component.

If you are a bit developper, you can easily change the upper value of coef_int. This is in the file config_model.py. Set it to 2 or 3 and make some tests.

Yep, I'll give it a shot.