Problem with condition within action - odd behaviour

I have a recent project - a connected doorbell sending in to an RPi hosted HA instance via MQTT. I use it to trigger a broadcast on one (or more) Google Homes and I am very happy with this solution which works well. I now want to add an extra enhancement: when the doorbell is pressed, turning the outside light (Tuya wifi switch) on for 3 minutes, but only if it’s dark. And this is where the problem starts.

When it’s dark, the rule works pretty well (although I do sometimes get an on -> off -> on from the light before it stabilises for the required 3 minutes). The problem is that when it’s light, the light is still being turned on and then off after perhaps 1 second, but weirdly, the notification rules (put in their for fault-finding) are not being triggered. I’m new to HA but I think I’m doing it right. I’ve tried a couple of different (valid) syntaxes for the condition command, but none work correctly.

Any suggestions as to what I’m doing wrong here? The exact automation config I’m using is posted below, with only the identifying URLs and entity IDs changed:

- id: '349873443422'
  alias: Front Doorbell
  description: ''
  trigger:
    payload: front_door_ring
    platform: mqtt
    topic: doorbell
  condition: []
  action:
    - service: media_player.volume_mute
      data:
        entity_id: media_player.broadcast_speakers
        is_volume_muted: false
    - service: media_player.volume_set
      data:
        entity_id: media_player.broadcast_speakers
        volume_level: 0.5
    - service: media_player.play_media
      data:
        entity_id: media_player.broadcast_speakers
        media_content_id: http://www.myserver.com/doorbell-2.mp3
        media_content_type: 'music'
    - condition: and
      conditions:
        - condition: state
          entity_id: sun.sun
          state: 'below_horizon'
    - service: persistent_notification.create
      data:
        message: "Sun down - light on"
        title: "Test"
    - service: switch.turn_on
      entity_id: switch.xxxyyy
    - delay:
        seconds: 180
    - service: switch.turn_off
      entity_id: switch.xxxyyy
    - service: persistent_notification.create
      data:
        message: "Sun down - light off"
        title: "Test"

So, to clarify, when the sun is “above_horizon” (i.e. it’s daytime), the light turns on and then off immediately, but the notifications don’t fire. When the sun is “below_horizon”, the light turns on for 15 seconds and then turns off and the notifications fire accordingly.

Any suggestions or ideas here?

Do you have any other automation that controls this light?

By the way, this can be simplified:

    - condition: and
      conditions:
        - condition: state
          entity_id: sun.sun
          state: 'below_horizon'

To this:

      - condition: state
        entity_id: sun.sun
        state: 'below_horizon'

You only have one condition, and conditions are “and” by default anyway.

Hi Burningstone,

Yes, I’ve tried several different syntaxes of the condition operation (this was just the last!) and all behave the same.

No, there’s no other automation on this light. This is actually all quite new to me, so I have a total of two automations at the moment - one for the front door and one for the back door and this is the only one that references this light. The switch was only installed a couple of days ago too, so I’ve not done anything more with it than what you see here.

It’s all very odd.

This could be your issue. How do you have these lights integrated?

That’s a really good question!

They all just sort of appeared in HA after it was installed and it seemed to detect the Tuya switches that I have on the network. I’ve not had to specifically configure an integration with Smart Life as I would with, say, IFTTT. Likewise with the Google Home stuff - they’re all just…there. I assumed that HA autodiscovered stuff like this without being asked!

This still doesn’t explain why the action is even touching this light when it should have fallen out of the automation when the condition was failed…

(FYI - there’s is definitely nothing else talking to this light. The only time it turns on or off is in direct response to me pressing the doorbell which is next to it)

This could be explained if the trigger is occurring again before the 3 minute delay has finished. You’re not the first to have been tripped up by this unexpected automation behavior. Basically, if an automation’s action section contains one or more delay and/or wait_template steps, and if while it is “in” one of those steps it is triggered again, the pending (delay or wait_template) step will be aborted and the automation will continue with the next step. It does not start over from the beginning.

So, if the doorbell is pressed, and the light goes on, but before the 3 minute delay has finished, the doorbell is pressed again, it will abort the delay and continue with the next step that will immediately turn off the light. Since you’re seeing on → off → on, I’m guessing the front_door_ring event is (at least sometimes) being sent three times in a row.

The typical way to deal with this is to add a condition in the automation’s condition block that allows the actions to run only if the automation has not been triggered (in this case) in the last 3 minutes.

Regarding the condition in the action part, as @Burningstone said, you don’t need the condition: and wrapper around the condition: state.

Regarding not getting the notifications, and the lights still turning on and off when sun.sun’s state is above_horizon, that doesn’t make sense. There must be more going on than you’ve explained. Have you checked the logs to see if the automation was triggered before the light goes on and off, etc.?

1 Like

Ah yes, I had read about this. It’s possible that this is happening on my tests although I’ve generally been testing with a 10s light timeout to speed things along a bit more. I’ll look into the workaround you mention.

I think this is an excellent plan. Are there logs that specifically cover the execution of automation scripts? I’ve not been able to find them yet (hence the addition of notifications to let me try to see what’s going on!).

Assuming you have it enabled, you can at least look in the Logbook. Also, if you have Developer Tools enabled, you can look at the LOGS tab there. Also you can check the home-assistant.log file in your config directory.

You can also enable additional debug output (overall, or for specific parts of HA.) But first look in the above places. If you don’t see enough detail, check out the logger configuration options.

Hi all,

Well, plenty of faffing later, I remain convinced that there’s some “unexpected features” lurking about within embedded conditions. In the end, I rewrote it as follows and this seems to work ok:

- id: 'front_doorbell_ring'
  alias: Front Doorbell
  description: ''
  trigger:
    platform: mqtt
    topic: doorbell
    payload: front_door_ring
  condition: []
  action:
    - service: media_player.volume_mute
      data:
        entity_id: media_player.broadcast_speakers
        is_volume_muted: false
    - service: media_player.volume_set
      data:
        entity_id: media_player.broadcast_speakers
        volume_level: 0.5
    - service: media_player.play_media
      data:
        entity_id: media_player.broadcast_speakers
        media_content_id: http://www.myserver.com/doorbell-2.mp3
        media_content_type: 'music'
        
- id: 'front_doorbell_light_on'  
  alias: 'Front Doorbell - Light on'
  trigger:
    platform: mqtt
    topic: doorbell
    payload: front_door_ring
  condition:
    condition: state
    entity_id: sun.sun
    state: 'below_horizon'
  action:
  - service: timer.start
    entity_id: timer.frontdoor_light
  - service: switch.turn_on
    entity_id: switch.xxxyyy
      
- id: 'front_doorbell_light_turn_off'      
  alias: 'Front Doorbell - Light off after timer'
  trigger:
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.frontdoor_light
  action:
  - service: switch.turn_off
    entity_id: switch.xxxyyy

timer:
  frontdoor_light:
    duration: '00:03:00'

This is probably a superior solution anyway as it shouldn’t glitch when the doorbell is re-pressed while the timer is running.

Thanks all for your assistance.