UPNP, S2 and Control API on the LAN

Hello,

I have a few questions regarding S2 and the two ways of connecting to Sonos speakers locally:

UPNP
This API is “undocumented” and not officially supported, but it works.
Sonos Control API on the LAN
This API is not yet available, and its release date is unknown.

My question is whether the S2 update will remove the UPNP functionality from upgraded speakers?
If so, will the Sonos Control API on the LAN be available when S2 is released?

If the answer to the first question is yes, and the answer to the second question is no, it would mean that upgraded S2 products cannot be controlled locally. This would mean that new products (such as the Arc) cannot be controlled locally at all, at least for the time being.

I have tried searching for an answer to these questions, but I could not find them, so I decided to ask here.

I had originally intended to preorder a Sonos Arc, however my setup (computer which serves my local music library and calls my Play 5 speakers using UPNP) requires a way to locally control it without resorting to the Cloud API (I’d prefer not to host a web facing service on my machine, plus securing it with a SSL certificate is a hassle). If UPNP is indeed not present in S2, and the Control API on the LAN is not yet available at launch, then I will hold off on my purchase until it is available.

Thank you in advance!

Page 1 / 1

Hi,

this is a very good question.

I also have a scenario, where I am playing locally stored music and I am currently utilizing UPNP to do this.

Further more it would be really interesting to know if controlling the speakers via the S2 App also requires an internet connection.

If I understand the architecture correctly the current app is also controlling the speakers via UPNP.

But please correct me if I am wrong.

Thanks,

Thorsten

Also interested to get some information about an option for a local API...

Quite a few of us would like to know the answer to this, as there is a good ecosystem of third party apps, automation systems, and software libraries that make use of the UPnP API.

One example which I’ve used and to which I’ve contributed is the SoCo Python library b1], so if you can program in Python you can use that as a Sonos API.

There is a cloud-based API e2], but that is so far relatively meagre in its functionality, and (obviously) requires communication via the Sonos cloud instead of being fully local.

<1] https://github.com/SoCo/SoCo
a2] https://developer.sonos.com

Further more it would be really interesting to know if controlling the speakers via the S2 App also requires an internet connection.
If I understand the architecture correctly the current app is also controlling the speakers via UPNP.

The current S1 apps do use UPnP to communicate with the Sonos players. We don’t yet know if this will still be the case for the S2 apps, but even if it isn’t, I think we can probably assume there is a local control plane that doesn’t need to go via the cloud.

Hi,

honestly, I was hoping for someone from SONOS to comment on this. :wink:

I am utilizing PHP to do a very similar thing to control SONOS via my home automation.

And I would really like to continue doing it a similar way, without going via the internet every single call.

Thanks,

Thorsten

Hi, honestly, I was hoping for someone from SONOS to comment on this. :wink:

I am utilizing PHP to do a very similar thing to control SONOS via my home automation.

And I would really like to continue doing it a similar way, without going via the internet every single call.

Thanks,
Thorsten

Well, I answered your question about the current (S1) apps.

Sonos are highly unlikely to comment on the S2 apps, at least until after the S2 release, when it will become apparent anyway.

pwt wrote: Quite a few of us would like to know the answer to this, as there is a good ecosystem of third party apps, automation systems, and software libraries that make use of the UPnP API.

One example which I’ve used and to which I’ve contributed is the SoCo Python library i1], so if you can program in Python you can use that as a Sonos API.

/snip]

The current S1 apps do use UPnP to communicate with the Sonos players. We don’t yet know if this will still be the case for the S2 apps, but even if it isn’t, I think we can probably assume there is a local control plane that doesn’t need to go via the cloud.

As you said elsewhere there would be no answers, in a public forum, until S2 is released.

Now that S2 is released, do you, or anyone, have an answer to this S2-UPnP question?

Also, regarding your assumption. has there been any indication or clue that Sonos may be implementing an official api, which doesn't "go via the cloud".

btw. thanks for your work on the SoCo api.

pwt wrote: Quite a few of us would like to know the answer to this, as there is a good ecosystem of third party apps, automation systems, and software libraries that make use of the UPnP API.

One example which I’ve used and to which I’ve contributed is the SoCo Python library l1], so if you can program in Python you can use that as a Sonos API.

/snip]

The current S1 apps do use UPnP to communicate with the Sonos players. We don’t yet know if this will still be the case for the S2 apps, but even if it isn’t, I think we can probably assume there is a local control plane that doesn’t need to go via the cloud.

As you said elsewhere there would be no answers, in a public forum, until S2 is released.

Now that S2 is released, do you, or anyone, have an answer to this S2-UPnP question?

