I would like to set my Nest Thermostat to ‘off’ when my backdoor state changes to open for three minutes but only if the Thermostat was set to heat.
I then want it to turn the thermostat to ‘Heat’ when the backdoor state changes to closed for two minutes but only if it was set to ‘Heat’ before it was turned off by the open door condition.
I can do the turn off when door open but I can’t figure out how to change it to heat when the door is closed but only if it was previously set to heat. I don’t want it turning my heat on when the door closes If I have manually turned the thermostat off.
Before we proceed to use wait_for_trigger we need to fix your automation’s State Trigger.
- platform: state
entity_id: binary_sensor.back_door
from: 'off'
to: 'on'
for: '00:03:00'
id: 'Nest Switched To Off'
A binary_sensor’s state value is either on or off. You can confirm this by going to Developer Tools > States and examining the state value for binary_sensor.back_door.
If you set the binary_sensor’s device_class to door it will represent on/off as Open/Closed in the Lovelace UI. However, that’s just for display purposes in the UI and the binary_sensor’s actual state remains on/off.
You’re welcome! The next step is to add this to your automation’s action.
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.back_door
from: 'on'
to: 'off'
for: '00:02:00'
timeout: '00:10:00'
continue_on_timeout: false
It waits for binary_sensor.back_door to change it state to off and hold that state for at least 2 minutes. When that happens it will continue to execute the next action (not shown above) which will be to set climate.nest_thermostat to heat.
It also includes a 10-minute timeout. If the back_door is not closed within 10 minutes, the automation will end (because we have set continue_on_timeout to false). Feel free to adjust the duration of timeout and if you prefer to have it continue executing the next action even after the timeout expires.
Here is your automation with wait_for_trigger.
- id: '1631090131652'
alias: Conserve Energy When Back Door Open
description: ''
trigger:
- platform: state
entity_id: binary_sensor.back_door
from: 'off'
to: 'on'
for: '00:03:00'
id: 'Nest Switched To Off'
condition:
- condition: device
device_id: 47585fcc9681ecc15ff20c2238c72a74
domain: climate
entity_id: climate.nest_thermostat
type: is_hvac_mode
hvac_mode: heat
action:
- device_id: 47585fcc9681ecc15ff20c2238c72a74
domain: climate
entity_id: climate.nest_thermostat
type: set_hvac_mode
hvac_mode: 'off'
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.back_door
from: 'on'
to: 'off'
for: '00:02:00'
timeout: '00:10:00'
continue_on_timeout: false
- device_id: 47585fcc9681ecc15ff20c2238c72a74
domain: climate
entity_id: climate.nest_thermostat
type: set_hvac_mode
hvac_mode: 'heat'
mode: single
Here is the same automation but instead of using a Device Condition and Device Actions it uses a Template Condition in shorthand notation and service calls. It’s functionally equivalent to the first automation, only shorter.
- id: '1631090131652'
alias: Conserve Energy When Back Door Open
description: ''
trigger:
- platform: state
entity_id: binary_sensor.back_door
from: 'off'
to: 'on'
for: '00:03:00'
condition: "{{ is_state('climate.nest_thermostat', 'heat') }}"
action:
- service: climate.set_hvac_mode
target:
entity_id: climate.nest_thermostat
data:
hvac_mode: 'off'
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.back_door
from: 'on'
to: 'off'
for: '00:02:00'
timeout: '00:10:00'
continue_on_timeout: false
- service: climate.set_hvac_mode
target:
entity_id: climate.nest_thermostat
data:
hvac_mode: 'heat'
mode: single
NOTE
In your original automation you assigned a named id to the trigger (Nest Switched To Off). Unless you plan to refer to this id in the automation’s action (using trigger.id) it’s not obligatory to do it.
No problem; my pleasure. Making the transition from one home automation system to another can be challenging due to different terminology but Home Assistant has an additional hurdle in the form of it automation language. I think you have already seen that it is quite different from openHAB’s Rules.
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic is resolved. This helps other users find answers to similar questions. For more information, refer to guideline 21 in the FAQ.
If I change the state of the back door from off to on either by opening the door or changing the state using the developers tools it doesn’t run.
If I set the state of the door to ‘on’ and then click the ‘run actions’ it turns the heat off immediately. Then when I change the door state to 'off; the after two minutes it turns the heat back on.
An automation’s “Run Actions” button literally does just that, it executes the automation’s action section and completely skips trigger and condition (if it exists). In other words, when you click that button you’re only testing the automation’s action.
Go to Developer Tools > States, find binary_sensor.back_door and then open and close the actual door. Do you see its state value change from off to on and back to off? It has to work properly there otherwise it will not serve to trigger anything.
I’ve checked in Development Tools>States and yes the state for binary_sensor.back_door does change from ‘off’ to ‘on’ and ‘off’ again when I open the door and close it again.
Then it should be triggering the automation. If you view Configuration > Automations, the list shows the last time each automation was triggered.
You can also check the automation’s trace to confirm it was triggered. In Configuration > Automations click the second icon displayed next to the automation’s name.
A trace is created for an automation when it’s triggered (but only if the automation has an id and yours does). If you open the door, and leave it open for at least 3 minutes, it will trigger the automation and produce a trace.
Just my opinion but I avoid using Device Triggers, Device Conditions, and Device Actions.
They were invented to make it easier for a user to make device-oriented automations via the UI. You pick a device in Configuration > Devices, proceed to create an automation for it, and it shows you what you can do with the device. It’s helpful but it produces far more verbose code than traditional triggers, conditions, and service calls.
