Experiences with self-regulation in "over climate" mode

[maia]

Lets see if we can fine-tune the algorithm introduced in 3.8.0 which can self-regulate the target temperature based on the room temperature. Please post your graphs.

Here are my experiences with a "light" regulation, a 30min cycle, an outdoor temperature of 8-10°C in the past 6 hours and a central gas heater heating 12 radiators with Eve Thermo TRVs. I also use all three presets (boost in the early morning, comfort during the day, eco at night – and the opposite in the bedroom) and a lower temperature for all three presets when noone is at home:

Kitchen:

Here the algo overshoots at 6:00-6:30. The room temperature was already rising, but the offset of the self-regulated was increased to +1,5°C. When at 7:00 the preset switched from boost to comfort, the room temperature was still rising, as the radiators were very warm. In this case it would have been better if the algo would have reduced the offset as soon as the room temperature was rising and was less than 0,5°C below the target temperature.

Bedroom:

Another example of overshooting. At 2:00 the room temperature is only 0,1-0,2°C below the target temperature, but the algo increases the offset (regulated temperature) by 0,5° at 2:30, causing the room temperature to rise more than necessary.

Bathroom:

The radiator in this room is too small for the room. Also it's only warm close to the radiator, but much cooler in the rest of the room. Unfortunately the TRV keeps the valve at 60-80% when the difference between target temp and measured temp at the valve itself is small. What would help is if the TRV would open the valve more, meaning I would need a rather static offset of ~2°C that's permanently added to the target temperature.

By the way, I believe that the algo should penalise too high temperatures. With the gas prices for heating being at 2-3x the multi-year level in Europe, the goal should be to not overheat any room.

In my case my TRVs are doing a pretty good job, if only I could tell them which more-or-less-static calibration offset they should use. I don't want to outsmart my TRVs. Maybe I should increase the minimum cycle duration from 30 minutes to 24 hours so VTherm can calculate a long term offset? The downside is that with a rapid weather change of 10°C in either direction all my rooms will be too hot or cold for a day or two with such a long cycle.

My current suggestion for a calibration offset of the TRVs is in pseudo-code:

user_adjustable_factor       = 0.05
offset_long_term             = AVG(target_temperature, 7 days) - AVG(measured_room_temperature, 7 days)
outdoor_difference           = current_target_temperature - current_outdoor_temperature
offset_outdoor_dependant     = outdoor_difference * user_adjustable_factor
offset                       = offset_long_term + offset_outdoor_dependant
regulated_target_temperature = target_temperature + offset

And most likely the currently used algorithm can be used to optimise the above suggestion.

I'm looking forward to your experiences and thoughs!

[maia]

Here are another two examples for the "light" mode with a 30min cycle being way too aggressive:

At 2:00 the preset changed from comfort to boost at 2:00, raising the target temperature by 1°C. The difference between room temperature and target temperature was abount 0,7°C. The VTherm algo decided it needed to use a 0,5°C offset. And within less than 90 minutes the offset was increased to 1,5°C.

