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.
Amon, Thank you for the reply. Apologies for the delayed response. With warmer weather moving in and the garden’s demanding attention it’s been a little hectic around here lately.
I never thought of using a template sensor while I await delivery of the real thing. Great idea, thanks.
- Some form of remote control or switch that could be initiated by the occupant. If, for example, the lady referenced in your use case wishes to leave heat running when the door is open, she would use the remote/switch to disable the automation. To re-enable, she would use the remote/switch to enable the automation. The disabled function could also be reset upon the door/window being closed.
- If the above mentioned automation is added then there should be a mean to allow an HA Admin to disable this ability (User Choice Lockout). Sometimes the occupant shouldn’t have a choice! Uhm, this might mean use of a helper. Not ideal! Makes installation of the Blueprint difficult.
- I mentioned the failure of a door/sensor being an issue. It was suggested that another automation be triggered by difference in temperature. I was thinking about heat, not A/C when I mentioned a low level temperature setting. My thought was this: if temperature in the room falls below a preset amount, say 55°F/16°C, heating would be restored and the automation disabled. I don’t see the same need for A/C.
- Should the failsafe mentioned above be added regardless of the state of the door/window sensor. Let’s assume someone opens a monitored door/window then, absent mindedly, leaves the house. Assume it’s very cold outside. The temperature in the house continues to fall. It could reach a point where water pipes or structural damage could occur. I think it would be better to override the automation and turn heating back on - assuming it was on in the first place!
5 You mention a clear definition (trigger) and to send a notification or even an actionable notification to an experienced Home Assistant user. I concur.
Thanks for the offer to add to this blueprint.
This is a much better implementation of what I had implemented in a limited way myself.
One question: What exactly is a window sensor? Is it a binary sensor that just needs on and off? None of my entities show up as options. My window sensors are Elk M1 alarm zones, which are either Normal or Violated…
Is the idea that I should make a template sensor for each HVAC zone that covers the specific sensors involved? I also have the issue that I can’t use the helper group creation feature because my alarm zones are not binary sensors, but if I am making custom template sensors, I can specify the entities in the yaml.
thanks!
Thanks!
It is a binary sensor with states like on/ off, Open/close, Lock/unlocked more details can be found here:
Yes. You make your own binary_sensor with the device_class: window out of the data you have. You need to specify the device class to window, otherwise the Blueprint will not recognize it.
Have also a look at this post here if you are having areas with more than one window or just to get an inspiration of templating.
Good day I wanted to try out the automation on my own, but I can’t select my window sensors there. Do I have to set something up beforehand? I haven’t been using the home assistant for that long and I’m not very familiar with it. The sensors are from Sonoff the SNZB-04
Is the device_class: window for your sensor? You can check that here /developer-tools/state
1 Like
Ah ok thanks it was device_class: door changed it to device_class: window and now it works.
All in all - after having heavily thought about the failsafe topic “How to monitor Home Assistant and prevent it from failing” I came to the following conclusion:
There is a need of another system that is used just for monitoring and diagnosing. Besides heating there are also other functions that also would need a monitoring. Imagine a door sensor fail in terms of a security alarm system. That monitoring system can of course be another Home Assistant instance or something similar. If your main Home Assistant is having any issues, the other one should inform you right away. But what about having problems with the internet connection that is probably needed in order to send messages to the outside world? We would also need an LTE/5G/3G Router to support that issue. Of curse, a backup battery would also be needed in order to get a notification of power failure and a complete stop of automations and functions managed by Home Assistant.
The delta temperature is used by some big climate IoT vendors like Tado and Fritz!Box in order to detect an open window. In practice, there are too many seasons where the delta is too small and the devices are doing wired things or do not work at all. Therefore, you could implement different deltas for summer, winter, autumn etc. But there is nothing more clear than a physical sensor attached to a window. And I have experienced them as very reliable. Videos like that support my opinion:
At the moment, the Blueprint has not been designed to make complex scenarios. We will need to give the developers a bit more time. In the meantime, we could work on a monitoring system as mentioned above. Thanks for giving me some inspiration!
Great! Can you tell us what climate device (thermostat) you are using?
I’ve been using this automation for a week or so now and find it works very well with the exception of one minor item. The length of time the automation waits before turning off the HVAC system. The current code reads;
I’m proposing a five minute timeout rather than the current two minute one.
During first days of use I discovered the two minute delay isn’t long enough for some situations. I often bring items from the kitchen to the patio table. During that time the door (being monitored) is often opened longer than two minutes. I’m finding the automation triggers when I don’t want it to. If the time to trigger was longer, then erroneous triggering could be avoided. I’ve determined that, on average, the door remains open just under five minutes. If you and others monitoring this thread agree, I like to see the blueprint update as noted below;
minimum_open_time:
name: Miniumum open time
description: Time in seconds to wait until the automation is triggered
default: 120
selector:
number:
min: 0.0
max: 600.0
unit_of_measurement: seconds
mode: slider
step: 5.0
Regards
@SmartLiving.Rocks , one item I forgot to mention is that the sensor I purchased reports itself as DOOR sensor. I got around this by changing the class attribute to window. Would it be possible to have the blueprint list both door and window sensors?