Homematic Thermostat: Temperature switches to 5°C after window open/close

[Ra72xx]

Describe the bug

I still use a few Homematic thermostats. They seem to react strange to the window open/close function of VT:
They switch off and on when opening and closing the window, which is the expected and intended procedure. However they are always set to 5°C when getting turned on again after the windows closes again.
It looks as if the thermostats default to minimum temperature when getting turned on, and not to the last set temperature.
So maybe VT should preserve the current temperature setting, too, when going in the window-off mode, and restore it afterwards. (Additional complexity when you have also an schedule running to change the temperature which can also kick in while the window is open, this should be respected somehow, too...)

[jmcollin78]

Hello @Ra72xx ,

When you open/close the window, do you have a preset selected ?
Can you post me your Developement Tools / State for the VTherm ?

You should see:

saved_preset_mode: boost
saved_target_temp: 17
saved_hvac_mode: null

when window is open. Theses are the values that will be restored after the window is closed.

[Ra72xx]

Here a log. In this case without a preset selected, but it's the same with a preset. Thermostat turns always on with 5°C. In this example it's a bit difficult, because there are 4 thermostats controlled by VT. This is only for Homematic thermostats, it doesn't happen with my Aqara E1 thermostats.

home-assistant_versatile_thermostat_2023-10-21T16-27-33.217Z.log

[jmcollin78]

Huuum, it is coincidence, but i'm currently see some weird thing about window temperature set.
You have a preview fix in this release: https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.6.0.beta4

It is not fully tested on my side but if you can, it would be valuable that you give it a try.

I will finish the test in //.

[Ra72xx]

I'll look at it, thank you.
I have the impression (no proof, only gut feeling) that the fix for #123 introduced some strange side effects. Maybe this is related?

[jmcollin78]

I have a look at your log, and here is what I have found:

1. you have a VTherm over 4 climate,
2. the window open is detected and shutdown the 4th climate (Stopping underlying entity climate.wz_thermostat_0),
3. the 4th climate are off (_async_climate_changed new_state...),
4. windows is closed (you have a very short delay 3 sec),
5. Heat mode is restored: (Restoring hvac_mode 'heat', target_temp is 22)
6. The 4 climate sistch to on (_async_climate_changed new_state is <state climate.wz_thermostat_2=heat and temperature=5.0)

The problem is that when turning on your underlying climates they swith alone to 5. And because now VTherm is following the underlying temp, Vtherm switch to 5°. This is due to #101 which have many side effect (and not #123).

What I will do is to force the temperature update after turning on an underlying climate. It will solve your issue.

[jmcollin78]

Fixed in 3.6.0. Tell me if this does the trick !

[Ra72xx]

Thanks for the quick fix once again.
However, I had to remove the Homematic thermostats from VT, because they are simply not usable: The Homematic radio technology has some kind of "duty cycle", which means the devices are only allowed to send a certain amount of time per hour. Obviously VT in combination with four thermostats runs into this limit, which means that suddenly no more transmission is taking place and the whole setup gets in an undefined stage as one device after another seemingly drops out of the network..
"Better Thermostat" has a special mode for Homematic because of this. However, as I'm currently thinking of getting rid of this system altogether, I won't pursue it any further..

[jmcollin78]

Ok fine. I will add this Homematic TRV into the incompatible chapter, I start.
Thanks for the tip.

I will keep the enhancement, which sends the target temperature after turning on a over climate. I think it was missing anymawy.

[Ra72xx]

It might not be outright incompatible, but it seems to get problematic if too many devices get driven by another entity which doesn't implement some kind of duty cycle management. I could probably have worked around if I'd paired those thermostats internally with the methods the Homematic protocol offers, so that only one thermostat has to receive the commands from VT and propagates them "internally", but that was too much of a hassle.

[nurunet]

Hi, I have the same issue. In one room, I have a Homematic heating group and an Aqara TRV combined via VT. After ventilating, the target temperature remains at 5°C. It does not switch back to the previously active preset. I am running VT 4.3, I think.

I am wondering if this is linked to the HmIP heating group having its own "window open" logic which also defaults to 5°C.

[jmcollin78]

Hello @nurunet ,

Homematic are known to badly work with VTherm: https://github.com/jmcollin78/versatile_thermostat?tab=readme-ov-file#incompatibilities

They have their own internal logic which don't work fine with VTherm. So sorry for this bad news.

If you to change, I recommend the Shelly TRV for which will able VTherm to pilot directly the percent of valve opening. So you have a full VTher feature and a still a TRV.