Universal media player: Support multiple actions for commands like turn_on and turn_off

Feature Requests
1

Currently, universal media players only accept one service action per command.
This request is to add support for multiple service actions per command… notably (but perhaps not exclusively) for the turn_on and turn_off commands.

Note: it is 100% true that the above can be accomplished with scripts. This request is primarily focused on (a) convenience and (arguably) conciseness, and (b) maintaining feature / syntax parity across various similar integrations, many of which have already enabled this capability (e.g. template switch supports multiple actions ).

Given the intent of universal media player to “wrap” / encapsulate multiple child players, it’s not hard to imagine common cases where the turn_on and turn_off might have more than one job to do requiring more than one service action

(E.g. 1+ media_player.turn_on actions for child players, plus a cover.close for a projector screen or window covering…)

Again the above is known to be possible by implementing the universal player’s desired behavior outside its config in a separate script. This FR requests the abiliy to implement such behaviors directly in the media player config.

2

You want a media.player domain entity to send a command that is meant for the cover domain?

Good luck with your request, but what you’re requesting is extremely unlikely to be implemented. Us a script or an automation instead.

3

Ah, that part of my previous post isn’t actually material to of this feature request.
In fact, with or without this FR I think what you are describing is already possible, even if it’s not considered a good practice(?):

media_player:
  platform: universal
  name: Already Supported Cross-Domain Action Example
  children:
    - media_player.child_entity_id
  commands:
    turn_on:
      action: cover.close # could be _any_ service action / any domain -- not relate to this FR
      target:
        entity_id: cover.projector_screen
# ...

This feature request is intended to expand the syntax that is expected / allowed for each individual entry under the universal player’s commands config variable.

I believe the individual config entries under commands: each specify an override for some matching command(s) on the child media_player. What I am requesting here is to expand the allowed syntax for each such override:

  • Already supported in 2025.4.3:
    • Accept any single action for each command override, as above
  • Requested change in this FR: also accept multiple actions for each command override

There are existing patterns enabling the above in other “wrapper-like” integrations, one of which which could be mirrored to support this FR. For exmaple:

  • @tom_l pointed out that e.g. Template Switch config variables like turn_on will accept an “action or list of actions”. This pattern offers a straightforward way to enable multiple actions per config entry, and better aligns universal media player’s config with other similar integrations in terms of feature / syntax parity.)

    That approach would satisfy this FR by enabling something like the following:

    media_player:
  platform: universal
  name: Multiple Actions Example
  children:
    - media_player.child1_entity_id
    - media_player.child2_entity_id
  commands:
    turn_on:  # PROPOSED: allow the following to be a list, as shown (not currently valid)
      - action: media_player.turn_on # PROPOSED: list syntax, first entry
        target:
          entity_id: media_player.child1_entity_id
      - action: media_player.turn_on # PROPOSED: list syntax second entry
        target:
          entity_id: media_player.child2_entity_id
# ...

  • Alternatively(?): I noticed that Template Alarm config variables like disarmappear to accept script syntax: the example YAML shows a list containing both a condition: and an action:

For my purposes, the first syntax (list, but perhaps not full script syntax) would be sufficient – the latter could be useful but, as folks have pointed out, there is always the option of placing more complex behaviors like that in a script.