Forcing off time at each end of the cycle

[ms5]

I am looking for a solution to force the thermostat OFF at the end of each cycle for some time. I currently have Legrand analog wall thermostats installed and they work with a PWM where after each cycle the relais stays off for some time. On the Legrand thermostats this is not really configurable, but I was able to measure what happens and the intervals by connecting a shelly to the thermostat and watch it for some time.

I thought about how to achieve this and a very easy solution that I came up with, is to multiply the calculated ON seconds with a configurable multiplicator to limit the max. ON time to a certain amount per cycle. Here an example: The cycle is set to 10min, the multiplicator is set to 0.75, if VT calculates an on time of 100% = 600seconds, this is then multiplied by 0.75 so we get 450seconds ON time and 150seconds OFF time.

I have attached a little graph that show in red the ON time and in blue the min. forced OFF time. The example uses the above parameters.

I tested this solution over the last weekend and it seems to work very well. For my example (to replace the Legrand Thermostats) I used a cycle of 10min, a min activation delay of 3min and a multiplicator of 0.6. This gives me an ON time for a heating cycle between 3 and 6 minutes and at least 4min OFF at the end of each cycle. The times still vary depending on the calculation, but at least 4min OFF at the end of each cycle are guaranteed.

I have made a POC of this that can be found here: https://github.com/ms5/versatile_thermostat/tree/output_time_modifier

The configuration can be made globally in configuration.yaml

versatile_thermostat:
    output_time_modifier:
        multiplicator: 0.75

I would like to get some inputs and hopefully get this integrated.

[jmcollin78]

Hello @ms5 ,

By doing this you are cheating with the TPI algorithm and then you will not be able to reach your target temperature.
This is not something, I recommend.

My advice: change the faulty thermostat. I consider asking to change an algorithm because of a faulty equipment is a very bad way to fix an issue.

So, you understand, I will not integrate this. Of course you can keep your fork if you want.

[jmcollin78]

If you have a climate that calculate for you the onPercent and do the correct specificities of your device, then you just put a VTherm over it, and voilà.

I have also checked how other projects approached this and for example smart pid thermostat has an output clamp setting, which limits the output to a max value

This is an option. Having a max value is something easy to do (but in expert mode to avoid over complexify the configuration)

[ms5]

If you have a climate that calculate for you the onPercent and do the correct specificities of your device, then you just put a VTherm over it, and voilà.

If I have to write a complete new thermostat, what is the point of using VT. I still don't see the benefit, since everything I use from VT would have to be implemented in the new entity too.

I am personally also more a fan of bundling efforts into a project, than making 100small ones that will die soon anyways. Versatile thermostat is therefore a great project and you already put so much work into it.

This is an option. Having a max value is something easy to do (but in expert mode to avoid over complexify the configuration)

My proposal has this settings in the config file. I think, chances are small someone could enable it accidentally and defaults are not changed. I can certainly rename it to something "expert". The already existing "expert" mode auto_regulation_expert is IMHO more related to regulation so I will not put it under there. I think a new section will be clearer. What would you thing about this?

versatile_thermostat:
    expert_output_on_time_modifiers:
        on_time_scaling: 0.75 # [float, default to 1]
        on_time_clamping_high_percentage: 0.75 #[float, default to 1]

I have also made a graph to visualize the outcome of the two different modifiers. I personally belief that scaling will deliver better results, since the scale of the calculated value will be kept. Although I have to admit I have not tested clamping yet. I belief there are use cases for both.

[jmcollin78]

If I have to write a complete new thermostat, what is the point of using VT

That is not my point. I suppose you already have an climate entity given by your thermostat vendor to handle the specificities. If yes, you just have to put a VTherm over it (over_cliamte).
Else, my words make no sense and you can safely ignore it.

I think a new section will be clearer. What would you thing about this?

Yes fine. If have another proposal: have a max value for the on_percent. The on_percent is calculated by the TPI algorithm and give the percent of time the heater should be on. If we clamp it to a max value < 1, you will always have an off perid equal to (1 - on_percent) x cycle_min minute. And so we just have one value to set with something like that (no need of subsection):

versatile_thermostat:
    max_on_percent: 0.8

But once more, you will generate disturbances in the heating regulation and could never reach the target temperature with such a parameter.

[ms5]

That is perfect and will work. I will implement it and create a pull request. Probably somewhere along this week.

[jmcollin78]

ok fine. Please start from the last beta else you will have a big merge. I will release it soon.