I’m not sure what is different about today’s message, other than tone. They will still require splitting legacy and newer products into two different systems. That means no whole house system. They will still offer a modest discount on new speakers in exchange for bricking older ones. Today’s email seems like a crisis management response that doesn’t really address the bigger issues. Have they attempted to make older and newer products work together, even if they have a slightly different code base? Or are they simply not going to put the money into trying? At this point I will continue using the 7 Sonos speakers I have, but I will not be buying more, nor will I be recommending Sonos to friends.

What’s seems different is this:

Secondly, we heard you on the issue of legacy products and modern products not being able to coexist in your home. We are working on a way to split your system so that modern products work together and get the latest features, while legacy products work together and remain in their current state. We’re finalizing details on this plan and will share more in the coming weeks.

What I hope this means is that the split system can still function as one system in terms of streaming the same music. In essence, sharing the least common denominator of features. If they do that, then honestly, I will be happy.

If it was just the same plan as before, it wouldn’t require additional engineering.

You do not have to split your system in two.  You can use all the units with legacy software, keeping the full functionality you have today.  You just won’t receive new features, but you will get bug fixes and security updates.  That was the new thing announced by the CEO.  

It is technically impossible to make old software coexist with new, so these are the next best choices.  

Jgatie how do you know “It is technically impossible to make old software coexist with new, so these are the next best choices”

It may be hard or expensive or time consuming (or it may not) but why impossible?

...but the more I read it, the more it seems like the same BS, repackaged in a nicer tone. :P

Here’s one reason:  Sonos often makes changes in their WiFi communications which makes adding an older unit to a newer system via WiFi impossible.  You must connect it via Ethernet to add it, then it must update to the current software.  If you allow new units to be on the newest software and old units to stay on the old, this difference in communications makes them incompatible.  So you are going to say “So don’t make the changes", well some of those changes are wholly necessary (otherwise, why make them?) and the software cannot bring new functions, security, features, etc. without them.  This is just one instance where the differences between old and new software makes running them concurrently impossible.

Here is the latest for folks that want to see what is going on

https://blog.sonos.com/en/a-letter-from-our-ceo/

and we are not taking anything away

Unless the legacy speakers can be grouped with the current speakers, then they are absolutely taking something away. So...

He doesn't know what is impossible because he doesn't work for them. He is only speculating like everyone else. 

“Impossible” is a pretty strong term when it comes to software.

So how would you solve the scenario I posted above?  

Nothing here that cannot be worked around in software, unless they change L1 standards, in which case a whole bunch more kit is about to get relegated to legacy status.

As you and I have discussed in the past, the obstacle here is one of Sonos choosing not to make the investment in a system architecture that can accommodate different protocol versions simultaneously.

I do not think there’s any chance they are going to reconsider this stance, but in making this choice they’ve made a one-time-only transition from a company that keeps all of its player hardware working well together to a company that sells hardware with a limited lifespan of full support. For me, that has fundamentally altered how I see Sonos products.

It’s not clear to me what your problem statement is. What you describe is a scenario that I’ve never seen even on very old Sonos components, but it seems to describe the inconvenience of requiring a wired network connection when adding very old components to a WiFi setup. Nothing in there says the players can’t talk to each other once it is set up or updated. So what is there to fix?

How would I solve this problem in general? Using a bridge device between old and new, that merges the old network with the new one. I seem to recall Sonos having some sort of device that glued a home, wired network to the wireless protocol used by the first gen of players. It was a Sonos bridge device of some sort. I can’t remember its name exactly….Sonos something...

I think people are a lot more surprised than they ought to be, this strikes me as being a fairly predictable issue with any ‘connected’ devices in modern times. You used to buy an amp, which might run for decades, but you only got a 12 month warranty - no ongoing service of any kind. Here we are asking a company to continue delivering a service indefinitely, for no fee (save being baked into the cost of the product). It was probably hubris to imagine they could do this in the first place, it’s not a scalable business model. Maybe we will see a shift towards subscriptions for connected devices in future.

Yes, as another poster said, impossible is a very strong term in software… the core technology of value here is the SonosNet bit that syncs all the devices so well, and it is hard to imagine that needs to change much. New products might want to support higher bitrates or codecs or somesuch, but they could also be designed to support the older protocol and continue to work, albeit by downgrading themselves to the lowest common denominator in any given system.

However continuing to support increasing lists of legacy devices in a single codebase does become harder, more error prone, and less fun for the people doing it. Software definitely has a shelf life.

If the old software cannot communicate with the new software unless it is wired, and you can’t update legacy units with the new software, how are you going to use it wirelessly? 

And that “Bridge” would need to process 32 different streams at once in order to accommodate the maximum number of Sonos devices.  I’m not sure (if it is even possible to build) that the cost would be something that wouldn’t reach a level of uproar equal to the current level. 

