Sonos with node.js, my attempt!



Show first post
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

397 replies

Userlevel 2
Absolutely awesome library! Let's talk, I'm building a new Sonos Controller.

https://github.com/michaelmcmillan/Zone
Userlevel 4
Badge +14
Can anyone tell me how to get the 'mobile' version to work? I have everything set up and working great {the 'desktop' version}, but when i access it from my phone, its cumbersome to try and change the volume. I assume the 'mobile' version will help with this issue. But my directory structure doesn't have a '/m'. I appreciate any and all assistance.

You need to checkout branch "mobile"

If you used git, just invoke "git checkout mobile". If you downloaded the zip from github, you need to view the mobile branch and then the zip file will hopefully reflect the correct version.

Do note that the mobile is far from finished. You can't for instance switch zone so you are stuck with whichever it chooses on load.
Userlevel 2
Can anyone tell me how to get the 'mobile' version to work? I have everything set up and working great {the 'desktop' version}, but when i access it from my phone, its cumbersome to try and change the volume. I assume the 'mobile' version will help with this issue. But my directory structure doesn't have a '/m'. I appreciate any and all assistance.
Badge +1
I, see, jishi, thanks for letting me know, and for the great API.
Userlevel 4
Badge +14
Thank you so much for this! Working great on my raspberry p for integration in a smart house system, and set up a cheapo RF remote to use for basic operating in the bathroom. (I.e. no tears if I drop it in the tub.)

There is one thing I can't figure out, though. How do you use the generated state.json? Do I have to use it as part of a preset.json? All I want to do is resume whatever was happening on one of my players before it was interrupted be the say command. I am trying to write a bash script that
1. Generates a state-file. (Succes)
2. Uses say for an announcement. (Succes)
3. Feeds the state.json back to resume whatever was happening before (No succes)

Any input?

(P.S. This a large thread, I've flicked through it but couldn't find anything on this subject. I'm sorry if I've overlooked it.)


Hi, the state json was merely a feature for integration purposes, to "display" the current state of your players. It is not related to the preset function at all.

What you are talking about, "saving" the current status as a preset is another feature that hasn't been built yet (in conjunction with a preset builder). That was supposed to be part of a sandbox function for the API, but haven't had time to work on that.
Badge +1
Thank you so much for this! Working great on my raspberry p for integration in a smart house system, and set up a cheapo RF remote to use for basic operating in the bathroom. (I.e. no tears if I drop it in the tub.)

There is one thing I can't figure out, though. How do you use the generated state.json? Do I have to use it as part of a preset.json? All I want to do is resume whatever was happening on one of my players before it was interrupted be the say command. I am trying to write a bash script that
1. Generates a state-file. (Succes)
2. Uses say for an announcement. (Succes)
3. Feeds the state.json back to resume whatever was happening before (No succes)

Any input?

(P.S. This a large thread, I've flicked through it but couldn't find anything on this subject. I'm sorry if I've overlooked it.)
Userlevel 4
Badge +14
what I have run into is when running the regular web interface on a mobile device i cannot click on a button, it highlights but never actually clicks. looks like it requires a double click but on a tablet that causes a zoom not a selection if that makes sense.

The regular GUI was never intended for touch devices. I have started working on an alternative view which is touch-enabled and responsive, but haven't had time to work on it lately.

If you check out the mobile branch you can access it using /m and try it out.
Userlevel 2
never mind I was able to fix my error changing permissions. what I have run into is when running the regular web interface on a mobile device i cannot click on a button, it highlights but never actually clicks. looks like it requires a double click but on a tablet that causes a zoom not a selection if that makes sense.

Ill run it with .10 and see if that changes
Userlevel 4
Badge +14
Hm, it seems to claim that it created the cache folder here:

/opt/node-v0.11.2-linux-arm-pi/sonos/cache

But you seem to be running the script from here:

/opt/node/sonos

Which one is correct? I haven't tested 0.11, maybe they've changed some stuff on how it discover different paths.

I assume you haven't changed the cachedir with a settings.json file?

Also, unless you have a specific reason for running 0.11, don't use it. It's unstable, and 0.11.2 is rather old. 0.11.x is not "newer" than 0.10.x, they use similar versioning as linux kernel.
Userlevel 4
Badge +14
As if this controller isn't great already, should you ever get bored and find lots of time on your hands - the next feature regarding connectivity would be to only connect to speakers you set [i.e. in the settings.json file].

This is similar to the previous request, but instead of having multiple sonos systems, have one system but only be able to see/control the speakers set in the settings.json file.

I believe you touched on this in a previous post but just wanted to reiterate. The reason this scenario would be ideal would be so I could use the same music service accounts [i.e. Pandora] to control all speakers as opposed to having to purchase an account for each sonos system.

But again, your household id update is fabulous and exactly what i asked for and fits my current needs perfectly. I appreciate your work on it.

I hope to one day be able to understand how your created/scripted this controller so i can help contribute.


