State trigger suddenly fails, but condition is true

Configuration
22

I did not mean to be sarcastic. If it came across like that, I apologize.
Here’s the history:
image
As can be seen, the sensor reports correctly.
I can test this again as we speak, by lowering the conditional value enough to prevent it from ever being 'True" and I bet it will never trigger despite changing correctly from ‘Detected’ to ‘Clear’

23

It needs to remain off for the full 5 minutes. It cannot dither, at all. Please post the entity_id that you’re selecting to show the history. Show the entity in the states table as well.

24

I will perform the test (without the delay) and post the result. Please just give me some time as I have to run an errand. (and again, your support is appreciated) :+1:

25

I thought that I was involved in a discussion about this exact situation (or something very very similar) several years ago. I’ve looked but I can’t find it tho.

If my memory is correct it seemed that the condition was being checked before the trigger fired and prevented the automation actions from running.

But it’s also entirely possible that changes to the automation engine fixed that situation because I’ve not run across it since then.

Or I could be completely misremembering and making it all up in my head. :crazy_face:

I just really wish I could find that thread because there was a pretty good back and forth on the problem I was seeing.

26

Conditions are 100% not checked before a trigger occurs. A condition will not cause triggers to “not work”. Automations only start working when a trigger is seen.

His issues are one of the following 3 things:

  1. His sensor is dithering between ‘off’ and some other state.
  2. His automation is still running from the previous run and it’s being canceled before it even starts. His automation mode is set to single, so it will only run one at a time. It will appear as if it’s not triggering. You can easily tell this by looking at the current attribute. If it’s at 1, then it’s running still and it will not trigger.
  3. He’s using the wrong entity to trigger the automation. I.e. he’s looking at the history of sensor A but the automation is using sensor B.

Other possible scenarios:

  • The automation is disabled (via an error or user intervention)
27

There needs to be clarity when talking about whether an automation has “triggered”. HA makes this a little confusing.

When an automation’s trigger fires but there is a condition (in the “and if” section of the UI) that is not met:

  • a trace in the automation will be generated
  • the last_triggered property of the automation entity will not be updated. This is what generates the detail text (e.g. yesterday) in the automations list in the UI.

Only 5 traces will be stored by default but you can change this

So when you say “the automation didn’t trigger” you should specify exactly what you mean by that.

  • The last_triggered property didn’t update?
    • if any condition wasn’t met → HA operating as designed
    • if all conditions were met → this should not be possible
28

Aha - that explains “my confusion” !
Thank you so much for clarifying. This information was completely unknown to me. When I insisted that the automation didn’t trigger, I was of course referring to the last_triggered property.

I would guess that the majority of HA users would conclude in the same way. Wouldn’t it be much more logical if the last_triggered property is updated consistently as a result of being fired?
My understanding now is that if the “and if” section of the UI is not met, it prevents the last_triggered from being updated, but any other conditions added to the automation will not prevent update of the last_triggered, right?

29

I’m pretty sure it used to be that way long ago but it was changed to mean that the actions actually ran instead of just that the trigger was satisfied.

It is a bit confusing tho.

It would make more sense to have two properties - last_triggered for the trigger becoming true and last_ran for the actions actually ruinning. That would make more sense for most users.

30

To me it would be a major improvement if the last_triggered would be updated each time the automation was triggered. Meaning; it did run, even if it terminated immediately because the initial “And if…” failed. Such behavior is to be considered normal for any type of executable code.

1 Like
31

The last_triggered attribute is often used for rate-limiting purposes; for example a template condition can be added in the “and if” section of the automation to check if last_triggered < today_at() which would only allow the automation to run at most once per day.

Changing the behavior of last_triggered would be a breaking change that will make this no longer possible and would upset a number of users if an alternative was not offered.

I’d agree with finity that, if a change were to be made, a new last_ran or last_executed attribute would be a necessary addition.

32

The confusion is in what is triggered: the trigger inside the automation, or the automation itself (the actions in it).

A trigger in the top section of an automation triggers when the thing specified in the trigger happens. No other things (conditions) are checked besides what is in the trigger itself. Triggering here means that something happens that requires the automation’s attention. If it does, a trace is started.

After a trigger fires, the automation becomes active to check the conditions. The conditions are checked after the trigger from the trigger section fires, the conditions do not prevent the triggers from firing, but the condition can prevent the actions from being executed.

The automation is triggered if one of its triggers is triggered AND the conditions are met. Here triggering means: the action block is executed. It would not make sense to evaluate conditions after the actions are already executed. So last_triggered for an automation refers to the automation itself (the actions) not to the triggers inside.

It is confusing that the same term is used for both, but it is not wrong per se once you know what it means.

I’m not so sure there’s a need for an attribute that says it tried to see if it needed to do something but it didn’t do anything. You can see it in the trace if that happened. For automation purposes the current meaning (something was done) makes way more sense for automation purposes.

1 Like
33

Aha, that makes more sense.
I wasn’t aware of that technique used to “rate-limit”. Thanks for enlightening me :+1:
Then I guess the current variable last_triggered could (should?) be renamed last_executed and then perhaps as you suggest add another variable (or whatever) to make it visible in the dashboard that the trigger was indeed fired, even if the automation itself may have been prevented from running due to the condition. Checking this would require examining the trace.
(I’m referring to the UI trace as I find the trace log far too overwhelmingly complicated to be useful)

34

Rater than checking if a trigger fired, you can look at the thing in the trigger to see what happened. If there are multiple triggers, you wouldn’t know which one fired by looking at the automation attribute anyway…

The trace is useful: that was what was asked and started the whole discussion. Look at the trace and you not only know what triggered, but also what condition failed.

1 Like
35

I’m not sure what you mean by “the thing” - but in general you are of course absolutely correct; If you know what to look for, then it’s generally possible (easy?) to check the details.
My situation was that I mistakenly concluded that the event never fired, and I got stuck there and didn’t know where to turn in order to progress.
Now I know :+1:and I am very grateful to all that helped me through this maze, @mekaneck in particular :blush:

36

So now you know: The automation trace tells you if conditions fail, and which one. If there’s no trace, there most likely was no trigger (if you edit the automation, traces are also removed).