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
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?
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.
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.
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.
I’m opening this thread now for the third time, always hoping you provided a piece of code that does it better. 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…
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!