action:
- service: climate.set_hvac_mode
data:
entity_id: !input target_climate
hvac_mode: auto
The original automation used a Device-based action that employs a device_id. However, when converted to a blueprint, itâs simpler to use a traditional service call which doesnât need a device_id.
blueprint:
name: Tado open window detection
description: turns the Tado off when open window is detected
domain: automation
input:
open_window_sensor:
name: Open Window Sensor
selector:
entity:
domain: sensor
target_climate:
name: Climate Device
selector:
entity:
domain: climate
trigger:
platform: state
entity_id: !input open_window_sensor
from: 'True'
to: 'False'
action:
service: climate.set_hvac_mode
data:
entity_id: !input target_climate
hvac_mode: auto
Be advised that if you intend to share this blueprint with others, it employs an unusual convention for the window sensor. Normally, it would be binary_sensor with on and off states. You are using a sensor with True and False states.
Aaaah! thatâs the problem. Action and trigger need to be on the same level as blueprint.
About the sensor: I writing this for the tado integration and their open window sensor is not a binary sensor. Itâs a regular sensor with âTrueâ and âFalseâ as states.
Also, I need to look at templating so I can handle opening and closing in one blueprint.
In that case, I suggest you consider limiting the Entity Selectorâs choices to the Tado integration. All you need is to add integration: tado to the selector. Thereâs an example in the documentation.
About the integration selector: I already saw that in the documentation, but thanks for the tip. It would be nice if I could filter the sensors on name ending on _open_window, but I donât think thatâs possible.
Thanks for the template and all the help. Itâs a bit frustrating that the error message is not really helpful, but now Iâm ready go wild with blueprints