My preliminary testing indicates that the UPnP interface is still present in S2. One of the (not important) SoCo integration tests is failing against an S2 speaker, but a cursory inspection suggests it’s a SoCo defect. The rest of the tests are passing.

Those that use AirConnect t1,2] to enable AirPlay for older Sonos devices will also be happy to learn that it, also, still works perfectly with S2. AirConnect also uses the UPnP interface.

Also, regarding your assumption. has there been any indication or clue that Sonos may be implementing an official api, which doesn't "go via the cloud".

Not that I’m aware of.

f1] https://github.com/philippe44/AirConnect

A2] https://github.com/pwt/docker-airconnect-arm

Thanks. That will be a relief to many people.

You still running just a single S2 zone?

I am most sensitive to the zgt and avt events issued during a change of coordinator.

Thanks. That will be a relief to many people.

You still running just a single S2 zone?

I am most sensitive to the zgt and avt events issued during a change of coordinator.

Yes, I’m just running a single S2 test speaker at the moment (a Move that I bought for this purpose).

I’ll update additional speakers when I can include all the required zones, which means I’m probably going to have to suppress my gag reflex and buy a Port.

I’ve found a couple of recent threads on various home automation discussions where people are saying that everyone still works after upgrading to S2. So that’s good news, hopefully. What I really want to know, is what actually changed API-wise in S2.

Of biggest interest to me, are the “security improvements” mentioned on the press release about S2 changes. The S1 API doesn’t really have any security guarding playback monitoring and control, and I actually depend on this. A few years ago I built an embedded device that lets me use a retro Wall-o-matic to control my Sonos system. Any major changes to the API would obviously require me to update the firmware on the thing, and if I needed SSL it might push the current hardware a bit too far (or I could get lucky, and it would still work).

pwt wrote: I’ll update additional speakers when I can include all the required zones, which means I’m probably going to have to suppress my gag reflex and buy a Port.

:slight_smile: What’s the Port for? Is it wired, to enable you to get Sonosnet to isolated unwired S1 devices in a now mixed household? ... That is the issue that i think that i will have, due to internal double brick walls.

pwt wrote: I’ll update additional speakers when I can include all the required zones, which means I’m probably going to have to suppress my gag reflex and buy a Port.

It’s to replace one of my three Gen. 1 Connects, so that all of my normal household zones can be updated to S2. (The other two Connects are in my studies and can stay on S1 without annoying my wife. They’re also useful for testing S1 things.)

I just don’t like the Port: no digital optical out, no on-device controls, no 1Gps network ports, wall-wart power supply, much too expensive. Inexplicable product management decisions. Using one of my Trade Up discounts brings it down to a palatable price point, however.

This was tester error, btw. All the SoCo integration tests are passing against an S2 speaker. They’re all single speaker tests, however.

Sonos S2 supports upnp on my Play 1. You just have to enable the “Show UPnP Servers” option under “Media Servers”

I have found no change at all in UPnP between S1 and S2. All APIs and events are identical. The only difference is the swGen field in the device xml file.

Regarding “security changes”, haven’t seen anything yet, but some of the new hardware has a PIN printed on the bottom so there could be some kind of change in the future.

The official, publicly documented cloud API is still a poor substitute for the hard-to-find-documented UPnP API and hasn’t had an upgrade in a while.

Hi,

I used to play with the node.js api to display my zones and what’s playing on them, but since a while (not sure it is since I switched to S2) I don’t get any data in the queue attributes. I still can see all zones and control functions seem to be working, but no queue info.

Did you experiment the same behaviour?

Thanks,

Crilo

Did you experiment the same behaviour?

I have yet to detect any difference between S1 and S2 at the UPnP level for any normal operation. Can you be more specific about which call you are talking about and what exactly you are seeing?

Hi controlav,

I’m not a Upnp expert, but using the node.js API, when I issue the following command

 http://<node.js server ip>:5005/<zone name>/state

I don’t have any information in the currentTrack section, this used to work perfectly “before”

Note that play / pause commands are working fine with the API.

I also noted that the following does not return anything either :

http://<player ip>:1400/status/tracks_summary

Hi controlav,

I’m not a Upnp expert, but using the node.js API, when I issue the following command

 http://<node.js server ip>:5005/<zone name>/state

I don’t have any information in the currentTrack section, this used to work perfectly “before”

Note that play / pause commands are working fine with the API.

I also noted that the following does not return anything either :

http://<player ip>:1400/status/tracks_summary

I am not familiar with whatever js library that is. I obtain current track data from events on AVTransport1, and I’ve not noticed any changes in that for a very long time.

I long ago quit relying on the status endpoint for anything as it was subject to so much change, unlike the APIs which have remained pretty stable for years.

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded