Understanding "actions" syntax in different contexts

Hello all –

I’m in the midst of (re)implementing a set of template select entities and corresponding universal media players to encapsulate and simplify the functions of my living room AV setup (eventually aiming to realize a post-Harmony-remote control setup that I’m actually happy with).

In working on this I keep running into syntax issues that so far continue to surprise and baffle me. Specifically relating to blocks of actions.

I feel like I do understand why, for example, a choose block would contain conditions and why conditions would contain an action (or sequence etc.). I can also grasp why the default condition for a choose block wouldn’t require a separate key to house the actions (because the “condition” is implicit for default and so the default block is just really specifying what to do in that case).

Where I start to lose my way is e.g. in the commands: section of a universal media player. Suppose I want the turn_on: command of my universal player to perform two actions: turning on the projector and turning on the AVR.

I know how to execute one action or service call in these situations. I can even sort of understand why syntactically it’s not possible to embed a “bare” sequence of actions to be applied in such a block e.g.

media_player:
  - platform: universal
  # ...
  commands:
    turn_on:  ### NOT VALID BELOW!
          - service: media_player.turn_on
            target:
              entity_id: media_player.lr_av_avr
          - service: media_player.turn_on
            target:
              entity_id: media_player.lr_av_proj

Nor is this valid:

media_player:
  - platform: universal
  # ...
  commands:
    turn_on:  ### ALSO NOT VALID BELOW!
        sequence:
          - service: media_player.turn_on
             target:
              entity_id: media_player.lr_av_avr
          - service: media_player.turn_on
            target:
              entity_id: media_player.lr_av_proj

I know I can just pull out the multi-command sequences into scripts. Maybe there’s also a valid way to just pass more than one target entity_id into the media_player.turn_on service call. But those are workarounds that sidestep my question:

Is there some principle I’m missing about when & why an e.g. “sequence” is considered a viable “action” vs when it’s not possible? If it’s just “certain code is more up-to-date than other code; univeral media player isn’t the most up-to-date”…I get it.

But if there’s some underlying concept I’m missing I’d love to know it because this feels like trial & error currently!

sequence is something only understood by the automation/script engine, it’s not considered an action. You can see how it is catogorized differently there as a “Building Block” instead of an action.

Your first example is a list of actions instead of an action, and according to the documentation of universal media player it just accepts one action, not a list of actions.

So if you want to do more than one action put them in a script and call that from your turn_on action.

Then open a feature request asking for the universal media player turn_on/off actions to support a list of actions. Like every other integration that has this feature (template cover, switch, etc…). I had a search there is not an existing feature request for this.

Thanks all for the thoughtful & helpful responses…

Ah, that’s an interesting observation that I think gets right to the root-cause of my confusion: The main doc for Performing Actions is written to cover cases both in and outside script syntax… but it happens to be written as part of the automation / scripting section and it also happens to use scripting examples in most places.

I think I must have over-interpreted this:

The configuration options to perform action are the same between all integrations and are described on this page.

Examples on this page will be given as part of an automation integration configuration but different approaches can be used for other integrations too.

I didn’t put much thought in to which things on the page above were generally true and which were specific to the script engine syntax specifically … and likewise I wasn’t asking myself whether various places in the YAML were likely to be using “script syntax” vs just “bare service action” implementations. I think with that distinction in mind I’ll find these situations a lot less baffling.

(I’ll also say that the dev-facing YAML style guide mostly uses block-style sequences to demonstrate service actions – absolutely valid, but implicitly script-specific IIUC.

Anyway thanks for the pointer… I think this will help me ask the right questions instead of just having the sense that I must be missing something.

:+1: I’ll certainly do this. (Edit: done)

I may also propose a few edits to tweak the docs for context/clarity.