Automation triggers when sensor is unavailable even though it should not

Configuration
1

Hi, I have a strange problem where my automation triggers when a sensor becomes unavailable even though the trigger config is set to only fire when the state goes from off to on.


  trigger:
    - platform: state
      entity_id: binary_sensor.door
      from: 'off'
      to: 'on'

When looking at the state history for the sensor I cannot see any state history that is ‘on’ but the automation still triggered when going from ‘off’ to ‘unavailable’. This should not happen with the config above, right?! Any thoughts?

Update: the Home Assistant log says that the entity was removed and then the automation triggered without the entity being available. I guess the mqtt integration reset the entity after it disconnected from the mqtt server. The automation should not trigger though since the state never changed to ‘on’.

2

You’re right, it should not trigger when the state changes from off to unavailable. If it’s doing that then it’s a bug and should be reported (in the core repository). Out of curiosity, are you using 0.112? It has a known bug for MQTT Binary Sensors at startup (can sometimes set them to unavailable). What you’ve reported doesn’t match the known bug perfectly but it might be related. The known bug was corrected in 0.112.5 but that patch version was only released for Core. All other installation methods will receive the correction in 0.113.

1 Like
3

I was just able to reproduce this. I used an input_boolean. When I deleted that “helper” the automation triggered. I’ll look into it and will probably create an issue. I’ll keep you posted. FYI, I tested with 0.112.5. EDIT: Same behavior in 0.113.0b3.

2 Likes
4

Ouch! Definitely undesirable behavior given the explicitly clear declaration of:

      from: 'off'
      to: 'on'

I can’t help but feel this behavior must have cropped up recently because it would’ve been noticed a long, long time ago.

Out of curiosity, for your experiment with an input_boolean, how did you create an unavailable state? For example, does this happen momentarily on startup when the input_boolean is configured?

5

I didn’t. I based the test on the update in the OP where it said the automation triggered when an entity was removed. I used the UI “Helpers” page to create and then delete an input_boolean entity, because that seemed the easiest way to reproduce the problem.

1 Like
6

Opened issue #38014.

1 Like
7

Ironically, the bug may have been introduced by a PR intended to properly handle the case when an entity is removed. See:

EDIT: Just verified. That change was first introduced in 0.108. I tested 0.107.7 and the automation did not trigger. But in 0.108.0 it did.

3 Likes
8

Just added a comment to your Issue that I can reproduce the problem (using your posted example) and the automation is also triggered when the entity is merely disabled.

1 Like
9

Thanks guys for your help and investigation! I use 0.112.4. I will follow the reported issue and hopefully it will be fixed soon. Not a huge problem but it feels strange waking up to a notification telling you the front door was opened in the middle of the night with everyone asleep :slightly_smiling_face:

1 Like
10

:sweat:

I think at least it works for the scenario without to: restriction, right? :sweat_smile:

I’ll try to modify the tests to cover all combinations, sorry :grimacing:

1 Like
11

after 2 years…

guys… almost same (just other way around) happened today twice: my esphome module went offline for a few seconds, and when it came back below automation triggerred. This automation have trigger from “on” to “off”. So, is it possible that in 2 years this is not solved or is this another problem?

trigger:
  - platform: state
    entity_id: switch.pavle_dimmer_stena_izklop
    to: 'on'
    from: 'off'