False trigger when sensor becomes unavailable

Configuration
1

I hope someone can help. I have a wifi plug with current monitoring and use the info from that as a current sensor in HA. This is used on the tumble dryer to get a notification when it has finished. It works well except that every once in a while the wifi plug goes unavailable and when it becomes available again it triggers a false alert. Any suggestions on how better to code this?

- id: 646380wer4
  alias: Tumble Dryer Finished
  trigger:
  - below: '50'
    entity_id: sensor.pm1_watts
    for: 00:01:00
    platform: numeric_state
  condition:
  - condition: numeric_state
    entity_id: sensor.pm1_voltage
    above: '200'
  - condition: time
    after: 07:00
    before: '23:00'
  action:
  - service: media_player.volume_set
    entity_id:
    - media_player.everywhere
    data:
      volume_level: '0.6'
  - delay: 00:00:01
  - service: notify.alexa_media
    data:
      target:
      - media_player.everywhere
      data:
        type: announce
      message: HURRAY! your pants have finished drying
  mode: single
1 Like
2

I thought this was fixed for the Numeric State Trigger in the version 2021.3.X. Which version are you using?

3

I’m on 2021.3.3. I see 2021.3.4 is available so I will upgrade although I didn’t notice this issue in the release notes. Be great if that fixes it!

4

I believe the correction is in the major release (2021.3.X), so if you’re not experiencing its improvement then upgrading to the 2021.3.4 patch release won’t help.

It was my understanding that the Numeric State Trigger, on startup, would only trigger if the previous value is a valid numeric value. For example, if it was null or unknown and then changed to 45 that should not cause the Numeric State Trigger to trigger (if using below: 50). I thought unavailable is handled the same way but your experience implies it isn’t. Perhaps the for option influences it.

5

Thanks for the explanation but it seems I’ll still have the issue then. I set it to below 50 for 1 minute to make sure the cycle had properly ended. I’ll test without the “for” statement and see what happens.

6

The behavior I described is found in this PR:

This line:

Specifically, we do not want to trigger numeric_state when moving from true to unavailable and back to true

It was created as a result of this discussion in the Architecture repo:

However, I think it was superseded by another PR:

It appears to introduce the behavior you observed:

  • Entity available, condition matches → trigger
  • Entity becomes unavailable
  • Entity becomes available again → condition matches → trigger
7

Yeah the change was reverted after comments in the release notes topic.

1 Like
8

Thanks for the info. I tried removing the “for” condition but it still occurs. I had hoped that using the “below” as the trigger meant that nothing would happen until the sensor had registered something above that value but it seems that the unavailable condition overrides. I think I somehow need to add a condition “and the sensor has not been unavailable within the last 10 minutes”

9

Yeah the change was reverted as it needed more discussion. Maybe we can start that discussion here?

The issue that this thread highlights is: how should the unavailable state be treated in a trigger?

Take the trigger from above (simplified):

trigger:
- platform: numeric_state
  entity_id: sensor.watts
  below: 50

If the sensor goes from 0 to unavailable and back to 0, do we want the trigger to fire? We do not really know because the value might or might not have been above 50 during the outage so both choices could be said to be right.

One way to look at it is “we do not know what happened so we have to trigger or we might miss an event”.

The other way to look at it is “we have no knowledge that the threshold was crossed so we should not trigger”.

A related example to consider:

trigger:
- platform: state
  entity_id: media_player.music
  from: 'playing'
  to: 'idle'

What should happen here if the state goes through playing -> unavailable -> idle?

(Note, I am asking how things should preferably work if starting from scratch; not how they work today)

10

Thanks amelchio for the insight into the thinking, I can see it is a potential can of worms. Perhaps we need a sort of failsafe = 1 or failsafe = 0 option, so we can choose which we think is the better option - trigger or do not trigger if the state is unknown.
For now I have created a history stats sensor to monitor if the sensor watts registers unavailable and added a condition to check this. I’ve only just done that so will need a few days to see if it works.

11

I think the trigger should occur when value changes from one valid state to another, where “valid” is determined by the entity (i.e. on/off for input_booleans and switches, etc). That would make unavailable universally an invalid value. Accordingly, there would be no triggering for playing -> unavailable -> idle (unless I was explicitly looking for unavailable in from or to).

If I’m not mistaken, I believe that’s what your PR had implemented.

12

My PR did not address state, I have only thought about that situation later on. But it already works like you said because unavailable is treated like any other value.

For numeric_state, my PR ignored unavailable which is not exactly the same. With my PR, a state going through 0 -> 100 -> unavailable -> 0 would still trigger because we know that the threshold has been crossed at least once.

Your approach has the benefit that it will only trigger at the right time which could also be important.

13

I think you may be able to avoid the history stats sensor and use a template condition like {{ trigger.from_state != "unavailable" }} but I didn’t test.

14

I have been thinking about this, I actually like your proposal better because it is more predictable.

However, one question. If we modify the trigger by removing from: …

trigger:
- platform: state
  entity_id: media_player.music
  to: 'idle'

… would you then expect it to fire for unavailable → idle?

15

If I follow my proposal’s rules, no. If I wanted to detect unavailable → idle I would need to explicitly indicate it with from: unavailable (because unavailable is not any entity’s “normal” state).

Unless I am mistaken, I believe the proposal would also prevent your example from triggering on startup when the entity’s initial state changes from unknown (or unavailable) to something known and valid.

To be honest, I have not subjected the proposal to an exhaustive list of test cases so it might have drawbacks that I haven’t envisioned.

16

Thanks for the suggestion amelchio but for now the history stats sensor has solved the problem and I have no more false triggers. Until it is fixed with an official HA update here’s my code in case it helps anyone else:
within the sensor section of config yaml:

  - platform: history_stats
    name: PM1 Available
    entity_id: switch.pm1_switch
    state: "unavailable"
    type: time
    duration: 00:02:30
    end: "{{ now() }}"

and added as a condition with the automation:

  condition:
  - condition: numeric_state
    entity_id: sensor.pm1_available
    below: '0.01'

The template condition is probably a neater way to solve it but I know this works so for now I will leave well alone.

17

for anyone else who gets here and is still stuck like me, its actually

{{ trigger.from_state.state != "unavailable" }}

2 Likes
18

Not sure if replying here is appropriate after 3 years…
I also hit this issue;
platform: numeric_state
entity_id: sensor.0x001784510cdb4c3b_illuminance_lux
for:
hours: 0
minutes: 5
seconds: 0
below: 800

When the sensor became unavailable after a mqtt upgrade, it triggered this condition; I am not sure now how the HA should work. Nor can I find the expected behavior.

What is the appropriate solution for preventing an unavailable to some proper value firing the trigger (which I think is conceptually false).

Walter
Ps; really like the above discussion ;-).