Input needed: Logical devices from ZoneGroupTopology

[svrooij]

Recently I started creating a way to use logical devices.

I wanted to return all the groups in the current sonos setup with all child Sonos players as a Sonos object. Then I got stuck in the circular reference hell, because the Sonos object had a dependency on the Event emitter which had a new introducted dependency on the Sonos object.

Do you guys have an idea on how to solve this? @jkazimir @Villarrealized @phoenixrising87

I was thinking about something like creating a SonosBase with all the functions but without the events part. Then creating an Sonos object that extends the SonosBase with the event part. Then we could have the event ZoneGroupTopology have all the childs be of the SonosBase type.

How would we have the group emit events as well? Or would we then have to implement a new event meganism on the group?

[ebaauw]

I would simply emit the group events from the coordinator zone player. Maybe also from each of the member zoneplayers, but then using a different event name to distinguish between "master" and "slave" events.

The setup you propose won't work for my homebridge plugin. HomeKit doesn't like configuration changes, and new accessories (for the groups) appearing and disappearing would lose any HomeKit associations to rooms, scenes and automations. That's why I only expose a HomeKit accessory per zone player (room), and handle all the group stuff from the coordinator zone player. I actually provide two services per zone player, one for the group stuff (play/pause, next/previous track, group volume) and one for the player stuff (volume, bass/treble/loudness, led). I point the group stuff for member players to the coordinator (so setting the group volume, or moving to the next track of a member is actually performed on the coordinator). The administration of which zoneplayers are members of which group was quite challenging. When joining and leaving groups, the various events for the different Sonos endpoints arrive in different order. The joy of asynchronous programming.

[Rolf-M]

I think it would be a big help (at least for me :-)) if you could implement a "getGroupCoordinator()", this should return the IP Address (and port) of the coordinator of your current speaker, and maybe a "grouped" bool flag. If you could then add an event, that fires each time, this changes like "GroupCoordinatorChange", then this would help most people. Then you may decide by yourself, if you send some request to the coordinator, or to the speaker itself. For me, this would be very helpful, as "ebaauw" mentioned, getting this informations from all the events is a real challenge.

[svrooij]

For me, this would be very helpful, as "ebaauw" mentioned, getting this informations from all the events is a real challenge.

I know, that is why input is needed on what would be the best solution.

Can I summarize your "requirements" as follows:

• Each speaker should get a property (or function) IsCoordinator, to show if this player is also the coordinator.
• Each speaker should get a function GetCoordinator() that gives a SonosConfig object (with port and ip) of the coordinator.
• Each speaker should get a function that will return the name of the group (like Livingroom + 2).
• Each speaker should emit an PlayerCoordinatorChanged event if it's joined to a group or removed from a group.

I'm thinking about the following 2 requirements:

• Starting without multicast discovery, so enter one players IP and load the (logical) devices from there. That would be useful when running this in docker.
• Global event emitter for changes to logical players.

[Rolf-M]

Hi svrooij, I would fully agree to your sumarization. About the two points you mentioned in addition, especialy the last one (global event emitter) would be great!

I forgot to mention, what I wrote in a different issue, that it would be more correct, if the api would redirect the play/pause and track and queue instructions to the master of the group. If you pause a grouped speaker (not the master) it will not be reflected in the original sonos controller/app. You can also not restart the speaker, so you end up with some kind of mess. So for my opinion the correct way would be if the api would internaly check, if the adressed speaker is group master and if not redirect the instructions that are meant to be sent to the master. got my point? Regards, Rolf

[svrooij]

I'll be focusing my efforts on my typescript version of this library. The new project is inspired by the stuff discussed here.

Closing this issue (for now).

[svrooij]

@Rolf-M and @ebaauw check out the latest version of my new library. https://www.npmjs.com/package/@svrooij/sonos

I solved the logical devices part there. A manager will find all the devices and set a .Coordinator on each group member, that also automatically updates by a special event subscription in the manager. That way the number of devices won’t change only the groups they’re in.