Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bang & Olufsen add beolink grouping #113438

Open
wants to merge 51 commits into
base: dev
Choose a base branch
from

Conversation

mj23000
Copy link
Contributor

@mj23000 mj23000 commented Mar 14, 2024

Proposed change

Add additional media player grouping to the bang_olufsen media_player entity, using Beolink custom actions.

Beolink is not limited to Mozart devices, which means that devices that can't to be added to Home Assistant (with this integration) can be expanded to using the custom actions, which reference the device's unique JID, instead of entity_id.

Additionally extra_state_attributes show Beolink self (name and JID), peers, listeners and leader.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
  • Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

Copy link
Member

@joostlek joostlek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please split this PR. One for bumping the library (and all changes needed to support that new version (not the changes needed for new features made possible for that version)). Then try to split the services into a separate PR if that makes sense. I haven't checked the media_player diff, but I don't believe adding services would add that much code to media_player.py

@home-assistant home-assistant bot marked this pull request as draft March 16, 2024 14:54
@home-assistant
Copy link

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@mj23000
Copy link
Contributor Author

mj23000 commented Mar 18, 2024

Please split this PR. One for bumping the library (and all changes needed to support that new version (not the changes needed for new features made possible for that version)). Then try to split the services into a separate PR if that makes sense. I haven't checked the media_player diff, but I don't believe adding services would add that much code to media_player.py

Of course.
I've made a new PR for just the API update. This PR depends on the API update, so I'll just keep this as a draft for now, and merge any changes that may be made when the time comes.

As for the custom services, there are 5 in total and they are all "required" for a smooth Beolink experience. These include "join", "expand", "unexpand", "leave" and "allstandby".

I could reduce this down to only the "expand" service and remove the extra_state_attributes for the Beolink session, which would retain support for media_player grouping and remove a sizable amount of code, if that would make this PR more digestable.

@mj23000 mj23000 changed the title Bang & Olufsen add beolink grouping and update API Bang & Olufsen add beolink grouping Mar 18, 2024
@mj23000 mj23000 marked this pull request as ready for review May 16, 2024 11:11
@home-assistant home-assistant bot requested a review from joostlek May 16, 2024 11:11
@mj23000
Copy link
Contributor Author

mj23000 commented Jul 31, 2024

A few comments.

Should we maybe split this PR to an initial PR which adds only the standard Home Assistant service API for creating groups and a follow-up PR which adds the custom B&O services?

Yes, I'll address some of your comments and then make a new PR for basic Home Assistant grouping.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make the implementation easier to understand, please add syrupy state snapshot assertions, maybe also snapshots of entity registry and device registry entries.

In particular, this would be helpful to understand the extra attributes.

@mj23000 mj23000 marked this pull request as draft July 31, 2024 15:39
@mj23000
Copy link
Contributor Author

mj23000 commented Aug 1, 2024

I've made a smaller PR with support for Home Assistant grouping #123020

@emontnemery
Copy link
Contributor

@mj23000 please don't forget to click the "Ready for review" button when you want the PR to be reviewed

@mj23000 mj23000 marked this pull request as ready for review September 25, 2024 11:04
@emontnemery
Copy link
Contributor

emontnemery commented Sep 25, 2024

Please fix the merge conflicts

Copy link
Contributor

@emontnemery emontnemery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments. I've not reviewed the tests.

homeassistant/components/bang_olufsen/strings.json Outdated Show resolved Hide resolved
homeassistant/components/bang_olufsen/media_player.py Outdated Show resolved Hide resolved
Comment on lines 438 to 439
assert self.device_entry
assert self.device_entry.name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is only for the type checker, let's hide the asserts behind if TYPE_CHECKING:, also, maybe be explicit the device and name are not None unless the name "" is impossible and we want the type checker to know that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The _async_update_beolink is also called directly on WebsocketNotification.BEOLINK notifications, so I don't think the if TYPE_CHECKING: can be added. I've added explicit None checks ("" is also a valid name).

homeassistant/components/bang_olufsen/media_player.py Outdated Show resolved Hide resolved
homeassistant/components/bang_olufsen/media_player.py Outdated Show resolved Hide resolved
homeassistant/components/bang_olufsen/media_player.py Outdated Show resolved Hide resolved

async def _async_beolink_join(self) -> None:
# Custom actions:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The meaning of this comment is unclear

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a separator for standard Home Assistant actions and custom actions.

"fields": {
"beolink_jid": {
"name": "Beolink JID",
"description": "Manually specify Beolink JID to join."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I've asked several times now, but where do users find the JID? Should we explain it here? Maybe add a section in each service, where the section explains how to find the JID?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JIDs are found using the beolink extra_state_attributes.
Great idea to add a section to the services for the JID parameters. Though it seems that sections have a bug where they need to have at least one required field outside of the section to work and examples from within a section seem to be broken as well, so it hasn't been possible for me to make use of them, but I'll try to investigate further and open an issue if needed.

Fix comment placement
Fix group leader group_members rebase error
Replace entity_id method call with attribute
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants