Controller previous setpoint not correctly restored

[lievendf]

Hi,

First of all thanks for creating this integration!

When turning off the integration the original setpoint of my controller is not correctly restored and I think I know why this is happening.
The climate entity for my controller has 3 modes: automatic, on and off.
These map to my thermostat, on = use daytime stored setpoint, off = use nighttime stored setpoint, auto = use time schedule to switch between day/night setpoint.
The important part is that in all 3 modes the setpoint can be adjusted, either using the thermostat itself, or through the climate entity in HA.
Adjusting the setpoint in on (day) of off (night) mode stores this as the new setpoint for that mode.
Adjusting the setpoint in auto mode causes a temporary setpoint, which gets discarded once the schedule switches from day to night or vice versa.

zoned-heating, when activated, always switches to on (day) mode and sets a new setpoint. That setpoint is then, by the thermostat, assumed as the new daytime fixed setpoint.
When zoned-heating is turned of, it switches back to the previous mode, which is practically always auto, and applies the previously stored setpoint from before the integration was active.
However this setpoint is now applied in auto mode which means the setpoint for daytime is not restored, and instead a temporary setpoint is applied...

Could it be an option to not switch mode and just apply setpoints in the current mode?
Or perhaps first restore the setpoint in the current mode, and then (after a small delay) switch back to previous mode?

Regards,
Lieven

[nielsfaber]

This behaviour seems very specific for your thermostat, and arguably is not even compatible with HA's definition for a climate device (since heat / off states should not refer to different day/night modes with their own setpoints).

Currently the controller is restored by first setting the hvac_mode back to its former setting, and then the setpoint is restored to its former setting.
This all is performed without any delay, so for your thermostat the commands will arrive more-or-less simultaneously.

perhaps first restore the setpoint in the current mode, and then (after a small delay) switch back to previous mode?

I know that some thermostats have a preset setpoint, which is applied when switching modes.
So when switching to mode 'heat', a thermostat could set itself to 20C.
For that reason the setpoint is sent afterwards.
Switching the order could improve things for you, but could break functionality for others.

Could it be an option to not switch mode and just apply setpoints in the current mode?

I could add a configuration option for this.
Such option would apply to both the override behaviour (so calculating new setpoint for the controller when a zone is turned on) and for restoring the thermostat afterwards.
If this solves your problems it's a small effort to add this.

[lievendf]

I have a Buderus central heating system that is available in HA as MQTT devices/entities by using an EMS-ESP32 gateway.
I guess on/day, off/night, auto/schedule was the most logical way for the developers to map the hardware to a climate entity?
In fact I have never turned the thermostat off in 10 years, but only changed setpoint or schedule...
Changing setpoint in HA using the climate entity card seems to work in any mode, so perhaps this just isn't explicitly restricted?

Currently to be able to use the integration I manually switch my thermostat to On (Day) mode before turning on zoned-heating.
That way I ensure proper restore of settings when zoned-heating is turned back off.
I proposed two options that might make this extra steps unnecessary, but I'm not sure they don't come with side-effects or drawbacks.
E.g. what if the schedule switches from day to night (on to off) while zoned-heating is active?
Let's say I haven't done the analysis yet ;-)
I'm no Python dev but I'm willing to try out some things if that helps.
Thanks.

[lievendf]

Could it be an option to not switch mode and just apply setpoints in the current mode?

I could add a configuration option for this. Such option would apply to both the override behaviour (so calculating new setpoint for the controller when a zone is turned on) and for restoring the thermostat afterwards. If this solves your problems it's a small effort to add this.

Hi Niels, if you could add such an option that would be great!