Why this automation is triggering even without state changes?

Configuration
#1

I’m using this automation to turn off the Air Purifier when I open the window and turn back on when I close it. But it’s triggering even when the window is closed all the time.

alias: Air Purifier - Turn On/Off when the Window is closed/open for 30s
mode: single

trigger:
  - platform: state
    entity_id: binary_sensor.livingroom_window
    for: '00:00:30'

condition: []

action:
  - entity_id: fan.air_purifier
    data: {}
    service: >-
      {% if is_state('binary_sensor.livingroom_window', 'on') %}
        fan.turn_off
      {% elif is_state('binary_sensor.livingroom_window', 'off') %}
        fan.turn_on
      {% endif %}
#2

Check the logbook in the sidebar. It mentions why an automation has been triggered and by whom.

grafik
grafik1545×162 15.5 KB

#3

I know that. It says that it’s triggered by the window, but how, when there is no state change from the window sensor?

Screenshot 2021-01-14 003848
Screenshot 2021-01-14 0038481540×243 23.5 KB

#4

So you should have included that in your initial post (obviating the need to be rude to @m0wlheld)
It says triggered by the entity, so the way your automation is written it could be any attribute of that entity that causes the trigger.
You can either double up on the trigger (both with opposing from and to’s)
Or simpler insert a condition to ensure that trigger_to.state != trigger_from.state
If that fixes your problem you are laughing, otherwise you will at least have more information.
What type of sensor is it.?

#5

Does your window sensor have any unknowns/unavailable’s shown in its history? Poor signal/connectivity could cause it.

If the device becomes uncontactable, that is enough to count for a state change. So closed -> unknown -> closed, would trigger your script.

Suggest you change it so it has states from: closed to: open and vice versa.

#6

Try this

trigger:
  - platform: state
    entity_id: binary_sensor.livingroom_window
    for: '00:00:30'
condition:
  - "{{ trigger.to_state.state != trigger.from_state.state }}"
action:
  - service: >
      fan.turn_{{ 'off' if trigger.to_state.state == 'on' else 'on' }}
    entity_id: fan.air_purifier

Or this

trigger:
  - platform: state
    entity_id: binary_sensor.livingroom_window
    for: '00:00:30'
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.livingroom_window
    for: '00:00:30'
    from: 'on'
    to: 'off'
action:
  - service: >
      fan.turn_{{ 'off' if trigger.to_state.state == 'on' else 'on' }}
    entity_id: fan.air_purifier

Basicslly the two options that Mutt suggested (and a little template magic to make it shorter :stuck_out_tongue:)

3 Likes
#8

The update from @Burningstone is the right one. It will prevent the automation to be triggered by state changes other than on -> off and off -> on.

#9

That’s not enough here as he wants to turn the fan on and off if the window is open or closed for 30 seconds.

#10

Does the triggering actually do harm? It the purifier on or off when undesired? As already mentioned, state changes other then “to on” or “to off” can trigger this automation (state changes to “unavailable”), but the if-then-else-condition in your automation’s action should prevent unwanted results.

#11

Thanks for all the replays.
I’m currently trying the condition from @Burningstone and for now it works fine.

My question was, why is triggering when there is no change (open/closed) from the sensor.
But probably the trigger was any other change like battery percentage drop, or linkquality.

#12

Because the state trigger reacts to any changes to the state object, which includes attributes. As you didn’t specify any to or from for the ‘state’ itself, this would include things like battery level updates, signal strength updates etc.

2 Likes