Add an adaptative regulation in over climate mode

[jmcollin78]

Following a discussion in https://github.com/jmcollin78/versatile_thermostat/issues/125 issue, we need a regulation for over climate mode. This regulation should:

1. take care of temperature sensor in the room,
2. adapt the target temperature by adding / substracing a value if the temp room is under / over the target temperature.

So regulation can be done by VTherm using the target temperature value and adapting it constently.

Some PI (proportionnel-intégral) algorithm seems to be exactly what is needed for this.

[maia]

Thanks. I suggest a development in two phases:

1. Add a configuration option for a constant offset value: underlying target temp = vtherm temp + offset. This allows to adjust for differences between the temperature measured internally by the TRV and the room temperature, preventing a constant over- or underheating. For example, my living room is overheated by 1,0°C on average, so I would set the offset at 1°C, so when I set the VTherm target temp to 21°, the TRV is sent a target temp of 20°C and as it's wrongly calibrated it will heat the room to 21°C.
2. Develop an algorithm (e.g. based on bayesian time series models, regression,…) that constantly compare the sensor data to adjust the offset explained above.

The second phase is most likely much more work (and might not be ready for this winter?)

[jmcollin78]

Yep. Will see that.

[Ra72xx]

If you add some kind of own mechanism to control the way the thermostat tries to reach target temperature, could you please nevertheless retain the current mode in which the thermostat does this with its own algorithms? In fact, this is the main reason I prefer VT over Better Thermostat: VT currently does not mess with the internal algorithms of the thermostat but assumes that the thermostat knows best what regulations have to be done to reach the target temperature to which it is set and which is also visible and controllable on the hardware.

[maia]

In my understanding this feature would only calculate a long term (days, weeks) offset between target temp and room temp and allow to adjust for that by sending the TRV a slightly lower/higher target temp. But of course it should not change the way how a TRV achieves the goal of a certain target temperature.

[jmcollin78]

That is what I intend to do @Ra72xx.

[jebeke65]

This might also solve my issue. I have a innova 2.0, used as AC heater. The temperature sensor is very inaccurate as it's withing the heater and can't be moved outside. If you set the target temp e.g. to 24deg then it quite soon stops heating as the internal temp sensor reaches 24deg, although the temp sensor that gives the real temp, is only showin e.g. 20deg. As long as the wanted temp is not reached on the temp sensor, it should keep heating by e.g. increasing the target temp to "internal temp sensor + x", where the x is driven by how fast you want to have it increased. As the innova 2.0 is driven by a heat pump, this might take some time. There is also an internal resistor/heater that is switched on if the difference between the targettemp and the internal temp sensor is too big. If you have time enough to wait (no boost needed), then one can gradually increase the room temp.

Would like to be able to control this behaviour on top of the underlying thermostat (here the innova 2.0) and I think this component is already doing a great thing.

[jmcollin78]

Development is starting. What I intend to do is the following:

1. add an option to enable auto-regulation with 3 modes: light, medium, strong,
2. each option will have a set of parameter which will have influence on the algorithm: offset max, kp, ki
3. the algorithm is a PI (Proportional and Integral) which is a cycle based algorithm that is based on this method:

   
   # pylint: disable=line-too-long
   """ The PI algorithm implementation """

