Automation Inconsistancies

Has anyone had automations that turn on Zigbee lights behave weirdly?
I have created a relatively basic automation that responds to the state of a binary sensor which is set to turn ff when a light sensor exceeds 80 Lux (with a hysteresis of 10 lux to prevent bouncing). The sensor is called Darkness, but is On (light detected) when the threshold is above 80 lux or off when below (No light detected). Activity records show that this is behaving as expected.
This is combined with a mm wave presence sensor in the office.
The option is defined with 4 options
Option 1, The darkness sensor is triggered by becoming No light detected AND there presence detected. (i.e. presence already in the office and it becomes dark)
Option 2.The presence senor detects a presence AND the state of the darkness sensor is set to No light.
Option 3. The Darkness sensor state changes to Light.
Option 4. The presence sensor state changes to Clear.

The issue I am having is with Option 2.
When this is triggered, entering the room. The automation triggers. This should turn on 4 zigbee lights in a sequence waiting 1 second before turning on the next finally turn on a basic Tuya based WiFi bulb.

The effect I am getting is that some occasions the zigbee bulbs turn on then immediately off. One may remain on. But the WifFi bulb turns on and remains on.

I tried getting assistance from Claude which made a few suggested changes, but didnt make a real difference.
This is the YAML. Is there an issue in the script or with a zigbee response which can be handled with a tweak in the script?

alias: Office lights
description: >-
  Turns on office ceiling group + accent light when it gets dark and the room is
  occupied; turns off when bright or unoccupied. Cleared trigger has a 1-minute
  debounce to avoid reacting to brief presence-sensor dropouts. Ceiling always
  turns on to 80% explicitly rather than resuming its last brightness.
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.office_light_sensor_flat_darkness_flat
    to:
      - 'off'
    id: Becomes dark
  - trigger: state
    entity_id:
      - binary_sensor.office_light_sensor_flat_darkness_flat
    to:
      - 'on'
    id: Becomes Bright
  - id: Occupied
    options:
      behavior: each
      for: '00:00:00'
    target:
      entity_id: binary_sensor.sonoff_snzb_06p
    trigger: occupancy.detected
  - id: Cleared
    options:
      behavior: each
      for: '00:01:00'
    target:
      entity_id: binary_sensor.sonoff_snzb_06p
    trigger: occupancy.cleared
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - Becomes dark
          - condition: state
            entity_id: binary_sensor.sonoff_snzb_06p
            state: 'on'
        sequence:
          - note: >-
              Explicit brightness so the group always turns on to a usable
              level, instead of resuming whatever dim level the bulbs were last
              left at (was landing around 14%, easy to mistake for off).
            action: light.turn_on
            data:
              brightness_pct: 80
              transition: 30
            target:
              entity_id: light.office_ceiling
          - action: light.turn_on
            metadata: {}
            target:
              entity_id: light.office_wifi_light_2
            data: {}
      - conditions:
          - condition: trigger
            id:
              - Occupied
          - condition: state
            entity_id: binary_sensor.office_light_sensor_flat_darkness_flat
            state:
              - 'off'
        sequence:
          - action: light.turn_on
            data:
              brightness_pct: 50
            target:
              entity_id: light.office12
          - delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
            enabled: true
          - action: light.turn_on
            data:
              brightness_pct: 50
            target:
              entity_id: light.office13
          - delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
            enabled: true
          - action: light.turn_on
            data:
              brightness_pct: 50
            target:
              entity_id: light.office11_2
          - delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
            enabled: true
          - action: light.turn_on
            data:
              brightness_pct: 50
            target:
              entity_id: light.office14
          - delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
            enabled: true
          - action: light.turn_on
            data: {}
            target:
              entity_id: light.office_wifi_light_2
      - conditions:
          - condition: trigger
            id:
              - Becomes Bright
        sequence:
          - action: light.turn_off
            data: {}
            target:
              entity_id: light.office_wifi_light_2
          - action: light.turn_off
            data: {}
            target:
              entity_id: light.office_ceiling
      - conditions:
          - condition: trigger
            id:
              - Cleared
        sequence:
          - action: light.turn_off
            data: {}
            target:
              entity_id: light.office_wifi_light_2
          - action: light.turn_off
            data:
              transition: 5
            target:
              entity_id: light.office_ceiling
mode: restart

As always, any help will be gratefully received.

