I just came across this (german) article, which sounds to me as if Sonos has removed UPnP support in their speakers with the latest 9.1 firmware update - if this is the case, it would completely break the openHAB Sonos Binding.
Has anyone already upgraded the firmware and could report? All others should probably better wait as there is likely no way back afterwards…
Regards,
Kai
This may be due to their new API that is supposed to be out this month…
Yes, that’s what the article says. I don’t care about the new API, the issue is the moment when they deactivate the old one, which might be now.
I am still on the old firmware but I got an invite from the Sons Sound Platform wrt the new API.
I just briefly read the new API and this sucks big time. It is an online service using OAuth2 for authentication, in combination with a RESTful interface which allows you to do basic things only. UPNP is indeed gone, for now. Furthermore, in order to receive events, you have to HTTPS publicly routable callback URL, so OH needs to be exposed. They talk about a LAN Control API, but that is not yet published
Some excerpts:
> The Control API on the LAN is not available for wide release. We’ll add a blog post when it is available.
_> _
> Use the Control API on the cloud to communicate with a Sonos player. The Sonos cloud manages the communication between your integration and the player. Follow the steps below to get started:
_> _
> 1. Authorize your service with users to access their accounts through the cloud.
> 2. Discover households and players on available on user accounts.
> 3. Control players by sending commands through the cloud.
> 4. Subscribe to receive events about changes to the Sonos system, such as volume changes.
> Use the Sonos login service to authenticate with a Sonos user’s household. The login service uses the OAuth 2.0 authorization framework and three-legged authentication. Three-legged authentication includes three participants, the user, your integration, and Sonos. These participants interact in three stages:
_> _
> 1. Your integration sends the user to the Sonos login service with your client credentials and parameters.
> 2. The user authenticates with Sonos and Sonos sends an authorization code back to your integration .
> 3. Your integration uses the authorization code to get an access token and a refresh token from Sonos .
_> _
> Your integration then sends your access token to Sonos in every API call. When the access token expires, your integration can use the refresh token to get a new one. See the Authorize Code Grant flow in the OAuth RFC for more information.
> Subscribe to Sonos groups to receive state change events about the user’s system. For example, changes to group or player volume; playback status, errors, metadata, and playback session errors. Sonos sends events to the callback URL that you specify for your API key. Sonos sends events securely to your callback URL with an HTTP Post, with a cryptographic secret in the header for each event. This secret is also tied to your API key.
> Create a service to handle Sonos events. Your event service must:
_> _
> * Support at least HTTP 1.1 with persistent connections (“keep-alive”). This is important to maintain the flow of data going back and forth between Sonos and your client.
> * Support secure HTTP with SSL/TLS v1.2.
> * Have a valid and trusted CA-signed X.509 certificate for the DNS name.
Just looked for release notes, and on 9.1 they report only minor fixes. I guess that UPNP is still there for now but I would not bet on it 
I already updated my Sonos to firmware 9.1 and everything seems still ok.
The new upcoming (cloud) API could become a total disaster for Sonos !
I am also on 9.1:
Let’s hope they add it and keep both that and UPNP for a while to allow us time to transition. But a compulsory cloud based API would ruin it for me.
I can confirm that 9.1 is still working…at least for Play:1 and the newer Sonos One. They didn’t remove Upnp in 9.1
yeah - wonder how they will deal with latency and that sort of side effects. 
Yeah, you should kick @David_Graeff to continue on New service for providing SSL/DTLS configuration · Issue #4088 · eclipse-archived/smarthome · GitHub - but first I need him to finish up the new MQTT binding .
I’m running Synology OH 2.3 and after the Sonos update; It’s not working for me anymore. The main issues is the definition of devices have changed; specifically the sonos:PLAY1 models.
The issue comes down to this in the DEF’s of the devices with in OH and the original binding:
.things file is defined as = sonos:PLAY1:LivingRoom
Self discovered things is defined as = sonos:zoneplayer:LivingRoom
I did see their is a github fix (.JAR download) for this in July 2018 with Sonos v9 for SmartHome specific which I tried it and it failed to work on OH.
Here’s the error I get from the “self discovered” devices now in a clean boot.
2018-10-04 12:03:40.677 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while initializing handler of thing 'sonos:zoneplayer:RINCON_B8E937B8A07801400': No thing type sonos:Play1 registered, cannot change thing type for thing sonos:zoneplayer:RINCON_B8E937B8A07801400
java.lang.IllegalStateException: No thing type sonos:Play1 registered, cannot change thing type for thing sonos:zoneplayer:RINCON_B8E937B8A07801400
at org.eclipse.smarthome.core.thing.internal.ThingManager.migrateThingType(ThingManager.java:301) [106:org.eclipse.smarthome.core.thing:0.10.0.201805151356]
at org.eclipse.smarthome.core.thing.internal.ThingManager$1.migrateThingType(ThingManager.java:266) [106:org.eclipse.smarthome.core.thing:0.10.0.201805151356]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.changeThingType(BaseThingHandler.java:684) [106:org.eclipse.smarthome.core.thing:0.10.0.201805151356]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.updateSonosThingType(ZonePlayerHandler.java:2845) [210:org.eclipse.smarthome.binding.sonos:0.10.0.201805241348]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.migrateThingType(ZonePlayerHandler.java:2828) [210:org.eclipse.smarthome.binding.sonos:0.10.0.201805241348]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.initialize(ZonePlayerHandler.java:204) [210:org.eclipse.smarthome.binding.sonos:0.10.0.201805241348]
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [99:org.eclipse.smarthome.core:0.10.0.201805151356]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [99:org.eclipse.smarthome.core:0.10.0.201805151356]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Best, Jay
The 9.2 update also seems to be working fine (at least for the Sonos Play:1 and Sonos Beam) but it brings an “automatic update” setting, this looks to be disabled by default for now but it’s something to keep an eye out if they do decide to break the API.
It might be prudent to stop Sonos from accidentally updating.
Steps:
And for good measure, also block Sonos statistics msmetrics.ws.sonos.com
I am a newbie setting up Sonos (9.2) and I can’t get it working. There was no auto discovery so I manually entered the UUID for the Thing but all I get is Status: OFFLINE - COMMUNICATION_ERROR The UPnP device RINCON_xxxxxxxxxxxxxxxxx is not yet registered.
I am seeing the same thing but it works sometimes and then goes offline. I am on OH 2.2.
My problem went away with OH2.3 version.
Is there someone that upgraded to 9.3?
Is open still working with this version?
I’m using 9.3 and my One and Beam are still working.
thanks!