Creating a generic window sensor and thermostat automation

Hi guys,

I want to create an automation for my rooms with door/windows sensors to set the thermostats in the room in eco mode and back to the state before the window was opened.

My window sensors are named as binary_sensor.fenster_{roomname} and my thermostates are named like climate.{roomname/groupname}

I have written this automation:

- id: '1661882818143'
  alias: Fenster auf/Heizung aus
  trigger:
  - id: 'eco'
    platform: numeric_state
    entity_id: binary_sensor.fenster_badezimmer
    above: '1'
  - id: 'comfort'
    platform: numeric_state
    entity_id: binary_sensor.fenster_badezimmer
    below: '0'
  action:
  - service: climate.set_preset_mode
    target:
      entity_id: climate.badezimmer
    data:
      preset_mode: {{ trigger.id }}

But this is only usable for one room, but I want to use one automation for every room. Is there any chance to generalize this?

I use sed to perform substitutions to replicate packages / automations. From a shell prompt

sed "s/_badezimmer/_badezimmer2/g" template_automation.yaml > template_badezimmer2_automation.yaml

You also need to generate a unique id. I would just append badezimmer to the id.

More examples here

1 Like

@PeteRage Well I even thought about this (I’m a developer so this wouldn’t be too hard for me) but I would prefer a yaml only solution within HA. But this could be my emergency solution if nothing else works :slight_smile:

Thank you for the hint!

If you use

{{ trigger.entity_id.split("_")[2] }}

that should return badezimmer in your example. But that requires all sensors to be named equally.
Why are you using numeric state trigger?

That means:

  action:
  - service: climate.set_preset_mode
    target:
      entity_id: "{{ 'climate.' ~ trigger.entity_id.split("_")[2] }}"
    data:
      preset_mode: {{ trigger.id }}

Should work

1 Like

You could do something like what I proposed in this Area-based automation to define the target climate entity.

1 Like

Naming shouldn’t bre a big problem here imho. I use the numeric state trigger because that was a neat solution by another guy here in the forum for another usecase.

I can’t see how that is “neater” than using on/off as the state is. In my opinion it just makes it harder to read.
But if it works then go ahead.

I guess there pretty neat hints mentioned by @Didgeridrew and @Hellis81. But there is one problem which I haven’t adressed or not outlined correctly:

When I open my window of the bathroom while beeing in eco mode the thermostat should be reverted into that mode again.

Can I retrieve the current preset_mode and store them to revert them back later?

Yeah, there is an edge case when opening the windows in eco mode and closing them in comfort mode (which could be the case because the schedules are on my Fritz!Box) but that could be ignored I guess.

What would be your approach to tackle this? I’m surely open to any other “better” solution :slight_smile:

That should be covered by the collapsed “Area-based Example with Scene creation” in the l post I linked above.

1 Like

Thank you! Will digg into this :slight_smile:

@Didgeridrew your approach is very cool it works flawlessly :slight_smile: thank you!

I’m currently using my phone but.
Use state trigger, to: on or to: off.

That is the states of a binary sensor so no “conversion” is needed anymore.

1 Like