A self-regulated VTherm over_climate doesn't follow the underlying temperature changes

[jmcollin78]

Discussed in https://github.com/jmcollin78/versatile_thermostat/discussions/472

^{Originally posted by **2fst4u** June 16, 2024} Hi, so far this is awesome, it's just what I'm looking for. I'm a bit confused about how the thermostat behaves when using it with another climate entity (in my case a heat pump). When I turn off the versatile thermostat, my heat pump also turns off which I would expect. When I turn on the versatile thermostat, my heat pump turns on too. Great! But when both are off and I go to turn on the heat pump manually, either in home assistant, or from its own app, or with the physical remote, then the versatile thermostat also turns on and starts interfering with the settings. Is there any way to prevent this? If the heat pump is manually turned on I'd like the versatile thermostat to remain off so that the manual settings can be used. The reason for this is not everyone in my household has the need or desire to use home assistant to control the settings and if they manually turn on the heat pump then they'd prefer to just have that manual setting remain what it is set to. Is this possible at all?

[2fst4u]

You beat me to it haha. Let me know if there is anything you need from me

[jmcollin78]

I've made some tests yesterday and I can confirm there is a bug. Thanks for your report @2fst4u !

[2fst4u]

No problem it's good to know I wasn't going crazy!

If it helps at all, one minor correction: when changing the underlying climate temperature, vtherm does actually go into manual mode. It just doesn't follow the temperature set is all.

[jmcollin78]

Hello, I come back on this issue, look at the logs and see what happens:

if your VTherm is regulated (have self-regulation configured), it will not follow manual configuration done directly on the underlying device. This is to avoid loop I guess. Self-regulation sends target temperature to underlying with an offset (that is how VTherm does the regulation), so the target temperature of the underlying is not the desired temperature of the user. I guess this is why I have done this.

See the piece of code, this is explicitly written:

if (
                # we do not change target temperature on regulated VTherm
                not self.is_regulated                                   <----------- here
                and new_state.attributes
                and (new_target_temp := new_state.attributes.get("temperature"))
                and new_target_temp != self.target_temperature
            ):
                _LOGGER.info(
                    "%s - Target temp in underlying have change to %s",
                    self,
                    new_target_temp,
                )
                await self.async_set_temperature(temperature=new_target_temp)

But when thinking about it, I wonder if it is a good idea and I don't remember exactly why I add this line.

So, the first question is: do you have configured the self-regulation on your VTHerm ? You can see that in Development Tools/States

[2fst4u]

I do have self regulation configured, yes. My hope is that using the physical remote will cause vtherm to use that new value as the vtherm temperature setting.

[jmcollin78]

Yes I understand, that was also what I expect when I do some test and was surprise it was not the case.

I will try to remove this test and do some test on my env. If I do a beta with this change, can you give it a try ?

[2fst4u]

Yea sure. Would it be pushed as a beta version within HACS? I can do that definitely.

[jmcollin78]

I do archeology search, and this line have not been added because of an issue but is there from the beginning of self regulation.

I will try without the line.

[jmcollin78]

ok, I have done some test, and the behavior is very bad. Within minute I got a divergence in temperature setpoint. With regulation VTherm sends target+offset, the underlying apply it. At the first change of the underlying (vtherm receive a notification like Underlying climate climate.underlying_thermostat2 have changed), the target+offset is set as target in VTherm, which apply the offset another time and so on.

So that is why a regulated over_climate VTherm cannot follow the underlying temperature change.

[jmcollin78]

Finally I found something which seems to work fine. If you can give it a try: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4.beta5

During your test, remember that you should wait between the last modification sent by Vtherm and a manual action on the underlying device, else it will be ignored.

[2fst4u]

I'm just out of the country at the moment so I'll have to try when I'm home in a couple of weeks and I'll let you know. Thanks!

-------- Original Message -------- On 13/10/24 17:33, Jean-Marc Collin wrote:

Finally I found something which seems to work fine. If you can give it a try: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4.beta5

During your test, remember that you should wait between the last modification sent by Vtherm and a manual action on the underlying device, else it will be ignored.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[jmcollin78]

All my tests are ok now. I will release soon.

[jmcollin78]

https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4