Yeah, a blacklisting/whitelisting feature wouldn't be that hard to implement, and it could even be based on room name or UUID (IP-addresses could change). Then just void all the actions that are about the go out to the players (like volume, track change etc). The one issue that might not make sense is if all players are grouped, only one of the controllers would be able to control playback (play/pause/next/prev/seek) unless you would allow anyone to control it if grouped, but then one could just group it and control it, and then remove it from the group.

However, this feature is really niche and would probably make more sense to be some sort of extension.
Userlevel 2
As if this controller isn't great already, should you ever get bored and find lots of time on your hands - the next feature regarding connectivity would be to only connect to speakers you set [i.e. in the settings.json file].

This is similar to the previous request, but instead of having multiple sonos systems, have one system but only be able to see/control the speakers set in the settings.json file.

I believe you touched on this in a previous post but just wanted to reiterate. The reason this scenario would be ideal would be so I could use the same music service accounts [i.e. Pandora] to control all speakers as opposed to having to purchase an account for each sonos system.

But again, your household id update is fabulous and exactly what i asked for and fits my current needs perfectly. I appreciate your work on it.

I hope to one day be able to understand how your created/scripted this controller so i can help contribute.
Userlevel 2
Jishi - your awesome. Works exactly like I asked. Now I can run 2+ sonos systems on the same lan using your web controller. This will be perfect for my situation as it will restrict people from only being able to listen to the music/stations/services i set whereas if i allowed them to use the SONOS controller they could do whatever they want. [the speakers will be out of reach for anyone to 'connect/sync' with their device/computer so they will be forced to use the great Jishi controller 🙂 Thanks again.
Userlevel 4
Badge +14
Ok, i've set up two different systems on the same lan. But, as you said, the web controller attaches the the 'first response' and pulls only speakers attached to that system. Is there any way to tell the controller [your web controller] to attach to a specific ip as opposed to searching for first responding speaker/bridge?

I have pushed an update which supports a household filtering now. Create a file called settings.json and put the following in it:

code:

{
"household": "HHID_XXxXxxxXXXXxxXXXXx"
}


Replace it with the household ID that you can find at http://X.X.X.X:1400/status/netsettings.txt

from each system. Yours probably start with Sonos_ instead of HHID_, they changed it some time ago. Older systems will begin with HHID.
Userlevel 4
Badge +14
Ok, i've set up two different systems on the same lan. But, as you said, the web controller attaches the the 'first response' and pulls only speakers attached to that system. Is there any way to tell the controller [your web controller] to attach to a specific ip as opposed to searching for first responding speaker/bridge?

Not at the moment. I'm thinking of adding a setting for household ID, just give me a few days. You will be able to find your household ID here:

http://[IP to one of the players]:1400/status/netsettings.txt

The reason for using household ID is because I know it is part of the response when searching for players, and it's the same approach that the regular controller uses.
Userlevel 2
Ok, i've set up two different systems on the same lan. But, as you said, the web controller attaches the the 'first response' and pulls only speakers attached to that system. Is there any way to tell the controller [your web controller] to attach to a specific ip as opposed to searching for first responding speaker/bridge?
Userlevel 4
Badge +14
I would be ok with having two different systems than could only be controlled independently but is that possible on the same LAN?

Yes, that is no problem. Just setup the first players for the first system.

When you setup the next system, and you are using the same controller, reset the controller first (I'm talking about the official Sonos controller now). This would create a new system, on the same LAN.

The Sonos controller supports multiple households, but I'm not sure how this works if you are on the same LAN. Usually this is for supporting different systems on different networks (like, work and home). Maybe you will be able to choose if it finds two different systems, otherwise you would need to reset the controller and re-associate it when you want to switch. This is not a very common setup, that's why it might seem clunky.
Userlevel 2
I would be ok with having two different systems than could only be controlled independently but is that possible on the same LAN?
Userlevel 4
Badge +14
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.
Userlevel 3
Badge +2
Just wire up an additional Bridge, then associate the desired players and controllers off it it. Voila, two separate Sonos households which will not see each other.
Userlevel 2
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?
Userlevel 4
Badge +14
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?

Well, if you separate them as two different systems (households), this would be possible (with a small modification). However, that would not make it possible to control all of them from one controller.

I don't see a simple solution to the latter, if you want to "remove" the possibility to restrict access to some of the players. Maybe it would be possible to implement some sort of IP (or UUID or room-name) based blacklist, but I'm not sure how I feel about that. You would still require to limit the access to the different instances of the controller as well, otherwise they would just open up the other controller anyhow.

If you could elaborate on different user scenarios that you would like to support, I could give you a better answer.
Userlevel 2
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?
Userlevel 2
I totally love this. Could not reliably get anything to work with WINE, whether on FreeBSD (my OS) or several of the Linuxes. Tried for months! :)

But this is awesome. Works great in FreeBSD. Thanks for writing it!

Z
Userlevel 4
Badge +14
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.
Userlevel 2
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 ...?