Automation: When a window opens, turn down thermostats *in that room*

Configuration
1

I have six thermostats and seven door/window sensors in five rooms. I was in the process of making the relevant automations:

  • if window in room 1 opens, turn down thermostat in room 1
  • if window in room 1 closes, restore thermostat in room 1
  • if window in room 2 opens, turn down thermostat in room 2
  • …

But it occurred to me that this is going to create a lot of automations!

This would - I think - be a better solution:

  1. if window opens, turn down all thermostats in that room
  2. if window closes, restore thermostat in that room

Would that be possible?

2

You could use IDs for each sensor that triggers that automation in order to turn down the right thermostat:

  - trigger:
      - platform: state
        id: 'livingroom'
        entity_id: binary_sensor.window_livingroom
1 Like
3

Sounds like a good idea - but I don’t see how I would actually put it into an automation…?

4

This is a general concept using templating with the basic on/off climate services. The details of the action section really depends on what type of thermostat/climate device you are using. If you need more specific actions such as setting temperature and mode you will probably need to use a Choose action to save and restore the settings.

trigger:
  - platform: state
    to: 
      - 'on'
      - 'off'
    entity_id: 
      - binary_sensor.window_1
      - binary_sensor.window_2
      - binary_sensor.window_3
condition: []
action:
  - variables:
      area: "{{ area_name(trigger.entity_id) }}"
      targets: >
        {{ expand(area_entities(area))
        | selectattr('domain','eq','climate')
        | map(attribute='entity_id') | join  }}
  - service: climate.turn_{{ iif( trigger.to_state.state == 'on', 'off', 'on') }}
    target:
      entity_id: "{{ targets }}"

One relatively easy way to save and recall the settings of a device like a thermostat is to use the scene.create service.

Area-based Example with Scene creation 
trigger:
  - platform: state
    to: 
      - 'on'
      - 'off'
    entity_id: 
      - binary_sensor.window_1
      - binary_sensor.window_2
      - binary_sensor.window_3_and_door_1
condition: []
action:
  - variables:
      area: "{{ area_name(trigger.entity_id) }}"
      targets: >
        {{ expand(area_entities(area))
        | selectattr('domain','eq','climate')
        | map(attribute='entity_id') | join  }}
  - choose:
    - conditions:
        - condition: template
          value_template: "{{ trigger.to_state.state == 'on' }}"
      sequence:
        - service: scene.create
          data:
            scene_id: thermostat_settings_{{area}}
            snapshot_entities: '{{ targets }}' 
        - delay: 5
        - service: climate.turn_off
          target:
            entity_id: "{{ targets }}"
    - conditions:
        - condition: template
          value_template: "{{ trigger.to_state.state == 'off' }}"
      sequence:
        - service: scene.turn_on
          target:
            entity_id: scene.thermostat_settings_{{area}}

Things to keep in mind:

  1. These ad hoc scenes do not survive restart, so you may need to create additional options within the Choose action to handle those situations.
  2. In rooms with more than one window and/or door entity being monitored it would be best to create a binary sensor group of those entities and put that in the trigger instead of the individual sensors. If you use the individual sensors you will need to filter out triggers caused by a second window being opened when one is already open. Otherwise, you will overwrite the scene that saved your original settings.
2 Likes
5

Okay; I was hoping this could be done without YAML, but I guess not. I’ve already had to use it a bit, though I’m not yet confident using it. I’ve never used YAML before, and some of it seems way more complicated than just markup. So I googled “selectattr” which you wrote above and found out that that’s not even YAML, that’s “Jinja” - am I correct?

This is something else I’ve never even heard of before - so I guess I have a learning curve ahead before I can feel like I know what I’m doing :slight_smile: But thank you very much for your kind answer!

The last thing you list is something I’ve actually implemented successfully now. I have two windows in my living room, so I have four automations:

  1. If Window 1 is opened AND Window 2 is closed, create a scene and turn down the thermostat,
  2. If Window 2 is opened AND Window 1 is closed, create a scene and turn down the thermostat,
  3. If Window 1 is closed AND Window 2 is closed, activate the saved scene,
  4. If Window 2 is closed AND Window 1 is closed, activate the saved scene,

Somewhat lengthy, but at least it is transparent to me what’s going on :slight_smile:

1 Like
6

I’m pretty sure you could accomplish the task in one (very long) automation using just the UI Automation editor. However, it will be worthwhile to learn the basics of how yaml is used in HA. You will find that most users on this forum and other places will give examples and answers in yaml. There really isn’t a good way to share an example from the automation editor for anything complex.

  • Screenshots take too much work to create and share, and then you would have to manually recreate the automation on your end.
  • Blueprints are great, but they are more difficult to write than an automation and, once created, are relatively rigid.

In contrast, the yaml example can be copied and pasted, and you just need to swap in your entity ids for the example ones I made up. Some of the most helpful users on here have helped 100’s and even 1000’s of people by writing up a quick automation to answer a question, but few of them have made more than a couple blueprints.

There have been changes to the Automation editor recently, but this video on translating YAML Automations for use in the UI Automation Editor is still a good primer.

Yes, templating in HA is done using Jinja. It is a very powerful tool that lets you extract and modify data in HA to create sensors, scripts, automations, and even dashboard cards.

In the second example above, using templates makes it so I only had to set up 2 options in the Choose action. Without templates, you would need to set up at least 2 options (on/off) for each room.

This is a great example of how Groups can save you from having to do extra work setting up or designing automations. If you create a binary sensor group that contains both Window 1 and Window 2 (making no other changes to the structure of your automations) you would only need 2 automations. And, the automations themselves would be more transparent because the group behavior handles the fact that you don’t need to retrigger if/when the second window opens, you don’t need to add those conditions yourself.