Dynamic scene_id, very good hint. It doesn’t seem to be possibel (until now) templating this parameter. What I found here might be a possible solution. I will investigate it.
I made a little success. I got an entity list with
{{ expand(state_attr('climate.trv_wohnzimmer', 'entity_id')) |map(attribute='entity_id')|list }}
I did define this device group in configuration.yaml like this:
climate:
- platform: climate_group
name: TRV-Wohnzimmer
temperature_unit: C
entities:
- climate.trv_wohnen_01
- climate.trv_wohnen_02
- climate.trv_wohnen_03
To group climate devices you’ll need Home Assistant Climate Group
Now i will do some tests how it behaves when you open and close several windows.
This doesn’t work also. becaus it restores always the last situation. I will try using two scripts as described here https://community.home-assistant.io/t/turning-on-a-scene-with-a-dynamic-entity-id-in-a-script/283941
Indeed, that tricky. Interesting links you have shared! Especially the climate group.
Here is also a guy who wants to improve the climate automation using node red. Maybe that is helpful for you: Window open, climate off - #191 by snikay
As far as I understand, you want to have a shorter code, but now you are creating two more scripts for each heating area to get it working?
Generally, Blueprints are designed to make complicated code easy to use for non-coders. You can have a look at how this Blueprint started (very easy, simple and straight forward) and how it has developed over the time. The community gave great feedback and we discovered a lot of corner cases from all over the world. Covering more than 90% of all climate devices from different vendors worldwide including air conditioning. To make it working and over all the corner cases the code became more complex/ complicated but at the same time it got better and better and now it is rock solid 
with more than 3,500 installations and even a fork for Homematic users as well as a working solution for AVM Fritz Dect Thermostats.
Regarding Homematic: thanks for pointing out the option to control the window state via setDevice-Dingenskirchen.
There is also an even better approach (in my opinion). When using the superceding in development integration for Homematic: GitHub - danielperna84/custom_homematic: Custom Home Assistant Component for HomeMatic one can expose the window state as a switch entity. The main benefit is that this adds read access to the state.
By default the window state is not exposed. You have to add the line “WINDOW_STATE” to an unignore file. See Fensterzustand TRV · Discussion #725 · danielperna84/hahomematic · GitHub
Thanks for sharing. I am already following the topic on github - somebody on the German Home Assistant matrix channel recommended it to me.
Unfortunately, I have not fully understood the homematic cosmos with it ip/wired/ “normal” and its reasperymatic in order to make it fully local accessible. Too complicated for a Z-Wave guy 
As far as I have seen, you already have reached out to @sota who is the Homematic expert and also made a blueprint version.
I’m facing an issue, the thread is too long to follow and can’t find similar that I’m facing. I have four automation that happens when open some window or door sensor and stops heating just as this blueprint promises, all automations was launched because I’m using mode: parallel, but when the first paralleled automation finish, all are finished also, is this behaviour correct? Or exist a way to each paralleled automation ends when the door window match conditions?
alias: Clima) Apagar calefacción Matrimonio si se abren puertas o ventanas
description: ""
mode: parallel
max: 4
use_blueprint:
path: SmartLiving.Rocks/window-open-climate-off.yaml
input:
window_entity: binary_sensor.sensores_de_ventanas_y_puertas_en_matrimonio
minimum_open_time: 60
minimum_close_time: 30
climate_target: climate.dormitorio_matrimonio
Why?
My original code is single
Then, it’s not possible to handle the automation for each room in parallel way? When I run the automation in more than one room, only one of the automation works
Was my mistake, I’m trying again, I revert the code without parallel and works as expected, thank a lot, something mysterious happened today at morning
Due to some limitation, a Shelly TRV doesn’t come back to the initial setting (temperature). Is it possible to toggle the preset instead of the HVAC (“operation” in UI)? Or do you think of a workaround? Thanks in advance.
Interesting! Thanks for Testing my blueprint with Shelly TVR.
I think here is the problem as the thermostat does not have an ‘off’ state.
I need to think how we can handle it.
- Storing the temperature needs an additional helper that needs to be created manually.
- Setting the temperature to its minimum is a solution but it would be exclusive for Shelly.
- Ask shelly to upgrade their firmware.
I have the same behaviour with a Zwave thermostat that is 8 years old. Turning off should be supported and I think more users will claim it
Hi. I’m using your blueprint and you’ve done a wonderful work!
I wonder if there was a way to detect when the door/window is open for a given time (e.g. 2 minutes) and then stop the cycle of the automation.
Better explained, I want it to work as it is intended to be, so I open the door and the climate stops, I close it and it restores the previous HVAC mode but I wanted to stop the automation if the door was open for more than X time and keep the climate device off.
Regards,
Handryck
You can use the optional action part for that. Choose a delay e.g. 5 min and then a call service ‘automation turn off’ and choose the automation (you need to create the automation first)!
How are you going to turn on the automation again?
Thanks.
Well, I don’t actually know how to turn it on again, I didn’t think of that. Would that work if instead of calling the service for automation stop I just use a normal “stop” command after the given delay of time under an if-else condition?
For instance, as the normal “stop command” I mean the one that can be chosen under the actions button.
Okay, is that what you want:
- Door is opened and turns off the climate/heater
- After 5 minutes the climate/heater should be turned on again unless the door is still open
I am not sure what you want to stop.
The heater not heating?
Not really.
My explanation was bad, let me be more precise:
What I want is:
- Door is opened and turns off the climate, just what your blueprint does normally.
- Let’s say the door is still open and the climate is still off by the automation, I want that if the door remains open for e.g. 5 minutes it will NOT turn on the climate again. If that time hasn’t passed yet the automation works normally so it turns on the climate again.
I just want to stop the automation if the door has been open for too much time (e.g. 5 min). Of course, when I turn on the climate again the automation cycle should reset and start over.
I hope this explanation was understandable.
Regards
So if the door is opened for more than 5 minutes, the blueprint stop the blueprint. If the door is closed, it can not turn_on the climate because the automation was stopped/canceled.
If climate entity will be turned_on manually, by another automation or script, the blueprint will trigger again and work as expected.
I have just tested it with the stop command after the delay. I think it is what you are looking for.
It stops the current automation and does not affect any change of the door sensor unless the climate is set to any other state than off
That’s exactly what I was looking for, but I tested it and doesn’t work.
When I open the door, it doesn’t even turn_off the climate before the delay (in this case 5 minutes), it just drops the blueprint execution.
Is there a way to stop the execution ONLY when the door has been opened for more than 5 minutes?
