Skip to main content

After having played around with play.sonos.com

Tried it on ,

  1. macos
  2. ubuntu
  3. iOS, on
    1. iPad, 17.4.1, 15.8.2 - via safari/firefox -  functional
    2. iPad 12.5.7 - via safari/firefox loads, not functional

I am left with the impression that going forward;

  1. the new app has the same functionality as play.sonos.com 
  2. the app is effectively a wrapper, for the web service (API)
  3. the app is therefore limited by the lack of functionality currently available in the new web service (API)

We as users are being separated from our Sonos devices

  1. currently we connect to the Sonos device directly on our local LAN - via the app, the player/device has it’s own operating system - you can also access it either via it’s own http server or as a DLNA/UPnP media device.
  2. You can access your device on port 1400 (see https://bsteiner.info/articles/hidden-sonos-interface)

Going forward, we will access our devices via a SONOS API,

  1. access to the LOCAL device via an EXTERNAL server (SONOS corporate)
  2. We will connect to play.SONOS.com (external to LAN), who will then connect to the local SONOS device (internal LAN) - so a man-in-the-middle, round trip.

The alarm, sleep, playlist, etc. functions still exist on the actual SONOS devices - all easily accessible through the old apps.

I think this is the larger story - we get better cross platform support (win, macOS, linux, android, iOs, etc), with a unified UI/UX

However, we lose direct local access to our devices (which we bought), with a firmware update to the devices, we may well lose direct LAN access to the device

- effectively meaning we may well end up subscribing to the play.sonos.com service.

I can very well see a possible future, when we have;

  1. SONOS basic
  2. SONOS plus, with a subscription for ‘added value’ services

This seems more than an infrastructure rebuild, it seems like a re-alignment and re-tooling of the core business model and the relationship between SONOS and it’s customers.


Does anyone else have views on the recent developments? 

I’m looking forward to the AMA, hopefully we will get a chance to ask questions like this and receive open transparent answers.

This was my Impression also, especially the technical part of your post.

All those posts saying “volume slider takes ages to apply” etc. seem to confirm it.

About the Business part, only the management knows ;-)

 

For me it’s nothing I ever wanted. Where’s the benefit of controlling music from afar? I won’t hear it anyway?

I’m looking forward to a possible opt-out (doubt!) or maybe I can find correct network settings to not letting Sonos call home.


Hi,

You are sketching a dark scenario but a real possible scenario. It is consistent with the trend to put everything in a kind of paid service; from streaming music and movies, added functions in your car etc. For me it is clear Sonos is moving to a ‘all online’ service. Local libraries? Sonos can not earn money over our local libraries. But they can over all data they have from customers. And who has the data, gets the money.

If this is the direction Sonos is going, well, no additional Sonos gear for me. I'll isolate my Sonos from internet,, keep the current firmware and use Music Assstant (Music Assistant (music-assistant.io)) combined with Home Assistant to access my Sonos. And of course the S2 app as long as it works.


I am left with the impression that going forward;

  1. the new app has the same functionality as play.sonos.com 
  2. the app is effectively a wrapper, for the web service (API)
  3. the app is therefore limited by the lack of functionality currently available in the new web service (API)

We as users are being separated from our Sonos devices

  1. currently we connect to the Sonos device directly on our local LAN - via the app, the player/device has it’s own operating system - you can also access it either via it’s own http server or as a DLNA/UPnP media device.
  2. You can access your device on port 1400 (see https://bsteiner.info/articles/hidden-sonos-interface)

Great analysis, neilmcg, your thesis holds water! One user pointed out that the new app functionally froze up during a 4-hour internet outage, which jibes with the architectural switch you outline. It also explains the variable responsiveness of the new mobile app, likely due to overloaded Sonos servers now being in the loop.

Observation: this “out and back” architecture is extremely common in IoT/smarthome devices. Nest and Ecobee thermostats, for example: the controller app on your mobile never communicates directly with your thermostat, even when they are on the same subnet; the controller app talks to a Nest/Ecobee server and the thermostat polls said server. The model works reasonably well > IF < there is little data passing back and forth and latency is acceptable.

On the other hand, the model works far less well if more data (think album art) is passing back and forth and latency is a problem (lagginess changing volume, for example). I fear this new system architecture makes it VERY hard to deliver a great user experience (UX).


And another user blocked *.sonos.com on his iOS device (thru AdGuard Pro) and found the new app is unable to load anything other than what’s playing at the moment.  I did the same with the old app and everything basically worked.

This is clearly Sonos’s strategy


I’ve taken snippets from the AMA that I believe are relevant to this thread.  All answers, understandably, from Diane.  I’ve posted this on the retated thread covering the same topic

 

Are you able to explain why Sonos decided to make the app cloud-based, what are the advantages apart from extra latency making the app seem slow?

There are many advantages to using the cloud, but I’ll highlight one. With our new content services, we are able to provide a richer experience for discovering music to listen to. Our previous app was built on APIs that did not provide enough metadata to make that rich experience. 

It’s also important to note that the app is not exclusively cloud-based. We still interact with the speakers on the local network, similar to the old app. We will be continuing to fine tune when we use cloud or local APIs. And we are already working on performance enhancements across the stack

 

I noticed that the re-introduction of alarms actually required an update to Sonos devices as well as the app today. Does this mean that the new UI revamp was in fact much more than just a revamp to the UI? Are there currently bigger changes happening on the device side as well?

The app is definitely a revamp, but it’s not just the UI that changed! This new app is using new features on the speaker firmware and new cloud services as well. Let me share a bit more about what happened with alarm settings. 

On the morning of the app launch, we discovered a data corruption error around the new Alarms APIs. The corruption could cause alarms to go off in the wrong room at the wrong volume with the wrong content! In order to save your alarms, we made the difficult decision to remotely disable the alarm settings feature and then completely lock it out. It allowed us to make sure your alarms stayed as they were - but at the steep cost of taking away your ability to change them yourself.

 

i almost always use my Sonos devices in groups, and with the new app, handling of group volumes is worse. Not only does it not change in real-time like the former app, you end up with a UI pop-up on top of the volume slider I am using to adjust the volume. 

A key part of this new app was using the newer Sonos APIs, which means we did indeed rewrite the volume experience entirely.  Until this new update, our app was using an older set of technology based on UPnP and SOAP.


 

I think this is the larger story - we get better cross platform support (win, macOS, linux, android, iOs, etc), with a unified UI/UX

However, we lose direct local access to our devices, with a firmware update to the devices, we may well lose direct LAN access to the device

When Diane said that about corrupted alarm data, it made sense and points towards my suspicion about config file off boarding from the device.

Previously alarm data has resided on the actual SONOS speaker, i.e. within our own LAN.

How could that be corrupted on everybody's own speakers, before the launch -- forcing them to drop the feature?

Looks like SONOS dumped all that data into their servers - so it now resides outside.

That dump was corrupted.

It would make sense that they then issued a firmware update, it’ll be changing how and where the speaker looks for the alarm config file.

I see the latest update supports Apple Music Lossless, however I don’t see any release notes for the last firmware - so can’t conform beyond much more traffic between my LAN and SONOS subdomains.

An accurate changelog for the firmware would be informative.


 

How could that be corrupted on everybody's own speakers, before the launch -- forcing them to drop the feature?

However given Apple’s Appstore review process and timings - it seems unlikely that they would have been able to pull the app and resubmit it the night before.

  • Diane’s story becomes more questionable.

When I go to About My System in the PWA it doesn’t show the IPs of my sonos devices so it feels like the PWA isn’t communicating with the device on my local network when it could. Unless the service worker is doing some magic and it’s just a UI thing.

 

I’m going to run a proxy to see what the iOS app does and if it’s calling anything other than play.sonos.com. I was having issues with the volume the other day where is was so laggy it was unsuable. Maybe that’s why they took the volume numbers away as users would be sending too many requests tweaking it to a nice number like we all do 🤣

 

I can understand that the current architecture must be frustrating for sonos where they have to support a huge mix of device versions, app versions and this may lead to elongated support and make it hard to move faster and they are probably spending ages and loads of money on customer support. By routing everything though play.sonos.com they can just put any mapping centrally and move quickly.

 

Might be completely wrong on all of this but this is the internet, I’ve seen people be wrong before!