Understanding why an automation triggers twice…

Hi Gang!

I have an automation that sets some lights based on the light level. I’d recently changed the way this works and put in some messages to help me check it which then highlighted to me when triggered, its running twice….but I can’t work out why!

The automation (<< with some comments to aid understanding)

alias: Day - Lounge
description: ''
trigger:
  - platform: state
    entity_id: binary_sensor.day_time    << a time range when to run, used as a trigger for when these hours start
    to: 'on'
  - platform: state
    entity_id: sensor.lounge_light_sensor    << explained below
    for: '00:05'
  - platform: state
    entity_id: group.home_occupied    << is anyone in the house
condition:
  - condition: state
    entity_id: input_boolean.occupied    << a holiday away type flag
    state: 'on'
  - condition: state
    entity_id: binary_sensor.day_time    << only run during specific hours
    state: 'on'
action:
  - choose:
      - conditions:  << are we home and is the light level low?
          - condition: state
            entity_id: group.home_occupied
            state: home
          - condition: state
            entity_id: sensor.lounge_light_sensor
            state: Low
        sequence:
          - service: notify.mike
            data:
              message: low light test
          - scene: scene.lounge_bright
      - conditions:    << are we home and is the light level medium?
          - condition: state
            entity_id: group.home_occupied
            state: home
          - condition: state
            entity_id: sensor.lounge_light_sensor
            state: Medium
        sequence:
          - service: notify.mike
            data:
              message: medium light test
          - scene: scene.lounge_half_bright
    default:    << all other conditions, i.e. home and high or out of the house
      - service: notify.mike
        data:
          message: default light test turn all off
      - type: turn_off
        device_id: f7956afaf7894ee68e8df772e43fa6a9
        entity_id: light.loungedz
        domain: light
mode: restart

The primary trigger here is sensor.lounge_light_sensor which is set as follows:

      lounge_light_sensor:
        friendly_name: "Lounge Light Sensor Level"
        value_template: >
          {% if states('sensor.lounge_light_level') | int <= states('input_number.lounge_low_light_level') | int %}
              Low
          {% elif states('sensor.lounge_light_level') | int > states('input_number.lounge_low_light_level') | int and states('sensor.lounge_light_level') | int < states('input_number.lounge_high_light_level') | int %}
              Medium
          {% elif states('sensor.lounge_light_level') | int >= states('input_number.lounge_high_light_level') | int %}
              High
          {% else %}
              Unknown
          {% endif %}

Basically, based on a low and high threshold points (input_number.lounge_[low/high]_light_level) compared to a light reading sets itself to Low (dark), Medium (no so dark) or High (bright).

Because I’d put in little messages (as part of tuning the levels) I can see whenever it runs, it does so twice:

image

The first run looking through the trace we can see an appropriate trigger happening sensor.lounge_light_sensor moving from Medium to High but it fails to complete on the default action

Now I wonder if this is because my automation is set to Restart and the second run is kicking off at this stage (but in all examples stops at this level regardless of the choice it made above).

image

So the second run of the automation executed at what appears to be the same time looks like this: Here we can see it completes but the trigger data, From and To are the same values.

image

Now, things are working so not terribly important, but I’d love to understand why this is happening. I would suspect as usual it is of my own doing, but I can’t explain it. Any suggestions would be gratefully received!!

It looks like your triggers are such that if any of the triggers occur, the automation is going to begin (day_time is on or lounge is on for 5 seconds or home_occupied), then the conditions are also set up the same way: occupied is on or day_time is on. Is that how you wanted to happen or do you need to have your conditions all met (i.e., occupied is on and day_tme is on)?

What that equates to is several things that will cause the automation to run rather than a specific set of circumstances. This might be what you were after, but if it’s not then that would explain why it runs more frequently than you anticipated. If you meant for it to be all conditions then you might need to do something like this:

Thanks @CO_4X4 - but it was intentional, that any one of those events could trigger it:

  1. has the daytime hours just started
    or
  2. has the light level changed
    or
  3. has the house just become empty or occupied

When any one of those events occur I’m doing a second check in the conditions on point 1 (given that point 2 or 3 could have triggered it to make sure we’re in daytime) and checking we’re not on holiday, then moving into the rest of it (both of which need to evaluate to true before proceeding). The down in the specific choices I’m doing further checks for example on occupancy.

So, a scenario could be the light level has change from High (no lights on) to Low (full beam on), that’s a trigger. The condition then checks we’re in daytime hours or not and we’re not on holiday. Then the choice makes sure someone is home before turning the lights up and if there is no one home makes sure they’re turned off.

I think my logic is okay :face_with_monocle: ?!

That sounds like an and to me, but maybe I read it wrong. So your current condition says if either of those conditions are met, not if both those conditions are met. Given that, this could run twice because it hits the first condition and sees that it passes and continues with the automation, ignoring the second (or vice versa). If that’s what you were going after then I may have misunderstood your intention and all things look good but you might get duplicate runs of the automation.

Maybe I am miss-reading the documentation here “Unlike a trigger, which is always or , conditions are and by default - all conditions have to be true.”

However, I’ll have a crack at putting some and’s in to see that cures the problem and report back.

Thanks for your assistance :slight_smile:

I believe if you look at your triggers you might see why it’s happening…maybe…

trigger:
  - platform: state
    entity_id: binary_sensor.day_time
    to: 'on'
  - platform: state
    entity_id: sensor.lounge_light_sensor
    for: '00:05'
  - platform: state
    entity_id: group.home_occupied

