Support group volume, mute.

[ebaauw]

Support group volume, mute.

[leoneleone]

Group volume support is much needed, I agree

[ebaauw]

@leoneleone Thanks for your feedback

I'm struggling how this should be exposed to HomeKit; I'd appreciate your thoughts on this.

Sonos offers volume/mute controls per zone and play/pause/group volume/group mute controls per group. A group consists of a coordinator zone with zero or more member zones. A zone is either a single speaker, a stereo pair, or a home cinema configuration (i.e. a speaker with a sub and/or surround speakers).
Under Rooms, the Sonos app actually shows groups, rather than zones. Per group, it shows the group play/pause controls as well as the zone volume/mute controls. Under Room Settings it actually shows zones. This is highly confusing and took me quite some time to figure out.

When a member zone joins a coordinator zone's group, the standalone group for the member zone is destroyed and the member zone is added to the coordinator zone's group. The Sonos app shows this group including its member zones, still with group play/pause controls, but now with the group volume/mute controls. When you select the volume control, it pops up the volume/mute controls for the individual zones.
When a member zone leaves a group, a new standalone group (with a new ID) is created for that zone. When the coordinator zone leaves a group, one of the members inherits the group, becoming the new coordinator (you notice a disruption in the music as the new coordinator takes control of the stream), and a new standalone group (with a new ID) is created for the former coordinator.

