Service-call climate.toggle always turn A/C units to Cool when toggled ON. Regardless og previous hvac_mode when toggled OFF

[gunmalmg]

Hi

I use the service call climate.toggle to switch many VT-termostats on and off. It functions fine on heating cables and ovens, but when performed on A/C unit it turns off the A/C unit fine, but when the service call toggles the A/C unit ON again, it always turn the A/C unit to "Cool" regardless off what hvac_mode it had when it was toggled off. So when eg I toggle off a A/C unit that was in hvac_mode: heat, and then toggle it back ON - it goes in to hvac_mode: cool.

It would be nice if the VT could remember the hvac_mode between on and off toggle. So it comes back into previous hvac_mode. Suggestion : could you use the vt-attribute "saved_hvac_mode" for this ?. The attributes "saved_hvac_mode" don't seemes to hold any value regardless of the current hvac_mode.

Thank you again for your grate work.

Regards Gunnar - Norway

[mag2352]

This is something that is easily resolvable, but from what I can tell, anything else that calls save_hvac_mode() can interfere with your suggestion. I did confirm, that it does work, but if a window state changes (or safety triggers, or overpower check triggers a save_hvac_mode()), this will result in the saved state being overwritten. Overall I will likely propose this as another issue altogether, but this could be resolved here in a single PR.

Firstly, windows being opened should not change the hvac_mode of the VTherm itself, it should only change the underlying entities (see BetterThermostat). The biggest issue with the current setup is the fact that I cannot use a scheduler to change the state of a VTherm to off if a window is open. The VTherm will restore the previous hvac state when the window is closed again, turning the VTherm back on. If a window is open, the VTherm is "off", even though it is not "off", it is just waiting for the window to close to turn the underlying entities back on.

I have 2 commits to propose here, one that addresses the toggle issue, and a second that addresses the window issue. Firstly, I'd like to mention that the same changes proposed for the windows should be applied to check_safety and check_overpowering, but I don't use those features (I suspect the changes for those would be trivial as well).

[mag2352]

This commit addresses the restoring of the state when using climate.toggle. I would make a PR, but I have other changes made there that aren't relevant.

mag2352/versatile_thermostat@6104d544d57e2e23d2b8c4dc3d9a27c0422faa03

    async def async_turn_off(self) -> None:
        self.save_hvac_mode()
        await self.async_set_hvac_mode(HVACMode.OFF)

    async def async_turn_on(self) -> None:
        if self._saved_hvac_mode != None:
            await self.restore_hvac_mode(True)
        else:
            if self._ac_mode:
                await self.async_set_hvac_mode(HVACMode.COOL)
            else:
                await self.async_set_hvac_mode(HVACMode.HEAT)

[mag2352]

This commit changes the window system so that the VTherm unit is not turned off (but the underlying entities are). This allowed for me to use the toggle functionality (and the scheduler) without having window states messing with the VTherm.

Edit: It might be easier to just edit the original async_set_hvac_mode to check for the window/central/overpower/safety flags rather than creating a duplicate function (but this isn't as simple as it seems). I think this change should definitely be implemented in the next version, as it makes the behavior of the VTherm more verbose. To elaborate, let's say that I have a window open. The VTherm would have an HVAC mode of "off". Upon looking at this, I can't tell if the VTherm is actually off (but the window is open), or "off" because the window is open (and would turn back on if the window closes). If the VTherm is in the second state, I can't turn it off unless I close the window, wait for it to turn on, and then turn it off again. Additionally, if the window closes, and I make a change to the HVAC mode manually before the window timeout triggers, the change I made would be overwritten by restore_hvac_mode. This makes it difficult to use the VTherm with the scheduler integration (the scheduler might turn off the VTherm when it's in the "off" state, which would not actually turn off the VTherm, as closing the window would make the VTherm turn back on).

mag2352/versatile_thermostat@c004a91007e9624643543532f91839b255e07785

[jmcollin78]

Hello,

Nice suggestion. I will try to implement this.

On my side I never use the Toggle feature on device which are able to do heating and cooling but I only click on the right mode I need.

[gunmalmg]

Nice if you can implement this. 😀

I think I have more cool/heat-units(heatpumps) than moste people have. This is the list of VTherm in my home. And I have similar number of units in my two cottages.

To save as much energy as possible - when we move from place to place - I use the presence entity to alter the presets automatically. But we also make use of the ability to toggle some climate entities on/off to even save some more energy. In our climate we can have heatpumps in both cool og heat state in different rooms/areas at the same time. When my wife leave or come home, I would like her to not have to consider witch state this heatpumps have to be set in - just toggle them on/off by an automation. Hope this is possible

Regards

Gunnar - Norway

This is the list of VTherm's in my cottage in the south of Norway

[jmcollin78]

Hello,

I take some time to look deeper in the suggestion of @gunmalmg and the first proposition of @mag2352 and also the PR described here: https://github.com/jmcollin78/versatile_thermostat/issues/468

What I can say for now is that:

1. keeping and restoring the previous hvac_state for heat pump seems a good idea and the implementaion of @mag2352 seems to do the trick. So I will implement and test that (maybe in this week-end if this doesn't generate regressions),
2. to go to the direction of @gunmalmg, I wish to implement an auto on/off feature for over_climate to "save more energy" by turning off when the current temp is far under target temp (in cool mode) or far above target temp (in heat mode) and turning on when the conditions are no more met. So I need also a "memory" of the last state to turn on in the right mode. With that, normally, @gunmalmg will no more need to turn off and turn on (or only on special case)
3. for window detection proposition of @mag2352, it is more complicated and do not with to generate desynchronization state between the underlying and VTherm. This will break and over complexify the rule "VTherm is always following its underlying which can be modified directly".

So I will keep you in touch which this.

[mag2352]

@jmcollin78 Understood, and fair point on the window detection. I use the scheduler integration, so having the VTherm desynced if a window is open is the only way to ensure the VTherm works with the scheduler integration (if the VTherm entity is being scheduled). I have this feature on my own fork, so if it doesn't get implemented on your version, it is okay.

A quick question about the VTherm. If the VTherm is set to 23C, and I change the underlying climate entity to a target of 24C, does the VTherm get changed to 24C? If this is the case, I can use the scheduler on the underlying entities instead (should have thought of this earlier).

[jmcollin78]

A quick question about the VTherm. If the VTherm is set to 23C, and I change the underlying climate entity to a target of 24C, does the VTherm get changed to 24C? If this is the case, I can use the scheduler on the underlying entities instead (should have thought of this earlier).

Yes. This is the "VTherm follows the underlying change" feature so that you can interact directly with your TRV or Hvac system.

[jmcollin78]

I have done a beta release implementing the first need exprimed by @gunmalmg , and ensure this is coherent with the window detection state.

For that, I simply refuse to Turn on a VTherm over_climate when the window have been detected as open (at the end of delay OR with the auto-window detection algorithm). So, the saved_hvac_mode is NOT overwritten and loose if you toggle or try to turn on the VTherm during the window open detection.

It works fine on my env, but maybe you can give it a try to have your opinion too.

Thank you (I will release tomorrow certainly).

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

[jmcollin78]

I do some tests and for me, the behavior is now great.

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

[gunmalmg]

Hello

The "ac-toggle" seems to be working nicely now. 😀

Thank you @jmcollin78 👍