WTH can't we use an input_boolean helper as the switch for a Generic Thermostat Integration?

[AJStubbsy (Adam)]

I know the official answer will be “Use a Template Switch” as this has been discussed in other posts, but I’ve been unsuccessful creating a suitable template that replicates the current behaviour.

I’ve had lots of help off more experienced coders but it’s not quite right. If I create the Generic Thermostat using YAML, I can use an input_boolean, which is a toggle switch and everything works fine.

Why not merge the existing fix that will allow for input_boolean to be used?

[tom_l]

Probably because input_booleans do not directly control things like switches do. And the generic thermostat is used to control something physical. It probably never crossed the minds of the developers that someone would want to use an input boolean.

Why do you want to use an input_boolean?

Can you illustrate your use case?

[AJStubbsy (Adam)]

Hi Tom,
Here’s a topic where Petro tried to help me solve this using template sensor

Generic Thermostat Helper Template Switch Help

switch: - platform: template switches: b_state: name: B State unique_id: b_state value_template: > {{ is_states('switch.srv_bedroom', 'on') }} availability_template: > {{ has_value('switch.srv_bedroom') }} turn_on: - condition: template value_template: > {{ is_state('input_boolean.heating_switch', 'on') and is_state_attr('climate.b_temp', 'hvac_action', 'idle') }} - service: switch.turn_on target: …

The problem is that the Template Sensor doesn’t update based on my particular (maybe peculiar) setup.

The whole point of the WTH for me is that I need experienced help to achieve my current behaviour using the Generic Thermostat Integration and Template Sensor but I have everything working fine with my YAML generated Generic Thermostat because I can use input_boolean, which does create a switch, effectively.

There was a branch that allowed the use of input_boolean but it didn’t get merged. I know YAML is here to stay but there’s a part of me that’s would rather adopt the most up-to-date method of Generic Thermostat creation, just in case.

[tom_l]

@AJStubbsy

I’m using an input_boolean helper to indicate if the generic thermostat conditions mean the radiator should be on or off and another input_boolean which is related to whether or not I actually want the heating to come on.

Don’t try and cram all that into a generic thermostat.

1. Create a generic thermostat.

2. Control its state (heating to some temperature or off) with automations triggered by those input booleans.

I have a ducted heating and cooling climate device. I let it turn the heating/cooling on or off to meet the set temperature. I automate:

1. When it should be on (schedule helper and automation).
2. What temperature it should be heating or cooling to. e.g. lower heating when away, in bed or during peak electricity times and boost the temperature before I get up or home.

There’s no way I would expect the climate device itself to do all that. That is what automations are for.

[AJStubbsy (Adam)]

All the scheduling and whether the heating should be on or not is controlled by automations. I’m just using the Generic Thermostat to turn an input_boolean on or off. For me it’s simpler logic than using a template sensor. Even my Heating switch is an input_boolean because I’m using an esp to simulate pressing the Heating On button on my controller. When the Heating input_boolean is pressed in HA, it sets the esp GPIO briefly to 1 then back to 0, which causes a Transistor to bridge the gap on the heating switch PCB, simulating it being pressed.

I can do it with YAML generated Generic Thermostat, I’d like to be able to with the Integration one, why aren’t they the same

I’ve evolved a method that you wouldn’t have adopted but it worked for me and now I need help to achieve something I could do before. On the github request for this feature (Generic Thermostat accept input_boolean as Actuator Switch · Issue #120950 · home-assistant/core · GitHub) others had different use cases for wanting to use input_boolean as a switch. It’s month of WTH, if you don’t ask you don’t get. This has 2 votes and one is mine, so I’m not too invested

Thanks for taking a look though

[tom_l]

I get what you are saying, and at the heart of it the only reason a switch is specified and not an input boolean is what I have already said:

@tom_l

input_booleans do not directly control things like switches do. And the generic thermostat is used to control something physical.

There is no reason the generic thermostat could not be extended to work with input booleans except it is the wrong tool for the job. Like trying to eat soup with a fork.

Good luck with your WTH. However if it does not happen we can help you with the spoon (template).

[AJStubbsy (Adam)]

I don’t know if you saw my very recent edit but even if I did adjust the rest of my system, so that the Generic Thermostat did it’s intended job and just turned my heating on or off, I would still need it to control an input_boolean.

Maybe it’s a bit like using a straw to eat my soup. Not very elegant and a bit tricky but does the job

[jimbovp]

Hi
Don’t know if you still have the issue, but I feel like you just gave the solution yourself: Create your thermostat in YAML and you can use an input_boolean all you want.
I used the “simple_thermostat” integration for this, but I guess it should work with the generic thermostat integration as well.
Or to use the metaphors earlier in the discussion: you were eating your meat with your fork just fine, why turn your meat into soup and have problems with the fork?

Hope it helps.

[AJStubbsy (Adam)]

That’s how my system is set up and it works. My point is, why doesn’t the Generic Thermostat Integration behave in the same way as YAML configuration. My concern is HA will move away from YAML and my use case won’t be supported.