Please add two wifi switches. One for 2.4GHz SonosNet/data and one for 5GHz used during ad-hoc surround/sub usage. I want incoming data handled over Ethernet but still need the 5GHz for bonded speakers.
Best answer by ratty
View original
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.
Userlevel 7
+17
What would you want to achieve with these?
You could argue that booth already exits. The 2,4Ghz switch would be the Boost and the 5Ghz switch is buit into any Sonos soundbar. What would you want to do with separate Sonosnet/Sonos surround switches that cannot be done already?
I believe the OP is asking for separate “disable WiFi” toggles -- for 2.4GHz and 5GHz -- in the Sonos home theatre players. It’s related to this saga.
It’s not quite so simple. When the HT setup is idle the satellites connect to the master player’s 2.4GHz radio instead. The 5GHz radio is turned off.
It’s not quite so simple. When the HT setup is idle the satellites connect to the master player’s 2.4GHz radio instead. The 5GHz radio is turned off.
I’m assuming to reduce power consumption when idle?
It’s not quite so simple. When the HT setup is idle the satellites connect to the master player’s 2.4GHz radio instead. The 5GHz radio is turned off.
I’m assuming to reduce power consumption when idle?
I guess. There could also be some periodic background scans for clear channels.
+2
it’s because I would like my Beam to create SonosNet. Instead I have to make my Amp create SonosNet because it has to have the 5GHz radio on for surrounds/sub. Beam is located more centrally. If I could turn only 5GHz on for Amp, it would handle its bonded speakers correctly and then my Beam could generate 2.4GHz for everything else.
There are pros/cons to each and what it is now is working well. I have about 10 of my 20 speakers plugged into Ethernet/Orbi with wifi off. Everything that isn’t plugged into Orbi has wifi on. Right now one speaker will 50% of the time flash yellow in signal strength, so again, it’s fine but from Beam they’re all always green.
Nah, don’t care about power consumption. A/C for 30 seconds wipes any meager savings away.
As already stated, the satellites idle on a 2.4GHz signal from the HT master player. Cutting them loose by disabling the HT master’s 2.4GHz radio could produce undesirable effects. Perhaps they’d try and seek out any 2.4GHz signal, however tenuous. Maybe none would be in range at all.
Basically, the HT setup isn’t designed for only one radio to be active in the master player.
An occasional yellow square in the network matrix is of no consequence. For reference, yellow is ‘satisfactory’. Systems will often work fine with amber signal strengths down to the low 20s.
Yours is an unsupported arrangement with Sonos devices wired to multiple wireless WiFi mesh nodes. Nevertheless you evidently have a solution which works so I suggest you don’t try to fix what isn’t broken.
+2
Agreed. All seems great now. How big are system updates? I was a little surprised how long it took to start the update a few days ago. With fast internet and a lot of wired/2 wireless networks handling traffic to all 20 Sonos nodes, it definitely didn’t take no “2-3 minutes” haha! I’d say around 10 minutes. The first step taking about 8 minutes, step 2 and 3 were a minute or two. When things just take longer than they should or I don’t hear the first chord of songs, I start to worry something is over burdened or not configured properly.
Although I kept getting errors when I tried to do the update so maybe some CDN locales were having trouble and nodes had to keep trying. I think it took me 30 attempts refreshing the page before it finally let me start the update. Of course I don’t have automatic on because then when stuff doesn’t work I’ll blame an update. I do them manually when I know I can be okay with downtime. Usually the same day I learn about them.
There’s no real way to tell how big updates are before you run them, most specifically for the speakers, rather than the controller. When updating the controller, the “store” will tell you how large the update is, but there’s no corresponding display of the speaker’s updates, and it can be wildly variable, as sometimes specific speakers can get an update, while others stay on the same firmware. While it can happen where all speakers get a firmware update, it’s not always the case.
While there could potentially be network traffic issues upstream from your modem, either initially at the CDN or somewhere down the pipe, most often, at least in “resolved” cases in this board, the issue is in the local network, in between the speakers and the router. Having to update your age 30 attempts does seem like a lot, for sure. Not sure how much “bandwidth” Sonos pays for simultaneous downloading, but it’s feasible in my mind, at least, that the output could have been saturated, in which case I’d have waited an hour, then tried again. Something I occasionally do with Apple, when they release an iOS update.
However, the purpose of a CDN is to avoid that kind of thing, so I’d still be looking at your internal network to see if there were bandwidth or other issues, especially as
The first step taking about 8 minutes, step 2 and 3 were a minute or two.
This is quite feasible on a larger system. The steps are:
- download
- install (presumably by pointing the bootloader at the new firmware image)
- restart
Each step has to complete for all units before the controller begins the next. Clearly the duration of the first step will be more variable, depending on system size, network conditions, etc.
The “2-3 minutes” quoted is for an average-sized system, which is probably barely a handful of units.
+2
How much multi-cast savings does Sonos enjoy? Meaning if you stream an Apple Music song, does it download once to the root node and that shares the data with the rest of the nodes? As it shares with the rest, does it have to send the packets each time for each node? Does it fan out or send one “broadcast?”
In a WPA encrypted WiFi network, each device cannot “sniff” other device traffic at the wireless level, can it? Once the network hits a switch then everything can sniff everything, if they’re unmanaged?
Curious because in one of my cases I have 2 surrounds + a sub all connected to a headless 5-port switch with just one surround having wifi on. Does the Amp send the same signal 3 times to the surround speaker? Essentially the intact audio data, then Left plays that part, Right its part, and sub pulls the bass out? Or does amp send just Left to the left and right to the right, and bass to sub? Subprocessing each part. I’d guess it’s sending it all intact or you’d end up with doubly encoded audio data.
Maybe someone has drawn up a summary of all of these questions. I try to get as down to as few devices as possible on wireless so there are fewest nodes taking over time slices on the wireless spectrum. One speaker handles all the communication across a mere 10 wireless nodes versus the 20 that there would be if every speaker just had wifi on.
I imagine that the surround decoding in the HT master player results in individual channels being sent to each satellite.
But does any of this really matter? Are you actually experiencing wireless problems? If not then this ongoing obsession with bandwidth has no useful purpose.
+2
If you don’t know, that’s totally fine. You can just say you don’t know. We don’t all have to be right all the time. 🤣🤪
How big are system updates? I was a little surprised how long it took to start the update a few days ago.
We don’t know the size. I suppose that you could use a network monitor to snoop the size. My updates are rarely 2-3 minutes, they are usually somewhat longer. Based on my observations it’s not a one size fits all download, each type of player will need a download, then the download needs to be unpacked and an image built, next a reboot, finally, the players must acknowledge that they are done and this can take a while. The older players are much slower. You can follow some of this by observing each player’s status light. They’ll flow through at different rates.
There will be some variability depending on Internet traffic, local traffic, and the associated player.
When players restart during a planned upgrade, the queue remains afterwards. I assume this means there is enough ‘space' on the device to hold it. I really wish Sonos would keep the queue in this ‘space' during normal usage too so the queue ‘survives' power outages or manual reboots.
When players restart during a planned upgrade, the queue remains afterwards. I assume this means there is enough ‘space' on the device to hold it. I really wish Sonos would keep the queue in this ‘space' during normal usage too so the queue ‘survives' power outages or manual reboots.
During an update the Sonos products do not power off, so they are able to retain their data/queue in volatile memory, but in the case of a power outage/manual-reboot the devices are powered off completely, so would likely need a backup power source (battery) to keep the info. stored, so I suspect that’s the reason why a queue is lost.
It would be nice to have a way to reboot a device without actually powering it off - that would be an answer, I think. Many have asked for that feature in the past, but it’s never been forthcoming, I’m not sure why that is?
It would be nice to have a way to reboot a device without actually powering it off - that would be an answer, I think. Many have asked for that feature in the past, but it’s never been forthcoming, I’m not sure why that is?
There was such as facility, by simply visiting http://x.x.x.x:1400/reboot. It was eventually withdrawn, for reasons unknown.
During an intermediate phase it was protected behind a CSRF token handshake with the originating browser. This would surely have dealt with obvious vulnerabilities.
It would be nice to have a way to reboot a device without actually powering it off - that would be an answer, I think. Many have asked for that feature in the past, but it’s never been forthcoming, I’m not sure why that is?
There was such as facility, by simply visiting http://x.x.x.x:1400/reboot. It was eventually withdrawn, for reasons unknown.
During an intermediate phase it was protected behind a CSRF token handshake with the originating browser. This would surely have dealt with obvious vulnerabilities.
I would find it a useful feature to ‘restart’ a device - I guess there must be some reason(s) that exist for it not being reinstated, but will just continue to hope the developers find a way to implement this and save us all having to traipse about the place, pulling cords and losing queues etc.
I agree, however, if the network is down, there is no great advantage of being able to reboot over the network.
+2
Yeah, so ridiculous that the step in the docs for so many things is to power cycle. Great, so I gotta run to 17 outlets. I often just restart my whole house at the breaker panel. This is like Apple vs Android simplicity. Once you progress upward, you wish there was an advanced panel with like 3-4 special features and capabilities.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.