The algo does not "wait" until the boiler starts burning gas again (which might only happen every 2-3 hours when it's not too cold outdoor) and the hot water in radiator warms the room. It would be great if the algo could incorporate the delay that such slow heating systems have. This encourages me to increase the cycle length from 30 minutes to 24 hours.

The second example here (please ignore the two reboots between 10:00 and 11:00 that reset the offsets):

At 11:15 that the room temperature was at 21,9°C and was rising over the past two hours. Without anything the target temperature of 22,0° would have been reached within minutes, keeping everything constant. But at that time VTherm decided to increase the target temp from 22,0°C to 22,5°C. The room temperature is now at 22,2°, so 0,2°C above the target temperature.

VTherm should ideally anticipate the change in the next 30 minutes: expected_temp_change_in30min = temp_change_of_previous_30min and probably also limit the offset to a maximum of e.g. 2x the current deviation from room temperature and target temperate. So in this example deviation = 22,0°-21,9°C = 0,1°C -> max offset = 3 x 0,1°C = 0,2°C.

Oh, the cycle cannot be in the range of 1-23 hours, as it would create problems when switching between warmer and cooler presets during the day, the regulation would overshoot. So either less than an hour or at least 1 day cycle length.

Unfortunately every reboot of HA will reset all offsets, as they aren't saved (or restored on boot).

[jmcollin78]

Very interesting. At a first glance it looks not so bad but I will do a more close look this week and post my curves.

Thank you for this

[jmcollin78]

Looking at this curve, the problem seems relatively clear : you have 2 hours to gain one degré. So the error is accumulated during the 2 hours and when the temperature grows up you have accumulated many errors. The accumulated error is resetted when the temperature is near (within 0.1°), which does appears 2 hours later which is too late.

I will have a look at your suggestion and see how to make both algorithm compatible (with just a matter of coefficient).

Basically, offset_outdoor_dependant is exactly the 3rd terms of my equation (kext * dtext) and the others are not so far.

What is also clear is that event the Light configuration or the algorithm itself are not suitable for your case.

i come back rapidly.

[jmcollin78]

Here is my curve of regulation on the 2 last days (with an electrical reversible climate and VTherm over climate):

What we can see is that:

1. on 31/11 at 22h00: the target change to 22°, the regulated change to 23,5° - 24°, the temperature then grow up until 22° in 15 min, then oscilate around the 22° (from 21°-23°),
2. at 23h30, the target falls to 19°, then the regulated falls immediatly to 18° (because the temp is > the target),
3. the temperature of the room falls gently during the 01/11 day, and the regulated temp is gently growing up,
4. on 01/11 at 22h00, same again, but this time the temperature is 0,5° or 1° higher than the target and the regulated temp, is near the target and sometimes 0,5 lower.

This is a good regulation as seen from my side. And it works fine because heating the room takes 15 min and regulation occurs every 5 min. The system responds quickly and so the regulation is working pretty fine.

I will try to find curve BEFORE i test the regulation to see the difference. Not sure, I've got this.

[maia]

Oh, that's a completely different physical setup. Your (electrical) heating is much faster than heating with 55°C water flowing in radiators, also either your insulation is worse or you live somewhere where it's very, very cold outside: Between 6:00 and 12:00 the room temperature drops by 2-3°C.

In my apartment and with the current 10°C outdoor my room temperature drops by only 1-2°C after 24 hours of not heating. That's an advantage. But also has the disadvantage of taking much longer to heat. I'm surrounded by 50cm thick brick walls of the late 19th century.

[jmcollin78]

This is a room under the roof which communicates with other rooms that are not heated. So if the door is open (and it's the case the morning) the temperature fails rapidly.

[jmcollin78]

Here are some historical curve:

What we can see is that when the target change to 22°, the room temperature never succeed to get over 21°.
So in my case, the regulation with Light regulation and 5 min works really fine. That means as said above, the problem lies between your configuration and the algorithm which seems not suitable.

I come back later with your algo suggestion.

[maia]

Thanks. I guess it's basically two different functionalities:

• long term offset calibration of TRVs based on room temperature and outdoor temperature
• short term regulation of target temperature to improve (electric) heating cycles

So the question is if and how these two features are technically just the same feature, just with very different parameters, e.g. 5min cycles in your case and maybe 24 hour cycles in my case?

[jmcollin78]

Exactly what I intend to do. The problem with your proposal is the AVG( temp). This doesn't exists and would be quite impossible to calculate.

[maia]

Would it solve the problem if users would provide their "own" average sensor, e.g. using https://github.com/Limych/ha-average or https://www.home-assistant.io/integrations/statistics/ ?

[jmcollin78]

Certainly, but having all temperature average on 7 days looks like a very bad idea. You suppose the temperature is stable saying that and that totally not the case: at night I've got 4° but during the day I've got 15°. Sometimes you have 20° variation on one week. We have that in France in september. What you need I understand is a stable offset, but you need also to follow the conditions, else you don't need regulation at all.

[maia]

My suggestion had two parts, like a regression (alpha + beta * k). Alpha is the part that's independant of the outdoor temperature, the intercept, it's the long term difference between targeted temp and actual indoor temp. Beta is the slope, the diagonal part, the function dependant on the outdoor temperature.

[jmcollin78]

The current algorithm is the following:

# Calculate the error factor (P)
        error = self.target_temp - internal_temp

        # Calculate the sum of error (I)
        self.accumulated_error += error

        # Capping of the error
        self.accumulated_error = min(self.accumulated_error_threshold, max(-self.accumulated_error_threshold, self.accumulated_error))

        # Calculate the offset (proportionnel + intégral)
        offset = self.kp * error + self.ki * self.accumulated_error

        # Calculate the exterior offset
        offset_ext = self.k_ext * (self.target_temp - external_temp)

        # Capping of offset_ext
        total_offset = offset + offset_ext
        total_offset = min(self.offset_max, max(-self.offset_max, total_offset))


        # If temperature is near the target_temp, reset the accumulated_error
        if abs(error) < self.stabilization_threshold:
            _LOGGER.debug("Stabilisation")
            self.accumulated_error = 0

        result = round(self.target_temp + total_offset, 1)

The other thing is that the offset_ext is calculated as target_temp - external_temp. This seems somehow weird. Each time you change the targe_temp, this will generate a pick of regulation.
Maybe using internal_temp - externa_temp will be more accurate to avoid thoses pics.

Moreover, in your case to have something stable and depending mostly on external_temp you need to:

1. have a low kp : because this is globaly done by your EVE TRV,
2. have a very low ki : because of your slow latency. With a low value you will not have so many error accumulation while waiting the room to heat,
3. have a normal k_ext : the most important part in your case I think. When it is cold outside, you should have a bigger offset than when it is warm.

I would like to test these hypothesis if you agree. Should I publish a new pre-version or are you able to change the source code directly ? You just need to see the source code in your /config/custom_components/versatile_thermostat/pi_algorithm.py.

I can send you an updated source file to replace the one you have.

[maia]

I think the issue is that

offset_ext = self.k_ext * (internal_temp - external_temp)

is always positive. Probably it should rather be something like:

offset_ext = self.k_ext * (internal_temp - external_temp - 8)

…which would mean that with an internal temperature of 21° everything above 13° outdoor would result in a negative external offset and only when it's outdoor below 13° it'll slowly be positive. This is probably a bit trial and error.

This issue was not noticeable with larger ki and kp, but now total_offset = offset + offset_ext is always positive as offset_ext is much larger than offset will be negative.

[maia]

Current status of thoughts: I'm not yet too familiar with the formula you're using for the internal offset calculation, I'll need to do some visualisations to understand it. And as I'm more familiar with something simple like the exponential moving average (which just needs the current error as input plus the previous result), I'm considering something like the following:

1. If I want to accommodate for long term calibration offsets, I need a cycle length of a day (or multiple days). With a 15min cycle that results in 4*24=96 cycles per day. I therefor need to use the exponential moving average of 96 periods:

period_length = 96
weighting_multiplier = 2 / (period_length + 1) = 0.02062
ema = (current_error – previous_ema) x weighting_multiplier + previous_ema

2. If my experience is that in autumn and spring when the difference of indoor and outdoor is less than 8°C the rooms are usually a bit too warm and when it's colder outside, the rooms are a bit too cold, I could use the following:

factor = 0.05  # this feels fine for me, others might need other values. .
offset_external = (indoor_temperature - 8 - outdoor_temperature) * factor

Note: A regression with the inputs (x = difference_indoor_temp_and_target_temp, y = difference_indoor_temp_and_outdoor_temp) with >100 samples of the last few days could probably replace the default factor of 0.05.

If I have some spare time over the next 1-2 days, I'll try to adjust the pi_algorithm and see how it works. I know it's something completely different, but the resulting feedback might help with the development. Because I could imagine that when using the EMA one could use a default 5min cycle and would not need to adjust that either. The number of user configurable variables could be reduced. What do you think?

[jmcollin78]

I think the issue is that offset_ext = self.k_ext * (internal_temp - external_temp) is always positive

On summer it will not. I should be valuable also for reversible climatisation which is cooling. If outside is warmer than inside, this is negative and it will influence the offset to a negative value. That's what we want.

Regarding the graphs :

The increase at 8:30 to 0,5° is due to external temp which is much colder. So the regulation push a 0,5° more. I think it is good not ?

The regulation adds 1° because it is cold outside and the inside temp is far from the target. I think this is perfect.

This one is certainly not needed but I suppose the EVE TRV is totally closed because inside temp is 3° higher than target. So, there is no consequences on consumption.

So when you said:

all VTHerm instances continue to have their regulated temp 0,5°C above the target temperature, although all rooms are hotter than they currently should be

The answer is yes but it is exactly what I wanted to do (and wtat we want I though). The regulated target should be a bit higher that the target else it is worse to regulate. I'm not sure we have the same understanding. For me what I see is normal and expected.

[jmcollin78]

I can suggest you to keep that one full day and see on a complete day how it works.

[jmcollin78]

What do you think?

I am begining to have some feedback (in French here for example).

This is French HA forum with a large community using the VTherm. Doing something totally different is an option only if this doesn't work as expected. The needs are differents: with low latency system we need something that can adapt quickly to temperature and target change. During the day, I stop totally heater in the bedroom. So there is actually 17° in the bedroom

But, at 22h00, I start heating and I expect the bedroom is hot at 23h00 max. You cannot do that on your side because you have a high latency. So your need is more to have something stable in time. I can understand this. But I don't think doing long average time is a solution for the first needs. I even think it's a disadvantage to do it like that. This will add inertia to the regulation which should be more real time. But maybe this algo (which is PI algo, i don't invent something) is not suitable for your case.

Let's wait a bit more and see how it is working on a longer period. What I see, seems good at 9h00 (with a very little regulation period).

[maia]

The answer is yes but it is exactly what I wanted to do (and wtat we want I though). The regulated target should be a bit higher that the target else it is worse to regulate. I'm not sure we have the same understanding. For me what I see is normal and expected.

I don't think any algorithm should suppose anything. Speaking in general, there are various things that can cause a difference between target temperature and room temperature (in both directions):

Permanent effects:

• a calibration error in a TRV
• a radiator that's too small for the room

Medium term effects:

• outdoor temperature
• temperature of walls, ceiling and floor

Short term effects:

• open windows or doors
• wind
• sunshine
• people in the room
• electrical devices: oven, stove,…
• other sources of energy (e.g. a hot bathtub, a long shower,…)

For the permanent and medium term effects some TRVs provide a configurable offset, e.g.: https://www.evehome.com/en/blog/eve-thermo-temperatur-offset (unfortunately this offset is only configurable when the device joins a non-Apple thread network).

If VTherm had a static offset instead of an algo, here's how I would configure it at the moment:
-1°C in the kitchen, +1°C in the bathroom, 0°C for all other rooms
Once the winter begins and it starts to freeze, I'd change the offsets to:
0°C in the kitchen, +2°C in the bathroom, 1°C for all other rooms
Once spring is back, I'd change them back to
-1°C in the kitchen, +1°C in the bathroom, 0°C for all other rooms

I can suggest you to keep that one full day and see on a complete day how it works.

With the parameters you provided the (internal) offset will always be in the range of -0,5 to +0,5°C due to being capped and the (external) offset will in winter be in the range of +0,5° to +1,5. The sum therefor can never be below 0°C in winter and is 2°C at max. But my issue with heating isn't that it's too hot in most rooms, not too cold. I'd need a negative offset in most rooms in spring and autumn. The current parameters make a negative offset mathematically possible.

[maia]

Using the current PI-algorithm it seems the following would be fine for me at a 5 minute cycle (=12 cycles per hour = 288 cycles per day):

External offset:

• k_ext = 0.04 this will add 1°C to the offset when it's 25°C colder outdoor than indoor

Internal offset: (at 288 cycles/day = 5min cycle)

• kp = 0.2 20% of the current internal regulation offset are caused by the current difference of target temperature and room temperature
• ki = 0.8 / 288 = 0,00277 80% of the current internal regulation offset are caused by the average offset of the past 24 hours
• accumulated_error_threshold = 2.0 * 288 = 576 this allows up to 2°C long term offset in both directions

Total offset:

• offset_max = 2.0 limit to a final offset of -2°C to +2°C
• stabilization_threshold = 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

I will try it with these parameters tomorrow. Still I'd prefer an exponential moving average over the accumulation of the errors over 24 hours as the EMA will instantly be usable and also it will reduce the necessary parameters.

[maia]

By the way, when using an EMA instead of the PI-algo for the indoor offset calculation the only parameter is the duration of the EMA. It will allow short term regulation and also long term regulation. In the config you could provide three options: 1 hour, 6 hours, 24 hours. And add the following explanation: "On a winters day, in how many hours of not heating does the temperature in the drop by 2-3°C?"

Alternatively, one could use three aspects, e.g.:
total_offset =
33% short term indoor offset (based on 1-hour-EMA error) +
33% long term indoor offset (based on 2-day-EMA error) +
33% outdoor offset

[jmcollin78]

it's too hot in most rooms, not too cold

ok. I haven't that in mind. I wonder why you said EVE are doing a good job, if there are often too hot. I think this is root cause of the misunderstanding. I always suppose that you EVE TRV was working quite fine and just need a small adjustement. That's why internal offset should be always low for me.

Ok, you can have a try with your configuration to see if it resolves your case. This is an interesting set of configuration.
You know where to change and how to change ?

I have doubt about this parameter: accumulated_error_threshold = 2.0 * 288 = 576 but let's have it a try.

[maia]

I wonder why you said EVE are doing a good job, if there are often too hot. I think this is root cause of the misunderstanding. I always suppose that you EVE TRV was working quite fine and just need a small adjustement. That's why internal offset should be always low for me.

Sorry, that was a misunderstanding. My Eve Thermo are doing a great job at short term regulation (5-30 minutes). But three issues remain with them:

1. permanent calibration errors
2. temporarily overheating rooms caused by other sources of energy (e.g. in a kitchen when cooking)
3. underheating of rooms when it's very cold outdoor

The second and third issues are only noticeable with a room thermometer. The internal TRV thermometer itself cannot sense the heat at the other side of the room. And to solve the first issue a completely static offset is fine (and provided by some TRVs, unfortunately not in Home Assistant).

You know where to change and how to change ?

Yes, thanks. In the past decades I worked on a couple of projects (mostly Ruby, Java, Lua), just not in the past 5 years. And I am not familiar with Python and also not with git, other than simple commits. So for now I might just send you a .py file instead of creating a PR.

[maia]

So far, the adjusted settings work better than anything I had before, but it's not 24 hours yet, so I'll wait another day. But what I want to do next is to change self.accumulated_error += error, because whenever a preset changes from e.g. boost to eco&away, there's a huge error being added. So I'm considering the following instead: self.accumulated_error += min(2.0, max(-2.0, error)) (or whatever threshold one is using).

More complex would be to only accumulate errors when:

• the current temp is above the target temp and the heating is on
• the current temp is below the target temp and the heating is off

…but that's not so easy as e.g. my TRVs only update their valve % every 15 minutes or so and frequently keep them open at 5-15%, which probably neither really is "heating" nor "no heating".

[maia]

Here's the results after 36 hours, displaying the last 12 hours, based on 288 cycles/day (=using a 5min cycle) with the following parameters:

kp:float = 0.2 # 20% of the current internal regulation offset are caused by the current difference of target temperature and room temperature
ki:float = 0.8 / 288.0 # 80% of the current internal regulation offset are caused by the average offset of the past 24 hours
k_ext:float = 1.0 / 25.0 # this will add 1°C to the offset when it's 25°C colder outdoor than indoor
offset_max:float = 2.0 # limit to a final offset of -2°C to +2°C
stabilization_threshold:float = 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:float = 2.0 * 288 # this allows up to 2°C long term offset in both directions

I like this regulation more than the currently available options. Still it needs some improvements (see above and the HA community forums), but for anyone else who want's to try them, you can edit the const.py file. Also keep in mind that any time you restart the HA server you'll start from scratch and all values will be off for the next 24 hours.

[jmcollin78]

Ok the valve position is important in the analysis. The orange curve seems to indicate it is heating, but if valve is only 10% this is not really heating. It is more clear now with this last graph.

This part of the graph is showing what I tried to explain earlier. We could think the auto-regulation is overheating but the valve are closed, so there is no problem with gas consumption and costs:

By the way, this last curve seems not too bad at all 👍

[maia]

The increasing temperature around 14:00-16:00 is caused by sunshine, the room has large windows facing west. So yes, this isn't overheating caused by burning gas. What I'm planning to do soon is to preemtively switch to a lower preset on days where the sun shines as it's pretty easy to calculate the exact time the sun will begin to shine into the rooms facing west. Because if we know the sun will heat the room soon, one can close the valve 30 minutes earlier.

[maia]

I'm now running a different algo based on merging 4 exponential moving average offsets for 4 different timeframes (20 minutes, 2 hours, 12 hours and 3 days). I'll let you know how it goes in a day or two once there are charts to look at.

[jmcollin78]

ok. Do you wish that I integrate the last tuning into the next release ? I have pending modifications now and I wish to commit this or forget. It could be a kind of "Very light" regulation mode.

[maia]

It would be great if you could integrate the parameters I've been using over the past 2 days. I wouldn't call it "very light" but rather "slow", but that's a semantic question. But if you can, please check if calculate_regulated_temperature is really only called 288 times per day when using a 5 minutes cycle. Otherwise calculations that should be based on a day will be rather off. Thanks!

[maia]

@jmcollin78 Is calculate_regulated_temperature in class PITemperatureRegulator only called once per configured "cycle duration" and entity? For a timeframe of 10 minutes and 10 VTherm climate entities I'm seeing 120 entries in the log, which is somewhat irritating. And unfortunately I don't know how to add the name of the service/entity to _LOGGER.debug(…) to see what's going on.

By the way, the cycle duration does not show in developer tools state inspector. That is strange, isn't it?

[jmcollin78]

calculate_regulated_temperature each time we need to recalculate the regulated temperature. That is when at each cycle but not only, each time the target_change (I believe). I should investigate more to be sure

[maia]

If you happen to know how to easily add the service/entity name (or id) to the logfile I could let you know my findings by isolating the entities. But certainly something is off, as it's being called more frequently than only every 5 minutes it seems.

[maia]

I have one entity with target_temp 25.0, here's that it shows up 36 times in the logs in the past 60 minutes. Sometimes it's many times within the same second, sometimes it's with a 5 minute distance. Whatever algo is used, it cannot work if there's no fixed frequency the update is called, especially when called multiple times per second:

16:14:18
16:14:21
16:14:50
16:14:50
16:14:50
16:16:06
16:18:01
16:18:01
16:18:01
16:20:51
16:20:51
16:21:06
16:23:33
16:26:02
16:26:02
16:26:02
16:26:06
16:31:06
16:31:13
16:31:13
16:31:13
16:36:06
16:41:06
16:46:06
16:48:35
16:48:35
16:48:35
16:51:06
16:54:25
16:54:25
16:54:25
16:56:06
16:56:36
16:56:36
16:56:36
16:57:33
16:59:36
17:01:06
17:06:06

[maia]

With currently 10 VTherm services using the regulated algo I can see 388 log entries within exactly 1 hour, so in average every service calls calculate_regulated_temperature in average every 1.5 minutes, even when using a 5 minutes cycle. Something is off, it should be called exactly once per cycle.

[jmcollin78]

Hummm, I will have a look at this. This seems not normal. I agree that accumulated error will be wrong if algo is called too much.

[maia]

@jmcollin78 This is what I'm currently using. It's simple and doesn't even consider the outdoor temperature yet (because it might not even be necessary), it's missing all configuration options, it's just a quick hack for myself. It's just for your information what I'm currently considering. I'll show you the generated graphs in a day. Or in case you find the reason for the too many calls of calculate_regulated_temperature, I'd reboot HA with a fix and then let it run for a day before showing any graphs, because the calculations are off when not using the 5min cycle but less (and partly at the same second).
pi_algorithm.py.txt

[jmcollin78]

#164

[maia]

@jmcollin78 A quick update: I've been running the 4-timeframe-EMA as replacement for the PI algo. It has some pros and cons, but for a real verdict I need to wait for the outdoor temperature to drop (current highs are in the 12-16°C range) and also for the fix for the too frequent calls to calculate_regulated_temperature, as the timeframes are completely off.

But what I realised is that with TRVs we have two temperatures available, the "internal" at the TRV itself and the room temperature. And the TRV decides the valve opening percentage based on the difference of measured room temperature and target temperature. So when we want to influence the valve opening indirectly, it might be smart to set the target temperature in relation to the TRV-measured temperature ("Is it too cold in the room? Set the target temperature to 1°C more than measured at the TRV"). But I'll have to think about that. So I'm not "done" yet and will get back to you with an update in the next days/weeks, depending on outdoor temperature and the fix for #164 .