class RegulateurTemperature: """ A class implementing a PI Algorithm PI algorithms calculate a target temperature by adding an offset which is calculating as follow:

• offset = kp error + ki accumulated_error

  To use it you must:

• instanciate the class and gives the algorithm parameters: kp, ki, offset_max, stabilization_threshold, accumulated_error_threshold """

  def init(self, target_temperature, kp, ki, k_ext, offset_max, stabilization_threshold, accumulated_error_threshold): self.target_temperature = target_temperature self.kp = kp # proportionnel gain self.ki = ki # integral gain self.k_ext = k_ext # exterior gain self.offset_max = offset_max self.stabilization_threshold = stabilization_threshold self.accumulated_error = 0 self.accumulated_error_threshold = accumulated_error_threshold

  def set_target_temperature(self, target_temperature): """ Set the new target_temperature""" self.target_temperature = target_temperature self.accumulated_error = 0

  def ajuster_target_temperature(self, internal_temp, external_temp): # pylint: disable=unused-argument """ Calculate a new target_temperature given some temperature"""

  Calculate the error factor (P)

  error = self.target_temperature - 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
  # Capping of the offset
  offset = min(self.offset_max, max(-self.offset_max, offset))
  
  # Calculate the exterior offset
  offset_ext = self.k_ext * (external_temp - internal_temp)
  # Capping of offset_ext
  offset_ext = min(self.offset_max, max(-self.offset_max, offset_ext))
  
  # print(f"error: {error} accumulated_error: {self.accumulated_error}, offset: {offset}")
  
  # If temperature is near the target_temp, reset the accumulated_error
  if abs(error) < self.stabilization_threshold:
      # print("Stabilisation")
      self.accumulated_error = 0
  
  return self.target_temperature + offset + offset_ext

  It calculates an offset (ajustement in French) which is the combinaison of  the error (P) and the integral of the error (I).

 4. at each cycle, I will calculate the target (consigne in French) + offset, store this into a new `auto_regulated_target_temperature` and send this new target to the underlying device.
 5. Depending on the auto-regulation mode, the 4 parameters will have default values:

    self.kp = kp  # Gain proportionnel
    self.ki = ki  # Gain intégral
    self.offset_max = offset_max. # The max offset allowed
    self.seuil_stabilisation = seuil_stabilisation # The stabilization threshold 

6. I keep all current attributes like target_temperature (not auto-regulated)

Any comments on the plan would be greatly appreciated if any !.

NOTE: this will be available only in over_climate mode.

[maia]

Thanks a lot for working on it. I can't yet understand the code as I don't speak french and will need to get google translate to translate your code (isn't there a ChatGPT kinda tool that allows code translation? I would hope so). But I'd appreciate it if I could also define a manual offset that is not adjusted at all. And by the way, the outdoor temperature most likely has a strong influence on the offset. The colder it is outside, the higher the difference between the temperature measured at the radiator and the temperature measured in the middle of the room.

But as an initial question: What is a "cycle"? Is a cycle something that happens every few minutes or hours or days?

[jmcollin78]

What is a "cycle"? Is a cycle something that happens every few minutes or hours or days?

yes.

I will translate the algorithm now and post it with English variables names.

[maia]

Haha, so is a cycle minutes, hours or days? :)

[jmcollin78]

Yes in minutes. All VTherm have a cycle in minutes configured.

The algorithm is English have been posted above.

EDIT:

But I'd appreciate it if I could also define a manual offset that is not adjusted at all

It would add another layer of complexity. if the regulation works well, you don't need any manual offset. For now I do not intend to implement this.

[maia]

Yes in minutes. All VTherm have a cycle in minutes configured.

Thanks, I will have to take a look what happenes within a single cycle. I think I remember having seen the cycle length in the config options but though it was not relevant for the "over climate" mode.

It would add another layer of complexity. if the regulation works well, you don't need any manual offset. For now I do not intend to implement this.

Okay, I understand. And as for my personal experience with the needed offset: last winter it ranged from -1,0° C to +2,0° C, meaning that:

• On very sunny days with an outside temperature of not less than 12° C the target temperature at the valves could be set to 1°C less than the room temperature.
• On very windy days with an outside temperature of less than 0° C the target temperature at the valves had to be 2° C above the room temperature.

I only had to adjust the offset temperature about once every few weeks for a temperature that was "good enough".

[jmcollin78]

Hello,

This kind of regulation PI or (even PID) could also be use as an algorithm for an over_switch vtherm and help stabilize temperature targeted no ?

VTherm over switch and over valve are already controller by an algorithm which is a TPI (Proportional and Integral). So we don't need to adapt the target temperature in that cases but eventually to adapt the coefs for the TPI algorithm.

The auto-regulation (or regulation by changing the target temperature), only make sens when regulation is not done by VTherm itself.

[adi90x]

