Use group with media_players, or media_player group

Configuration
1

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
2

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.

3

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

4

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.

5

@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