Automation sometimes fails to trigger

Configuration
1

I have several automations that are configured to switch off lights when the interior light level sensor (Shelly Motion 2) reports a level above a specific value for a short time. There are three automations that all use the reported luminosity value. The specified value and delay times very slightly depending opon where the controlled light is located. One of the automations seems to trigger reliably, the other two often fail to trigger. The luminosity history shows the expected luminosity variation but the history for the problem automations doesn’t show the automation triggered when it clearly should have been. I have tried reloading the YAML for the automations, and even re-creating the problem automations with no change in results. Any idea what might be causing this erattic behaviour?

2

if you show us your automation we can have a better idea whats wrong

3

Thank you for the suggestion. Below is an example of the generated YAML for the problem automations. There are three automations of this exact format differing only in the trigger luminosity and the target device ID.

alias: Kitcab 02 off in morning
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.stairwell_luminosity
    for:
      hours: 0
      minutes: 3
      seconds: 0
    above: 150
conditions:
  - condition: device
    type: is_on
    device_id: 471f8a4d4c21274a915cdd2d0addfb1f
    entity_id: 39ed170dd91791229222a2224f42b937
    domain: switch
actions:
  - type: turn_off
    device_id: 471f8a4d4c21274a915cdd2d0addfb1f
    entity_id: 39ed170dd91791229222a2224f42b937
    domain: switch
mode: single
4

try this way

alias: Kitcab 02 off in morning
description: ""
triggers:
  - trigger: numeric_state
    entity_id: sensor.stairwell_luminosity
    for:
      hours: 0
      minutes: 3
      seconds: 0
    above: 150
    below: 100
conditions:
  - condition: state
    entity_id: sensor.stairwell_luminosity
    state: "on"
actions:
  - action: switch.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: your device
mode: single
5

Thank you! I will try this. The automations run every morning, so it may take a week or so to determine if the problem is solved. If it solves the problem, I will have to study it to understand what is the operational difference. Once again, Thank You for the quick assistance!

6

I don’t think those changes will help and the changes look like they change the functionality/intention of the original automation.

If the trigger isn’t triggering in your original automation, that means the sensor wasn’t above 150 for 3 minutes after being below 150.

For those trigger to fire, you need to be below the threshold, then rise above, then stay above for the configured time.

7

if you only run it everyday on the morning, why don’t use time as a trigger also?

So you have a secondary trigger to avoid any faulty sensor

8

This automation normally only runs in the morning because, while the luminosity is always near zero at night, it is rarely below 150 after sunrise. I have watched the history for the reported luminosity and it varies as expected with no indications that the sensor became unavailable. This morning for example, the night luminosity was reported as zero, but by 10:00AM, it was at 2479.

One of the three automations using this exact format triggered as expected, but two did not trigger.
The one that did trigger;

When Entryway Luminosity is above 240 for 10:00

The two that did not trigger;

When Entryway Luminosity is above 150 for 3:00

When Entryway Luminosity is above 210 for 10:00

9

So the highest luminosity triggered, which means the threshold of the other 2 was not reached.

10

I have not used a time trigger for these because, though it is rare, there may be instances on a very cloudy day where the luminosity does go down very low and then rise when the weather clears. In that instance, I would still want the automation to trigger.

11

No, as noted, this morning the luminosity went from zero to 2,479 so all three should have been triggered but two were not.

12

If the luminosity raised quick, your triggers, which have a for: clause, could never reached the for: time.

13

In most instances, the morning luminosity does indeed rise quickly, but in all three instances this morning, the luminosity rose quickly above the threshold and has remained far above the threshold values for several hours.

14

More trigger details;

Recorded luminosity;

at 06:00 = 0
at 06:10 = 7
at 06:15 = 13
at 06:16 = 67
at 06:26 = 101
at 06:40 = 127
at 06:53 = 216
at 07:09 = 329 (now above threshold for all three automations)
at 07:40 = 364
at 08:26 = 506 (now well above threshold and time requirement for all three automations)

all subsequent luminosity values continued to rise far above threshold with no interruptions.

15

Can you post the luminosity history graph here?

16

image
image1577×735 39.9 KB

Not sure how to post the history graph directly so I tried inserting it as a screen clip. Hope that is useful.

17

Just a by-the-way, the proposed code probably won’t trigger for another reason. It can’t be both these…
I don’t think that’s an or.

18

As Sir_Goodenough noted, the “above 150” and “below 100” conditions are a disjoint set and as expected the conditions taken together can never be true. Thus no trigger.
Since these three automations are most often running concurrently, I wonder is there is a variable scoping problem in the underlying code. My coding experience is very old (bordering on paleolithic), so this might not be an issue. I am going to try to step through several days with only one of the automations enabled at a time to determine if each works as expected if the other two don’t run concurrently.

19

Thanks to everyone for consideration on this. With no other changes, the problem seems to have disappeared with the HA update to 2025.7.0