OK internal_temp is the temp of the TRV, right ? But the error accumulated process could improve all vtherm precision, as of now vtherm will define heating as tpi_inttemp_int + tpi_exttemp_ext, using your new algo when can have target_temp=tpi_inttemp_int+tpi_exttemp_ext+tpi_offset*offset(compute by the algo) this may 1/ give à solution to get ride of external sensor 2/Help/Automatize tuning of the vtherm 3/ Improve the stability, even when external event modify temperature ( such as an open door) If implemented, it shouldn't be too difficult to make it available for all kind of vtherm no ?

[jmcollin78]

I understand your point but this is not TPI algorithm. TPI doesn't change the target temperature but changes the power percent. In the VTherm over switch configuration, you can choose an algorithm and the only choice now is TPI.

This is another algorithm like PID which is not planned to be implemented yet. But it will be one day, I hope so. See https://github.com/jmcollin78/versatile_thermostat/issues/8 for real PID algorithms.

[adi90x]

Got your point, but if we use this algo with internal_temp = current temp it should work almost out of the box no ? And at least you can get ride of the external probe sensor ( + I am quite sure the proportinal/integral on error should help smooth the TPI algo)

In fact, could be easy to try/use by just running an over_climate vtherm over a switch vtherm

EDIT : after receiving the "adjusted temperature" we can convert it to power as usual, instead of replacing TPI, it can just be an addon to the TPI ( ie: we receive 20° target temp, it goes into the new algo, based on previous error we compute that target temp should be 20.5° and then it goes back into normal computation. Or adjust TPI algo to add the offest into the formula ( if the new algo return offset+offset_ext instead of target_temp+offset+offset_ext)

[jmcollin78]

@maia , @adi90x I have published an alpha release https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.alpha1 if you want to test. i will do my-self in // on my AC device.

It is only for VTherm over climate for now.

[jmcollin78]

it is working in my house. you can test if you want.

[maia]

Thanks, I will test it as soon as possible (within the next 24-48 hours). Shall In enable debug/info/… mode in logging to track what it does? Is there anything else I could adjust or specifically test? Any specific kind of feedback you're looking for?

[jmcollin78]

I will change my regulation parameters that are a little too strong. So I will publish a beta1 in the next minutes.

Log in INFO should be enough.

I'm looking for regulation curve with the new regulated_target_temp, current_tempand target_temperature and hvac_action in the same graph. This should look like this and show the correct regulation:

You just have to put your thermostat into the "historic dahsboard":

[jmcollin78]

https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.beta1

[maia]

Thanks, I just started testing 3.8.0b1 and am very much looking forward to the results. As my central gas heater only turns on 2-5x per hour, it usually takes a while until a room temperature changes. But I can already give you two feedbacks:

1. My TRVs (Eve Thermo) only allow a 0,5°C step in target temperature, like probably most TRVs. I'm unsure how they react to HA requesting a 0,1°C step in target temperature, but must likely it will be ignored. I suggest a step size for the regulated temperature, defaulting to 0,5°C.
2. From what I've read, the flash memory of TRVs are made for about 10.000 changes. Changes in the target temperature should happen as rarely as possible to prevent the hardware from dying too early. But in the 20 minutes I'm using the beta the regulated target temperature was already adjusted 9 times (at "medium" setting). That's way too much. For example when changing the target temperature every 30 minutes (=48x per day) that's 9.600 changes over 200 days. So a TRV would die within a single heating season.

As water heaters are very slow, the algorithm seems to be much too fast at the moment. As mentioned above, my heater only turns on a few times per hour, and even then it takes a while for 55°C water to flow into the radiator and heat the room. A change of 1°C sometimes needs an hour. It's even slower when using a floor heating system. In my specific situation I'd be happy if VTherm adjusts the offset by 1°C after a few days of analysis. I'd not want VTherm to adjust the target temperature over periods of minutes or hours.

[jmcollin78]

Huummm, ok thanks for the informations.

I don't understand why the temperature don't goes up even if the valve is open at 45% ? Is it normal ? To stabilize the system need the temperature to increase when valve is open. When stabilization is done, command to the valve should be rare (only when something change)

Another remark, can you control directly the valve position of your EVE TRV ? If yes, I add a new VTherm over valve for doing need.

[maia]

This is completely normal. The cycle of a central gas heater works the following way:

1. The heater gets a request to heat (frequently: by a room thermostat in a single room).
2. It turns on the pump and turns on the flame at the lowest level (in my case at 5kWh gas consumption), the water is slowly heated to maybe 40°C while being pumped around the house for a minute or two.
3. If the thermostat turns off the heating request, the cycle is over. Otherwise the flame is slowly adjusted (in my case up to 25kWh) over the next minutes, the cycling water temperature slowly increases to up to 60°C (or 55 or 70, depending on the setup).
4. Once the temperature of the water returning to the central heater is too high (e.g. because most TRV valves are closed), the flame is turned off. The pump stays on for 3-10 minutes. In that case the gas heater will stay off for 10-60 minutes (depending on the setup), no matter if there is a new heating request.
5. Ideally, the returned water isn't too hot and the radiators heat the rooms. The thermostat turns off the heater. The pump stays on for a few more minutes.
6. Only when the room temperature of the thermostat drops by at least 0,5°C, a new cycle begins. This can take a long time too.

In my current case, the gas heater was simply off for 20 minutes, as in the previous cycle the water returned was too hot. This is common when the outdoor temp isn't very cold and the gas heater is a bit larger than necessary. The goal is to prevent frequent cycles. A gas heater shouldn't run more than 4-6 cycles per hour.

As the the room I'm testing in at the moment: The radiator now is warm, as it has water with ~45° temperature in it. It will take another 30-60 minutes until the room temperature rises significantly. So between the start of the adjustment of VTherm and reaching the target temperature it'll take about 2 hours.

Of course I could adjust my gas heater and tell it to heat the water to 70°C and to turn on up to 20 times per hour, but this is a waste of energy. Even the water pump for the radiators needs lots of energy, not even considering the gas. That's why it's only turning on a few minutes per hour.

[maia]

PS: no, I cannot control the valve directly. Homekit devices do not expose this. There will be a Matter upgrade for my Eve Thermo TRVs in mid-November, then the valve might be adjustable, I don't know yet. But Eve does a pretty good job at adjusting the valve.

[maia]

PPS: Within the last hour, VTherm changed the regulated temperature about 20 times. That's 1/500th of the entire lifespan of the TRV.

[jmcollin78]

Ok. You can set the regulation mode to None.

Le lun. 30 oct. 2023, 19:39, maia @.***> a écrit :

PPS: Within the last hour, VTherm changed the regulated temperature about 20 times. That's 1/500th of the entire lifespan of the TRV.

— Reply to this email directly, view it on GitHub https://github.com/jmcollin78/versatile_thermostat/issues/129#issuecomment-1785828758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANCB5VEQIZ6BWKBQN4MLKTYB7X6XAVCNFSM6AAAAAA6IR6YIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBVHAZDQNZVHA . You are receiving this because you authored the thread.Message ID: @.***>

[maia]

Ok. You can set the regulation mode to None.

I've now changed from "medium" to "light", that might reduce the number of changes.

And I'm fine with having a single thermostat that's at the end of its lifespan soon due to beta testing. It's just not production ready yet with so frequent updates.

[jmcollin78]

FYI, here a great regulation done by the algorithm (on a very poor AC device) :

Sending new regulated temp is done at high frequency it that case. I will add a way to reduce to frenquency of changes but I wonder what wlll be the result.

[adi90x]

Will also try to use it over another vtherm to have proof of interest 😁

[jmcollin78]

@maia for your case, with a central gas heater and a very low heating cycle, I will add two parameters to the algorithm:

"auto_regulation_dtemp": "The threshold in ° under which the temperature change will not be send", -> default value of 0.5
"auto_regulation_periode_min": "Duration in minutes between two regulation update".    -> default value of 5 min. In your case, you should put something like 1 hour to see if the regulation occurs.

I already add a service which you can call to change the auto_regulatio_mode without having to reconfigure the VTherm.

This should be quick to implement. I let you know when it is available.

This should be interesting also for you @adi90x

[maia]

@jmcollin78 Being able to adjust the step size (the thermostat only accepts 21.0°C, 21.5°C, 22.0°C, 22.5°C, 23.0°C,…) and the cycle duration should help. I'm looking forward to the next beta.

Edit: I think you should not use the word "threshold", I suggest using "step size" instead. Because threshold would implicate that only the first step is 0,5°C but after that the next steps can be 0,1°C again.

[jmcollin78]

Hello @maia and @adi90x ,

The new beta is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.beta3 Have a look to the release note please.

NOTE : the log to find the regulation changes is: Regulated temp have changed to X. Resend it to underlyings

[maia]

I've been using the "medium" mode in six rooms for the past hours. It's warm outside, so the heater doesn't turn on a lot, so the temp in the rooms doesn't change a lot.

I've noticed a bug:

The calculated offset (regulated_temp - target_temp) should not change when the preset changes. Once the algo finds a "good" offset that is added/subtracted from the target temperature to ensure a proper room heating, it shoulnt not be "reset" when a preset changes the target temperature.

The above is an example for something going wrong: Around 17:00 the algo thinks that the offset can be -1,5° from the target temperature at the valve. But then at 18:00 the target temperature is raised by 1°C and the offset increases by 3°C, instead of staying at -1,5°.

@jmcollin78 Maybe you have something in mind that's fine for electric heaters but not for valves? What I've been suggesting over the past week or so is a stable offset value that can be defined which will always be added/subtracted from the target value and which is then passed to the underlying. So if a room heats fine with an offset of 1°C, then that's what is added to the target temp for the next weeks (until the outdoor temperature changes radically). But what the algo currently tries to do is to outsmart the valves by adjusting the target temperature over minutes or hours – and resetting everything when the target temp is changed.

I'd be most happy if there was an input field in calculation named "offset" where I could define "+1,5°C" which is then used for the next weeks, when I notice a room is warmer than intended. And I'd be even more happy if that offset could be a function of the outdoor temperature (lower offset at lower outdoor temperature). The current algo seems to have a different goal?

[jmcollin78]

Are you in beta3 ? I reduce the coefficient in beta3, for Medium and Strong regulation mode because it was really too much.

+3 ° is the max allowed for Medium regulation so it is not totally anormal. I will do the calculation by hand to see if something weird happens.

Moreover, I don't understand why it was heating at 16h45 with a regulated temp at 18,5° and target at 20°. There is something wrong at this place.

EDIT : I post this before your changes.

[maia]

And another room, here with a different issue. I don't know what is causing the swings in the regulated temperature:

Why is it above the target temp around 14:00? Why does it jump around 18:30?

[maia]

Are you in beta3 ? I reduce the coefficient in beta3, for Medium and Strong regulation mode because it was really too much.

Yes, I'm in beta3.

Moreover, I don't understand why it was heating at 16h45 with a regulated temp at 18,5° and target at 20°. There is something wrong at this place.

I don't know when it will shade the area orange. How does it define "heating"? Is it orange when the valve opening is above 20% or so? I couldn't figure out the orange shading, so I currently am ignoring the color.

[jmcollin78]

Why is it above the target temp around 14:00? Why does it jump around 18:30?

It would like to have the log around 18:30 ? Did you restart HA ? Or the integration or change the configuration of the VTherm (which reset all parameters) ?

[maia]

It would like to have the log around 18:30 ? Did you restart HA ? Or the integration or change the configuration of the VTherm (which reset all parameters) ?

I just realised I had the log level set to warning, I'm sorry. I now changed it to info and restarted HA. But I didn't do anything around that time, I was eating dinner.

Here's the valve graph for the same room added below. You can see that Eve Thermo TRVs are doing a good job at keeping a temperature constant. Their marketing material talks about "AI", but whatever it is, the valve is rarely at 0% or 100% and it holds the room temp steady with small changes. The only issue is that many TRVs in HA do not allow access to the offset variable. Which is why I suggested to add an offset variable in VTherm that is more or less constant and does not change every few hours:

[jmcollin78]

I have a regulation running all the afternoon and I don't experience this. I'm with a reversible climate. It was too warm so I force the temperature to 22° at 11h00. I've got the +3° when I change the target.

As you said, when the target change, I reset the accumulated error which no more valuable in my opinion because conditions changes. But may be I'm wrong and I should keep the error.

Let's do the calculation by hand: The accumulated error is limited to 25 which is then multiply by 0.08 (= -2 °).
The error should be near 0,3 which is then multiply by 0,4 (= 0,12). The 3rd factor is the external temp: (target_temp - external_temp) 0,1 (= 10 0.1 = 1)

So the offset is +2 + 0,12 + 1 -> 3,12° limited to 3°. So the calculation seems good. This shows that accumulated_error is NOT resetted else we should have +1,12 ° . Maybe the bug is here.

EDIT: the accumulated error factor should be -2 in your case (and not +2)! So I think you are right, there is something weird.

You can see that Eve Thermo TRVs are doing a good job at keeping a temperature constant

I think you don't really need regulation. For you I will suggest a Light regulation (more stable with low variations).

[maia]

As you said, when the target change, I reset the accumulated error which no more valuable in my opinion because conditions changes. But may be I'm wrong and I should keep the error.

Yes, you should keep the offset/error. Two examples:

1. Imagine a kitchen. 3x a day food is prepped. The oven is on. Children are playing. Grown ups are cooking food. Even if the temperature measured at the TRV below the window is 21°, the room temperature is higher, let's say 23°C, because people and oven,… heat the room. In that case the offset in the kitchen will be a (more or less) constant -2,0°C.
2. Imagine a room with windows on one side with a radiator below, and a door on the other side of the room. This door leads to the outdoor area. The door is opened frequently every day, causing the room temperature to be lower than the temperature measured at the TRV. The offset would probably be at +1°C.

And unless the usage of the rooms change, it doesn't matter if the target temperature is set to 20°, 21° or 22°. The room no. 1 will always be warmer than intended, the room no. 2 will always be cooler.

Only if the outdoor temperature changes radically, the offsets change. Imagine it has -10°C outdoors. Now the offset in the room number two will need to rise to +3°C to ensure that the room temperature is okay, even if the door is opened frequently.

PS: I more or less have rooms as in the examples above. Which is why a regulation is very helpful to me.

[jmcollin78]

I will try to remove the reset indeed. I think you are right.

[maia]

I will try to remove the reset indeed. I think you are right.

Great. Also the offset should survive HA restarts. Something that might need a day or two to settle properly should not be reset unless the user wants to reset it manually.

[jmcollin78]

https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.beta4

I remove the reset at each target temperature change and I lower all coefs. There were still too much.

Also the offset should survive HA restarts

This makes no sense. The offset is fully calculated at each cycle and change. This offset is not stronger because it has been calculated during 3 days. The eventual restored value will not be used and recalculated immediatly.

[maia]

I installed beta4 at 4:45 in the morning. The algo currently "overshoots" with its swings in both directions, as it doesn't consider that heating a room by 1°C will take 1-2 hours.

How can I tune the variables to prevent that behaviour? I'm currently using "medium", 0,5°C step size and a 15min cycle.

[maia]

Maybe I should set the minimum cycle to 24 hours to prevent the issues of overshooting when the preset changes during the day?

[maia]

This makes no sense. The offset is fully calculated at each cycle and change. This offset is not stronger because it has been calculated during 3 days. The eventual restored value will not be used and recalculated immediatly.

Recalculation needs a few cycles. So with a cycle of 15min this might mean 1-2 hours until it's recalculated. With a cycle of 24 hours (as mentioned above) it would mean 3-4 days lost with a single HA reboot.

[jmcollin78]

In your case, I would recommend the Light mode of the regulation algorithm and a period of 30 min because your heating is slow. You definitively don't need much regulation thanks to "the good jobs" of EVE valves.

Note: I will release in few minutes.

[jmcollin78]

I will close this discussion, but you can continue if you want to post your experience / remarks / trouble here.

[maia]

@jmcollin78 Thanks, I will switch all entities to "light" mode and 30min cycles and give you an update in a few days.

By the way, how does the regulation algorithm deal with open windows? Will it be paused for the time the window is open (e.g. 20 minutes) or will it steadily increase the regulated target temp?