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

Month of "What the heck?!"
1

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?

2

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?

3

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

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.

4

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.

5

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 :man_shrugging:

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 :joy:

Thanks for taking a look though :+1:

6

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:

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).

1 Like
7

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 :joy:

1 Like
8

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.

9

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.

1 Like
10

What about my situation for a genuine use case:

  • Gas boiler heating in my house is controlled on/off for three separate circuits (by floor e.g. ground vs 1st vs 2nd)
  • Each room has its own smart TRV and separate thermometer, and I have set up heating schedules for each room
  • I need a generic thermostat that will use the thermometer temperature vs the scheduled target temperature and decide if heat is required for the room
  • The complexity is that turning on the heating for a room requires a) turn on the TRV in the room, and b) turn on the heating for the floor it is on. And for turning off heating it requires a) turn off the TRV, and b) turn off the heating for the floor, ONLY if there are no other rooms on the floor.

Currently I have this last part complexity implemented via input_booleans per room, grouped by floor, and an automation that uses these to turn on the TRV / floor heating as required.

So for me, an input_boolean is required as a legitimate use case for generic thermostat and it would be great for it to be configurable via UI rather than YAML.

Unless you would suggest a better way to structure my solution, e.g. if you think I’m eating spoon with a fork? :slight_smile:

EDIT: FWIW, i’ve implemented this now using blank template switch entities instead of input_boolean’s which have the same effect but can be integrated with the thermostat

Thanks!

11

I landed here after also being blocked by this design choice, and not finding a good solution after some months.

Probably because input_booleans do not directly control things like switches do.

Why does the Generic Thermostat care whether it’s controlling something at all? It’s my job to make it control something, not its job to make sure I’ve connected it the way it envisioned I should want to.

And the generic thermostat is used to control something physical.

I’m holding in my hands right now an actual, physical, commercially available, off-the-retail-shelf thermostat. It’s not connected to anything but a pair of AA batteries. No wires in the back. It is happily letting me set temperatures, changing its LCD based on whether it would cool at the moment, and toggling an entirely disconnected relay. I could connect that relay to anything, from my HVAC unit as intended, to the ‘ON’ switch of a clapping-cymbals monkey toy so I at least get entertainment when it gets hot. The real physical thermostat does not care in the least what I do with those wires.

Why is this physical, retail-sold, dumb thermostat, more flexible than Home Assistant’s virtual thermostat?

I could (and have) told Home Assistant’s ‘Generic Thermostat’ to control a lamp in my room, and it was fine with that. So it doesn’t care what the physical switch does, only that’s it’s a physical switch?

I could tell it to control an empty smart outlet with nothing plugged in. So it doesn’t care if the physical switch does anything, only that it’s physical? (Heck this wouldn’t be a bad ‘hack’ for this issue, just $15 per virtual thermostat.)

I could program an ESP32 to pretend to have a switch that only exists as a YAML config. Having no wires connected, you could easily argue those are “virtual”, but the ‘Generic Thermostat’ would happily allow them just because they look like a device.

So it’s not even about the switch being virtual or real. It’s purely a matter of the ‘Input Boolean’ being categorized differently than a device, and the field not filling from that category. There is no other substance whatsoever to the design choice of forcing the ‘Generic Thermostat’ to have a non-empty target that must be a device, or there would be some problem with one of the above.

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

Showing that this has no basis in the functionality of the thermostat. It’s 100% just artificially imposed rules toward someone’s mental image of how a thermostat “should be used”. Home Assistant should design for flexibility. Especially for its virtual devices.

Anyone who wants their virtual thermostat to directly control a physical device is guaranteed going to put a physical device in that target slot. Nobody needs to worry about those people doing that.

But, there is nothing about the concept of a virtual thermostat that cannot operate if that target slot goes to something else, controls something indirectly, or even is empty and only shows someone what the thermostat would be doing on their test dashboard. “I would be cooling right now” is still useful in automations even if that specific entity isn’t directly in charge of said cooling.

In fact I could implement what I want, in Home Assistant, right now, by purchasing physical thermostats that only connect to power and nothing else. Pair them all with HA, and simply because they are not this virtual Helper thermostat, I would be able to use their cooling-or-not state in further logic in a way that I’m blocked from doing with the virtual thermostat.

I implore the Home Assistant team, please don’t impose artificial limiting rules on our logic legos!