Disable a trigger in an automation?

Configuration Frontend
1

I’m attempting to simplify my automations in HA by consolidating separate automation for a singular function into one. Recently, I came up with a concept for my home office that involves triggering the following actions when I enter the room:
Condition: Time between sunrise to sunset
Trigger 1
Office motion sensor detects motion > Open blinds to 50% (only once per day)

Trigger 2
Sunset > Close blinds

I’m facing a challenge where I need the blinds to open only once a day, allowing me to control the open/close state for the rest of the day. While I can achieve this through separate automations working together, I’m looking for a way to incorporate it into a single automation.

I’m trying to figure out if there’s a way to disable a trigger in an automation (not the whole automation) or through HA to achieve the same result. I’ve been searching, but haven’t been able to find anything yet. Am I overlooking something?

Thanks in advance :slight_smile:

2

This is an XY problem.

Post your two existing automations. We will show you how to consolidate them.

4

Thanks, mate, I actually found an alternative solution in the interim by creating a boolean input, but no one seems to know if there is a way to disable a trigger in an automation (not the whole automation). Or would you have to keep making booleans to achieve the same result?

5

You’re looking for something that doesn’t exist; there’s no service call to “disable an automation’s trigger”.

The offer still stands to help you redesign the automation in order to eliminate this highly unusual need to ‘disable a trigger’. For example, with the appropriate conditions the trigger can be ignored (i.e. trigger isn’t disabled but allowed to execute the action only under very specific conditions).

6

Dimitri,
It sounds like what you need is to know the state of the blind and the time. So if you trigger on both, you just check whether the blind state and time are correct (use a condition with and/or) and only then do the action.

-David

7

Is that still the case? I can disable a trigger from the GUI editor, so why not a service call?
My use case is that I have an automation to update my electricity tariffs just once and on a particular day. The automation triggers every day but gets stopped by a Condition until the day is reached. I’d like to be able to disable that trigger. I want another trigger in the same automation that will re-enable it when it detects I have entered new values into the dashboard form for the next rate change.
I know I can achieve the same by separating the 2 automations, but I like to keep related automations together.

8

Your request is no different than adding an input boolean and using that as a condition, resetting the boolean at midnight. It’s the same number of service calls too.

9

I was trying to stop the automation triggering (and then being stopped) every day once the due date had passed. It’s not that necessary I know, but just seems tidier to me.

10

Is this in reference to your post in this topic?

No need for a service call to disable a trigger. Just use a trigger that’s appropriate for the application; see my reply in the other topic.

11

Can I take you up on this offer? I am also attempting to temporarily disable a trigger as a part of an automation/blueprint.

I have an automation that controls a light switch. This light switch has an LED bar on the side and the “brightness” of the LED bar corresponds with how much of the light bar is illuminated. For example, if the brightness of the light is set to 100%, the light bar is fully lit. If the brightness of the light bar is set to 50%, the light bar is only lit halfway up. If the brightness of the light bar is set to 1%, only the very bottom of the strip is illuminated.

I have written a script to keep the value of this light bar in sync with the brightness of the overhead lights that the switch controls. If the overhead lights get set to 75%, the LED bar will automatically adjust to match the lights.

This is great, except when dimming the lights. The switch sends an “held down” event and a “released” event. When held down, the LED bar starts to change its own brightness based on a configuration for how long it should take (I have chosen four seconds). So if I hold down, the LED bar will take 4 seconds to get from wherever it is to 1%.

Polling the LED bar and setting the Overhead lights to match it’s value was a very unsmooth experience and had unpredictable behavior. So instead of polling the LED bar I figured out that I can instead tell the overhead lights to transition to 1% at the same rate as the LED bar and interrupt the transition when the “released” event is triggered by reading the LED bar value and setting the overhead lights to it. It is a very smooth transition. But the sync script needs to be disabled during this time because the syncing direction is temporarily going the other direction (LED bar to lights instead of lights to LED bar). I would like to combine the sync automation and the switch automation into one, reducing overhead for each switch I have so that instead of disabling and enabling a separate automation I could just disable and enable a trigger internal to the automation itself. Below is the current actions for “held down”, “released”, and “sync”

Held Down

downHeld:
      - alias: Disable auto-sync
        action: automation.turn_off
        metadata: {}
        data:
          stop_actions: true
        target:
          entity_id:
            - automation.dining_room_light_sync
      - action: adaptive_lighting.set_manual_control
        metadata: {}
        data:
          manual_control: true
          entity_id: switch.adaptive_lighting_living_and_dining_room
          lights:
            - light.dining_room
      - delay:
          hours: 0
          minutes: 0
          seconds: 0
          milliseconds: 500
        enabled: true
      - action: light.turn_on
        metadata: {}
        data:
          transition: >-
            {{
            states('select.dining_room_dimmer_switch_dimming_speed')|trim('s')|trim('m')|float
            }}
          brightness_pct: 1
        target:
          entity_id: light.dining_room
        alias: Start dimming of lights

Released

    downReleased:
      - action: light.turn_on
        metadata: {}
        data:
          brightness: >-
            {{state_attr('light.dining_room_dimmer_switch_light_1',
            'brightness')}}
        target:
          entity_id: light.dining_room
        alias: Stop dimming at current value
      - alias: Re-enable auto-sync
        action: automation.turn_on
        target:
          entity_id:
            - automation.dining_room_light_sync
        data: {}

Sync

alias: Dining Room Light Sync
description: ""
trigger:
  - platform: state
    entity_id:
      - light.dining_room
    attribute: brightness
    id: brightness
condition: []
action:
  - action: light.turn_on
    metadata: {}
    data:
      brightness: "{{ state_attr('light.dining_room', 'brightness') }}"
    target:
      entity_id: light.dining_room_dimmer_switch_light_1
mode: single
12

Unfortunately, I don’t currently have free time available for your project. Hopefully someone else can help you. Good luck!

13

That’s OK, thank you for replying and not leaving me hanging! Hopefully one day automations or blueprints will have a limited internal state and help avoid needing to set up separate input booleans.

14

You can use the context object in your automation to ignore the state changes.

- condition: template
  value_template: "{{ trigger.context.parent_id not in [ states.script.downreleased.context.id, states.script.downheld.context.id] }}"
15

If I am understanding this correctly, this is tracking the trigger’s back up the stack?

So when the automation is triggered by a downHeld event and that triggers a change in the light brightness, that context is passed down to the next trigger even though it was indirect?

trigger: downHeld is somehow passed to the next trigger and becomes

trigger: brightnessChanged
  context:
    parentId: foo
    trigger: downHeld

Objects not meant for accuracy, just to be descriptive of what’s going on. If so that’s cool, but I guess I don’t understand how HA would know what caused the value change.

16

this creates context in the script, the state change event will contain the id for the script.

This triggers off state change events, which have context.

This blocks the automation executing based on the context, which came from the script.

17

Awesome. I did not realize that context was created when an action occurred. I guess I thought it was all asynchronous, in that the state change is triggered by the lights themselves and not from the script that called the action.

18

That may be the case. It depends on the state change event. If you are correct, and the event is coming from the device itself, this won’t work.