Sonos with node.js, my attempt!

I've submitted a pull request for to correct my (dumb) mistake. Hopefully it'll be accepted soon, and you'll be back in business.

Sorry again.

Excellent - many thanks Matt and Jishi:D

If you want to try out the mobile version, you can pull the "mobile" branch from sonos-web-controller, or download this:

https://github.com/jishi/node-sonos-web-controller/archive/mobile.zip

then visit http://IP:8080/m from your mobile browser. Only tested in Chrome for Android as of now. You can also try the "Add to homescreen" feature, which would open it up fullscreen.

Today only prev, play/pause, next and group volume works. And it will control the first zone that it finds, no way to select.

Thanks for your work. I've been using AirSonos for a couple weeks, and its awesome.

Thanks, but I can't take credit for AirSonos, haven't been involved in that at all. Looks really neat though!

Hi,

I've been working on a little project recently and I've been using the node-sonos-discovery module to handle Sonos events. (Thanks for creating it, BTW, it's fantastic!) However, I think I might have found a small bug ...

During development, I stop/restart the discovery code many times, and it sometimes fails trying to subscribe to UPnP notifications. I see the following error in the console and then the discovery service just hangs:

{ [Error: connect ECONNREFUSED]
code: 'ECONNREFUSED',
errno: 'ECONNREFUSED',
syscall: 'connect' }

After poking about in the sonos.js code I discovered that it was trying to subscribe to events from my Phillips Hue Bridge! Here's an example of the response received:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.108:80/description.xml
SERVER: FreeRTOS/6.0.5, UPnP/1.0, IpBridge/0.1
ST: upnp:rootdevice
USN: uuid:2f402f80-da50-11e1-9b23-0017880a2371::upnp:rootdevice

I might be wrong (I'm not experienced with UPnP), but I assume that the variable PLAYER_SEARCH that is broadcast is intended to filter so that only Sonos devices respond? Maybe this isn't working quite as intended.

I've managed to work around this issue by hacking the code to check if the response contains the following string

urn:schemas-upnp-org:device:ZonePlayer:1

and ignoring any that don't. Not sure if this is the best solution though!

Anyway, thanks again for a great module and I hope this feedback is helpful to you!

You are correct in the assumption that I only scan for devices matching the correct ST, and this has always worked on my network. My best guess is that the Hue does not respect this and replies anyway, in violation to specs.

With this in mind, it would be wise to check this on replying devices as well. If you send me a patch I will review it and merge it. Thanks for sharing the discovery, this might probably happen with a few other devices.

Thanks for the response!

I've forked the project, and I'm currently testing my patch in a branch.

Once I'm happy, I'll submit a pull request for you to take a look at.

OK - pull request sent!

Thank you very much! Hopefully this resolves this issue for a few users.

I have a quick question, if that's OK? I notice that if I create a stereo pair from two speakers I get 4 topology-change events in quick succession (although not as a contiguous block - there are also some volume and transport-state events mixed in with the topology-change events.)

The events seem to be identical, so I can't work out why there is more than one! For instance, grouping the speakers creates just a single topology-change event, as I would expect.


No, never experienced that. Haven't tried the stereo pair though. However, receiving multiple topology events at a rapid rate is a "normal" scenario, I think that if you "ungroup" players you will get that behavior.

I thought I already aggregated this, but seems like I removed that code. It may be a good idea to do so, but remember to act on the last event and not void the following ones, to prevent that you are working on stale data.

Thanks for the advice!

And you're right - I get two events when I ungroup, although still just one when I first create the group. I wonder why Sonos does this ...?

My best guess is that each coordinator will send a topology trigger, one from the player that becomes it's own group, and one from the coordinator of the group which loses a player. However this is mere speculation.

This controller is great. I bought 4 players [along with 2 bridges] for my company. 3 will be placed in one building and the 4th in another. My goal is to basically have 2 instances of the controller giving the people in building 1 access to only those speakers and those in building 2 access to only their speaker. Is it possible to force the controller to only 'discover' the particular speaker(s) I want? I want to keep them all on the same network for many reason, but also so that I can control all speaker from another instance of the controller that would discover them all. Sound simple enough?

basically i have multiple 'offices' that are all on the same network. I would like to be able to have 'sub' controllers so that 'Jim' can only see his speaker(s) and 'Joan' can only she her speaker(s). I'm not concerned about Jim being able to open up 'Joan's' controller as i can restrict that via apache/htaccess. I just want a way to see only certain speakers when opening up certain controllers?. Please forgive my ignorance, but is there a way to 'turn off' Sonos-Discovery so it doesn't search the network for devices but just use user-set ip addresses to access/control those specific devices?

basically i have multiple 'offices' that are all on the same network. I would like to be able to have 'sub' controllers so that 'Jim' can only see his speaker(s) and 'Joan' can only she her speaker(s). I'm not concerned about Jim being able to open up 'Joan's' controller as i can restrict that via apache/htaccess. I just want a way to see only certain speakers when opening up certain controllers?. Please forgive my ignorance, but is there a way to 'turn off' Sonos-Discovery so it doesn't search the network for devices but just use user-set ip addresses to access/control those specific devices?

So basically, the controller searches for players and the first one that responds will be the one I associate with (like a regular controller). This player will then give me info of the rest of the players that belongs to the same system (household). If you chose to setup two different systems, the controller will only see the first system it finds. To force a controller to a specific system, would require some sort of configuration (which would be easy to implement), but you would still only see players from a specific system, never both at the same time, and you can't pair players from two different systems because of this.

What perhaps would be possible, is to consider all your players a complete system, but controller 1 could not control player 4, and controller 2 could not control player 1,2,3. By control, I mean that they wouldn't be able to adjust volume, change track etc. However, if someone would install the official clients, this can no longer be enforced. The upside would be that you could still group all 4 players together, but would only be controllable by one of the controllers (depending on coordinator, initial player for grouping). This would be a lot more work, and I'm not sure if it's such a good idea either. If you don't have the requirement to group all 4 players together, then the split-system setup is enough.