[Bug] Manual switch of opposite mode results in non idle state

[KairuByte]

Reproduction Steps:

1. Set up thermostat with two switches, one for heat and one for cool (as expected)
2. Set thermostat to heat
3. Set thermostat to outside heating range (if ambient is 74 set target to 70 for example)
4. Manually turn cool switch on

Expected results:

Thermostat should remain in idle state, as we are not heating.

Actual results:

State is set to "heating".

Note:

I believe this works in both modes, but heat was chosen for the steps arbitrarily.

I noticed this because I have an automation set up, which turns on the fan associated with cooling on, as long as the state is not "off".

[KairuByte]

Further testing shows this may actually result in cycles not properly kicking off. In the example above, the heat switch will not fire even if the ambient temperature drops to 66.

[zacs]

It seems to me like if the cool switch is manually activated, the climate itself should then shift to "cool" mode, but I realize that isn't the best experience. Having to manage and listen for all events where the heat/cool switches get activated manually will be a pretty big undertaking if we want to go that route.

Generally though, if mode is set to heat and the cool switch is manually toggled on, then the keepalive logic should just be naively turning off the cooler switch. I've tested on my end (I am still running the component from before reverse_cycle addition) and that's the behavior. Does your manually-activated cooler switch stay on indefinitely even when you are in heat mode?

[KairuByte]

It will stay on until the mode switches.

I'm actually not "manually" enabling the cooling device, I'm automating it by detecting the climate entities state change, and when it changes to anything other than "off" it simply switches the cooling device on. Similar in effect to how #11 would work if implemented.

Admittedly not the best solution, and I could likely be using the standard generic.

[zacs]

Thanks for the clarification. When I say "manual" I suppose I mean "anything outside the component." So just to be clear, you have:

• Climate device in heat mode
• Cooler switch gets turned on by automation

And once that happens, even after many minutes, the cooler switch remains on? If so this may be a condition for when the component doesn't think to activate (since it is not too_cool) and I may need to add the logic there to turn off the cooler.

I'm making an assumption that by handing over the heater/cooler switches to the component, you are ceding control of them. Otherwise like I say, the component would need to keep an audit of service calls turning the switch on, and conditionally act. It just seems like that would get very complicated very fast (the ambient lighting component does this and it seems difficult to maintain).

The good news is that I started adding auto and fan modes this week, so perhaps this is a moot point :).

[KairuByte]

Auto and fan modes would definitely negate the need for the automation, so it would solve my use case.

Slight addendum to your "timeline", the heat switch will never turn on once it has hit "idle".

If I had to guess at the root cause: Any associated switch being "on" results in a "non idle" state, "idle" state is required before the associated switch will trigger. This would mean "heat" mode with the cool switch "on" would result in a perpetual "heating" state. Even if the heat switch is "off", the "heating" state means it never attempts to turn the heat switch "on".

I'm not certain a state monitoring is required. The major issue is going to be "non idle" resulting in never switching on the proper device when the tolerance has been reached. In my opinion, any side effects after that (opposite mode switches being turned off for example) would be much easier to deal with if anyone ever really wanted to replicate the situation.

[brandondb1]

I think that as @zacs said, the assumption is (and needs to be) implicit that control of devices is ceded to the component. If you need to control them from elsewhere in the UI, you could call the relevant service rather than triggering the switch directly.

I use a couple of input booleans (one for cool, one for heat) as the 'switches' the component controls, these in turn trigger automations and scripts for heat or cool (because I have two modes of heat, a central fan, a mode valve for a heat pump, and the need to delay switching on the compressor under some circumstances, this is necessary), but the only control of the system comes from the component triggering automations via the input booleans.

@zacs I have created a verson with a fan control if you want the code for that. I can't get the fan icon to change color when it's on (it seems like the default lovelace thermostat card uses the same color for fan_only and off), but otherwise it works...code attached.

climate.py.txt

[zacs]

Nice @brandondb1 I'll diff that with current and try to get it added this week.

Auto mode is a bit more annoying to add since technically it requires a temperature target range instead of a temperature target (and there are a bunch of implications to the logic there). So likely fan will get added first.

[brandondb1]

I tried to figure out an auto mode, but as you say it was hard to do. You risk creating an infinite energy consumption machine that heats until it cools...

On Mon., Nov. 30, 2020, 13:39 Zac, notifications@github.com wrote:

Nice @brandondb1 https://github.com/brandondb1 I'll diff that with current and try to get it added this week.

Auto mode is a bit more annoying to add since technically it requires a temperature target range instead of a temperature target (and there are a bunch of implications to the logic there). So likely fan will get added first.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zacs/ha-dualmodegeneric/issues/13#issuecomment-735967171, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7MZB74V76ZJRXTSEOUEHLSSPRF7ANCNFSM4TYD6JFQ .

[jacopoventura01]

Nice @brandondb1 I'll diff that with current and try to get it added this week.

Auto mode is a bit more annoying to add since technically it requires a temperature target range instead of a temperature target (and there are a bunch of implications to the logic there). So likely fan will get added first.

hi, do u add the fan controls?

[david-kalbermatten]

@jacopoventura01 If you feel adventurous, you can try my version over on https://github.com/david-kalbermatten/ha-dualmodegeneric

I added a fan and dryer mode (both optional) and merged the latest changes of this repository, so it also supports the heat_cool mode.

Looks like this in HA:

If you want to try it, you can add my repository in HACS and you should be able to install it that way.

[zacs]

Closing, since the assumption is that the switches are ceded to the component, and it's too complex to listen for other things changing those switches.