This automation turns OFF the Ecobee AC when the attic fan is manually turned on (Z-Wave), then turns the Ecobee AC back on when the attack fan is turned off.
Trigger: State–when attic fan changes from Off to On
Actions:
Device: Change HVAC mode Ecobee to Off
Wait for: When attic fan changes from On to Off
Device: Change HVAC mode Ecobee to On
I am mostly interested in knowing whether the actions align with best practices. I started with the if-then function, along with condition to determine the state of the attic fan. I found that the state function when used under triggers, one can define “from” and “to” states, but when state is used under conditions, the only option is to define the entity’s current states (the from/to is missing).
I would like to learn to create better automations. This one puzzles me. Thanks.
It makes it much easier for us to offer help if we can see what you have done.
In the automation editor click the 3 dot menu at the top left, then select “Edit in YAML”
Copy/Paste the configuration from there into your post using the code formatting
That is correct. Conditions are checked immediately, they do not wait. If you want the automation to wait until something happens or becomes true you can use Wait for Trigger or Wait Template actions.
Thank you, @Didgeridrew. Attached is the code. Your explaination of Conditions is also helpful. I am not proficient in YAML at this time, so I like to stay in the GUI for the configs.
alias: Attic Fan AC control
description: ""
trigger:
- platform: state
entity_id:
- switch.attic_fan
from: "off"
to: "on"
condition: []
action:
- device_id: 8344dad2525a8641b4b0cd32d41795
domain: climate
entity_id: 9ac303f27a2009e926f3137390f7fa
type: set_hvac_mode
hvac_mode: "off"
- wait_for_trigger:
- platform: state
entity_id:
- switch.attic_fan
from: "on"
to: "off"
- device_id: 8344dad2525a8641b4b0cd32d417
domain: climate
entity_id: 9ac303f27a2009e926f3137390f7
type: set_hvac_mode
hvac_mode: heat_cool
mode: single
That’s understandable, but YAML is the currently the most efficient way to share automations and get help debugging issues. It saves you from having to share a bunch of screenshots and us having to retype everything…
It is funny to see that there are more ways to achieve 1 goal.
Personally from what I see, i would trigger only the device, not the state… and in the action do the check what to perform.
Trigger attic fan changes
action:
if attic fan = off set AC to cool
if attic fan - on set AC to off.
alias: Attic Fan AC control
description: ""
trigger:
- platform: state
entity_id:
- switch.attic_fan
condition: []
action:
- if:
- condition: state
entity_id: switch.attic_fan
state: "off"
then:
- device_id: 8344dad2525a8641b4b0cd32d41795
domain: climate
entity_id: 9ac303f27a2009e926f3137390f7fa
type: set_hvac_mode
hvac_mode: heat_cool
- if:
- condition: state
entity_id: switch.attic_fan
state: "on"
then:
- device_id: 8344dad2525a8641b4b0cd32d41795
domain: climate
entity_id: 9ac303f27a2009e926f3137390f7fa
type: set_hvac_mode
hvac_mode: "off"
mode: single
A switch entity’s state value isn’t limited to only on or off, it can also be unavailable. Therefore your latest example can also be triggered by a state change to and from unavailable. It will also be triggered by any changes to the switch entity’s attributes.
That’s why the example I posted explicitly specifies the two state-changes of interest, namely on → off and off → on. In addition, each trigger contains the value for hvac_mode (in its id option). Therefore the automation’s action doesn’t have to make any decisions and simply uses the supplied value of id.
It also uses a service call as opposed to a Device Action. Service calls support templates whereas Device Actions do not.
A switch becoming unavailable is something (besides hue bulbs) which I have encountered errors with (yet).
I use the unvailable state in my particular case to drive other automations. I have a “analog” lux sensor which powers my lights in the garden. If it turns on, my light go from unavailble to off or on.
In that case, you are completely right.
Isn’t it that if it does not go into actions, it does not update the last run time of the automation. not sure about that.
An automation’s last_triggered attribute is updated only if the automation is triggered, and its condition (if any) evaluates to true and then begins executing its action.
If it’s triggered but its condition evaluates to false then it doesn’t execute its action and it doesn’t update its last_triggered attribute.
Thanks again–this is very helpful and I will include the code in the future. I will also have a look at the YT video. Sounds like a good skill to develop.
@123 Thanks very much for this and the rest of the discussions. All very educational. I like your solution, especially because it is unaffected by a restart. This reminds me of a blueprint I am using to trigger motion lights. If a restart occurred after the motion the light was triggered on, it will not turn off after the restart. The discussions here help me understand that a script can deal with restart conditions. Makes sense, but never thought about it before.
The Automation Editor in Visual mode has several limitations. You have encountered one of them.
Switch the Automation Editor to YAML mode and replace this line:
hvac_mode: "off"
with this:
hvac_mode: "{{ trigger.id }}"
You can then switch back to Visual mode. The portion of your automation (namely the service call) that the Automation Editor cannot display in Visual mode will continue to be displayed as YAML (along with a message informing you of the Automation Editor’s inability to display templates in Visual mode).
@123, your method has been working well. In addition to the attic fan, I also duplicated the same method for a balcony door sensor. The idea is that if either the attic fan is ON or the balcony door is OPEN, the AC should turn off. When both the attic fan is OFF and balcony door are CLOSED, the AC should turn on back to heat_cool.
With two independent automations, as of now, if either the fan is OFF -or- the door is CLOSED, the AC is back to heat_cool.
How can I make the scenario work so that both the fan has to be off and the door closed in order for the AC to turn on? Thinking simplistically, each automation can check to see if the other dependency is met, but I’m not sure how to do that. Or, is there a way to make this a single automation?
Glad to hear it. Please consider marking my post above with the Solution tag.
Use a State Trigger to monitor the two entities changing to off and two State Conditions, one to confirm the door is off and the other that fan is off.
I marked your post as a solution. Thanks for that.
I am working off of your original code from your above post and trying to follow your instruction to accomplish what I previously wrote:
If I understand you correctly, I am using 1) ONE State Trigger to monitor the TWO entities changing to ‘off’. Question: I do not see how I can monitor two entities with a single State Trigger; and 2) Two State Conditions, one to confirm each entity is ‘off’. Question: In an automation that has a Trigger and two conditions, will the Actions only be performed when the two conditions are met, after the automation is triggered?
Also, your original code is for controlling a single entity. In order to do what I want now, am I correct that I should create one automation to monitor either entity to be ‘on’ and turn off the AC and a separate automation to monitor for both entities to be ‘off’ in order to turn back on the AC?
I also can use some tips on how to specify the OR and AND conditions. Again, I’d like to do all this in the GUI where possible (the action YAML from your original post is fine).
@123, following up to my questions last night, this is what I slapped together. Please let me know if it looks right.
Edit: The last one I posted did not work. I think I am closer here (V2 below), but still, if one of the entities is “off”, the trigger fires. My intention is for both entities to be “off” before the automation fires.
Edit 2: V2 did not work. I reworked the conditions, the logic seems sound to me, but still the same problem. If one of the entities is “off”, the trigger fires.
alias: AC control by attic fan and balcony door V3
description: ""
trigger:
- platform: state
entity_id:
- switch.attic_fan
id: "off"
from: "off"
to: "on"
- platform: state
entity_id:
- switch.attic_fan
id: heat_cool
from: "on"
to: "off"
- platform: state
entity_id:
- binary_sensor.balcony_door_contact
from: "off"
to: "on"
id: "off"
- platform: state
entity_id:
- binary_sensor.balcony_door_contact
from: "on"
to: "off"
id: heat_cool
condition:
- condition: or
conditions:
- condition: or
conditions:
- condition: state
entity_id: switch.attic_fan
state: "on"
- condition: state
entity_id: binary_sensor.balcony_door_contact
state: "on"
- condition: and
conditions:
- condition: state
entity_id: switch.attic_fan
state: "off"
- condition: state
entity_id: binary_sensor.balcony_door_contact
state: "off"
enabled: true
action:
- service: climate.set_hvac_mode
data:
hvac_mode: "{{ trigger.id }}"
target:
device_id: 8344dad2525a8641b4b0cd32d417
mode: single
The condition you created is designed to set hvac_mode to:
off if the fan is turned on or the door is opened.
heat_cool if the fan is off and the door is closed.
In other words, it’s the same as this Template Condition.
condition:
- condition: template
value_template: >
{% set fan = states('switch.attic_fan') %}
{% set door = states('binary_sensor.balcony_door_contact') %}
{{ fan == 'on' or door == 'on' or (fan == 'off' and door == 'off') }}
So, in theory, all it takes set the thermostat to off is to open the door or turn on the fan.
To set the thermostat to heat_cool, the fan must be turned off and the door closed.
@123, yes, I thought it would work in theory, but it does not. With the automation I showed in the earlier post, either the attic fan ON -or- balcony door OPEN will turn the HVAC to OFF.
However… -either- closing the door or turning off the attic fan will set the thermostat to heat_cool.
Today, I had the attic fan ON and door OPEN, I then turned OFF the attic fan (door still open) and the HVAC was set to heat_cool. I swear that the balcony door was still open!
This is the trace I got:
Trigger:
platform: state
entity_id:
- switch.attic_fan
id: heat_cool
from: 'on'
to: 'off'
Conditions:
Executed: September 20, 2023 at 11:45:16
Result:
result: true
conditions/0
Executed: September 20, 2023 at 11:45:16
Result:
result: true
conditions/0/conditions/0
Executed: September 20, 2023 at 11:45:16
Result:
result: false
conditions/0/conditions/0/entity_id/0
Executed: September 20, 2023 at 11:45:16
Result:
result: false
state: 'off'
wanted_state: 'on'
conditions/0/conditions/1
Executed: September 20, 2023 at 11:45:16
Result:
result: true
conditions/0/conditions/1/entity_id/0
Executed: September 20, 2023 at 11:45:16
Result:
result: true
state: 'on'
wanted_state: 'on'
Ah… I think see the problem in my construction. Consider this: The fan is on and the door is open. I turn off the fan. That activates the trigger with the set heat_cool string. When it gets to conditions, as soon as the automation sees the balcony door open (as part of the “or” condition), the action will fire to set the heat_cool.
How can I fix this automation (again, UI preferred) to work as you and I described:
off if the fan is turned on or the door is opened.
heat_cool if the fan is off and the door is closed.
where “all it takes set the thermostat to off is to open the door or turn on the fan.
To set the thermostat to heat_cool, the fan must be turned off and the door closed.”?
