Some transports won't select group entity ids

[jeyrb]

• AlexaMediaPlayer
• NotifyEntity
• MediaPlayerImage

MobilePush also ignores groups but selects targets based on actions not entities ( since each physical mobile device gets its own action in HomeAssistant)

Chime is currently the only transport that expands groups.
AlexaDevices accepts groups and passes them on untouched to notify.send_message

[lollox80]

Happy to pick this up with a PR if useful. Initial sketch:

1. Add a Target.expand_groups(hass_api) helper that resolves group entity_ids to their members.
2. Wire it into the affected transports: �lexa_media_player,
   otify_entity, media_player_image, and mobile_push (the last one needs the per-device action re-resolution after expansion).
3. Leave chime as-is (already working) and �lexa_devices pass-through unchanged.

Tests would cover: nested group expansion, mixed groups+entities, empty group, non-applicable entity types per transport.

Want me to open a PR? Happy to align with whichever direction you prefer (helper on Target vs helper on the Transport base vs per-transport).

[jeyrb]

How I'm thinking about it:

• TransportFeature for group expansion
• Call an expand method on target for any transport that doesn't have it,
• Add a GroupPolicy enum that has expand/pass/skip options, defaulting to pass for transports that handle groups and expand for ones that don't
• transport and delivery can define a GroupPolicy

[lollox80]

Love the framework approach — much cleaner than my per-transport sketch, and it future-proofs any new transport that gets added later. A few clarifying questions before I start, just to make sure my PR lands close to what you have in mind:

1. Where should GroupPolicy live?
My instinct is model.py next to TransportFeature / TargetRequired, with the string values re-exported through const.py so they can be referenced from schema.py for YAML validation. Sound right?

2. YAML surface
Would something like this work?

transport:
  alexa_media_player:
    group_policy: expand   # override the default

delivery:
  living_room_announce:
    group_policy: pass     # per-delivery override

Or do you prefer a shorter knob (groups: expand|pass|skip)? Happy to follow whatever reads best to you.

3. Where does the dispatch happen?
I'd put the expansion in notification.py during target resolution (i.e., once, before delivery routing), so each transport's deliver() stays clean:

• transports declaring TransportFeature.GROUP_EXPANSION get the raw group entity in their target list
• transports without the flag get pre-expanded member entities

That way Target.expand(hass_api) is called by the framework, not by each transport. Does that match your mental model, or were you thinking the call should live on the transport base class so each transport can opt-in/out at delivery time?

4. skip semantics
Just want to confirm: does skip mean "drop group entries from the target list entirely" (so a delivery whose only target was a group would suppress with SuppressionReason.NO_TARGET)? Or does it mean "ignore the group expansion request and let the transport handle it"?

5. mobile_push special case
Since mobile_push routes per-device action (notify.mobile_app_<device>) rather than per-entity, the expansion would still need a second step that maps person → mobile_app device(s). I think this fits naturally if we expand groups → people → devices in people.py after the generic Target.expand. Want me to keep that part inside the same PR, or split it out?

---

Happy to open the PR once we converge. I'd split it into commits for easy review:

1. Framework — GroupPolicy enum, TransportFeature.GROUP_EXPANSION, Target.expand, dispatch in notification.py, schema validation
2. Wire-up — alexa_media_player, notify_entity, media_player_image, mobile_push (with the people/device step)
3. Tests — nested groups, mixed groups+entities, empty groups, non-applicable entity types per transport, per-delivery policy override

[jeyrb]

1. model.py seems right
2. Prefer not having 'policy' in the key name (regret 'dupe_policy'). group_entities more explicit. The whole thing should probably live inside config.delivery_defaults.options as its a fine-detail tuning, so not make overall config seem more complicated. MessageUsagePolicy already there.
3. I like your idea of splitting up the transports and doing the expansion once then passing it on, though it should be at delivery level I think and driven by the group policy for each delivery. Transports always get more complicated, and good to keep as much common stuff out of them.
4. yes, skip meant don't pass the group entity at all, though to be honest can't think how I would use it (persistent notification doesn't take groups, but then it doesn't take any entities at all). It's more about learning to regret adding boolean config, when in future a 3rd case crops up, so having enum based policies instead.
5. of course, the groups could be groups of indirect targets, like person, as well as direct. not sure about groups of groups, or groups of groups of groups, I'd hope that's now allowed in Home Assistant, can do without more recursion. It's not just a mobile push case - the person could drive e-mail or SMS as well as mobile action, and I'd like that as part of a PR since it might change the overall approach