How do I write automations that handle both turning something on *and* off again?

Complete noob question: how do I write automations to handle both the “turn on”-condition and the “turn off”-condition? I keep creating 2 automations evertime I need to handle an “on” and “off” action.

Concrete example: I have a humidity sensor in the bathroom. I have an automation so that, when humidity increase above 75%, HA acivates a “boost mode” on the ventilation system. I then have a separate automation to turn boost mode off again, when the humidity drops below 60%.

I use the front-end for this stuff, but I suppose the YAML is easier to share. Here are the two automations. How do I write this a single automation?

Start

alias: Vent bathroom humidity
description: Boost when bathroom humidity increase from showering
trigger:
  - type: humidity
    platform: device
    device_id: 342d6a8703e4223f16fee46888880014
    entity_id: 7adcffd4d7e5aef6880d7b76eedc4d9e
    domain: sensor
    above: 75
    for:
      hours: 0
      minutes: 1
      seconds: 0
condition:
  - condition: state
    entity_id: switch.ftx_boost
    state: "off"
action:
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.ftx_boost
mode: single

Stop

alias: Vent bathroom humidity stop
description: Stop boost when bathroom <60% humidity
trigger:
  - type: humidity
    platform: device
    device_id: 342d6a8703e4223f16fee46888880014
    entity_id: 7adcffd4d7e5aef6880d7b76eedc4d9e
    domain: sensor
    for:
      hours: 0
      minutes: 5
      seconds: 0
    below: 65
condition:
  - condition: state
    entity_id: switch.ftx_boost
    state: "on"
action:
  - service: switch.turn_off
    data: {}
    target:
      entity_id: switch.ftx_boost
mode: single

Add both your triggers to 1 automation and set a trigger id on each (different obviously). Then in actions use a choose and triggered by to call the right action.

alias: Vent bathroom humidity
description: Boost when bathroom humidity increase from showering
trigger:
  - type: humidity
    id: above75
    platform: device
    device_id: 342d6a8703e4223f16fee46888880014
    entity_id: 7adcffd4d7e5aef6880d7b76eedc4d9e
    domain: sensor
    above: 75
    for:
      hours: 0
      minutes: 1
      seconds: 0
  - type: humidity
    id: below65
    platform: device
    device_id: 342d6a8703e4223f16fee46888880014
    entity_id: 7adcffd4d7e5aef6880d7b76eedc4d9e
    domain: sensor
    for:
      hours: 0
      minutes: 5
      seconds: 0
    below: 65
action:
  action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - above75
        - condition: state
            entity_id: switch.ftx_boost
            state: "off"
        sequence:
          - service: switch.turn_on
            data: {}
            target:
              entity_id: switch.ftx_boost
      - conditions:
          - condition: trigger
            id:
              - below65
        - condition: state
            entity_id: switch.ftx_boost
            state: "on"
        sequence:
          - service: switch.turn_off
            data: {}
            target:
              entity_id: switch.ftx_boost
mode: single
1 Like

Need to remove that original condition that was left in there.

Sorry yes. Was doing on my tablet! Corrected it now. Thanks

1 Like

you can simplify it even more, have this as an example:


alias: "Parkinglot Switch light on/off "
description: Turn on at sunset, turn off after sunrise
trigger:
  - platform: sun
    event: sunset
    id: "on"
  - platform: sun
    event: sunrise
    id: "off"
condition: []
action:
  - service: switch.turn_{{ trigger.id }}
    target:
      entity_id: switch.shelly_parkinglight
mode: single

so maybe something like this?

trigger:
  - platform: numeric_state
    entity_id:sensor.ac3829_living_room_humidity
    above: 75
    id: "on”
    for:
      hours: 0
      minutes: 1
      seconds: 0
  - platform: numeric_state
    entity_id:sensor.ac3829_living_room_humidity
    below: 65
    id: "off”
    for:
      hours: 0
      minutes: 5
      seconds: 0
action:
  - service: switch.turn_{{ trigger.id }}
    target:
      entity_id: switch.ftx_boost

PS try to stay away from device_id’s; use entity_id’s instead

and there is realy no need to check for condition ’on’, nothing will happen if you call the service again (as you can only turn a switch on/off once :thinking:)

1 Like

@smarthomejunkie created a video tutorial about this topic, just watch and follow and your good to go: https://youtu.be/fE_MYcXYwMI?si=72N-1FnBdQhY3-DI

@DotNet2Web it could really be shorter still :grin:

:smiley: thats for sure :smiley:

and there is realy no need to check for condition ’on’, nothing will happen if you call the service again (as you can only turn a switch on/off once :thinking:)

I do the extra check in order to avoid spurious log messages or notifications. Eg. many of my automations ends with notifying me that the thing has happened (at least while setting things up, veryfying that everything works as I expect it to). Some triggers happens more frequently than Id like and so I took to the habit of checking if we’re actually moving from one state to the next, even if redundant calls aren’t harmful.

Perhaps there are better ways to filter out frequent or multiple triggerings of the same thing?

PS try to stay away from device_id’s; use entity_id’s instead

What’s the difference?

To be clear, these YAMLs were generated by the Automation front-end. I really hoped that the UI would generate YAML files that follow best practices…

Yet you can choose to use either…
image
Choose entities (as they are more clear, and easier to adjust later on, especially when you need to use yaml)

I don’t recognize that UI at all. Here’s what the Automation screen look like for me:

A new automation does not seem to offer entity, only device:

The best practice would be to use State when you need a trigger or a condition, and use Call service when you need an action. Both will let you use entity_id’s.

3 Likes

And this is the reason it is best practise:

That’s a bit out of date. Device automations are now supposed to be marked as unavailable if the devices they depend upon are not available, however that may be broken and it may prevent all automations loading. See here for some more up to date advice: Why and how to avoid device_ids in automations and scripts

2 Likes

Thanks @tom_l :wink:

That thread was amazingly helpful. Wish I had seen that a long time ago.

Even this simple statement is super helpful in wrapping my head around the terminology of Home Assistant;

Essentially, devices are physical objects, while entities are the functions or services.
For example, a Philips Hue motion sensor is a device which acts as a container for seven entities.

Nothing for it but to go back and rewrite my old automations. :smiley:

For future reference: