Add an adaptative regulation in over climate mode

[jmcollin78]

Following a discussion in #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 #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]

@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?

[jmcollin78]

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?

When the window is open, the VTherm is shut off. Then then temp will go down and the offset be at its maximum. When the window is closed, the VTherm turns on and send the maximum regulation to underlying this will boost the heating of the room. And progressivly the offset will recover the stable value.

I guess this is expected behaviour and the big advantage to have an offset which is depending of the conditions.

[maia]

When the window is closed, the VTherm turns on and send the maximum regulation to underlying this will boost the heating of the room.

It very much depends on the construction and outdoor temperature if this is helpful or not. Because one could also argue the other direction: When a room that was constantly at 20°C is filled with cold air for 30 minutes and it's air temperature drops to 17°C, this does not mean it needs to be heated at all. As all walls, the floor and the ceiling all still have 20°C and hold temperature much longer than air, the room might be back to 20°C within another 30 minutes even with no heating at all.

In situations with bad construction that does not maintain temperature long and with very low temperature outdoor it's different.

But think of a big church and how it can hold its temperature over months. It all depends on the mass of stone/concrete/… you're surrounded with.

Also it seems you don't trust how TRVs regulate the valve and try to boost its regulation. This is a completely different use case than what I was describing in the past 2 weeks: current_offset = long_term_difference_of_target_temp_and_room_temp + (target_temp - outdoor_temp) * factor, where factor would be about 0.05 in my specific case.

[adi90x]

Hello,

Instead of using 3 different classes ( or even 4 in code ) why don't we have only one```RegulationParamXXX`` and let user input all parameters in setup ? ( Same one service can be use to update all those parameters ) and then maybe only put some basic parameters in the documentation ?

    kp:float = 0.6
    ki:float = 0.1
    k_ext:float = 0.2
    offset_max:float = 4
    stabilization_threshold:float = 0.1
    accumulated_error_threshold:float = 30

[jmcollin78]

Instead of using 3 different classes ( or even 4 in code ) why don't we have only one```RegulationParamXXX`` and let user input all parameters in setup ? ( Same one service can be use to update all those parameters ) and then maybe only put some basic parameters in the documentation ?

Because it makes 6 different parameters + 2 parameters (dtemp and period) to input which is very much complicated.
Let see if those values make the trick.

[adi90x]

Instead of using 3 different classes ( or even 4 in code ) why don't we have only one```RegulationParamXXX`` and let user input all parameters in setup ? ( Same one service can be use to update all those parameters ) and then maybe only put some basic parameters in the documentation ?

Because it makes 6 different parameters + 2 parameters (dtemp and period) to input which is very much complicated. Let see if those values make the trick.

Maybe it could be a new page in config when regulation is ticked no ?

[jmcollin78]

I thought about it but, really i want to keep it as simplier as possible. I'm pretty sure the parameters given will satisfied 99% of the needs.

There is already 60 parameters now, and it is very important to keep that as simplier as possible for most of the users. I see some PID algorithm and other AI algorithms with lot a confusing parameters and many people having great difficulties to use it. That is not my philosophy.

But what is possible, is to have an "expert mode" in the Switch type page, and then a new page or a config in configuration.yaml. So that expert people will be able to specify their parameters. In that expert mode, it should be possible to specify a static value as asked by @maia .

But for now, because, I do a lot of work on the last month, I will make a pause and wait for user feedbacks on the current new self-regulation.

Feel free to propose a PR in the mindset exposed above if you think you can do it and have time for this. I would be please to merge it.

[jmcollin78]

I add a Discussion section on the root page of Versatile Thermostat if you want to continue this discussion