Yes a Sonos player, wired into a switched Ethernet port, will act like a bridge for the entire Sonos Mesh network. Not everyone has one nearby where they want their audio (eg outdoors) so they have the cheap/dedicated bridge device.
I ordered my Play5 on Saturday, and will find a cheap Connect sometime to hook in the rest of the AV stack.
For the networkports, you can just use them as ordinary switchports (take the existing cable to something, plug it in the Sonos, and then connect the other port to the equipment that used to have the connection). You can also use Sonos to bridge your network through SonosNet, ie use both ports for equipment that dont have wireless access to your normal network.
You mean that connecting an equipment to a Sonos in a room without any wired network will bring the equipment to my home network ? This is an interesting bonus feature, especially if WiFi used by Sonos is 802.11n. Do we have this information ?
Yes, it’s 802.11n, it is mentioned on wikipedia page: http://en.wikipedia.org/wiki/Sonos
So, as SonosNet is a mesh network, this feature could be interesting for example for big houses, because it could provide a better WiFi access than the normal WiFi home network in rooms far from the router (assuming you have enough Sonos boxes to build a good mesh network).
I have heard them both an the Play 5 has a more rounded sound, and deeper bass. Both are good, but if you want the best ‘all in one’ and can afford itnI would go with the Play 5. If not and you do not need to fill a big room with sound, the cost and size of the Play 3 is your best bet then.
You should also know that both the Play 3 and the Play 5 can be made into stereo pairs should you ever add another one to your set up in the future…
You get internet connection in the switch ports, through SonosNet, but the SonosNet is still a “closed” net. But they allowed Android-devices to connect to it a couple of months ago, so maybe other equipment will be allowed in the future. It also requires a special driver since it is not a standard wifi-network.
The idea was not to add devices in the SonosNet network but just use the SonosNet network as a bridge to Internet and the home network.
You’re right, I read that Android phones are now allowed to connect to the SonosNet network. It can help in case you are in a room and your phone cannot join the “normal” WiFi network (or if you have no other WiFi than SonosNet).
I just pushed this change in, so the icon will be smaller when it’s next picked up.
[quote=“parkerc, post:226, topic:169644”]Hi @anker, i didn’t realise you had started on trunk 19. A quick fyi, the original flashicon ref i used in the first JSON was too big, so if you can replace it with this one below it seems to work better. (The eventual goal is to put the icon’s png on to Vera that way the json can look for it locally)
I’ve been trying to help out by tweaking the existing Squeezebox JSON file to work with the Sonos, but my tweaking skills are not very good, but it looks like it might have potential as a basis?
As we’re sharing ideas for a potential TODO list. I’d love to see…
[ul][li]A more informative/functional/live JSON - (as above and as you mentioned too)[/li]
[li]An ability to place a URI into queue to play next (currently it only clears the current queue and plays the chosen track)[/li]
[li]able to load an existing saved Sonos playlist into the queue[/li]
[li]Ability to group all zones, if you have more than one you can join them[/li][/ul]
It’s already a great plugin, I only wish I could contribute more…
This sounds great - I simply have not had the time *(and skills I guess) to spend time ecxpanding functinality for this plugin.
I however have a lot of ideas and info.
json UI interface showing info only - buttons is not needed for me - I can create scenes for controlling and would not use a button in the UI. Playstate, volume and currentURI would be my priority
Automatic update of the variables (current version trunk 18) - is only done once in startup. Tried to do the simple function call to do this say every 15th sec, but got lost in a restructuring that I couldn’t fix… I did nbot spend time on this. This regular polling is needed for the UI to display correct info.
The correct upnp way would be to subscribe to events - the way sonos does it internally. I have not been succesfull doing this, but I have sniffed the requests - my trouble here is specifyin the return call url - a script capturing data could call a function, but cannot really use the “incoming” standard interface from what I can figure out.
A master Sonos instance with auto discovery of zones. This would enable a mute all and a total auto overview of linked zones.
Add an “announce” function
inputs would be URItoPlay and volume
basicly this would save the currentURI, Playstate etc - then ramp volume to announce input volume - then play the URI wanted and then return Sonos to the original state. This is possible with the upnp calls available. This has been requested by a few posts - i.e. to use google tts…
Add AddURIToQueue to enable a function to queue something. This would enable us to load Sonos playlists using “file:///jffs/settings/savedqueues.rsq#X” as URI.
Implement RamptoVolume - would enable a more smooth volume handling
Grouping functions - There seems to be some upnp sonos functions to do this, but i have not tried this. Some say that chainging the URI is the simple way.
This is all for now - maybe we should out a more formal list together and do a prioritization? I am not a programmer and is doing this the hard way - so I have a lot of ideas, but lack the skills.
I’m curious, is there a size restriction on the JSON device UI you can design? i only ask as I’ve seen a thermost (aircon) device appear that was well over 1 and a half times the width of a standard device (but still the same height). Plus looking at my device list, the Variable Container plugin is slightly wider too, so it suggests it’s flexible. It’s possible that they are controlled by the locations/dimensions you specify for your buttons/options, so it might flex accordingly…
a) Single code stream
If you want to have UI4 and UI5 compatibility, then there are design constraints that must be applied. For the moment, since the bulk of the users are likely still on UI4, the layout needs to handle both. I don’t plan on forking JSON files per platform, that quickly gets out of hand.
b) Cross release compatibility
MCV doesn’t keep an eye on [UI] compatibility across releases, so I don’t put a lot of effort into their Dashboard/UI experience. It’s clunky at the best of times (can anyone say “Hasbro”?) and most people get a better experience from a real control device. In the case of Sonos, this is particularly true.
Overall, a “standard-sized” UI5 Dashboard component is ~50% wider (and taller) than it’s UI4 counterpart. You can made them bigger than that, if you go UI5-specific, but your screen isn’t bigger, so the larger these components are, then the less of them you can fit on a page at any time without further triggering scrolling for the user.
So overall, it’s going to get a cursory upgrade for some basic “quick reach” functions only. Everything advanced will be done by working with the Control Point owners, since they’re yrs ahead of the Dashboard in terms of UI functionality.