Sounds plausible. I just blocked *.sonos.com on my iOS device (thru AdGuard Pro) and the app is unable to load anything other than what’s playing a the moment. Don’t know how this worked before but I always assumed the app connected to the speakers and the speakers in turn connected to the web to fetch data instead of Sonos data systems pushing it?

I want to be able to control who and what reaches into my home through a fiber cable and Sonos isn’t on my list. This would seriously mean a huge breach of trust and privacy, without any warning in advance. Surely they can’t mean this? I was on the verge or setting up another system in a second home but will postpone for a while until things have cleared up; it’s all speculation for now.

Great analysis, cpalmer74, 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).

The only thing I can possibly hope for with this web-control thing is that Sonos is planning on releasing a hardware device which provides a local web server and the control app. This could actually be a real win for the user as it would allow us to control the local system without needing an app (good for guests!), and would tie in very nicely with home automation systems.

But I agree that this is unlikely. Corporations seem to believe that there’s a lot of value to be gained by running everything through their servers.

While it’s true that a lot of IoT devices use this approach, there are also plenty that use a dual approach of having local control while still providing cloud-control when and if you want it. I don’t mind this so much as long as my system is entirely functional without requiring a round-trip to the internet. It’s very possible Sonos could go down this road, and I hope they do.

I tested the old app behavior when blocking *.sonos.com. Played around a bit, I found that almost everything worked.  I did find one hiccup.  When I use spotify connect on another device, and then block sonos.com, I can’t access spotify on the blocked device, even after disconnecting from connect.  Renabling *.sonos.com resolves this issue.  It appears the old app may occaisionaly need to “phone home”.  But it’s rare.

Seems like OP’s hypothesis is true

Here is the original thread:

 I like to think positively for as long as I can.  Dreams can come true.

Yes they do.  The value is convincing shareholders of the long term potential for monetization.  Imagine being able to charge $0.005 per stream.  The market value pecking order is usage base > software subscription > software purchase > hardware purchase.  Sonos right now is a hardware company.  They want to move up in the pecking order.

I hope they do to.  I guess we’ll see.

This would also mean they can easily roll back the app to v16.1 while keeping play.sonos.com in the air, adding back missing features, until such time that there is feature parity between the old and new environment. Only at that moment it would be appropriate to introduce a new app.

Actually I suspect this explains why they have not rolled the app back already.

If they have moved data from the local speaker network to their servers then it is likely that they have not made provision to keep that data in synch between the local and server copy and have not created a plan to merge any changes in the data that have been made on the server back to the local as part of a fall back.

Whilst I am sure that most of us users would be happy to revert to our data as it was on the 6th May I suspect there are customers that would find this problematic. Note that a global failback is a very different scenario to users using the .apk to revert to the old version.

Failing back would also assume that the data is still in place somewhere. It is possible that Sonos deleted this data from some systems once the update completed and the data was “safe” on the server. Most likely on older speakers with less memory available.

Another complication would be the way that the data is stored on the server as they may have reformatted it to optimise server performance.

As this unfolds it seems what they have not told us so far will be more worrying than what we already know.

In that scenario I would be unable to use the v16.1 desktop app on my Mac? Unless they moved some but not all of the users over, or halted somewhere when this unholy mess unfolded and are now clueless how to solve it. That would not be very reassuring either ;-)

This big of a change should have been communicated in technical terms and highlighted in updated privacy policies etc.
It should have been a new S3 app, and S2 should have gone into maintenance mode. That however wouldn’t have got Sonos the numbers high of users on their new system for their shareholders.

Running all that data on the cloud is going to cost money, which they will want to recoup from their customers, but who will want to pay a subscription, when we aren’t gaining anything? We had working systems before v80 that didn’t lag due to the round trip to a data centre!

Connected thermostats and cameras make sense, as you want to be able to view/adjust remotely. Speaker systems on the other hand don’t make sense, maybe apart from the headphones no one wants. However Bluetooth works perfectly fine, and not locked into an ecosystem. I don’t get the headphones USP!

I’ve taken snippets from the AMA that I believe are relevant to this thread.  All answers, understandably, from Diane

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. 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. Looks like they data 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 - that would be informative.

Yes, those headphones. If you are out of home and want to listen to music, it may be difficult to get access to the music on your home NAS - making up a good explanation for killing the functionality of playing music from that one.

Like so many IoT devices, our Sonos devices are now prone to hacker attacks to a much higher degree than before, and our data, being kept in an unknown server space somewhere in the world can - and probably will - be stolen by hackers even from that space. Including user names, personal information, passwords, etc., but maybe also such information as home infrastructure (connected devices to the home network), that could be interesting for burglarers.

I think that this whole scenario and its perspectives will make me switch off all Sonos equipment for good, right away.