Oh totally didnt see that post, thank you so much, gonna try it right away!
I personnaly use Aqara sensors in Zigbee. Not expensive, long lasting battery and small size is perfect for me.
Use them via Home Assistant ZHA integration.
1 Like
Can this blueprint be extended to not only turn off a climate device but also set a new target temperature?
My Eurotronic Spirit ZigBee TRVs are pretty dumb, they donāt react to turn off/set hvac mode to off commands and proceed to heat.
For this (in other automations) I have to use the āclimate.set_temperatureā service (see below). Maybe this blueprint can add this as an option (allowing to set a) temporary off temperature like 7 degrees and b) turn back on temperature, where ideally b) could be stored from the state before lowering it so there would be no need for static values).
action:
- service: climate.turn_off
target:
entity_id: climate.device
- service: climate.set_hvac_mode
target:
entity_id: climate.device
data:
hvac_mode: 'off'
- service: climate.set_temperature
target:
entity_id: climate.device
data:
temperature: 16
I am currently working on a modified version. I will update it soon so that this blueprint will use the set_hvac_mode
- Could you please share with us the
hvac_modesof your climate entity (/developer-tools/state)? - Tell us what happens to the set temperature if the mode changes from
heatingtoofftoheatingagain
Thanks
1 Like
- Full output (same for all Eurotronic Spirit ZigBee):
hvac_modes:
- auto
- heat
- 'off'
min_temp: 7
max_temp: 32
current_temperature: 20.5
temperature: 20
offset: 0
valve: 38
locked: false
icon: phu:thermostat-v2
friendly_name: Thermostat XYZ
supported_features: 1
- Nothing - when being set via HA. Thatās why I (need to) use the temperature as this is the only language this device is speaking.
Some worked around this behavior by adding another layer of complexity (e. g. GitHub - WolfRevo/climate.spzb0001_thermostat: A clone created from the Home Assistant generic_thermostat to use EUROTRONIC Zigbee SPZB0001 Thermostats with external temperature sensors). Iām fine with the temperature being the only way to remotely control these devices - as long as all of my automations can set those 
When setting the heat mode physically/directly on the TRV (āboost mode buttonā), HVAC jumps to heat and set temperature is set to 30 degrees. When disabling the boost mode, HVAC jumps back to auto - and set temperature back to the value set before (takes some time, up to two minutes for HA to be in sync with local screen again).
Here is the expected behavior for your thermostat I found in another thread here:
If a window opens, the thermostat turns off, once it closes, it turns back to heat, reverting to whatever temperature it was set to before turning it off.
Anyway, if it is not working, at the moment this blueprint cannot help you because variables cannot be set using blueprint. 
But here is the updated version. You can give it a quick try 
blueprint:
name: v3 Window open, climate off after a defined time
description: It goes back to the previous set stage after the windows is closed again
domain: automation
input:
window_entity:
name: Window Sensor
description: The window sensor that controls the climate entity.
selector:
entity:
domain: binary_sensor
device_class: window
window_entity_2:
name: 2nd Window Sensor
description: "Optional: The second window sensor that controls the climate entity."
default: []
selector:
entity:
domain: binary_sensor
device_class: window
window_entity_3:
name: Any Binary Sensor
description: "Optional: The third sensor that controls the climate entity."
default: []
selector:
entity:
domain: binary_sensor
#device_class: window
window_entity_4:
name: Any Input Bolean
description: "Optional: The 4th sensor that controls the climate entity."
default: []
selector:
entity:
domain: input_boolean
#domain: binary_sensor
#device_class: window
minimum_open_time:
name: Miniumum time the window is open
description: Time in seconds to wait until the automation is triggered
default: 12
selector:
number:
min: 0.0
max: 120.0
unit_of_measurement: seconds
mode: slider
step: 1.0
climate_target:
name: Climate Device
description: The climate entity that is controlled by the window sensor.
selector:
entity:
domain: climate
# source_url:
trigger:
- platform: state
entity_id: !input "window_entity"
to: "on"
for: !input "minimum_open_time"
#
- platform: state
entity_id: !input "window_entity_2"
to: "on"
for: !input "minimum_open_time"
#
- platform: state
entity_id: !input "window_entity_3"
to: "on"
for: !input "minimum_open_time"
#
- platform: state
entity_id: !input "window_entity_4"
to: "on"
for: !input "minimum_open_time"
condition:
- condition: not
conditions:
- condition: state
entity_id: !input "climate_target"
state: "off"
action:
- choose:
- conditions:
- condition: state
entity_id: !input "climate_target"
state: cool
sequence:
- service: climate.turn_off
target:
entity_id: !input "climate_target"
- wait_for_trigger:
- platform: state
entity_id: !input "window_entity"
to: "off"
- platform: state
entity_id: !input "window_entity_2"
to: "off"
- platform: state
entity_id: !input "window_entity_3"
to: "off"
- platform: state
entity_id: !input "window_entity_4"
to: "off"
continue_on_timeout: false
- service: climate.set_hvac_mode
target:
entity_id: !input "climate_target"
data:
hvac_mode: cool
#
- conditions:
- condition: state
entity_id: !input "climate_target"
state: heat_cool
sequence:
- service: climate.turn_off
target:
entity_id: !input "climate_target"
- wait_for_trigger:
- platform: state
entity_id: !input "window_entity"
to: "off"
- platform: state
entity_id: !input "window_entity_2"
to: "off"
- platform: state
entity_id: !input "window_entity_3"
to: "off"
- platform: state
entity_id: !input "window_entity_4"
to: "off"
continue_on_timeout: false
- service: climate.set_hvac_mode
target:
entity_id: !input "climate_target"
data:
hvac_mode: heat_cool
#
- conditions:
- condition: state
entity_id: !input "climate_target"
state: heat
sequence:
- service: climate.turn_off
target:
entity_id: !input "climate_target"
- wait_for_trigger:
- platform: state
entity_id: !input "window_entity"
to: "off"
- platform: state
entity_id: !input "window_entity_2"
to: "off"
- platform: state
entity_id: !input "window_entity_3"
to: "off"
- platform: state
entity_id: !input "window_entity_4"
to: "off"
continue_on_timeout: false
- service: climate.set_hvac_mode
data:
hvac_mode: heat
target:
entity_id: !input "climate_target"
# auto
- conditions:
- condition: state
entity_id: !input "climate_target"
state: automatic
sequence:
- service: climate.turn_off
target:
entity_id: !input "climate_target"
- wait_for_trigger:
- platform: state
entity_id: !input "window_entity"
to: "off"
- platform: state
entity_id: !input "window_entity_2"
to: "off"
- platform: state
entity_id: !input "window_entity_3"
to: "off"
- platform: state
entity_id: !input "window_entity_4"
to: "off"
continue_on_timeout: false
- service: climate.set_hvac_mode
data:
hvac_mode: automatic
target:
entity_id: !input "climate_target"
My TRVs offer the hvac_modes: heat, auto, off.
Is it possible to have this automation return to auto if it was set to it before? Right now the TRVs all return to heat, which means the valve opens 100% - even it the measured room temperature did not change. This wastes energy.
Sure! I just published the modified version based on HAVC modes. 
Please share with us the information about your TRV device (vendor and model). A link would be nice.
Happy automating!
Thank you for the quick fix, I will check it out.
Model info of my TRV
Model: TS0601
Maker: _TZE200_cwnjrr72
Recognized as: TS0601_thermostat
Product link: Tuya Smart ZigBee Radiator Actuator TRV Programmable Thermostatic Radiator Valve Temperature Controller Support Alexa|Building Automation| - AliExpress
Great, thanks for the information! What Zigbee Adon / Integration are you using - Zigbee2Mqtt, ZHA or Phoscon/Deconz? Please let us know if it is working.
Zigbee2Mqtt - I gave ZHA a try before, but Zigbee2Mqtt works pretty great for me.
And, most importantly, your blueprint is working great. Itās really useful in this transitional phase like spring.
Thanks! Thatās good to hear! Cool, so we also cover the (manly build for) Tuya Zigbee thermostats 
Thanks for the confirmation. Iāll also give Zigbee2Mqtt the next try. Having a lot of Lidl/Tuya lamps, Ikea and Aqara Sensors. Still waiting for the Aqara P1 Motion Sensor before I set it up.
Yes, thatās the way it should work. But in reality, it is switching back to AUTO HVAC mode after approx. 10 minutes (where the window is still openā¦!):
I updated to the latest version (of your original post) and donāt see any difference in terms of function. It also does not improve/fix my issue as far as I can see.
Well, what about using the input services for storing the temperature value before opening the window in an input entity (serving as variables storage)? Automatically turn off thermostat if door is open for so long - #2 by Didgeridrew
+++ Could you please add this, so this blueprint can optional be used based on target temperatures, not hvac modes only. +++
E. g. in automation (action part):
1) Window opened - store current temperature
service: input_number.set_value
data:
value: "{{ state_attr('climate.entity','temperature') }}"
target:
entity_id: input_number.climate_entity_target_temperature_temporarily
Now set climate entity temperature to a very low value (minimum supported value of my TRVs: 7 Ā°C).
service: climate.set_temperature
data:
temperature: 7
target:
entity_id: climate.entity
2) Window closed - reading/setting temp
service: climate.set_temperature
data:
temperature: "{{ states('input_number.climate_entity_target_temperature_temporarily') }}"
target:
entity_id: climate.entity
That would be awesome! 
Please let me know.
Otherwise I would need to do that on my own 
but then this great blueprint would not benefit from it.
Please check the trace of the automation and share the results.
When upgrading to the latest blueprint version, now after the first HA restart I got this:
- First log entry
Logger: homeassistant.config
Source: components/blueprint/models.py:61
First occurred: 20:00:52 (1 occurrences)
Last logged: 20:00:52
Invalid config for [automation]: Invalid blueprint: extra keys not allowed @ data['blueprint']['input']['climate_target']['selector']['multiple']. Got None extra keys not allowed @ data['blueprint']['input']['window_entity']['selector']['multiple']. Got None (See /config/configuration.yaml, line 19).
...
- Second log entry
Logger: homeassistant.config
Source: components/blueprint/models.py:259
First occurred: 20:00:52 (1 occurrences)
Last logged: 20:00:52
Invalid config for [automation]: Failed to load blueprint: Unable to find SmartLiving.Rocks/window-open-climate-off.yaml (See /config/configuration.yaml, line 19).
...
And trying to manually import it again with the IMPORT button in post one of this topic gives this again:
Invalid blueprint: extra keys not allowed @ data['blueprint']['input']['climate_target']['selector']['multiple']. Got None extra keys not allowed @ data['blueprint']['input']['window_entity']['selector']['multiple']. Got None
So of course currently ALL my automations based on this blueprint are broken. I needed to revert back to the old, working version I used until 2022-04-16.
OLD version:
blueprint:
name: Window open, climate off after a defined time
description: An automation that turns off a running your climate device for exmple
a heater or an air conditioning if a window sensor is open for a specific time.
It waits until the window is closed again in order to turn the climate entity
on again.
domain: automation
input:
window_entity:
name: Window Sensor
description: The window sensor that controls the climate entity.
selector:
entity:
domain: binary_sensor
device_class: window
minimum_open_time:
name: Miniumum time the window is open
description: Time in seconds to wait until the automation is triggered
default: 12
selector:
number:
min: 0.0
max: 120.0
unit_of_measurement: seconds
mode: slider
step: 1.0
climate_target:
name: Climate Device
description: The climate entity that is controlled by the window sensor.
selector:
entity:
domain: climate
source_url: https://community.home-assistant.io/t/window-open-climate-off/257293
trigger:
- platform: state
entity_id: !input 'window_entity'
to: 'on'
for: !input 'minimum_open_time'
condition:
- condition: not
conditions:
- condition: state
entity_id: !input 'climate_target'
state: 'off'
action:
- service: climate.turn_off
entity_id: !input 'climate_target'
- wait_for_trigger:
- platform: state
entity_id: !input 'window_entity'
to: 'off'
continue_on_timeout: false
- service: climate.turn_on
entity_id: !input 'climate_target'
Please help to fix this issue so I can use the latest blueprint version and provide you the requested trace logs.
Note: My HA is still running on 2022.3.7. Is the multiple: false part maybe only usable with latest HA Core 2022.4.x?
Update:
- Reading through 2022.4 release notes (2022.4: Groups! Groups! Groups! - Home Assistant), it might be possible the Selectors - Home Assistant has really been introduced with 2022.4.
- In case this is true: just wondering why HA does not take care of the requirements management (āThis blueprint needs at least HA version 2022.4!ā).
- Anyway, will test the current blueprint again once updated to latest HA release.
I cannot answer this question. You can make a feature request here. I have left a note in the description and a link to GitHub for a version that also works for older versions - thanks for the hint!
No! I have already tried to explain you approximately one year ago in this post:
Your suggestion requires a manually created and configured helper (or in your words āinput servicesā) before you could use the blueprint! That make things more complicated and does not make really sense for a community automation that is already serving a lot of people!
Furthermore, 90% of thermostats work with HVAC modes and do not need your suggested workaround. In Addition to that, I am also quite confident that your thermostat will also work if set up correctly as your thermostat is using the right HVAC modes!
So please share a proof that this blueprint is responsible for turning on your climate device by providing the trace or logbook entry! Thanks
Thx.
Unfortunately not, I never said the blueprint is doing crazy things: the firmware of the TRV is just crap. It always resets to auto mode after few minutes. Thatās why I need to control it using target temperatures - as simple as that.
Therefore I will implement this on my own, itās really not much needed, exactly as you wrote. Just one input helper entity created before, yes. You are the author and it is your decision. If itās a corner case or not, I would see it as an extension of features.
Anyway. In case Iāll fork your blueprint I will leave a note here. Probably Iāll do it just plain as automation without the blueprint UI, working only for me unfortunately.
That statement leads space for some interpretation. Other users reading this could assume that it has to do something with the Blueprint. Thanks for clarifying it!
I do not agree that this is a feature because you are the only one requesting it and it is due to a malfunction of your TVR. So fix it (try another Zigbee integration, upgrade your firmware ā¦) or use a different method by using Node Red or for your specific scenario - just make an automation and use the copy function.
Amon, Iām waiting on a window sensor to arrive so that I may setup this Blueprint. In the meantime, Iāve installed the blueprint and looked over the code. I like what I see but have one question. I know via HA any action performed by this blueprint may be deferred or cancelled in a number of ways. Disabling the blueprint or adding a helper in parallel with the door sensor are just a couple of ways that Iāve thought of. How would someone with out access to or knowledge of HA override this blueprint?
Hereās a couple of situations Iāve thought of where an override might be desired;
- Occupant opens the monitored door and does not want HVAC (heat or cool) to stop operating.
- Door sensor fails in a ādoor openā position.
What happens if the window sensor fails when the blueprint is active; a door or window was opened, the HVAC shut off as a result. Will the blueprint know the sensor failed and reset the HVAC to itās previous on state?
Also, is there a fail safe state? My thermostat will call for heat if it fails and temperature in the house falls below a certain level. Is there a default low temperature setting that would force the blueprint to restore operation of the HVAC system if temperature in the house falls below a certain setpoint?
Regards,
Hey, thanks for the feedback! In general, this is a basic automation helper in order to easily create one of the most common functions in therms of reducing heat costs and make heating more efficient. My aim is that even a Home Assistant beginner can use the blueprint. Most of the advanced features demand to create one or more input_boolean or other helper to be crated manually. Letās assume there are 5 rooms and you need 3 helpers for advanced functionality: that would be 15 additional helpers
On the other hand, I have so many feature requests so that I am open to create a more professional version. So letās think together what features should be included.
For development of this blueprint, I am using a template sensor that makes a "window sensor" out of an input boolean helper.
# configuration.yaml
template:
- binary_sensor:
- name: "Fenster KĆ¼che StraĆe"
state: "{{ states('input_boolean.fenster_kuche_strasse') }}"
device_class: "window"
Yes, a restart of Home Assistant and a reload of automations would crash the automation. I have left a note in the description. Please tell us what else could crash the blueprint so that we can work on it.
I just had that use case in one of my projects as well. The lady is always cold and did not want to turn off the heating while the kitchen door is open. She also demanded to raise the temperature for that period. At this point, I just added the automation to the frontend in order to easily toggle on or off the automation.
So that would be a input_boolean helper for overriding or in other words to disable the blueprint. It is like switching from automatic to manual mode. Or is it enough to use the automation toggle created by Home Assistant?
But how can that helper be triggered, if some persons do not have access or knowledge of HA override? A physical or virtual button?
Generally, I have experienced window sensors as very stable devices. So in the meantime, there was no need to double-check if the āclimate controlā is even working. I assume another automation that is triggered by difference in temperature could be a solution. In other words, another sensor (temperature in this case) to check if the other sensors (window) fail. But what if the temperature sensor also fails?
We could think of a timeout to include. So that the wait for trigger will be overridden by a delay and/ or a notification would be nice, eg:
Notification: Window in
roomhas been openddelay timeago. Either it is very warm or something is wrong with your automation.
How does Home Assistant recognize a fail? The house/ area/ room can be in an away, manual or holiday mode. If we have a clear definition (trigger) to a fail, my idea is also to send a notification or even an actionable notification to an experienced Home Assistant user.