Shouldn't generic_thermostat use hysteresis?

Development
1

Hi,
generic_thermostat uses cycle duration. IMHO it should use hysteresis.
Shouldn’t it?
Kind regards,
Jurek

1 Like
2

I read the part on hysteresis, and I vaguely know the term, but can you explain in more detail what you would like to see in the thermostat component?

3

In terms of code - I’ve just made it for myself, it’s here.
When temperature is close to its target, small changes, mostly because uncertainty of measure would switch heating on and off very often. To avoid this to change too often, original author of the component introduced rule that heating state cannot be changed too often, which is OK - that just works.
But common, more reliable and flexible is the rule that state of heater should be switched on when measured temperature drops a small delta below target temperature, and - accordingly - should switch off when temperature raised over target plus a small delta.
Using that rule gives more stable temperature, especially in condition of quick heating or cooling. This rule is used in almost all simple heating thermostats (however they may have also a timer which prohibits state change when a short, sudden change occurs - a open door etc.).
Delta should be selected to exceed temperature measurement uncertainty, it’s 0.2 - 1 degree depending of used thermometer.

3 Likes
4

Hi!
As Jurek proposed I think that hysteresis is very important to be included in the generic thermostat. Without hysteresis the heater is doing short start and stop cycles and more energy is consumed in every cycle in comparison with longer ones.
Thank you!

5

A pull request to add rhis featue is welcome

1 Like
6

@jaskey Why don’t you pull your code?

1 Like
7

The code itself seems to be ready, but I did’t managed to do required tests nor updated documentation yet.
That’s the reason…

8

Hi!
I’ve made my first pull request and it’s already merged in the development branch:

Shortly I hope it to be released in a new version update. I think you would like to hear about this.

Regards.

1 Like
9

Thank you. Besides simpler name, it’s almost identical to my version :-). Now it’s further work to do: make it able to switch after time lapses, even when temperature didn’t changed any more. Using simple wait causes tests not passing, so it may be more efficient way to do this (a Timer?)

10

Sorry, I didn’t use your code. Because in your code there was an error using the same condition “too_hot” and “not too_hot” for switching on and off. It would be the same than before changing tolerance by histeresis/2.

Please, note that in my code I use two different conditions. For example in heater mode, I use “too_hot” for turn off and “too_cold” for turn on. You can see in the documentation what that means:

tolerance (Optional): Set a minimum amount of difference between the temperature read by the sensor specified in the target_sensor option and the target temperature that must change prior to being switched either off or on. For example, if the target temperature is 25 and the tolerance is 0.5 the heater will start when the sensor goes below 24.5 and it will stop when the sensor goes above 25.5.

I don’t understand what you refer about switching after time lapses. If the temperature is always above the target in heater mode it shouldn’t turn on the heater any more. Isn’t it?

One new improvement will be the thermostat to have defined two devices, one for heater and one for cooler. Then the thermostat will be able to switch heating or cooling mode automatically (new mode automatic?). This would be great!

11

Oh, no, I’m not complaining. According to principle of minimal changes, we made they very similar. Code is very clear, so it’s all OK.
About the time lapse: consider following scenario:
Temperature is set to 20, 0.1 tolerance, min cycle duration 10 minutes. Thermometer resolution is 0.1, too.

  1. Temperature drops to 19.9 - heating is on,
  2. Within eight minutes, temperature raises to 20.1, but switch remains on because of cycle duration.
  3. After 10 minutes, Min cycle duration passes, but switch remains on, because there is no temperature change that would trigger thermostat,
  4. Switch will be on until temperature raises to 20.2 (which is definitely wrong).
    Of course, there are other means to trigger the event, ie. increasing thermometer resolution. But doing this to its uncertainty level produces noise in event bus…
    Is it clear?
12

Ok! I’m sorry. Now I understand what you mean. I think it allways will stop when temperature is above target + tolerance independently of the time lapse. Because tolerance is not added to the last reading. If you read the code it’s allways comparing the target and the current temperature within the tolerance difference. Have you tried?