Right. The choice was made.  That’s the reality now.

I personally see every connected hardware manufacturer heading that way, unless they can charge subscription… and even then…

If they put sufficient resources into maintaining support for every legacy unit, a competitor with no legacy devices will be quicker to market with new ranges and features, so they lose share, then have less resources to continue supporting old devices that don’t create revenue, ad mortem.

The bolded is exactly what Sonos is doing.  If a legacy device is the lowest common denominator, you are downgraded to legacy functionality.  

The announcement is a mere rewording with a softer touch. 

In what way?  The original announcement said there would be no updates whatsoever, thus bugs were not going to be fixed, security was not going to be enhanced, and service changes would cause loss of that service.  Now those things are going to happen.  Not a “rewording” to me (and is most certainly a large number of manhours to develop and test these things in the legacy software that they were not willing to spend before).

Now you’ve lost me. Are you saying that this happened before, and Sonos made products that only worked with wired connections? Or are you speaking hypothetically?

What, exactly, and I mean specifically, is the issue you are referring to? And how, exactly, is wired-to-wireless bridging an unsolvable problem?

Just like the Sonos Bridge used to do, you mean? And how all Sonos products work today? (If you want 32 legacy components each receiving a different audio source then maybe Sonos isn’t the right solution for you. There can be reasonable limits on something like this.)

Why do you think this is a problem? That is how they work now.

Look: a Sonos group has a master and a bunch of slave members. The master pulls in the source stream that you have selected, either from an Internet service, your local music library, or the line input in back (if it has one). That stream is then decoded to audio (unless your source is the line in, in which case, the audio is already there), and then re-encoded for broadcast to the other players in the group along with some metadata that allows the players to synchronize the playback. Those players then decode the audio stream they are receiving, synchronize it with their clocks, and then play.

Sending audio streams around wirelessly has not suddenly gotten more difficult. What has changed is that Sonos wants to do more with their components. Fine. So let them play in the same sandbox. My legacy devices can’t be the master if I want NextBigThing audio stream, but they can still play audio that comes from somewhere else. That’s an acceptable solution to me.

If Sonos wants to update their whole wireless protocol to use something other than WiFi someday, then sell me a bridge device. Or, put the bridging capability in another component (see, for example, the Sonos Bridge: you didn’t need it if you had a Connect or a Play:5, for instance). Or do both. Don’t care which.

I get that Sonos is a business and they’d rather sell me $2000 of new equipment, but what a business wants to do and what a consumer is willing to do are not always aligned. Sometimes, they are very far apart.

People are asking for a mixed service level, not a global downgrade. Is it harder to do? Yes. Is it unsolvable? None of us know, obviously, but given how the products work today the word “impossible” is pretty extreme. It might not be as smooth of an experience as we have today, but those of us on legacy components can figure it out.

Not at all what I said.  Here’s what happens:

You buy a Sonos device that has sat on the shelf for a few software updates.  So its software is out of date, which is akin to “legacy” software.  You take it home and try to add it to the system, and it sits there and blinks at you.  This is because there were some changes to the wireless protocols that are preventing it from connecting.  The standard response when someone ask for help with this scenario is to connect it via Ethernet, add it to the system, let it update to the new software, then disconnect it and it will run wirelessly.

But by definition, the legacy units are always going to be on legacy software, they can’t be updated.  So when the new software makes a protocol change, there’s no way the wireless legacy units are able to communicate.  Even more extreme, very out of date legacy software (and remember, people want their legacy units to work for a long time!) sometimes can’t even connect using Ethernet, they need Sonos support to intervene.  

There’s a difference between a simple network device that just passes data like a basic switch, and one that has to translate the protocols from legacy to modern or modern to legacy for 32 streams at once.

Again, so what? There’s update/install, and then there’s playing audio throughout the zones. I admit that procedure sounds irritating, but playback sounds unaffected. What problem am I solving? Sounds like there’s already a solution to me.

So support a reasonable limit if 32 is too big.

You don’t get it.   There is no update/install, because legacy units, by very definition, have to stay on the legacy software and there is no support for the new protocol changes on the legacy software.  They are stuck with the old software that has no way of connecting to the new! 

These aren’t just audio players, they are smart speakers that need to communicate with each other, and they do that through proprietary protocols that are subject to change.  Change the protocols on one, and you need to change the protocols on all of them.  If you can’t change the protocols on the legacy units, the legacy units can’t talk to the modern units.  If they can’t talk to each other, they can’t play audio together.   They are effectively a split system. 

The system supports 32 separate streams.  If you truly want what you have now to work with the stuff in the future, you need to process 32 streams.  Anything else is just bargaining away the facts, a very bad thing in computer science.