[soundtouch] allow customized source setting
Proposed change
Allows more customized source setting for Bose Soundtouch devices.
Issue
The current iteration only supports source setting of AUX or BLUETOOTH. However, there is a lot more sources available, and the entirety of the supported sources is device dependent. As such, we need a method to proxy string values through the HomeAssistant interfaces to the upstream library so that proper sources can be set.
To further complicate matters, it looks like the sourceAccount field is used to distinguish between similar "sources". For example, when I queried my Soundtouch 300, I obtained the following (abridged) output:
<?xml version="1.0" encoding="UTF-8"?>
<sources deviceID="redacted">
<sourceItem source="PRODUCT" sourceAccount="HDMI_1" status="UNAVAILABLE" isLocal="true" multiroomallowed="true">HDMI_1</sourceItem>
<sourceItem source="PRODUCT" sourceAccount="TV" status="READY" isLocal="true" multiroomallowed="true">TV</sourceItem>
</sources>
From this output, it looks like the TV is supported, but the HDMI_1 may not be. Furthermore, PRODUCT isn't even a valid source in the upstream libsoundtouch library (evidence that valid sources are device dependent).
Fix
To support more granular source setting, I propose the following modification: instead of only supporting AUX and BLUETOOTH, this PR will allow values to be set as such:
action: media_player.select_source
data:
source: PRODUCT.TV
target:
entity_id: media_player.bose_soundtouch
If no sourceAccount is necessary, a period with no source account can also be set (i.e. PRODUCT.).
Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] 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
- This PR fixes or closes issue: fixes #141776
Checklist
- [x] The code change is tested and works locally.
- [ ] Local tests pass. Your PR cannot be merged unless tests pass
- [x] 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:
- [ ] Documentation added/updated for www.home-assistant.io
If the code communicates with devices, web services, or third-party tools:
- [x] The manifest file has all fields filled out correctly.
Updated and included derived files by running:python3 -m script.hassfest. - [x] New or updated dependencies have been added to
requirements_all.txt.
Updated by runningpython3 -m script.gen_requirements_all. - [x] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
To help with the load of incoming pull requests:
- [ ] I have reviewed two other open pull requests in this repository.
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:
Hey there @kroimon, mind taking a look at this pull request as it has been labeled with an integration (soundtouch) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of soundtouch can trigger bot actions by commenting:
@home-assistant closeCloses the pull request.@home-assistant rename Awesome new titleRenames the pull request.@home-assistant reopenReopen the pull request.@home-assistant unassign soundtouchRemoves the current integration label and assignees on the pull request, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.
any chance to get a beta from this? :-)
Is there still hope?
@domanchi what is this PR waiting for? If it's ready for review, please mark it so by clicking the "ready for review" button.
there is /sources endpoint that returns a list of available (and non-available) sources the device knows. If I remember correctly it even returns the given names for the sources (as users can rename the sources on the SA-20). My delphi code for it is as follows, maybe it helps (sorry for the formatting???):
Data := GetData('/sources'); if not(Data = nil) then begin; NWInfo := Data.ChildNodes; for index := 0 to NWInfo.Count - 1 do begin; if NWInfo[index].AttributeNodes.Count > 0 then begin; try isLocal := NWInfo[index].Attributes['isLocal']; isAvailable := NWInfo[index].Attributes['status']; if isLocal and (isAvailable = 'READY') then begin; AuxSource := NWInfo[index].Attributes['sourceAccount']; try AuxName := NWInfo[index].NodeValue; except AuxName := AuxSource; end; // Result.Add(Auxname); Result.Values[AuxName] := AuxSource; end; except end; end; end; Data := nil; end;
there is /sources endpoint that returns a list of available (and non-available) sources
Ok, then I think we should use that to populate the source_list property
the used libsoundtouch by this integration seems to be more than dead. But there is a well maintained python library here https://github.com/thlucas1/bosesoundtouchapi which would support the selection of different sources along with plenty of additional feature that the current HomeAssistant integration is missing
@da-anda if the library used by the soundtouch integration is dead and there's a better maintained one, a PR changing the library would be welcome.
@da-anda if the library used by the soundtouch integration is dead and there's a better maintained one, a PR changing the library would be welcome.
I am not a python dev. I only did some googling and found that libsoundtouch was last changed 7 years ago. So it basically is dead. There seem to be several other python based soundtouch libraries that could be used instead. The one that seems to be the most active developed/maintained one (from my limited research) is https://github.com/thlucas1/bosesoundtouchapi and it also does support a lot more features (like managing the presets, naming devices, change bass levels etc).
If somebody were to update the soundtouch integration, it IMHO would need a complete rewrite. The multiroom features are now supported by HomeAssistant directly, so the custom services etc are no longer required and the integration would have to be made compatible with current HomeAssistant standards for media players. Same with media playback services and what not. This is no complaint by any means, just an observation.