music_assistant: forward player.device_info.connections to device_registry

[trudenboy]

music_assistant: forward player device_info.connections into HA's device-registry

Summary

The Music Assistant integration constructs HA DeviceInfo from the
upstream MA Player model, but drops the connections set that
MA's per-protocol providers (BT bridges, AirPlay, WiiM, hass_players,
local_audio, …) populate to advertise hardware identity. As a result
HA's device-registry can't merge MA's media_player.<name> cards with
other integrations that know the same physical device — every speaker
ends up as two cards.

This PR forwards player.device_info.connections verbatim into HA's
DeviceInfo.connections argument.

Motivation

Empirical evidence from a HAOS production deployment showed every
Bluetooth speaker exposed via MA appears in HA as two device cards:

Card	connections	Source
MA media_player.<name>	[]	This integration
Other (e.g. bluetooth integration / HACS bridge)	{("bluetooth", mac)}	The other integration

HA's device-registry can't merge them because there's no overlapping
connection tuple. The empty-connections half comes from this
integration — MusicAssistantEntity.__init__ constructs DeviceInfo
with only identifiers, manufacturer, model, name, and
configuration_url. MA's internal player model already carries
MAC_ADDRESS / IP_ADDRESS identifiers (from WiiM, hass_players,
local_audio, …) but they were never exposed to HA's registry.

A companion change in music-assistant/models adds a separate
connections: set[tuple[str, str]] field on the player's
DeviceInfo, mirroring HA's open-ended device_registry shape so
provider authors can cleanly express HA-bound hardware identity. This
PR consumes that field.

Changes

homeassistant/components/music_assistant/entity.py
(MusicAssistantEntity.__init__):

connections = set(getattr(self.player.device_info, "connections", set()))
self._attr_device_info = DeviceInfo(
    identifiers={(DOMAIN, player_id)},
    connections=connections or None,
    manufacturer=...,
    ...
)

getattr with default keeps the integration working with older
music_assistant_models releases that don't yet have the field. After
the model bump (see Coordination), the new field is always present;
the getattr becomes a defensive no-op but is kept for safety.

The connection-type strings come from the provider — HA's registry
treats any string as a valid connection type, so new transports
(zigbee, matter, thread, custom) work without a manifest change here.

Tests

tests/components/music_assistant/test_init.py:
new test_device_info_forwards_player_connections exercises the path
end-to-end via the existing fixture infrastructure.
tests/components/music_assistant/fixtures/players.json gains a
connections block on its first player so the new test can assert
against device_entry.connections.

The fixture's player declares two connections: a Wi-Fi-style MAC and a
Bluetooth MAC. The test asserts both appear in HA's device_registry
device record after setup. This catches regressions in the
forwarding (drop, normalization mistake, type coercion).

Local-test caveat

HA core's full pytest dep tree is not feasible to set up locally on
Intel macOS without significant time. ruff lint + format on the
changed files were validated locally and pass cleanly. The HA CI
runner will exercise the full
tests/components/music_assistant/test_init.py suite including the
new test. Captured CI output in .local-ci-output.txt.

Backwards compatibility

• getattr(self.player.device_info, "connections", set()) keeps the
  integration working with music_assistant_models releases that
  predate the new field — the integration neither requires nor crashes
  on its absence.
• connections=connections or None — empty set passed to HA's
  DeviceInfo is converted to None so the registry input stays
  unchanged for players that have no hardware identity to advertise.
• No other behaviour change — identifiers, manufacturer, model,
  name, configuration_url all unchanged.
• Existing devices in operators' registries get connections retro-
  added on next entity initialization. This may cause HA's device-
  registry to merge previously-separate device records that share
  hardware connections (e.g. bluetooth integration's BT MAC matches
  MA's newly-forwarded BT MAC). This is the intended outcome — the
  documented HA behaviour for device_registry.async_get_or_create
  is to merge on overlapping connections. Operators with bespoke
  per-card automations may want to re-test those after upgrade.

Coordination

The connections field this PR reads is added in
music-assistant/models#215.
Per-provider passthrough lives in
music-assistant/server#3813
(Sendspin provider) — other providers (WiiM, AirPlay, hass_players, …)
will adopt the same passthrough pattern over time.

This PR can technically merge before the model PR (the getattr
guard makes it backwards-compatible), but practically should land
after a music-assistant-client release that bumps its transitive
music_assistant_models dependency to a version that has the field —
otherwise the test player fixture's connections block deserializes
to nothing and the new test silently passes without exercising the
real chain. Recommend bumping manifest.json's
music-assistant-client requirement alongside this merge.

Umbrella discussion with full design context and status:
https://github.com/orgs/music-assistant/discussions/5415

CLA

I'll click through the HA Contributor License Agreement on first PR;
this draft awaits maintainer review of the upstream coordination.

Test plan locally (full)

script/setup
pytest tests/components/music_assistant/test_init.py -v
pre-commit run --all-files

(Local Intel-mac restriction documented in .local-ci-output.txt —
ruff was the only tool run on this development host. CI runners
exercise the full path.)

[home-assistant]

Hi @Renso

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[home-assistant]

Hey there @music-assistant, @arturpragacz, mind taking a look at this pull request as it has been labeled with an integration (music_assistant) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of music_assistant can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant mark-draft Mark the pull request as draft.
• @home-assistant ready-for-review Remove the draft status from the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign music_assistant Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant update-branch Update the pull request branch with the base branch.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the pull request.

[Copilot]

Pull request overview

This PR updates the Music Assistant integration to forward upstream player hardware connection identifiers into Home Assistant’s device registry, enabling HA to merge devices across integrations based on shared connection tuples.

Changes:

• Forward player.device_info.connections into DeviceInfo.connections when creating Music Assistant entities.
• Extend the Music Assistant player fixture with connections data.
• Add a test asserting that fixture player connections appear on the created HA device entry.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
homeassistant/components/music_assistant/entity.py	Adds forwarding of player.device_info.connections into HA DeviceInfo.connections.
tests/components/music_assistant/fixtures/players.json	Adds connections entries to the first player fixture.
tests/components/music_assistant/test_init.py	Adds an end-to-end test validating the forwarded connections are present in the device registry.

[home-assistant]

Hi @trudenboy

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[arturpragacz]

Thank you for your contribution, however we explicitly do not want to merge devices across integrations.