Sure! There is a version that accepts any binary sensor:
Happy Automating!
Iāve just stumbled upon this thread. Thanks for all the work youāve done so far, @SmartLiving.Rocks.
I can see a lot of versions on the blueprint being posted here and Iām struggling to find which one is the āmainā one which covers most use cases - I tried looking at the repo as well but itās difficult to see that from first glance. Can you give any tips?
Something that would potentially simplify the implementation - have you considered using dynamic scenes? You can capture the state of the climate entity in a dynamic scene before turning it off and once the minimum_close_time expires, you can turn on the scene which will bring back the old state of the climate entity (including modes, temperature, fan speeds etc). This way you wonāt have to create all those conditions for every (original) state of the climate entity 
The one you can download in the first post.
Yes, the blueprint initially had only a few lines of code and now it has 28 revisions since the introduction of blueprints to Home Assistant 
Due to the feedback and suggestions for improvements from the awesome users of this blueprint it grew over the time and fits to min. 96% of climate devices.
Actually the point with fan speed and heating/cooling mode is a good one. I have a fan coil thermostat that has a lot of features. Scenes - Home Assistant does not work because you need to hardcode a scene_id to the bp. Normally a user has several bp and the would all refere to the same scene_id and that would screw up the bp/ automation. Thanks for the idea!
Does not go back to auto when window/door close, itās go to manual mode.
Do you have a bit more information like the manufacturer, model, smarthome standard etc.
The TRV is TuYa TRV602 control via MQTT | Zigbee2MQTT im running it in auto mode, using a external temp sensor.
- 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
hvac_modes: auto, heat, off
preset_modes: none, auto, manual, off, on
Its turn off fine when you call heating off, itās need to set back to preset_modes: auto.
Ah okay. Now I see where the problem is. This blueprint is designed for climate.set_hvac_mode and it supports auto. Try to set your thermostat to auto with the service climate.set_hvac_mode and try again, please.
Still goes back to manual.
Going to use a automation for this.
hi SmartLiving.Rocks,
I think I found a bug in your blueprint when used with Tado heating this morning. When the Tado thermostat returns from āoffā to āheatā mode the heating target temperature gets replaced with the current room temp. This happens even when you simply turn the thermostat from āheatā to "off! and back to āonā manually within HA.
I think we may need to take the heat target temperature as a variable when the automation runs and turns the heating off and then set the target temperature back when itās reset.
Any thoughts how to accomplish this?
Did you check your settings on the Tado site?
Hi,
I am thinking of using this blueprint but instead of using window sensors I want to use precense dection with a mmwave zigbee device. The logic is: if for xx time the state of the sensor is ānoneā disable the ac, if the sensor is back to move restore the ac. Is this something that can be done ?
Yes. You can use your presence sensors as a basis for a template sensor.
Hello, unfortunately I have the problem that the heating is switched off but when the heating is activated again, the temperature stays at 5 degrees and does not go back to the old value before switching off. I have read that there are sometimes problems with the Homematic devices but I have not found anything that corresponds to my case.
Since I have underfloor heating and therefore do not use a setback temperature due to the inertia, all room thermostats are set to heat at a constant temperature. I use a HmIPW-STH.
In principle, it does not make much sense to install window detection because the underfloor heating is so slow. However, I thought that it could make sense now in the transition period. For example, the temperature is set to 20 degrees heating, I open the window, the temperature briefly drops below 20 degrees, valves open and warm water flows into the heating circuit, then I close the window and the temperature is already over 20 degrees again and the valve closes again. Actually, the heating shouldnāt have come on at all.
RM / search / FYI
Hi, thanks for the blueprint. Cool stuff!
I have window and door sensors and would like to continue using them as intended, eg I donāt want to change their device class. Instead I changed the blueprint slightly:
I changed
input:
window_entity:
name: Window Sensor
description: The window sensor that controls the climate entity. If you have
more window sensors please make a group sensor.
selector:
entity:
domain:
- binary_sensor
device_class:
- window
multiple: false
to
input:
window_entity:
name: Window Sensor
description: The window sensor that controls the climate entity. If you have
more window sensors please make a group sensor.
selector:
entity:
domain:
- binary_sensor
device_classes:
- device_class: window
- device_class: door
multiple: false
Now I can select doors and windows for this automation.
Also thereās something Iām missing is the fallback modes.
We use Tado heater controls and use automatic and manual modes mixed. I would like the fallback mode to go back to whatever the heating system was doing, be it automatic or manually set to heating or switched off.
The last thing I would love is this automation preventing rooms to be heated when doors are opened at the moment an automation is triggered. Sometimes we forget to close the kitchen doors at night and the Tado automation will try heat up the kitchen in the morning, even when both our doors are being left open.
Yes, a few years ago I also delivered alternatives of this Blueprint using my GitHub. GitHub - SmartLiving-Rocks/Blueprint: Blueprints fĆ¼r Home Assistant in deutscher Sprache. "Fenster auf, Heizung aus!" mit nur 3 Klicks umsetzen! Auch fĆ¼r Klimaanlagen und andere climat.entity geeignet!
Glad that it is working for you.
Fallback
That feedback is really inspiring! What do you have in mind for the following questions:
- What trigger should be used in order to set the previous mode?
- What conditions should be met in order to set the previous mode.
Group Sensor
You can make a helper binary group sensor that combines of all your binary sensors (door/window/input boolean) in that certain area.
That Group Sensor could have also been used to answer your first question instead of changing the Blueprint.
Merry Christmas!
Iāve been working out this idea a bit and got it working for my situation.
Iām not really experienced with programming and creating blueprints, so Iāve created two automations and two helpers: an input_select helper for storing the HVAC mode (listed auto, off and heat as options) and an input_number helper for storing the target temperature.
The first automation is triggered when the door is opened. When the HVAC mode is set to āautoā, this will be stored in the input_select helper and the HVAC will then be turned off. When the HVAC mode is set to āheatā, this will be stored in the input_select helper, the target temperature will be stored in the input_number helper and the HVAC will be turned off. When the HVAC mode is set to āoffā, this will be stored in the input_select helper and no action will be taken.
hereās the yaml:
alias: Woonkamer verwarming uit bij openen deur
description: ""
triggers:
- trigger: state
entity_id:
- binary_sensor.schuifpui_openen
to: "on"
conditions: []
actions:
- if:
- condition: state
entity_id: climate.woonkamer
state: auto
then:
- action: input_select.set_options
metadata: {}
data:
options:
- auto
target:
entity_id: input_select.woonkamer_thermostaat_modus_opslag
- device_id: xxx
domain: climate
entity_id: xxx
type: set_hvac_mode
hvac_mode: "off"
else:
- if:
- condition: state
entity_id: climate.woonkamer
state: "off"
then:
- action: input_select.set_options
metadata: {}
data:
options:
- "off"
target:
entity_id: input_select.woonkamer_thermostaat_modus_opslag
else:
- action: input_select.set_options
metadata: {}
data:
options:
- heat
target:
entity_id: input_select.woonkamer_thermostaat_modus_opslag
- action: input_number.set_value
metadata: {}
data:
value: "{{ state_attr('climate.woonkamer', 'temperature') }}"
target:
entity_id: input_number.woonkamer_thermostaat_temperatuur_opslag
- device_id: xxx
domain: climate
entity_id: xxx
type: set_hvac_mode
hvac_mode: "off"
mode: single
The second automation is triggered by closing the door. When the door is closed, the HVAC will be turned back on, selecting the HVAC mode stored in the input_select helper and, when the HVAC mode is āheatā, selecting the target temperature stored in the input_number helper.
Hereās the yaml:
alias: Herstel verwarming woonkamer na sluiten deur
description: ""
triggers:
- trigger: state
entity_id:
- binary_sensor.schuifpui_openen
to: "off"
conditions: []
actions:
- data:
entity_id: climate.woonkamer
hvac_mode: "{{ states('input_select.woonkamer_thermostaat_modus_opslag') }}"
action: climate.set_hvac_mode
- condition: template
value_template: "{{ states('input_select.woonkamer_thermostaat_modus_opslag') == 'heat' }}"
- data:
entity_id: climate.woonkamer
temperature: >-
{{ states('input_number.woonkamer_thermostaat_temperatuur_opslag') |
float }}
action: climate.set_temperature
mode: single
For me this works really well, but Iāll need to duplicate this for every room in my house that has Tado HVAC control and a door/window sensor, so I really hope you could implement this in the blueprint somehow, preferably without the need of creating helpers.
Regarding this request
And this statement:
Is this still valid? Or can this blueprint finally solve my issue? Now that it seems to have been updated and
- has the
mode: singleadded finally and - even allows to run custom actions in addition
this sounds like I could finally implement this. ā¦IF I can set a variable like temperature_before (which gets read in the close_action section so I can pass it to the
- service: climate.set_temperature
target:
entity_id: !input climate_target
data:
temperature: !input temperature_before
service.
Thanks for an update on this @SmartLiving.Rocks 
Edit: gave it a try myself with
open_action:
- variables:
former_temperature: >-
{{ state_attr('climate.thermostat', 'current_temperature') |
float(0) }}
- service: climate.set_temperature
target:
entity_id: climate.thermostat
data:
temperature: 10
and then using
close_action:
- service: climate.set_temperature
target:
entity_id: climate.thermostat
data:
temperature: {{ former_temperature }}
This unfortunately gives the error expected float for dictionary value @ data['temperature'].
Edit 2:
After spending one more hour I realized it seems to be impossible for a blueprint automation to access variables set in a blueprint based variable in a later action. I could not get rid of the error. Therefore, for now (until you confirm/deny), I migrated away from the blueprint to a fully manual automation. Here the variable is fully accessible. Maybe a HA Core limitation?