Enable control of groups, information caching, add test environment for ease of development

[JohnathonMohr]

• When mute is set to false, use the group coordinator when getting and controlling play status.
  • The idea is to take the "logical" action - if a speaker in a group is to be paused, and it's in a group, the entire group should be paused (which is what would happen via the Sonos app). The status for the speaker should also reflect the coordinator, since the real-world "audible" status would be identical. However, the current behavior results in no action (and incorrect status) if the accessory being controlled is not the coordinator.
  • The "logical" action isn't as obvious if the accessory is configured to mute, though, since muting an individual speaker would still work as expected, and may be the desired outcome. I therefore left this as-is.
  • Note: I had to update the version of the sonos package to get the details of the group configuration.
• Cache device information (device description, group configuration) to reduce amount of network traffic.
  • This is especially helpful for scenarios when homekit issues an "on" or "off" command, where the status is likely checked before and again immediately after the command.
  • Homebridge seems to instantiate the plugin/accessories in a way that results in each accessory having its own cache for some reason. It's not ideal, but still an improvement over no caching.
• Updated readme with new relevant details.
• During development, I created a script to initialize a test environment for testing. I thought this might be valuable to others as well, so I've included it and written up some documentation for it.

Note: the diff for index.js looks larger than it really is: a lot of it is indentation updates to make it easier to read. If you enable the "ignore whitespace" setting when reviewing, my updates will be clearer.

[nfarina]

Thanks for this contribution! My Sonos setup at home is very basic so I haven't had the need to really change this plugin in a long time.

Could you make these changes in a forked repo of your own that I can link to from the README here?

[JohnathonMohr]

I could keep a forked repo, but wouldn't that make it more complicated for others to get these features and fixes? There are a few users who have issues open that would be fixed with these updates, vs. asking them to start using a new fork (and likely a different npm package, if I can get one published - though I haven't actually published one before, so I don't know what the process is).

Is there a specific concern you have with the changes that I can address? I can put the extra functionality behind configuration params if you're more comfortable with that, or revert a lot of whitespace changes to reduce the diff size.

[nfarina]

Well I'm more worried about inadvertently disrupting any existing users of the plugin, then not having the bandwidth to deal with the support issues from that. I'd be happy to give you control of the repo if you'd like to manage that yourself though!

[JohnathonMohr]

I see. That's definitely understandable, and I appreciate your concern.

While I don't know how much time I can commit to managing issues broadly, I am willing to monitor and address any issues that others have as a result of my changes. I think it's fair I take responsibility for that. (Maybe that's what you meant, I'm just not 100% sure).

I think I'd enjoy trying to tackle other issues I see too if I do have the time though, so I would keep an eye on things anyway.

If that is what you end up deciding, I greatly appreciate it!

[nfarina]

Yes that's what I meant - and sounds good! I'll make you a contributor and you are welcome to merge this yourself whenever you like :)

[JohnathonMohr]

Thanks Nick! I'll go ahead and merge it now.

I'm assuming you'll take care of npm publishing...

[nfarina]

Ah forgot about npm! I can add you there as well if you like (just need your username); but I'll go ahead and publish now regardless.

[JohnathonMohr]

Great, thanks! My username is jmohr.