One turns on my splits, sets heat mode and target temp if OAT is below a value
Second if the OAT is in range and humidity are below a value it powers down the splits
Third is for cooling and obviously turns on the splits in cool mode with target temp.
Last night it got cold, the heat mode activated like a champ, but when it warmed up the good weather mode didn’t turn everything back off..
Good weather mode
alias: EnergySave Good Wx
description: >
Every 30 minutes, if the NWS temperature is between 64-77, turn off the heat
pumps.
triggers:
- alias: On each hour and at half-past each hour
trigger: time_pattern
minutes: /30
conditions:
- condition: numeric_state
entity_id: weather.forecast_home
attribute: humidity
below: 55
- condition: numeric_state
entity_id: weather.forecast_home
attribute: temperature
above: 60
below: 77
actions:
- action: climate.set_hvac_mode
target:
device_id:
- 321e33d5a9477bcea75385374e1d98fd
- dde65488b26be2e4031916c05100b835
- 2e69838a92aa999e56cfdae4789e4924
- 651944e09ceaf191b1cdc88ea5376cce
- 193c817f0da04cee81c8c004c04b8b35
- dc1435c41838e814de907b4b89a2bc02
data:
hvac_mode: "off"
mode: single
Heat mode
alias: Heat Mode
description: ""
triggers:
- trigger: numeric_state
entity_id:
- weather.forecast_home
attribute: temperature
below: 60
conditions:
- condition: not
conditions:
- condition: state
entity_id: automation.energysave_good_wx
state: []
attribute: current
actions:
- action: climate.set_temperature
metadata: {}
target:
floor_id: first
data:
temperature: 65
hvac_mode: heat
- action: climate.set_temperature
metadata: {}
data:
temperature: 62
hvac_mode: heat
target:
floor_id: second
mode: single
A very simple way to solve this is to create a sensor with your desired mode:
- sensor:
- name: "AC Mode"
unique_id: ac_mode
state: >
{% set temp = states_attr('weather.home', 'temperature') | float(65) %}
{% set hu = states_attr('weather.home', 'humidity') | float(0) %}
{% if temp > 77 %}
cool
{% elif temp < 60 %}
heat
{% elif hu > 55 %}
hold
{% else %}
off
{% endif %}
Note: The use of 65 as a default, so if the sensors are unavailable the mode will switch to off.
hold is not mapped (in the next automation), so it will leave the AC doing whatever it was previously doing.
Once you have that sensor defined, you can create a very dumb automation:
mode: single
triggers:
- trigger: state
entity_id:
- sensor.ac_mode
to:
- "off"
- cool
- heat
conditions: []
actions:
- choose:
- conditions:
- condition: state
entity_id: sensor.ac_mode
state:
- "off"
sequence:
- action: climate.set_hvac_mode
target:
floor_id:
- first
- second
data:
hvac_mode: "off"
- conditions:
- condition: state
entity_id: sensor.ac_mode
state:
- cool
sequence:
- action: climate.set_temperature
target:
floor_id: first
data:
temperature: 75
hvac_mode: cool
- action: climate.set_temperature
data:
temperature: 77
hvac_mode: cool
target:
floor_id: second
- conditions:
- condition: state
entity_id: sensor.ac_mode
state:
- heat
sequence:
- action: climate.set_temperature
target:
floor_id: first
data:
temperature: 65
hvac_mode: heat
- action: climate.set_temperature
data:
temperature: 62
hvac_mode: heat
target:
floor_id: second
Sure you could add variables or remove some of the repetition, but with an automation as simple as that one, it's unlikely you will ever touch it again after the initial creation.
This is nice. The template really simplifies things. And since the mode maps directly to temps couldn't you set the temps in a variables section and avoid the choose: and have a single, no, two actions total?
An alternative would be to create two automations (Off and On) instead of one:
Off
mode: single
triggers:
- trigger: state
entity_id:
- sensor.ac_mode
to:
- "off"
conditions: []
actions:
- action: climate.set_hvac_mode
target:
floor_id:
- first
- second
data:
hvac_mode: "off"
On
mode: single
triggers:
- trigger: state
entity_id:
- sensor.ac_mode
to:
- cool
variables:
target1: 75
target2: 77
- trigger: state
entity_id:
- sensor.ac_mode
to:
- heat
variables:
target1: 65
target2: 62
conditions: []
actions:
- action: climate.set_temperature
target:
floor_id: first
data:
temperature: "{{ target1 }}"
hvac_mode: "{{ trigger.to_state.state }}"
- action: climate.set_temperature
target:
floor_id: second
data:
temperature: "{{ target2 }}"
hvac_mode: "{{ trigger.to_state.state }}"
That removes all branching logic in the automations.
However you have to take a step back and realize that the function of the automation is trivial.
Pretty much any way you construct it, it is going to work.
Its never going to be a maintenance burden - it simply doesn't have any implicit complexity to it.
Hence any arrangement of the automation you choose, is going to be your personal preference - it's not better or worse than a different arrangement (at least within the set of the reasonable choices).
What's the benefit of creating a separate sensor, splitting the automation in two, and/or removing all branching logic vs this consolidated automation?
If you come back to it a few months later you can instantly see what it does and have confidence there are no edge cases that haven't been handled, you can add additional clauses and understand exactly what the impact of those extra cases would be.
Another effect is sometime I need the state in other automation ... only do X if AC is cooling etc sure there are other ways to state that, but I find myself using sensors in multiple places.
Full disclosure there is also a negative: Sensors will typically be evaluated more often than a well crafted automation, personally I am okay with trading CPU cycles for brain cycles, but others may feel differently.
Stylistic/Personal choice.
Some will find it easier to read multiple small automations, some will prefer to read a smaller number of larger automations.
Personally I don't like "medium" sized automations, a have a few large automations and a bunch of tiny ones.
As I said previously in this case the automation isn't complex enough, so in this case it's personal choice.
However I do consider a lot of branching to be difficult to read, you will find other posts from me where I have said that I try to restrict my automations to a limited number of branches and loops (typically only one of each, max).
Both the HA GUI and the verbose YAML format become very difficult** to read with a lot of branching.
** - When compared to any "C like" programming language.
You posted three automations. The first handles turning off the thermostats and the second and third automations handle setting them to heating/cooling.
The example I posted combines all three of your automations into one.
Every approach listed in this thread would work, they are all designed to produce them same result, hence would run the Heat/AC at the same time (as each other).
I don't see a reason to overcomplicate things if you understand any of the solutions with only 1 automation go with that.
I personally find my original solution 1 sensor + 1 automation the most understandable, however as noted above it will work identically to the other solutions, so if you prefer one of them go with that.
The climate where I live requires a lot more cooling than heating, in my case the biggest cost saving was to monitor the outside temperature and when it drops below a certain temperature turn off the AC and open a window.
I don't have motors on my windows, so I have to manually open the windows, but HA does send me a notification when it would be advantageous to do so, additionally I have sensors on the windows so as soon as I do, HA turns off the AC.
