SonosNet, WiFi, and EoP (Ethernet over Powerline) are competing technologies, each eager to embarrass the others. SonosNet was developed for streaming audio because WiFi is a generalist technology, not optimized for streaming. EoP is my last choice because one is attempting to use wiring designed for 60Hz, high current devices to carry multi-megabit traffic. Wiring in old houses can be hostile for EoP, along with large items such as washers, microwave oven, air conditioning, pumps, and such. EoP might collapse when some combination of these large items switch ON. That said, occasionally EoP is the magic bullet. EoP continues to improve with each new generation.



At a first approximation WiFi and SonosNet ignore each other, however, they operate in the same frequency band. One should use channel 1, 6, or 11 for WiFi, "Auto" is a bad choice. Use different channels for WiFi and SonosNet.



I wish that SONOS would not use the wording "BOOST Setup". There are two different radio systems used in SONOS systems "New" and "Old". BOOST and newer designs use 'n' technology and are much more effective than the older units. BOOST is simply a regular (newer design) unit with audio processing removed to lower its cost. BOOST is handy to use when you need to extend coverage and you don't need audio processing at the most practical BOOST location. BOOST is not required. In your setup you could remove the BOOST near the router, wire the nearby player to the router, then deploy BOOST where it could help cover a difficult area. Each BOOST counts toward the 32 unit limit.



An approximate rule of thumb is that WiFi can support up to six players.



Old houses can have very dense construction that is hostile to WiFi and SonosNet. A single, central access point, regardless of its advertised potency, usually does not work well in old houses. Multiple access points, mesh or not, work better. "High Power" is usually useless because the remote device, even though it can receive a signal from the access point, might not have enough transmit power for return communication to the access point and two-way communication is not practical. In a multi access point environment one should adjust transmit power to minimize coverage overlap on the same channel. Some older iOS devices don't roam well in a multi-channel environment -- your mileage will vary. A quick fix for a device that refuses to give up a bad signal when a good signal is available is to briefly switch to and from Airplane mode.



---



With respect to Groups: the first player in a Group becomes the Group "Coordinator". All streaming traffic associated with that Group passes through the Coordinator. If the Coordinator is having communication issues, wireless or wired, the Group will suffer. You can imagine the struggle if the music source must first pass through a series of difficult nodes to arrive at the Coordinator, then pass back over at least part of that difficult path for distribution to Group members. Sometimes a better choice for the Coordinator will work around an issue. Likewise, the Left player in a Stereo pair is the Coordinator for the pair.



You can work with the Network Matrix to pick good and bad coordinator candidates.

---

Buzz, thank you for the detailed response!



Regarding the "rule of thumb" you mentioned - does this pertain to SonosNet also? As I understand it, WiFi is not as robust at handling Sonos players vs. having a player or boost hardwired thereby creating a SonosNet mesh network. Is there a guideline on how many players can be wireless using SonosNet? "I have setup several with 10-15 wireless and have not had these issues before." Finally if I have to (break up) the 30+ players into 2 or 3 groups - would it be best to have a Sonos Boost (either wireless or hardwired) with an ethernet connection to a group coordinator in that group?



Thanks again for the feedback!

---

I don't know how many WiFi units will work reliably but the suggestions on Group Coordinators is a good one. If you have a good WiFi monitor app that shows channel congestion as well as SSID / signal strength you can watch what happens as you fiddle with what is playing where. Keep in mind the SonosNet is usually hiding the SSID.



I'd think breaking groups up would not be a good idea, it likely would end up with them out of sync with each other and it would also likely increase both your Internet download usage and SonosNet channel saturation.



I was looking at your first post here and this bit is possibly a key:

* - currently one (boost) is hardwired about 6 feet away from any other wifi.

* - (1) Play 1 is hardwired to boost about 3 feet from boost and other wifi devices.

* - Currently I have 6 ethernet over powerline adapters on various Sonos devices in the house to try to fix the issue.

Since you have a component hardwired already, the Boost (and I think the Play 1) that puts your Sonos system in Boost Mode and it should not be using your home WiFi for anything. If you haven't removed the WiFi access credentials from some of your devices that could be part of your problem, some in Boost Mode and some in Standard Mode.



Is the boost the Play 1 is wired to also hardwired to your router?



I'd spend some time looking at the NetworkMatrix as your second step, after removing any left over WiFi credentials and rebooting. Next would be monitoring the WiFi channel SonosNet is using looking for usage levels as well as noise levels. If you have an Ubiquity AP and Controller it does a very good site survey that looks at usage and noise. You can move the AP running the survey around to various locations if you have an net connection there to get very short range noise readings. I'm not aware of any Apps that do the same level of testing.



