Spotify Playlist in Presets - Integration Guides

[rummens]

Hi @jishi,

first of all thanks for creating this awesome API, I've been using it extensively for quite some time. I now moved most of my code to use presets, makes things prettier on the client side. The one thing still missing for me is the support of Spotify playlist and I did some quick tests:

I was able to get it working by moving some of the Spotify code from this repo back into your discovery repo. I am not sure how you are handling the separation between these two, I see that there is no music service implementation over there but I guess you want to keep that one standalone.

Any suggestions on how I can implement this without having duplicate code or linking between the projects, rendering the discovery repo not fully standalone anymore?

FYI, This is what I am talking about. Its super dirty but works :-)

Happy to help Marcel

[jishi]

Hi. I understand the confusion. When I built the spotify-support initially, it was kind of a proof of concept rather than a well designed feature. I always planned for moving it into the discovery-package because it seemed more useful as a core-feature, rather than something only limited to the http api.

However, the discovery package has decent test coverage, so any implementation there should also have corresponding tests, which adds some friction for a refactoring.

My thinking would be to expose methods on the Player class like: spotifyEnqueue(), spotifyNow(), spotifyNext() or make the addURIToQueue() support different URI prefixes and act accordingly (allowing null for metadata, perhaps).

If you add new methods, they preferably should be added via the prototype approach (there is some auto-loader for files that are in the prototypes folder, I believe), which makes it much easier to read the code in the future (IMHO). With spotify playback available in the core package, the http-api should instead just use that instead of it's own logic, simplifying the http-api significantly.

Just a heads-up, I suspect that the new S2 software that is due release any day now might break this API. Sonos has been working on cloud control for a few years now, and I believe that the UPnP api might go away in favor of a websocket-based cloud-api. I think this is the reason for the S1/S2 fragmentation, they can't fit this new API into the hardware of older speakers, but they don't want to deal with the legacy of UPnP in the new speakers, hence, they will be incompatible systems.

Maybe I'll write a new, cloud-hosted API that will use the S2 api in the future, we'll see. The API has a few strength for automation that people find useful (I personally don't use it as much anymore), like presets and simplified group control, but my time is also limited I'm afraid.

[rummens]

Thanks for the detailed description. I guess the questions is if it make sense to do a huge amount of refactoring now if the API is deprecated very soon. As my speaker are all fairly new, I will have to switch to the new API anyway :-/

What do you think? The solution I build works for me now but I am happy to help on the refactoring in any event. Do you know if Sonos will release an official REST API of some sort? Its always nicer than having to deal with low level interactions like UPnP or whatever the new one will look like.

[jishi]

They already have a REST api but with limited functionality: https://developer.sonos.com/reference/control-api/

It is using oauth authentication which isn't very nice to deal with from an home automation system or similar though.

I believe that this might be one of the big changes that comes with S2, making their own app move over to this API and extend it with all functionality. We'll see.

[rummens]

Okay, I guess in this case let’s wait for the changes and re-evaluate this.