#Climates Control Buttons - Control different room climates by different buttons

1 messages · Page 1 of 1 (latest)

zinc tiger
#

Objective: 5 manual buttons that each toggle their respective Climate devices in 5 different rooms. I'm hoping for 1 automation that takes some "room" selection input from the button and then conditionally turns that room's climate on or off.

Trying to find the right content on how to do what I'm looking for, but I keep getting a lot of alternate information for doing other things which are not really related to what I want to do.

Two parts to solution:

  • How to set/pass the room (or target climate device if needed to be granular) by a button when running an automation. Is there some "select room" field that can be set on the button and passed to the automation for use in the Climate device/area selection?
  • On the backend in the automation, how can input be allowed or used from the button as the target for the automation's Climate action. I.e. IF: "Climate <DEVICE> is on" -> THEN: "Turn off Climate <DEVICE>" Where <DEVICE> can be selected/passed from the button config on the frontend.

It seems I could solve this very likely by making a large automation with nested "Choose:" conditions where I duplicate the "on/off" logic for each room, explicitly. But my hope is I can pass in/select the climate room/entity on the front end and use that parameter directly in the "Climate <DEVICE> on/off" logic to save a lot of duplication.

The impact is big because not only is there a lot of code duplication, but any time I want to adjust the automation logic, I'll have to do it 5 times (once for each room) which makes iteration painful.

I could also, of course, just make 5 different automations, one for each climate room/device, and call each automation separately with each button, but again, it would require 5 edits any time a change is made.

#

Additional context

versed shell
#

This is just screaming for a script rather then a automation. Automatons listen to events. Scripts just wait to get called. And a script has the option for fields (HA implementation of parameters).

zinc tiger
#

Seems like Blueprints is what I want, but it seems like that just still creates 5 seprate automations in the end

#

Ah ok

#

I'll read up on scripts then, I don't mind going script route vs automation, just wasn't sure the standard approach and was trying to stay in HA UI as much as possible so I don't over complicate things

versed shell
#

you could also use a Blueprint but that would lead to 5 automations. And you don't want to listen to an event but just call it from a button.

zinc tiger
#

Got it, so automations are pretty much always active loops checking for event triggers?

#

I wonder if they have an impact on resources as well then

versed shell
#

Scripts can be done from the UI, even the fields. Only adding specific selectors to the fields need to be done in yaml

zinc tiger
#

Ah perfect

#

Sounds just like what I want then

versed shell
#

Automations are not checking / polling, they are waiting for the event. They bind to an event and the moment the event is fired the bond items are executed.

zinc tiger
#

Ah got it, ok that makes sense.