Add an expert auto-regulation mode in which we can specify our self-regulation parameters

[jmcollin78]

Self-regulation algorithm have a fixed number of presets Light, Medium, Strong, Slow.

For many cases, we need to have a more flexible way to configure it. We need to specify our parameters.

I suggest being able to specify these parameters in the configuration.yaml file so that the configuration process will not be complexioned more than today.

The user choose "Expert" auto-regulation mode and then add a section into its configuration.yaml file.

Then those parameters are used by the self-regulation algorithm.

-- Note: this feature will enable some default configuration in the configuration.yaml file allowing for future use.

[maia]

Jean-Marc, I'd like to ask you to ensure that this feature does not prevet future versions of versatile_thermostat to use different variables for auto-regulation. The reason is that I don't think the ones that are available now are an optimal solution. When the new slope calculation is available (and slopes of different time frames can be calculated), the auto-regulation could be improved drastically, for example by allowing the overlay of short-term adaptations and also long-term offsets. I'd like to contribute to that, but if you create a specific structure required in configuration.yaml that will cause issues when the structure is changed in future versions, this would make it very complicated to add some optimisations.

[jmcollin78]

I understand but many people needs to adapt their configuration. See the post of gunmalmg here https://github.com/jmcollin78/versatile_thermostat/issues/188 for example. I've got other people with very good regulation with those parameters:

    kp: float = 0.4 
    ki: float = 0.08
    k_ext: float = 0.0
    offset_max: float = 5
    stabilization_threshold: float = 0.1
    accumulated_error_threshold: float = 50

What works fine is to set to 0 the k_ext and have a big accumulated_error_threshold. While error is not 0, the accumulated_error will grow up and regulation will finish by succeed.

So while I wait for an eventual modification of the algorithm, I have done this to allow people (and me as support) to test and adapt the parameter without having to republish something.

This is done now, documentated I will release soon. When I will have your algo, I will do an evolution to adapt this. It will be easy. No worry.

[maia]

Thanks. How complicated is it for you to persist the accumulated error (or in other algos something similar like a EMA) on a reboot of HA? That would be great, as currently testing long term algos is very challenging.

[jmcollin78]

Not so hard. I have this in mind. When temp = target, the error is reseted. So the normal state is when accumulated error = 0. So in a normal case (the temp will converge), persisting the error is accumulation is not useful. It is useful only in transitory mode.

You can see that because the accumualted_error is published in the VTherm attributes so you can check its evolution.

[maia]

I‘m currently not near a HA installation, but I think for being able to adjust to long term offsets it may not be resetted, as otherwise each time the preset changes and for a brief moment target temp and current temp are the same, anything that was built up in the past 6-17 hours is lost.

[maia]

Here you can see what happens (using the „slow“ setting) to a long term offset of 1,0-1,5 degrees when HA restarts (at around 10:00).

When accumulation rests at target=current it has the same effect and completely counterproductive.

Please disable that setting for the slow mode and persist the accumulation, thanks.

[jmcollin78]

ok it is clear. That mean, your accumulated error never goes to 0 but will stabilize to a value when error is 0. that is clear and I will remove that.

[jmcollin78]

https://github.com/jmcollin78/versatile_thermostat/issues/199

[jmcollin78]

In 4.1.0 Release

[jmcollin78]

Hello @maia ,

I've got an interesting case this morning here: https://github.com/jmcollin78/versatile_thermostat/discussions/191

Before 6:30 the VTherm have accumulated much error because target was 2° under the current temp. At 6:30, the target change to 18°, above the current temp. The user expect that the valve will open (slowly). But because of this accumulation of negative error, the regualted temps stays at 15,5°. I pretty sure it will finish by growing up.

This is the side effect of not reseting the accumulated_error after a target temperature change that I remove in a previous release.

Do you agree with me that, this is mistake ? When changing the target temperature I should reset the accumulated_error because it is no more relevant. I think yes, but I want your opinion.

EDIT: this will be an issue with mobile average and that is why I'm curious of your algorithm. How to take the historical values but adapt to new conditions quickly.

[maia]

@jmcollin78 Oh, that was the discussion about. I've seen it, but decided to unwatch the discussion as my french isn't good enough for comprehension.

Regarding the accumulated_error, I understand the issue. And I'm not sure about the right answer that's suitable to all, but here is an attempt:

1. I don't know which regulation setting the user has, but I'm irritated about the negative offset increase (target/regulated) from 1°C to 3°C between 4:00 and 5:30. This is most likely not the "slow" setting and I wonder if the regulation setting he/she is using is suitable for the local environment. I would not like a regulation to change the offset by 2°C within 90 minutes.
2. The building he/she is in has a temperature loss of 0,5°C within 4 hours (4:00 to 8:00). I think it is not suitable to use presets that have temperature differences of 2°C. If I know that my room will take 16 hours without any heating to drop by 2°C, why would I use a "night" preset that is 2°C below the previous preset? Using "wrong" presets with too big temperature differences will always cause issues with self-regulating, as the algo can never "learn", because the temperature is always off, either too high or too low.
3. …or, alternatively, was the room heated by another source, e.g. an open door to another room?
4. Speaking in general, it might be suitable to reset the accumulated error for short term regulation (like in your specific use case) but it is not suitable for the long term regulation (which I prefer to call "offset calibration"). As mentioned in #200, it might be necessary so split the code into 4 aspects of adaptation – and in that case the long term offset calibration might be treated differently on a preset change.
5. Additionally, I think it makes a difference if the accumulated error is negative or positive. Maybe these errors need to be calculated separately and only one of these is used? But again, that's more of an issue related to the aspects 1+2 above and to the "strong/medium/light" setting. With the "slow" setting the user would not have had the issue he/she experienced.

For now, the quick-fix might be to disable the reset of accumulated_error only for the slow setting and keep it for the others?

Once you have the code ready for slope calculations I would draft a concept for something that mixes the 4 different time frame aspects mentioned in #200. Does github have a place for collaborative/wiki style edits? Then the 3-5 people who are interested enough might collaborate on a concept before coding it.

[jmcollin78]

This is the strong setting. I will do a test with it with the reset to see if it solve the issue. And then you certainly right, some mode or algorithm needs to reset and some others no.

Once you have the code ready for slope calculation

For now I just don't start because of making many support.