It sounds to me like the issue stems from:

You have a binary sensor whose state triggers the automation, and at the same time the actions of the automation can cause that sensor’s state to change…

Many thanks for the pointer. I will try setting it to single and see if that does the trick.

I would add a few seconds delay here as well to prevent it from oscillating like that. If you switch the WIFI Tuya thing too quickly, the signal can’t get to China and back fast enough and it will be weird like that. I see it happen on mine.
If the light is on a few seconds when it gets light, so what. BUT if it’s dark and there’s a lightning storm flashing, you really don’t want it messing with the lights.

Thanks. Will give that ago. I’ll put in a 5 second timer for the trigger. Along with the Mode Single, see if that steels the system down.
I have tried using the Spook integration to find anything rogue that may have been messing with the automation. It found a number of headless entities and scenes pointing to missing entities which I have also cleared up.
I appreciate the help. I will post how things go over the next few days as it seems to be more of an issue early on in the evening.

So my automation is still not playing the game.

I have tried looking at the actions the automation has triggered in particular when the presence sensor becomes occupied and it is dark such as at 9.23 this evening.

I can see that after turning on the light.office_14), this is followed by setting the group ‘light_office ceiling’ to be on. That is a group of all four ceiling lights. There is a setting in the Lights_office_ceiling ‘All entities’ so the group is on only when all the members of the group are on. Hence setting light,office_14 to on, being the last of the four, means that the group should now be on. Thus I assume this is ok.
It then goes and turns on the wifi light, as per the automation.
But then for an unknown reason off office_14 is turned off and then the group is turned off! That is not part the automation. I have no idea why that is?

Not really addressing your specific issue, but I’ve quit combining my automations and using trigger IDs, and instead write small automations that have a single event trigger and one or two actions at most. I find it has really reduced my debugging needs and simplies the traces, of course.

Sorry if I’m missing something, but that sounds like two (or three) short automations,

  1. trigger when occupied w/ condition it is dark out, turn on lights.
  2. trigger when not occupied for x seconds, turn off lights.
  3. trigger when daylight, (condition not occupied?), turn off lights.
    Maybe another for when it becomes dark – I don’t do that on my motion sensors.

What does the Activity show for that light?

Hi busman
i am close to quitting using this multi option automation and revert to four simple automations to see if they resolve the situation, but am gonna keep going for a little as I really like the idea of containing the solution as one and I hate admitting defeat.

There are four defined triggers and then four actions depending on each. It is the second that is initially triggered by occupancy, but then looks at the helper which is set when identified as dark as a light sensor has a threshold of 80 lux.

The office has a cluster of 4 zigbee bulbs also defined in a group called office_ceiling. I have a smart button that can trigger an automation to turn the group on. Which I have to use to turn on the lights if the presence sensor trigger in the above automation fails. After that If I leave the room, the lights turn off, and if i return the automation works as expected. for the rest of the evening but then the following day fails again. This is why I am confused.

I will see what happens tomrrow.

Although I have a few Zigbee devices in a box, I’m all Z-Wave. But I did have something similar where a device was turning off unexpectedly. Turns out I had a timeout configured on the device itself. The Activity page should help show what’s turning office_14 off.

And to advocate a bit more…
I went through a few years of building everything into single automations – I didn’t like how I had so many separate automations in the UI related to some task. And it felt more “advanced” to combine them. As the automations grew it became really hard to work with them in the UI so I spent all my time in YAML mode (I have a feature request to have the editor retain last YAML/UI mode.) And the large automations became more difficult to debug, and I had related helpers, and YAML-based template sensors all scattered around. I found my happy place with packages, triggered template sensors, and tiny, trivial to debug, automations.

Beside changing the mode, I would start by disabling the “Becomes Bright” trigger, and seeing how that works out. I’m a little confused as to the purpose of that trigger/action combo in the bigger picture of this automation… in what situation are the lights on, but it still counts as “dark”, then it turns “not dark” and you want the lights turned off?

The option is to account for when it was determined as being dark for a period, such as a passing storm, but then later becomes bright as the clouds pass and the sun comes out, thus the lights no longer need to be on. This seems to work as the hysteresis on the trigger for darkness means that the light level has to change a considerable amount before it being triggered. It is not a major requirement, so might take that off to see if that settles things down.

Thanks for the suggestion.

that may be a happy place for me to visit too :slight_smile: