Myth 2: Sonos doesn't have an open API

This myth is usually repeated in several different forms, including "Sonos has a closed API" and even "Sonos won't let you use it's proprietary API".

I have heard these statements from people who claim to be "integrators" when what their job title should really be "installer" (they wouldn't know what integration was if it hit them in the eye).

I have heard this from ignorant people who assume that because there aren't dozens of Sonos apps written by third parties that this must be the reason.

I have heard it from fans and employees of other vendors who are trying to spread FUD about a competing product.

The bottom line...
It isn't true!


The Sonos control API is based on UPnP which is one of the most open commercial home control protocols there is. All of the specifications can be downloaded for free from www.upnp.org.

Furthermore, much of the functionality is based on UPnP-AV, which is the AV specification from www.upnp.org. Again, the specification documents for this are available free of charge from www.upnp.org. Here's an example:
UPnP Device AV Architecture 1.1

With these specifications, and these specifications alone, you can perform a whole host of activities with your Sonos setup including:

• Getting a list of devices on the network, their name, device type, IP address, etc.
• Getting the "tranport state" of a Sonos zone (whether it's playing, paused,. etc.)
• Getting track information about what any zone is playing, including cover art (if available)
• Setting a track to play, or pausing it on a specific zone, or all zones.
• Changing the volume,muting and unmuting on any zone
• Browsing the Sonos index by Track, Artists, Album, Folder, etc.
• Browsing Sonos playlists
• Seeing changes in the status of any zone, such as the player changing from paused to playing

That's a pretty good range of integration capabilities, right?
On top of that, there's a range of Sonos-specific capabilities that, whilst not standard UPnP, are published via the UPnP interface. That means they are visible to end users and some idea of how to use them is presented. Most of these are fairly obviously named so it doesn't take much more than a little experimentation to work out how to use them. It would be nice to have documentation, but as none exists part of my aim here is to use this blog as an unofficial documentation of some of these features, as and when I get around to addressing them.
The sort of things that are available:

• Adding songs to the Sonos queue (note you can play tracks using standard UPnP-AV, the queue is slightly different)
• Setting alarms
• Grouping and ungrouping zones, and seeing how they are grouped
• Creating Sonos playlists
• Changing Sonos device configuration (e.g. Line In settings)

As I say, I'll try to address these eventually in this blog, but it's totally subject to my personal time, so it might be a while off.

One area which really could do with some more documentation is Music Services (more recently this includes radio as the radio service is provided by TuneIn). The trouble is many music services have their own API which Sonos hooks into to use them. This API is the property of the music service and,even if they wanted to, Sonos could get into contractual problems with their partner if they publish it. I'll try to illustrate some of these as I go along, but bear in mind I don't have access to all of the music services so I can't cover all of them.

These generally work in roughly the same way:

1. use music service API to log in and browse music service
2. Use UPnP to push selected tracks to Sonos queue (as normal)

More recently Sonos have announced a standard integration API for music services. I think this is a smart move as most music services have yet to develop their own streaming API. By providing a free, open API standard which makes it easy for services to build a streaming interface to their systems, and therefore to reach Sonos users, this should escalate the development process and may lead to a more standardised streaming service interface across the industry.
In theory this should make control app development easier, as the interface to control external music service access should be more standard.

Integrating with Sonos

As an active participant in the Sonos Forums, one of the subjects I come across fairly often is the subject of integration.

I should mention that IT integration, in general, is a subject I'm pretty familiar with: one of the major roles I have performed over the years is as a System Architect overseeing the design of operational systems for large telecommunications companies. Such systems usually comprise a hotch-potch of systems operating to different standards, to different data models, driving different operational processes. There is always a mixture of legacy and new. In fact the normal driver for the work I do is the introduction of a new system, new piece of technology, new process, etc. and the need to slot that as seamlessly as possible into the existing mess.

I will also mention that, as part of this work I often have to "roll my sleeves up" and actually get down and dirty with the integration. I am a competent and experienced developer in a range of development languages, including Java/J2EE, PHP and Perl, and have developed integration adapters for a range of systems, APIs, and protocols including XML, SOAP, JMS, HTTP, CORBA, and TMF standards (TMF814, TMF854).

Boasting aside, the point is, I understand this stuff pretty well!

So, being a long time Sonos user, I get pretty interested when the subject of integrating Sonos is discussed. Part of this is because, most of the time, it's spoken about with apparent authority by people who haven't got the first clue about the subject. Many of these are people who think they understand computers because they know how to use one competently. They think that, because they wrote a spreadsheet formula or a DOS batch script once, they are qualified to to authoritatively about professional software development. Worst still some believe such limited experience qualifies them to dismiss the views of highly experienced software professionals.

There are also a lot of industry observers and vested interests who like to put two and two together to create something much larger than 4.

The result is: a lot of bullshit is written about the ability to integrate Sonos with other systems.

I should point out that I do not, nor ever have, worked for Sonos. Nor do I have any financial or other vested interest in the company other than being a happy customer. There are people who try to suggest otherwise: they are bullies and idiots.

What i will attempt to do in this, my personal blog, is to dispel some of these myths. I plan to do this partly by using actual code showing that it is possible to integrate with Sonos using the UPnP API which it largely conforms to and uses.

Note that, at least to start with, the development platform I am using is C on Linux using the GUPnP Libraries which are readily available on a range of systems and languages, and are normally bundled with most Linux distros. It's important to realise that, despite a significant background in software development, I'm not normally a C coder. I would describe myself as adequate at best. Any code examples I post are to illustrate something as clearly as I can. Sometimes (and my lack of skill) this gets in the way of the examples being "good design". On that note I'm happy to take recommendations from others as to how to improve this code, as long as it's not at the expense of the educational value.

It's also important to realise that this is only one of a large number of permutations of hardware platform, OS, development language and library. There are literally dozens more. I can't cover all of them, but the principles I show here should be roughly applicable to other environments.

With that I will dispel a myth:

Myth 1: Sonos needs to release a SDK to support integration

This is a myth for two reasons:

1. An "SDK" will target a specific environment, and there are two many variations to support even all of the "popular" ones. An SDK which is deigned for, say, Windows using C# and .NET libraries won't be at all useful to an iPhone iOS developer, or to a Mac user. In fact, many of the systems people want to integrate with (for example Russound or Control4) are not based on conventional PCs. Such an SDK would do nothing to support integration with those environments.
2. There are already plenty of SDKs available. Any UPnP client library is, in fact, a Sonos support library, because the Sonos control protocol is compliant with UPnP. In fact, much of it is compliant with UPnP-AV which means code you develop for many Sonos functions will also control any other UPnP-AV media device. As I said, I'm using GUPnP, but I could easily have used libupnp or Platinum UPnP or Cyberlink and that's just some of the options I have in C. If I was using a different language I would have a different choice.

So, whilst in some circumstances I can certainly see some benefit in Sonos providing some additional development support, it's a nice to have, not a "need". This myth is spread by people who are either too lazy to check facts, ignorant of how software development works, or who just like slagging Sonos off. Sometimes it's all three!

Back to the subject, some of the code on this blog is based on code originally published in the Sonos Forums under the heading "Developer's Diary" (the subject line has now been changed to "Exploring the Sonos control API"). I have decided to focus my attention to posting in this blog for several reasons. Firstly, the Sonos Forums are largely made up of "end-users" whose only interest in development is the possibility they might get some cool free apps. There's nothing wrong with that, but it does mean that there were actually very few people who were genuinely interested in writing code of their own. I actually had someone quite aggressively querying why I was posting such information on the forums, and another couple who used it as an opportunity to make less than complimentary remarks.
Secondly, there wasn't enough space in a post to adequately cover one topic, so I found I was splitting articles up into multiple posts. Also the formatting options available are limited.
Finally, this is my blog, so I can post what I like. On the forums, as a volunteer moderator, I'm the target for all kinds of hate, abuse, and attempts to suppress my views. Forums are, by nature, more public. People join the Sonos forums for community support and discussion. In general they don't want to see fights and so I largely have to toe the line. As such, suggesting people are idiots (even if they plainly are) is likely to start a fight which is not conducive to a pleasant forum. On here, I can say what I like. If you don't like it, go somewhere else.

On that final note, if you're not happy about anything I post here, then here is the place to complain, not on the forums. This blog is deliberately separated from the forums and is nothing whatsoever to do with them. Attempts to use content on this blog to attack me on the forums will not be tolerated. As Wil Wheaton so beautifully put it: "Don't Be A Dick!"