Use group with media_players, or media_player group

tried this in Discord #integrations, and somewhat unresolved, so please allow me here too:

is there a preference of any kind using a media_player group over a regular group with the same media_players? Asking because up to now Ive always used a regular group with media_player entities, and that works just fine. My intercom plays/pauses/stops tts, music files etc etc o er the regular groups.

It was because I also do

      service: group.set
      data:
        object_id: broadcast_available
        name: Broadcast available
        entities: >
          {{expand('group.broadcast')|rejectattr('state','in',['unknown','unavailable'])
            |map(attribute='entity_id')|join(',')}}

to auto create a group with only available players that I had a look at the media_player group, hoping it would do something like that built in. But I dont think it does… And we can not create a media_player group like that (I think).

Unless, this is valid?:

    action:
      - service: group.set
        <<: &select_players
        data:
          object_id: broadcast_available
          name: Broadcast available
          entities: >
            {{expand('group.broadcast')|rejectattr('state','in',['unknown','unavailable'])
              |map(attribute='entity_id')|join(',')}}
      - service: media_player.join
        <<: *select_players

(nope it isnt… automation.create_broadcast_available_group: extra keys not allowed @ data['name'] )

as far as I can see, the main difference is:

{{expand('group.broadcast')
   |rejectattr('state','in',['unknown','unavailable'])
   |map(attribute='entity_id')|list}}

{{expand(state_attr('media_player.broadcast_group','entity_id'))
   |rejectattr('state','in',['unknown','unavailable'])
   |map(attribute='entity_id')|list}}

in iterating them, but other than that, why would one choose a media_player group over a regular group?

1 Like

Not sure that’s a notable difference because the first of the two templates can also expand the entity_id attribute of group.broadcast. I guess what you meant by difference is that you can’t expand a media_player group directly (nor can you expand a light group directly).

Aside from that, I don’t know the pros and cons of choosing a media player group over a group. Possibly you can control more properties, of the members of a media player group, than a group containing media players?

Disclaimer: I don’t have much experience with either scenario because I use the Sonos integration which has a native grouping capability and its own service calls (sonos.join, sonos.unjoin and even its own snapshot service call). I’m still exploring and learning about the possibilities.

thanks Taras, and yes, that was what I meant (the expand difference). btw, its a bit odd that we can directly expand the group (even though that too has an attribute entity_id:) and for all the others, we need the state_attr() construct. Would have been easy if that were the same, and make templating those in lists/counting etc etc way more obvious.

But besides that, media_player also has a join/unjoin function,which as far as I understand that, allows joining another (slave) player to a master player. And not join several players in a group, one can call in a script/service

It’s been my impression that Home Assistant’s media_player grouping and join/unjoin is purely software based and not hardware based (where the devices themselves support the concept of grouping) but I may be wrong about that.

@Mariusthvdb thanks a lot for this post!

I’m using this to not even/only create a group, but having a Symfonisk remote control whatever media players are currently playing in the house, with your entities list code directly in the entity_id.

Example for volume:

service: media_player.volume_set
target:
  entity_id: >
    {{expand('media_player.all_players')  |selectattr('state','in',['playing','paused','buffering'])  |map(attribute='entity_id')|list}}
data:
  volume_level: "{{ state_attr('media_player.salon', 'volume_level') +0.01 }}"

I’m exploring whether it’s worth it for me to create/update a “Playing” group, if the remote/automation can directly target the running players each time (don’t need a UI for this scenario, which the group would cover).

Just posting in case it can be useful to someone in a similar situation :slight_smile:

2 Likes