Window open, climate off

Interesting use case. So you want the blueprint to turn of the climate device and open a blind? If the window is closed again turn the heating back to its previous state as well as the blinds?

I thing we would need an additional helper to save the blind position in order to make it work.

yes, exactly.
i didn’t thought about saving the state though.
Just open to a user given value (like 10%) and back off. Just for opening the blinds to let a little bit more air through. because most of the time, opening a window is about ventilation, right? :slight_smile:
i don’t know of a scenario where it’s needed to turn the blinds back to the state before.
even for a window-door with blinds, i guess it’s okay to turn it to 100% (e.g. for entering a terrace) without saving the state.
i guess even checking day/night times is not necessary, because even in day times, opening a window with closed blinds seems pointless.

so maybe like this:

window example:

  • blind-entity: XY (window)
    – approach target value below: XY (10%)
    – target value: XY (15%)
    – close back after window is closed: Y/N (Yes)

terrace door example:

  • blind-entity: XY (terrace-door)
    – approach target value below: XY (100%)
    – target value: XY (100%)
    – close back after window is closed: Y/N (No) (because it would lock you out)

thank you

:face_with_raised_eyebrow: I am seeing too much corner cases and a lot of additional helpers that would be required.

But there have also been some feature requests regarding notifications:

:partying_face: Now we finally can do what ever we want!

@snikay As you are mentioning also to control the blinds, suddenly the feature introduced by Loxone came to my mind. Bugs, especially mosquitos, cannot see if there is red light. With the updated version of the blueprint, you have the freedom to also control the lights.

Here is a version that has additional action features. You have to import it manually from GitHub because I do not know if it is 100% stable. Please feel free to give it a try and let me know how it is working.

1 Like

Thanks @SmartLiving.Rocks. I’ve installed the blueprint. Will report any problems.

1 Like

altough i like the feature of addional actions for all sorts of things, i still think blinds will be the most used one. also blinds are very special, because it needs to check whether the blinds are closed or not, which needs again choosing the “do-if” action and makes the usage of a blueprint a little obsolete^^ otherwise the blinds would close if already open.
same for closing-action (checking for after sunset to close).
maybe you can add blinds on top? :slight_smile:

1 Like

Thanks for the feedback. I totally agree that there is a need for a functionality like this. Actually, I have tried to get it working, so that the position is stored to a variable if the window is opened. So I added a part in the Blueprint.

variables:
  cover_previous_position: {{ states.cover.living_room_window.attributes.current_position }}

and in the action part:

  - service: cover.set_cover_position
    data_template:
      position: '{{ states(cover_previous_position) }}'

:warning: But it is not possible :warning:

The variable is set correctly but cannot be restored:

Error: Error rendering data template: AttributeError: 'NoneType' object has no attribute 'lower'

Workaround

As I already have tried to explain here - an additional input numbers helper is needed to store the current value of the blind_position Open your Home Assistant instance and show your helper entities.

Create Helper

I named mine input_number.test_2

Use additional actions of the Blueprint to control the cover

:warning: Make sure you have imported the right version from GitHub :warning:
You can directly import the Blueprint directly here:
Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

I have used in my Example cover.living_room_window

Additional Open Action

  1. In order to set the current position of the blind to the input number use a Call Service action:
service: input_number.set_value
target:
  entity_id: input_number.test_2
data_template:
  value: '{{ state_attr(''cover.living_room_window'', ''current_position'') | int  }}'

  1. Open the Blind

Additional Close Action

  1. Set the cover to the saved position of the input number value use a Call Service action:
service: cover.set_cover_position
data:
  position: '{{ states(''input_number.test_2'') | int  }}'
target:
  entity_id: cover.living_room_window

:partying_face: You are done!

At least for the moment. Additional features like the mentioned sunset, close back after window is closed: Y/N (Yes) and stuff like that are still not part of a KISS climate blueprint (POV)!

ezgif-4-960674f87d

Additional information


Here is the blueprint in YAML

