-
-
Notifications
You must be signed in to change notification settings - Fork 149
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
Sonos Boost breaks the module #515
Comments
Why would you control a bridge? care to create a PR for this? Can the app using this library not just filter out the boost (with the possibly good filter method above). |
Precisely there is no reason to control a bridge hence my suggestion to
filter them out right from within node-sonos.
In the interim i did filter it out upstream in the calling application.
Happy to submit a PR if you confirm it makes sense and I am not
missing another usecase somehow
Le sam. 19 juin 2021 à 22:11, Stephan van Rooij ***@***.***>
a écrit :
… Why would you control a bridge?
care to create a PR for this? Can the app using this library not just
filter out the boost (with the possibly good filter method above).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#515 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABCACKD5SDW5GON32LNZNDTTT2YHANCNFSM46QFD6NA>
.
|
It would be nice to filter out non-players in most cases. But you can still rename a boost for instance. So maybe optional parameter to filter them out. |
yep that's why the proposal is not to filter on the name "Boost" but rather the specific property that is only present for Boost and the older brides |
I mean, the use case to return the boost is that you can control some things off it. Hiding them always might not be a good idea. can you make the PR to the alpha branch? |
I have a Sonos Boost (bridge) in my network and whenever it is plugged in the module breaks with the following error:
A command is sent to the bridge which is not supported
Current Behavior
Ideally bridges should be ignored as they cannot be piloted, they are just here to manage the Sonos network
Possible Solution
I suggest filtering the bridges in the network in
ZoneGroupTopology.prototype.AllZoneGroups
by returning
return groups.filter(z => {return !z.ZoneGroupMember[0].hasOwnProperty("IsZoneBridge")})
Versions (and Environment)
Node version: v15.7.0
node-sonos version: 1.12.5
OS: MacOS, Raspberry PI OS
The text was updated successfully, but these errors were encountered: