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.

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.

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.

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!