Something probably not related but that could avoid future problems would be to assign static/reserved IP addresses to all your Sonos gear, that seems to help several issues, particularly updates to the firmware.

---

To avoid misunderstandings, "Group" is a SONOS concept where several rooms in a system are playing the same track in a time aligned fashion.



"Household" or "Sonos ID" (depending on where you read about it) is an identifier that bonds a collection units into a system. It is possible to have multiple systems on the same network -- his/hers, adult/kids, etc. Some people will use the same Sonos ID at home and at a beach house or cabin. The advantage is that music service registrations apply to both locations and players can be effortlessly shuttled between locations. The disadvantage is that some music services will not allow simultaneous play at both locations and, since all units in a system must be at the same version level, if the remote location does not have an Internet connection and an update is required -- there will be heartburn.



One can bust the 32 device limit by breaking the system into a few separate systems (each with its own music service registrations). It is not straight forward to prevent one user from controlling systems on that network that "belong" to someone else.



"Coordinator" is another SONOS concept that describes how data flow is managed when units are Grouped or "Bonded" as a stereo pair.



A given BOOST can only belong to one SonosNet.



With regard to the number of wireless units that SonosNet will support, this depends on the local environment. 32 seems like a stretch in a noisy high rise, but could work well in a quiet suburb. The exact network topology is a factor too.

---

Stanley_4,



Yes, the CloudKey is fun. I live near a highway and there is a flood of "JoesAudi", "JillsBMW", and similar in my log.

---

I have a large 27 speaker Sonos setup and here is the wisdom I've gained and some tips:



- Connect via Ethernet as many Sonos speakers as possible. In my experience there is no downside and lots of upside to connecting as many speakers as you can via Ethernet. This gives SonosNet as many possible hubs for connecting points as possible. SonosNet will always prefer to connect a wireless speaker to wired speaker above all else.



- Make sure the "Sonos Matrix" debugging view has all green in the device-to-device array. If you have all your wired speakers in range of every wireless speaker then everything will be green. Only worry about colored boxes as ones without color are not active paths. If there are speakers that are on the left 1st column that are not green all the time then those are also good candidates for hard wiring as they indicate wireless interference that could cause big problems. The "Noise Floor" and "OFDM ANI level" reading change slowly but all the time and give an area to look for intermittent interference sources.



- Once you connect a single Sonos speaker via Ethernet then the WiFi configuration capabilities of Sonos are disabled and all speakers then communicate via SonosNet and all traffic then goes via the one or more Ethernet connections. With SonosNet running having WiFi is irrelevant and thus adding more wireless access points does not help at all.



- If you have more than one Ethernet connected Sonos speaker then in most cases you will need to make sure that all your network switches support and are configured for Spanning-Tree Protocol (STP).



- Don't let Sonos be the STP root and thus you need to configure the switch connected to your firewall/gateway as the STP root with a priority of 4096 and make all others switches in your network 8192. Sonos will use 32768 and thus will never be the root which is what you want.



- Sadly Sonos does not implement the more modern and efficient RSTP protocol and thus all yours switches must be configured for STP or chaos will ensue.



- If you don't implement spanning tree or have switches that don't support it then even if it does occasionally work, you will most likely have ongoing highly problematic and erratic network behavior including total random network outages due to looped packets sucking up all the bandwidth. The conditions that can cause these random loops is very complex and hard to explain easily but trust me this is a big source of problems.



- Since you don't have Ethernet cables on the Sonos speakers connected directly to STP capable switches and instead using alternative multi-access connectivity methods of Powerline and eero wireless mesh this is probably the source of your problems. I also used a similar method to avoid running cat5 cables with MoCA coax adapters to then hardwire the Sonos speakers. It was not until I deployed an STP capable switch at every location I extended the Ethernet network this way did I finally get stability. I ended up using Ubiquiti Unifi switches that each cost about $100.



- The WiFi method of connecting to Sonos is highly problematic and nearly unusable with multiple access points. This is because each Sonos speaker will lock onto a single AP even if there is a better/closer/stronger signal level AP. They implement no WiFi roaming intelligence and for various reasons (like an AP reboot) it will invariably get locked onto a less than ideal radio and stay there. If they implemented decent roaming capabilities along with 802.11k and 802.11r support then WiFi only mode could be viable for someone that has a good WiFi network.



- The Achilles heal of Sonos is that they only support for 2.4GHZ which is highly problematic. That spectrum is a mess with limited bandwidth, crowded usage, and many sources of competition and interference from neighbors and other devices. For example I have a Pansonic microwave that will totally obliterate the 2.4GHZ WiFi when it's running. If you can't direct Ethernet connect every speaker, then the next best thing is using an 5GHZ wireless mesh solution and hard wiring the Sonos speakers is your best way to overcome. This is very unfortunate since SonosNet is really clever is how they manipulate and massage STP path costs to make their mesh work really well but you can't overcome the reality of when a microwave oven obliterates the entire spectrum for many minutes when you happen to defrost a turkey...