alias: '😎 Window based climate-entity control with cover control'
description: ''
use_blueprint:
  path: SmartLiving-Rocks/window open climate off with optional actions.yaml
  input:
    open_action:
      - service: input_number.set_value
        target:
          entity_id: input_number.test_2
        data_template:
          value: >-
            {{ state_attr('cover.living_room_window', 'current_position') | int 
            }}
      - service: cover.open_cover
        data: {}
        target:
          entity_id: cover.living_room_window
    window_entity: binary_sensor.door_window_sensor_x
    minimum_open_time: 1
    climate_target: climate.hvac
    close_action:
      - service: cover.set_cover_position
        data:
          position: '{{ states(''input_number.test_2'') | int  }}'
        target:
          entity_id: cover.living_room_window

thank you again.

i see storing the value of the blinds before opening the window is making things complex. but i don’t think it’s actually necessary. at least not for me. just check for like “is blind closed?” if yes, open to XY%. if already opened to some percent, for me, it could stay that way. because i want to open it to only 20% anyway.
so would that latest version only work with that helper? or does it also work without? like choosing between “stupid” and “smart” ? ^^

Is it possible to add a delay before the climate returns to the state from before the window sensor was activated?
I have 5 TRV’s and I prefer if they all turns off, when a window is opened, but then I would prefer if there could be a delay for like 5 minutes before the TRV’s returns to heating mode after all windows are closed.

there is a minimum open time, but i too thought about a minimum closing time - would be great especially if one’s closing the tilted window just for a second to open it completely.

Sure! Here you go:

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

You can have a look at the code on GitHub.

You haven’t made your self familiar with the “Choose” or the “If-then” options for the additional action part, have you? If yes, please share the code with us and tell us what is not working

Sure it is! And it is even more complex to build because a lot of people have Venetian blinds nowadays. That means also to save the tilt position and results in two helpers for each blind entity. Yes it is more complex, but it also should fit all situations and not only an individual one.

Wonderful addition! Thank you.

1 Like

Hi Amon

Really a great blueprint, it works off the shelf while sticking to the supported HAVC modes :slight_smile:
The only trouble I had: My AC was in hvac-mode “cool” which is not supported by your blueprint. Took me a while until I noticed. It would be great if you could include this mode as well :slight_smile:

Best regards
Tom

Actually, it is already included as you can see here:

Please have a closer look at the trace of your AC automation and share the result with us. Thanks!

I’ve noticed that “Additional Close Actions” occur as soon as the window sensor triggers, not after any set delay time. I’d like to see the close action occur at the end of the delay cycle. What are your thoughts? Should the action occur at the time the sensor changes or should it occur after the set time delay? Perhaps an option for either?

I see this being useful in cases such as blinds being set to automatically close once a window is closed. Without a delay, the person closing the window may be in way of the closing blinds.

Thanks for your feedback and testing the automation. That is very helpful. I agree that the additional close action should be after the delay.

So I have changed the code accordingly - give it a try and tell us what you think!

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Maybe there are also use cases that require Additional Close Action (Optional)

  1. At the time of closing
  2. After the delay of Miniumum close time

Maybe someone can give us an example for each case - that would be helpful

Appreciate the change. It’s been downloaded and installed. Will advise if trouble arises.

Thank you.

1 Like

Can you share the Trace?

Really helpful blueprint which saves a lot of time. Thank you for it.

I have a quite large living room with 4 windows and 2 radiators. For the window sensors I created a group, but the helper doesn’t support a climate group. I did it with the old syntax in the yaml configuration, but this wouldn’t be recognized by your blueprint.
Of course I can use 2 automations, one for each radiator, but is there maybe a more elegant solution for this?

Yes, grouping climate devices is not possible because of the different states a climate device has. It is a bit more complex as e.g. a binary sensor (open/close).

I have added a second thermostat that acts as a slave. So if it has Home Assistant different state than the master, it will be overwritten.

Here is a version with two thermostats:

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Let me know if it is working for you! Furthermore, would also like to know what thermostats you are using (vendor and model). Thanks and have a nice day!