the second trigger has no “to:” condition. That means that every time the ’ sensor.lounge_light_sensor’ changes (state or attrinbutes) then the automation will be triggered.

the same for ’ group.home_occupied’. Every time that entity gets its state or attributes updated the automation will trigger.

then the conditions are checked and if satisfied the actions run.

And since you are controlling the lounge lights with the automation when you turn on the lounge lights the lounge lights sensor changes (because it sensed the lights being turned on) so it triggers the automation again.

At least that’s my theory.

Hi, yes I’d specifically left the “to:” out on both triggers, as they only moved between values I wanted to test against and didn’t carry any additional attributes; it would save me specifying a trigger for value A, B and C.

Good call on the lights coming on changing the sensor but I’ve got it set up (layout wise) that the lights don’t affect the reading from the sensor which is by the window.

I appreciate the input and will mess around a bit with the triggers to see if there’s something lurking in there.

Grrrr. tried to make things simple with this one!

I believe also that the hidden “universal” attributes of “last_changed” and “last_updated” might also trigger it as well.

Damn it :slight_smile: - thanks for the heads up, I’ll take a look at that also!

1 Like

Nope, only attributes and the state. Nothing else in the state object will cause a trigger.

Then it almost has to be a state change in the sensor doing it if there are no other attributes.

That’s what I concluded. I can see the trigger (from the possible three) being the sensor one thats causing the duplicate runs. So, I threw the trigger.from_state and trigger.to_state onto a message.

When triggered (in duplicate) had a look at them and they were identical

First run:
<state sensor.lounge_light_sensor=High; friendly_name=Lounge Light Sensor Level @ 2021-05-10T19:42:13.477484+01:00> - <state sensor.lounge_light_sensor=Medium; friendly_name=Lounge Light Sensor Level @ 2021-05-10T19:42:27.030950+01:00>

Second run:
<state sensor.lounge_light_sensor=High; friendly_name=Lounge Light Sensor Level @ 2021-05-10T19:42:13.477484+01:00> - <state sensor.lounge_light_sensor=Medium; friendly_name=Lounge Light Sensor Level @ 2021-05-10T19:42:27.030950+01:00>

I’m at a loss :open_mouth:

Yeah, that looks to me like the sensor went from High to Medium to trigger both runs. It’s likely that the light sensor is hovering around the high to medium threshold and it blips down occasionally.

try removing that created sensor and just use the original sensor for the trigger. then in the conditions check that the original sensor value state is correct compared to the input select value. then you can eliminate the secondary sensor all together. You still might need to add in some hysteresis to the setpoints tho or you may run into the same situation even in the conditions.

Thanks @finity, appreciate the support!

Job for the morning I think. I was using the ‘for’ to smooth out those blips but it is constantly happening each ‘trigger’.

Could well be my derived sensor (reason for having it was I can set my thresholds in one place and reference that sensor in multiple automations - have found that even though the actual light level is the same, in winter we tend to turn them down to come on sooner etc.).

Great stuff, will try and update hopefully with some success.

1 Like

So by means of shutting this thread down an update with findings…

I am not 100% confident I understand the true root cause but on my sensor I also had an icon_template which updated based on the sensor value. This meant the sensor changed twice, first when the value was set and when set, a second time to update the icon.

I’ve replaced the icon_template with the same logic in the sensor so both the value of the sensor and icon change in a single action. This appears to have addressed the issue.

However, I still don’t understand why the for in the trigger didn’t catch this and only react on the second change after 5 mins.

But, we’ve got to something working so I’ll thank everyone who contributed suggestions and assistant, awesome! (the automation remains unaltered FYI for those raised questions about it - works just fine for my use case)

So the icon was an attribute of the sensor that changed and triggered the automation again?

Yes @finity - I had removed the icon_template prior to the original post but wonder if, well something wasn’t right…

It would explain why the automation was triggered twice with the same time stamp. Thanks again

Yeah, that makes sense with the stateless 5 second sensor trigger.

1 Like

Again, grateful for the comments from everyone. I think I had drawn some incorrect conclusions early on around what constituted a holding state. Following testing with some dummy configuration I think I’m happy to settle on this explanation:

  • The trigger is waiting for a state to be held for 5 minutes. Because I have not defined a To or From state to evaluate it is also considering Attributes
  • The early version of the sensor set its icon attribute based on the sensor state, this was in effect a double tap action, happing sub-second but as two separate events
  • When the sensor moved state (say from Low to Medium) this state change was then being monitored to check it held true for 5 minutes by the automation
  • At the same time, as a separate event the icon attribute then changed. This was also clocked as a possible trigger and monitored for 5 minutes

Assuming then nothing else happened:

  • When 5 minutes had elapsed the first trigger for the state occurred
  • In the same second the second trigger occurred which was watching the icon attribute
  • This has the effect of making it look as though the automation had run twice on the same criteria (but I’m now guessing they’re distinct actions)

The incorrect assumptions I’d drawn……

  1. The icon template would run as part of the value template – whereas it is actually a separate event caused by the value template changing (completely my bad)
  2. The open holding state trigger (i.e. no To, From or Attribute and using For) would evaluate the entire sensor’s position. However it monitors the aspect that changed and watches for that to change again (be that the State or separately an Attribute)

The above may not be ‘technically’ correct but I don’t have the skill to dive into the code and am happy that the above makes sense to me :slight_smile:

2 Likes