- Another really weak point for large Sonos deployments is only supporting STP and not RSTP which means the time to converge the network when there is an temporary outage or change is quite slow leaving big connectivity gaps for a while.



Hopefully some of this wisdom helps.

---

I have a large 27 speaker Sonos setup and here is the wisdom I've gained and some tipsJust a few comments:

- Make sure the "Sonos Matrix" debugging view has all green in the device-to-device array.

Green is ideal, but in my experience systems will work fine with active tunnels in the yellow and even the orange. Red should be avoided.

- Once you connect a single Sonos speaker via Ethernet then the WiFi configuration capabilities of Sonos are disabled and all speakers then communicate via SonosNet and all traffic then goes via the one or more Ethernet connections.

Usually, yes. However if WiFi credentials are stored in the system then 'Mixed Mode' can arise -- with some units attaching to WiFi and some to SonosNet. If a unit is out of range of SonosNet but can see an AP this behaviour is by design. Sometimes a unit can however get stuck on an AP and not flip over to SonosNet, or even oscillate between the two. This can cause problems.

- Don't let Sonos be the STP root

Here I beg to differ. There's nothing wrong per se with a Sonos unit being root. It depends on its effect on the rest of the network topology. Where there's a central STP-enabled switch it might be sensible for it to be root.

I have a Pansonic microwave that will totally obliterate the 2.4GHZ WiFi when it's running.

I suggest you get your microwave checked over. It sounds like its seals could have gone. Some RF noise is to be expected within close proximity, particularly on channel 11, but devices more than a few feet away should continue to operate.

---

Green is ideal, but in my experience systems will work fine with active tunnels in the yellow and even the orange. Red should be avoided.

I agree that when a system has a smaller number of speakers that Sonos does a great job of overcoming weaker signals on the mesh but as your speaker count grows I believe the communications paths have to be exceptional or else features like group all, large group volume changes, and starting a new source with many speakers become very slow, erratic and a very frustrating element of using the system. And even when you have a great network Sonos gets kinda sluggish with creating large speaker groups. As my system grew over the years I found the network quality demands of a 5 speaker Sonos system are very different than one with 20 or more speakers. I'm confident enough now in my Sonos environment that I just ordered two more Play:1's I found a deal on to bring my system up to 29 speakers.

Here I beg to differ. There's nothing wrong per se with a Sonos unit being root. It depends on its effect on the rest of the network topology. Where there's a central STP-enabled switch it might be sensible for it to be root.

The problem I've found with Sonos being the STP root is the frequent software updates cause the Sonos units to reboot. Rebooting the STP root is problematic and causes network instability for an extended period, and invariably another Sonos speaker will takeover as the root, which also might get rebooted later during the update, or more likely a failed update that you keep retrying on. Making a switch outside Sonos for the STP root just makes everything work better during the Sonos update process and I suspect is a reason why many people have problems with Sonos updates failing.

---

I agree that when a system has a smaller number of speakers that Sonos does a great job of overcoming weaker signals on the mesh but as your speaker count grows I believe the communications paths have to be exceptional or else features like group all, large group volume changes, and starting a new source with many speakers become very slow, erratic and a very frustrating element of using the system.

Back in the days when we had access to more diagnostics at x.x.x.x:1400/status, if you looked in the dmesg log for a wired node supporting a lot of active tunnels you might see periods of TX jams. Basically queued outbound packets are being held back. Some of that could be due to interference, some possibly because of near/far effects. By striving to achieve green signal strengths you may have overcome this. I've found that increasing the number of wired nodes, such that they 'share the load' as it were, yields excellent system performance on a mix of green/yellow/orange tunnels.

The problem I've found with Sonos being the STP root is the frequent software updates cause the Sonos units to reboot. Rebooting the STP root is problematic and causes network instability for an extended period, and invariably another Sonos speaker will takeover as the root, which also might get rebooted later during the update, or more likely a failed update that you keep retrying on. Making a switch outside Sonos for the STP root just makes everything work better during the Sonos update process and I suspect is a reason why many people have problems with Sonos updates failing.

I take your point that there could be short term topology instability during updates. I have a larger system but have never found updates failing for that reason. In my case a Boost is root and it boots quickly.



In fact by far the most common reason for users having post-update woes is IP conflicts. These obviously afflict systems in WiFi/Standard mode just as much.

---

That STP stability might be an answer to why my Sonos system was not so stable when an antique ZP-80 was being picked as the root and is happier with my Boost now being root. I think this is the page I used to disable the ZP: http://x.x.x.x:1400/advconfig.htm

---