Feature request: prevent repair_incorrect_state from fighting manual control of the underlying climate when VTherm is off

[romain-bury]

My setup is the following: I have VTherm 10.0.2, with four over_climate VTherms driving Mitsubishi heat pumps via MELCloud Home. repair_incorrect_state is on in the central config.

My dashboard has an Auto / Manual toggle per room. Manual just sets the VTherm to off, and I can drive the underlying climate entity myself (sometimes I want one unit at my own setpoint for an hour, with no regulation). Same thing when central mode is Stopped and I turn a single unit on by hand.

The issue is that, at every cycle, repair sees the underlying on while the VTherm is off, and turns it back off:
Example :
19:18:09 I turn the living room AC on manually (cool). pac_salon still off.
19:19:13 PAC Salon - RepairIncorrectStateManager: underlying
climate.melcloudhome_83b0_61eb_climate was repaired. Consecutive repairs so far: 1
19:19:21 underlying back to off
19:19:31 I turn it on again
19:24:13 ... Consecutive repairs so far: 2
19:24:15 off again

I read #2020 and #2021 first. The PR says the resync is deliberately bidirectional, "underlying on while VTherm is off" included, and in #2028 you say off has priority over everything else. So I assume this works as intended and I'm the one holding it wrong.

The trouble I see is that "VTherm off, underlying on" is the same state for two opposite situations. Either VTherm sent off and MELCloud dropped it (repair is exactly right, otherwise the unit runs all night), or I temporarly want VTherms off, and turned the heat pump on myself and repair undoes a deliberate action).

Two possible options, as I see it.

1. A runtime switch to turn repair off per VTherm, like switch._enable_auto_start_stop. As far as I can tell, repair is the only feature that can force the underlying off with no runtime escape hatch (auto-start/stop has its switch, window has set_window_bypass, repair has neither switch nor service). It's also the workaround you suggested in After auto-start/stop activate, we can't use the climate on other mode #2028 for auto-start/stop, so it would be consistent. Downside is I have to remember to flip it, and it desyncs if the VTherm goes off from anywhere but my own dashboard.
2. Have repair read hvac_off_reason and skip on hvac_off_manual and hvac_off_central_mode, while still repairing on hvac_off_auto_start_stop, hvac_off_window_detection and hvac_off_safety_detection. VTherm already knows why it's off, so
   nothing to flip, nothing to desync. The cost is that a genuinely dropped off command would no longer be caught in those two cases (a grace period after VTherm's last command would keep both).

I feel like Option 2 would be nicer for me day to day, but it could have unintentional effects elsewhere or for other users. Option 1 looks simpler. In any case, they probably aren't exclusive.

Which one would you rather see, if either? Or is there an existing way to tell a VTherm "stay off but leave the underlying alone" that I missed? I went through the entities and services and found nothing (set_hvac_mode_sleep is valve regulation only, lock goes the other way). I doubt I'm the only one who wants to grab a unit by hand once in a while.

Happy to hear your feedback.

[jmcollin78]

Hello @romain-bury ,

The behavior is intentional: when repair_incorrect_state is enabled, VTherm remains the sole controller of the underlying entity and ensures that it follows VTherm's desired state, including when VTherm is off. This is a safety feature, and I don't know to disable any safety feature.

If you want to temporarily take manual control of your heat pump, please disable the relevant VTherm from Settings > Devices & services > Integrations > Versatile Thermostat > Disable. VTherm will then no longer control or repair the state of the underlying entity, so you can operate it manually.

Re-enable the VTherm when you want to hand control back to it.