Automations > "Specific automation" > RUN ACTIONS - counterintuitive, but +/- understood

I defined an automation yesterday using a blueprint provided by a HACS integration.

I expected the “RUN ACTIONS” button to trigger the automation in order to verify that the actions are the ones that were expected.
However, clicking the “RUN ACTIONS” button did not result in any action.

But now, the automation actually worked.

What happened?
“Show trace” is actually helpful.
When running manually, it just say “triggered manually”, but because of the choose condition using the event id (or type), nothing happended

When there is an event wit an event id listed in the “choose” conditions, then action is taken:

Basically, Automation Trigger - Home Assistant explains how the event can be assigned an id, which is then later ised in the action :

action:
  - choose:
      - conditions:
          condition: trigger
          id: trigger_id_label
        sequence:
          - type: turn_off
            device_id: 37502f6423b5b7c825d845bc4774fca2
            entity_id: light.tz3000_dbou1ap4_ts0505a_level_light_color_on_off
            domain: light

etc.

Anyay, the morale is that “Run Action” is not doing anything if there is a “choose” condition doing some filtering.

I do not know when “RUN ACTIONS” can be actually useful as automations are useually triggered by some external event, and not by “RUN ACTIONS” - I guess that there is a way to make “RUN ACTIONS” do something useful. Maybe somebody can tell?

Look at the name of the button you clicked:

RUN ACTIONS

That’s all it does is run the action section of an automation. It skips the automation’s trigger and its condition (if it exists). By clicking RUN ACTIONS you are only testing the automation’s action.

Your automation’s action refers to the trigger variable. It’s doing that in choose right here:

          condition: trigger
          id: trigger_id_label

The trigger variable is undefined if the automation is not triggered. Therefore trigger.id can never be equal to trigger_id_label (or anything else) if the trigger variable is undefined.

A good deal of what I have explained can be found in Troubleshooting Automations.

The RUN ACTIONS button can be useful for testing purposes but only if it doesn’t employ the trigger variable. At the very least, it can confirm the action section works. However, a far better debugging procedure is to allow the automation to trigger and then examine its trace.

If you want to check the automation including the trigger, you can go to Developer Tools —> States (tab) —> Find the entity —> Change the state to the desired state —> Set States.

What is the blueprint that you used? The trace’s flowchart is intriguing (a boatload of triggers).

@123 Thank your for the link to Troubleshooting Automations . I think it would be usefull to mention @ardysusilo 's suggestion there on how to trigger a state.

The blueprint I used is: https://github.com/IATkachenko/HA-SleepAsAndroid/blob/67fd3cffc5fcf2f8eb51e262ab9505895556954e/blueprint.yaml and I was testing the trigger that happens only once a day. As this is communicated over MQTT, in order to test the action, I should have published the desired event.

The reason I wanted to see the blueprint is because I noticed the trace’s flowchart showed numerous triggers. I was curious to learn why it needed so many triggers. I now know it’s because it’s simply an inefficient design (and can be reduced to a single trigger).

In the automation at hand, there are many types of trigger types and for each type the action can be different.

Maybe all this triggers could be joined in a single one using some or condition, but he list of actions would still be ling.

I think one has to use the automations for a while to understand them well enough to optimize it. In this case, I think that he developer found a working solution for one case and combined the all in a single blueprint/automation.

They can be joined into one (Event Trigger).

It would be the same as what already exists.

It doesn’t require a great deal of experience to ask oneself if there’s a better way than creating numerous nearly-identical triggers.

Oh c’mon Taras (@123), don’t let us die dumb. :rofl: :rofl: :rofl:

I’m opening this thread now for the third time, always hoping you provided a piece of code that does it better. :slight_smile: I have to be honest, I haven’t looked at the blueprint, but the picture with the triggers and your comment let me think I could learn something from a revised piece of code… :wink: :smiley: :smiley: :smiley:

At least I want to learn why and foremost how it can be done better. I will take a look at the blueprint right now, to see what you’re talking about, promised! :slight_smile:

When you do, think of “Event Trigger”.

1 Like