Why Sonos Maintains a Closed Architecture

I don’t know why you keep referring to using keypads.  That would merely be a side benefit, and a very basic one at that.  I think most of us would like to be able to control Sonos from a 3rd party touchscreen, as if it’s one more source on the system.  And there is no reason whatsoever that such an interface should not be able to perform as beautifully as the sonos (which I agree IS a great interface).

Likewise, I’d like to be able to have actions on the Sonos controller trigger other actions.

With regard to your statement that the lack of integration is due to the lack of capability on the integrators behalf, it’s a non-starter.  That’s like blaming integrators for not being able to control a lighting system from a manufacturer that refuses to release the RS-232 protocol.  After all, it is *possible* to use a packet sniffer and figure out the protocol, right?

“I’m not saying integration is always pointless, just that a lot people’s view of what that means and how useful it would be in reality is naive and misguided.”

I don’t disagree but when isn’t that the case ?

I suspect it’s the case a lot of the time. I believe there are very many cases where people overestimate the benefits of certain types of integration.

I think this is especially the case on comment threads like this one.

“If only we could integrate this into our current system, wouldn’t that be cool and awesome?”

In a lot of cases the real answer is a resounding NO!

(I believe that’s part of what Loren was trying to say).

I’m guilty of this myself. I’ve wasted hours on trying to integrate something simply because I could, or thought it would be cool, or the right thing to do or because conventional HA wisdom told me I should and then have been massively underwhelmed in the end result. And professional installers are motivated by paid work. If someone insists on having something dumb and is happy to pay for it, why would the installer argue?

I think one thing that the HA/Integration industry often forgets is the usability aspects. I still recall that episode of The Osbornes with Ozzy randomly pressing buttons and swearing at his brand-new integrated HA/AV system controller.

I believe one of the things that makes Sonos a great system is that they get this useability aspect in everything they do from ease of setup, through everyday use, even to a support experience that’s head and shoulders above the alternatives. The Sonos benefit is that it’s a great system to use and people love to use it. If you force it to be used through another system’s interface and you are highly likely to lose most of these benefits. The biggest problem with integrating a control interface with Sonos is not the technical aspects like protocols, but making it as useful and usable as Sonos’s native interface.

What I’m saying is I think the calls for integration with Sonos often come more out of of a knee-jerk reaction than a rational need. I think the perception is very different from the reality.

It’s like the old HA chestnut about controlling your coffee-pot so you can put the coffee on when you’re on the way home. It sounds cool and great, but is mostly useless and impractical.

Majik,

Comments after each of yours.

“I think one thing that the HA/Integration industry often forgets is the usability aspects.”

Actually, usability is usually THE driving factor for good integrators, so maybe you are hanging out with the wrong people .  Usability is WHY this integration should exist!  However I agree with you that there are people who get it wrong.

“If you force it to be used through another system’s interface and you are highly likely to lose most of these benefits.”

Not necessarily, however yes, that is a possibility.  Which is why if they open their systems up it would also behoove them to take steps to help maintain the user experience.  For instance, they could create a module and a GUI for Crestron and AMX.

“It’s like the old HA chestnut about controlling your coffee-pot so you can put the coffee on when you’re on the way home. It sounds cool and great, but is mostly useless and impractical.”

Your analogy is questionable because you pick one of the most ridiculous integration examples possible and then compare it to an instance in which integration would instead make great sense.  If I have a 15” Crestron touchscreen and I have a Sonos system, it makes great sense to be able to access that Sonos system from the Crestron touchscreen.  In fact, the two could beautifully compliment each other.

“Not necessarily, however yes, that is a possibility.  Which is why if they open their systems up it would also behoove them to take steps to help maintain the user experience.  For instance, they could create a module and a GUI for Crestron and AMX.”

Firstly this statement is based on a premise which is wholly incorrect. The interface is already open. 100% of the basic functionality (volume, transport, getting information on current track etc.) has been available for years in openly published specifications.

Secondly, how are Sonos supposed to develop modules for this without AMX Crestron, or whoever’s support? To make this work properly, without ruining the user experience, requires more than a little macro programming. It requires the sort of development that simply isn’t possible by third-parties on many of these systems either because the vendor keeps this sort of capability inhouse and protected, or their system simply is incapable of supporting it.

If you had read the article properly you would notice that the Extra Vegetables development was mostly dependent on AMX providing capabilities on their system to support the Sonos integration.

“Not necessarily, however yes, that is a possibility.  Which is why if they open their systems up it would also behoove them to take steps to help maintain the user experience.  For instance, they could create a module and a GUI for Crestron and AMX.”

“Your analogy is questionable because you pick one of the most ridiculous integration examples possible and then compare it to an instance in which integration would instead make great sense.”

In your opinion.

You make it sound like it’s a “no-brainer”. It is not.

Whether it makes sense or not depends almost entirely on the execution, and this is mostly dependent on the ability of the developer/integrator to deliver a user experience which isn’t significantly degraded from the Sonos one. I’ve seen various attempts at this in the past in some of the many open source projects that exist (a fact which exposes the lie that Sonos don’t have an open API) which allow me to control Sonos from my mobile phone, my PSP, my TV, etc. Although these tools have their merits, In practice I’ve yet to find anything I would use instead of grabbing a nearby Sonos controller.

“Your analogy is questionable because you pick one of the most ridiculous integration examples possible and then compare it to an instance in which integration would instead make great sense.”

It depends. It depends on the implementation and it depends on the use.

And I used that example because it’s an extreme case, but you chose to focus on the fact that it’s a ridiculous example. Consider that, to people new to HA, the coffee pot thing sounds pretty cool. My point was that there’s a lot of “that sounds pretty cool”, which doesn’t actually stack up in practice.

As for your touchscreen, I agree that being able to execute “macros” for preset scenes would be very useful. It’s probably useful to have some basic zone transport/volume control as well. Would it make sense to replicate the full Sonos controller into the Crestron interface? If it could be done, then I’m sure the answer is yes. There’s not really anything stopping it happening from the Sonos side.

“With regard to your statement that the lack of integration is due to the lack of capability on the integrators behalf, it’s a non-starter.  That’s like blaming integrators for not being able to control a lighting system from a manufacturer that refuses to release the RS-232 protocol.  After all, it is *possible* to use a packet sniffer and figure out the protocol, right? “

No it’s not at all. It’s like blaming the integrator because they don’t understand how to wire the RS-232 up and configure the system to send commands using a protocol WHICH IS PUBLISHED. This sort of thing is an integrators job. If they can’t do it then I would question their competence.

Now the Sonos control protocol (which, mostly by the way IS PUBLISHED AND OPEN) is more complex than a simple RS232 command/response protocol so it requires more skill to integrate. But it’s complex for a reason: Sonos does more than most other systems and most of this functionality is exposed via the control API. I can appreciate this is beyond many integrators who don’t actually do any real software development of their own, but that, again, is pointing to a lack of capability in the integrator, not with Sonos.

There’s dozens of different systems out there. Sonos provides an integration API, the key parts of it are documented. It just needs someone to glue the pieces together. I would argue that’s the role of either the integrator or the vendor of the system that claims it can integrate with everything. Have you asked Crestron why they’ve not created a Sonos control module?

The guys at Extra Vegetables get it and increasingly so do AMX, Phillips, etc.