Automation ignores "for" condition

Configuration
1

Hallo Community!

In this topic a similar problem is discussed, however I have no attribute in my yaml:

alias: Neue Automatisierung
description: ""
trigger:
  - platform: numeric_state
    entity_id:
      - sensor.esp32_numeric_state
    for:
      hours: 0
      minutes: 3
      seconds: 0
    above: sensor.inverter_numeric_state
condition: []
action:
  - service: notify.notify
    data:
      title: Warnung
      message: Details
mode: single

As described in the other topic, the automation is triggered when esp32 is inverter, but it is not checked via the for condition for three minutes.

Do you have a hint to understand this condition correctly?

All best
Dirk

2

Can u post the trace?

3

Did you wait to have the value go below the given value, then go above it, and stay above it without interruption for exactly three minutes? Or did you expect it to fire because it was already so for three minutes? Because the second thing I asked is not how it works:

4

Here is the last one:

this:
  entity_id: automation.neue_automatisierung
  state: 'on'
  attributes:
    id: '1721242186700'
    last_triggered: '2024-07-29T06:26:00.417587+00:00'
    mode: single
    current: 0
    friendly_name: Info
  last_changed: '2024-07-21T08:42:47.658699+00:00'
  last_reported: '2024-07-29T06:26:00.761541+00:00'
  last_updated: '2024-07-29T06:26:00.761541+00:00'
  context:
    id: ...M0
    parent_id: ...NM
    user_id: null
trigger:
  id: '0'
  idx: '0'
  alias: null
  platform: numeric_state
  entity_id: sensor.esp32_numeric_state
  below: null
  above: sensor.inverter_numeric_state
  from_state:
    entity_id: sensor.esp32_numeric_state
    state: '0.0'
    attributes:
      state_class: measurement
      unit_of_measurement: W
      device_class: power
      friendly_name: ESP32 Heizung Heizstab Leistung
    last_changed: '2024-07-29T08:49:00.416273+00:00'
    last_reported: '2024-07-29T08:49:00.416273+00:00'
    last_updated: '2024-07-29T08:49:00.416273+00:00'
    context:
      id: ...4F
      parent_id: null
      user_id: null
  to_state:
    entity_id: sensor.esp32_numeric_state
    state: '1500.0'
    attributes:
      state_class: measurement
      unit_of_measurement: W
      device_class: power
      friendly_name: ESP32 Numeric State
    last_changed: '2024-07-29T09:17:00.419752+00:00'
    last_reported: '2024-07-29T09:17:00.419752+00:00'
    last_updated: '2024-07-29T09:17:00.419752+00:00'
    context:
      id: ...AP
      parent_id: null
      user_id: null
  for:
    __type: <class 'datetime.timedelta'>
    total_seconds: 180
  description: numeric state of sensor.esp32_numeric_state
5

I expect to trigger the fire when “esp32” is above “inverter” for three minutes. Not directly when “esp32” is above “inverter” for a single measurement because they have different update intervals. This currently causes false fires and is correctly after all sensors are up to date. I tried to prevent this using “for” condition.

6

For three minutes, that is clear. But you did not answer my question. When did it “fail” to do so in your opinion. When it was already more then three minutes above the limit, or did you test when the value started below(!!!) and then it rose above, stayed above continuously without going below, and then was exactly three minutes after it rose above? Because leave even one of those things out then it does not fire.

I would also leave out the below: null line because that might produce unexpected results.

(edit: sorry, I mistook the trace for AI generated automation garbage. I edited my last rant out, I’m happy to help).

7

Ok, I try to describe it more precisely:
In general the esp32 is below inverter state, this is the starting point. When now esp32 rose above inverter the automation trigger “fails”, because it does not check this state for three minutes. I expect a fire event only if esp32 is above inverter for three minutes.
If esp32 goes below inverter during the three minutes nothing should happen and the process starts again when esp32 is above inverter again.
I checked the statistics and esp32 is not above inverter for three minutes but automation trigger was fired.

Did I answer your question?

8

Yes, it is clear now. However, you said it was the same as the post you referred to. In that post it did not fire, so that was my assumption. Now you say it did fire, but too soon.

The trace you gave does not show the value of the limit you tested for. I do not immediately see anything weird, but I also cannot see what the state of the invertor sensor is, so it is hard to tell if that value is the cause. Is it a positive value, or negative?

On second thought, I do think I know what is wrong. The limit is set when the trigger is primed. It expects an input_number. I think I read before it does not allow a sensor value that is constantly changing. So the value may have been lower for three minutes, but compared to some (arbitrary) value it saw when loading.

So what you should do is create a template sensor to compare the values (either subtract them, or create a binary sensor to compare them), and then a trigger on that sensor, using the delay. Another option is to do the calculation in a value template in the numeric state condition, and use a fixed boundary.

9

Hi Dirk921,

I don’t see the for: in the trace, so assuming you did as Edwin suggested, there may be a formatting issue with your code here that we cannot see:

May I suggest try this to see if it clears up? (as a diagnostic test if nothing else)

for: "00:03:00"
10

The trace shows this in the to_state section:

for:
 __type: <class 'datetime.timedelta'>
 total_seconds: 180

It implies it did consider the for option’s value (3 minutes = 180 seconds)

11

Here is a diagram of the two sensors:

grafik
grafik761×190 1.98 KB

The automation gives a false alert at 16:27:40.

Currently, I use a template as you suggested and we see what happens.

12

You are right. After two days, I got no false positives any more.
Thanks!

1 Like
13

Yes, that’s correct:

Not obvious behaviour. I’d solve this problem with a template binary sensor helper set to be on if one variable is higher than the other, then use that in a state trigger with the for time set.