If I were to follow the Sonos app approach for homebridge-zp, I would create an accessory per group, with group play/pause control and with zone volume/mute control. When a member zone joins a coordinator zone's group, the accessory for the member zone's standalone group would be deleted, and the accessory for the coordinator's zone group would get additional characteristics for the volume/mute control of the group and for the volume/mute control of the member zone. When the member zone leaves, a new accessory for the new standalone group for the former member zone would be created, and the additional characteristics for the group would be removed.
With the current design of homebridge-zp, I cannot create or delete accessories at run-time (see issue #1). But even with dynamic platform accessories, HomeKit would lose any room, scene or rule assignments when the accessory is deleted. Also, it doesn't make sense for the group accessory to remain in the coordinator's room, as it now spans two rooms. Note that I cannot change room, scene, nor rule assignments from homebridge-zp - these can only be controlled from HomeKit apps, not from HomeKit accessories.

So homebridge-zp currently creates an accessory per zone, with the group play/pause controls and the zone volume/mute controls. I could add the group volume/mute controls to each zone (just like the play/pause controls), but that would be confusing for standalone groups.
With dynamic platform accessories, I should be able to add the group volume/mute controls when a member zone joins a group and remove them when the member zone leaves, but that would prevent the use of group volume/mute characteristics in homekit scenes or rules.
Alternatively, I could ignore the zone volume/mute controls and only use the group volume/mute controls, but that would disable volume/mute control per zone. Personally, I like to be able to control volume per room from HomeKit.

[leoneleone]

@ebaauw

I have been thinking about the information above ever since I read your reply a couple of weeks ago.

There is no simple and clear way of matching group volume and mapping it to HomeKit as of yet. The easiest way is what you suggested "I could add the group volume/mute controls to each zone (just like the play/pause controls), but that would be confusing for standalone groups.". It's not the most user friendly solution, but I believe it would be much less confusing for the HomeKit protocol itself. Users just have to aware of how "Group Volume" would work when they see it as a Characteristic within HomeKit apps such as Elgato Eve, and that Sonos CoordinatorZone and grouping are done only within the Sonos app and now in HomeKit.

The other option I have been testing is to have HomeKit do most or all the grouping via Service Groups. So if you had say 3 Sonos speakers in the Living Room grouped in a Service Group called "Living Room Speakers" or "Living Room Sonos", you could set each Sonos speaker's individual volume separately (Characteristic.Brightness) via Siri Commands or via an app, and then call out separate Siri Commands to raise or lower the Service Group's relative Volume(Brightness) using: "Hey Siri, lower the "Living Room Speakers" (the name of the HomeKit Service Group) by 20%". Just like with lights, the volume(brightness) of the current state of individual volumes would lower by 20%. This relative change of (Characteristic.Brightness) has always been possible via Siri Command, but I have noticed Apple has been experimenting with changes in the wording and vocabulary of this "Relative Brightness" siri command.
There is no real way to see or control this relative-values change from within a HomeKit app, but it is a workaround for getting some sort group volume control just through Siri Commands.

I'll explain a little more about my Sonos setup and how I use it with HomeKit if that's any help, but I really believe that each individual user will have a difference preference regarding this.

I currently have my speakers setup in Sonos Groups indicating which physical Room they are in:
Bedroom Speakers
Bathroom Speakers
Living Room Speakers
Kitchen Speakers
Spare Room Speakers
Spare Bathroom Speakers
etc

I then have HomeKit Service Groups for clusters of physical Rooms:
HomeKit Service Group "Master Speakers" = Bedroom Speakers + Bathroom Speakers
HomeKit Service Group "Living Speakers" = Living Room Speakers + Kitchen Speakers
HomeKit Service Group "Guest Speakers" = Spare Room Speakers + Spare Bathroom Speakers
etc

This way I can control volumes of the separate speakers (sonosZones/Rooms) by calling out their individual names, and can control relative volumes by calling out the HomeKit ServiceGroup names and using the Siri Command wording I mentioned above for relative volume controls.

I think we will have to wait until some manufacturer (Sonos maybe, although they tend to be very slow in releasing new products) joins the "Works with HomeKit" program and decides to release an official Speaker device before Apple implements an elegant solution for a wireless speaker system, which takes into account dynamic grouping and relative volumes.

I'd like to hear your thoughts on this if you have any 😊

[ebaauw]

Hi @leoneleone thanks for your input!

I hadn't thought about using HomeKit Service Groups for Zone Groups. This definitely is a way to explain it to Siri, but they're fairly static (compared to Sonos Zone Groups), which matches your setup quite nicely. Unfortunately, you can only maintain HomeKit Service Groups from an iOS HomeKit app, not from a HomeKit accessory (like homebridge). Alternatively, you could use HomeKit Zones (e.g. your Master zone would include the Bedroom and Bathroom rooms). This has the added advantage (or not, depending on your setup) that Siri will also understand Master Lights, Master Switches, etc for all Lights, Switches, etc. in both these rooms.

Incidentally, my setup is quite different. I want my lights and my music to follow me automatically, as I change rooms. I use a series of Hue motion sensors to detect entering or leaving a room. On enter, the room lights turn on (when it's dark) and the Sonos speakers in that room join the group currently playing (when previously paused). On exit (actually five minutes after), the lights turn off and the Sonos speakers leave the group.

I'm currently working on group volume and group mute support. I'll publish a beta version, once I have something working. I need to create a second service (e.g. Living Room Sonos Group) for these, so I can re-use the same characteristics as for speaker volume and mute. Siri won't understand a custom GroupVolume or GroupBrightness characteristic. I'm adding a custom characteristic for the group name to this Group service to give at least a clue what is going on.

To match the logic in the Sonos app as closely as possible, I'm creating one service Bedroom Sonos Zone with controls for volume/mute, bass/treble/loudness (future), speaker LED (future), and join/leave group, and one service Bedroom Sonos Group with controls for play/pause, current/next/previous track, (group) volume/mute, group name. The group controls would be either be disabled when the speaker joins another speaker's group, or (preferably) would interact with the group's coordinator instead of the member speaker. As mentioned before, Sonos refers to both of these as "Room"...
You could rename the "Bedroom Sonos Zone" service to "Bedroom Speakers" and the "Bedroom Sonos Group" service to "Master Speakers" (assuming Bedroom is the coordinator of the Master zonegroup) to achieve your current setup.

I'm seeing some funny feedback, in that changing the group volume causes the volumes of the speakers in the group to change, which in turn cause the group volume to change, ... I turned to wireshark to see how the Sonos app deals with this. It appears like it doesn't use the relative volumes nor the GroupRendering service provided by the Sonos players at all. It sends/receives only the absolute volumes of the individual speakers.

[leoneleone]

@ebaauw

All your future plans for the plugin sound great!
And yes exposing Sonos Group Volume in the way you mention seems the most effective way for most people. It's still strange that you can't target the (Sonos Group) Volume control independently of the actual coordinator Room/Zone Volume.

Assuming all you Sonos Rooms/Zones are using the the same input (Airplay) in my case, I would give preference to indivisible Room/Speaker Volume control rather than the Sonos Group Volume control.

I have my Speakers(SonosRooms) configured as HomeKit Switches with the added Brightness characteristic, Siri still works for changing Brightbess despite the Speaker appearing as HomeKit switches - that way I can avoid Siri including then in any commands I give for Lights. I can safely say "Turn off the Living Rooms" without the Sonos Speakers (switches) being affected. This also allows be to "add Speakers to a playing group" (not according to Sonos, but within the HomeKit ecosystem by turning Speaker ServiceGroups I created in HomeKit on and off.

The only working method to change Group Volume (relative volumes of grouped sonos speakers) using Siri is what I mentioned earlier:
Sonos Speakers configured into HomeKit Service Groups. Then calling out the specific voice commands "increase/decrease (brighten/dim) the (ServiceGroup name) by X%". I don't really see any usefulness to Group Volume control as part of any HomeKit Automation rules (Triggers) because people usually have set volumes preferences which don't change much. Plus if you can set volumes for individual Sonos Speakers to be triggered by other devices or as part of HomeKit Scenes, there really is no need for Sonos Group Volume control in that specific use case.

If I can think of any other solution I'll be sure to let you know.

Have a very Happy New Year in the meantime 🎉

[ebaauw]

@leoneleone
Thanks. Best wishes for 2017 to you and your loved ones.

And yes exposing Sonos Group Volume in the way you mention seems the most effective way for most people. It's still strange that you can't target the (Sonos Group) Volume control independently of the actual coordinator Room/Zone Volume.

I could (with dynamic platform accessories) create a new accessory when a group is formed (when a member zone joins a coordinator zone) and delete this accessory when the group is disbanded (when the last member zone leaves). This is more or less how the Sonos app works. However, you would lose all HomeKit assignments to rooms, scenes, triggers, etc. for this group accessory when it's deleted. Indeed, this might be acceptable for group volume/mute control, but definitely not for play/pause control.

So I either need to add group characteristics to each zone service, or create a (potentially dummy) service for each potential group, tied to the accessory for the coordinator zone. As you would want to use Siri to change group volume as well, I would need to use the same characteristic types twice to the zone service. As HomeKit doesn't support this, I need to create a second service for the group. Once I'm doing that, it makes sense for other group related controls (play/pause) to move to the second service, so at least you'd understand which controls affect a single zone and which affect all zones in the group.

Assuming all you Sonos Rooms/Zones are using the the same input (Airplay) in my case, I would give preference to indivisible Room/Speaker Volume control rather than the Sonos Group Volume control.

Yes, so would I, and that's what homebridge-zp currently does ;-) The challenge is to support both.

I have my Speakers(SonosRooms) configured as HomeKit Switches with the added Brightness characteristic, Siri still works for changing Brightbess despite the Speaker appearing as HomeKit switches

Cool - I haven't tried that. So, I don't need to expose Sonos as Lightbulb, just use Brightness instead of Volume.

[leoneleone]

@ebaauw

Yes, you can add any Siri Characteristic to any Service Type and it will still work via Voice Commands.

I think Apple limited that a while back so that Services can only have Charactistics limited to those specified for each service in (HomeKitTypes file), but then they reverted it back so that Characterics became agnostic again regarding what ServiceTypes they can be added to.

So you could have a Speaker.Service with brightness characteristics for Siri volume control by using addCharachteristic when defining the Services within the homebridge plugin. Volume characteristic is an optional Characteristic for the Service.Speaker, Characteristic.Mute is mandatory.

[ebaauw]

v0.1.4.