A setting when HVAC Mode is OFF to not touch (state change) the underlying to allow for manual control of the underlying

[bwip]

Is there a setting to change the behavior when the thermostat is off to not change the underlying entity?

The use case would be to be able to control the underlying switch with a handcrafted automation.

For example when thermal solar is running, I would like to quickly turn off versatile thermostat to control the valve switches via an automation. The reason behind is, that I want to overheat the underfloor heating a little bit to "store" the heat.

Now, the behavior seems to switch the underlying off if the underlying is active. I know I could change the preset on the thermostat too but this inconveniently interferes with the heating target temperature scheduler (scheduler-component).

What do you think?

[jmcollin78]

Hello @bwip ,

Have you look at this ? https://github.com/jmcollin78/solar_optimizer. This can help for your usecase by changing preset ou temperature.

What you need is not to block the underlying but the Scheduler which will overwrite your preset change, I guess. What I suggest is to:

1. build an automation that: deactivate the Scheduler, change preset to Boost on the VTherm,
2. call this automation with Solar Optimizer or your own automation when production power is sufficient,
3. Do the same with another automation to réactivate the Scheduler which will then resent the "normal" preset to VTherm.

[bwip]

Thank you for pointing me to your solar_optimizer. Will definitely, have a look in it once I can invest in solar + battery.

Switching of the scheduler is an option, however then the last schedule action is not resumed.

E.g.:

• Scheduler: heat eating room at 10:00 to 12:00. Then after midday resume to normal temp.
• A lot of sun at 11 am, set the thermostat to boost or use custom automation to open the underfloor heating valve. Disable the scheduler.
• Sun is gone at 12:05; reenable the scheduler; scheduler missed event at 12:00 to reset the thermostat to the state before or the scheduled preset at 12:00.

I could work around with persisting the last temperature in a helper, but it would be more convenient if there would be a switch like in https://github.com/ScratMan/HASmartThermostat called force_off_state = False not to touch the underlying when thermostat is OFF.

I also run the smartthermostat for the rooms with floor tiles. I like your implementation more, because of the UI and the window detection feature. Nevertheless, the TPI algorithm does not work well with tiled floors. During heat up, the floor temp. has a lot of inertia. Than the temperature rises fast. At this point the thermostat needs to stop heating. With the PID controller in smartthermostat this works fine (high weight to the derivate term). Without this derivate term the controller would behave like your TPI controller, which would still heat a little bit until the proportional term gets smaller and smaller. This increases the overshoot of temperature however.

I would appreciate and test if you could add this little switch once you touch the code again.

[jmcollin78]

• Sun is gone at 12:05; reenable the scheduler; scheduler missed event at 12:00 to reset the thermostat to the state before or the scheduled preset at 12:00.

Are you sure ? I'm pretty sure the Scheduler is redoing the current state. There is an option "recalculate" or something like that.

[bwip]

You are right, the documentation of the scheduler card mentions:

If you enable a disabled time scheme: the schedule will determine which timeslot is active, and trigger this action immediately.

If a custom temperature is set before, it is then reverted to the preset temp. defined. That is okay. I will disable and reenable the scheduler entity in my automation.

Nevertheless, i still think the proposed setting would make sense.

Would it go in this method: start_cycle in underlyings.py?

        # if we not heat but device is active
        elif self.is_device_active: # BWIP: additional setting check here?
            _LOGGER.info(
                "%s - stop heating (2) for %d min %d sec",
                self,
                off_time_sec // 60,
                off_time_sec % 60,
            )
            await self.turn_off()
        else:
            _LOGGER.debug("%s - nothing to do", self)

[jmcollin78]

Nevertheless, i still think the proposed setting would make sense.

Would it go in this method: start_cycle in underlyings.py?

I do not understand what is your proposal.

[bwip]

To have a boolean in advanced settings called Force off state , defaults to True, to have the current behaviour.

If set to false and when the thermostate is in state HVACMode.OFF that it is not changing the underlying state, meaning it will not touch the entity.

This would allow to control the switch/valve manually (via automation or whatever) without needing to workaround with disable schedulers or disabling the versatile thermostat at all.

If the thermostat is put again in heating mode/cooling mode then versatile thermostate would resume taking control with its configured target temperature.

Similar behaviour like in the smart thermostat:

force_off_state (Optional): If set to true (default value), Home Assistant will force the heater entity to OFF state when the thermostat is in OFF. Set parameter to false to control the heater entity externally while the thermostat is OFF.

[jmcollin78]

Hello, Let see if other people are interested. You have another solution which is working out of the box.
So i'm really not sure that it is a must.

[bwip]

Let's see if there is common interest. The workaround to disable the scheduler is fine too. If it is a low hanging fruit in your next coding session, then I would appriciate if you go for it.

Another small advantages would be that I could switch easily between the generic thermostat, the smart thermostat and the versatile thermostat. Just put the one you don't want to use to OFF and force_off_state = False. Both the smart and the versatile thermostat have advantages. PID controller vs window open detection and the really confortable UI.

Nevertheless, thank you for your great work you are doing here.