Why is using Sonos so hard?

When you start the Mac App, how long do you wait for potential discovery?

Don’t Factory Reset without further consult.

After opening the app, it said Sonos system can;t be found  - Try again?  After downloading a fresh copy of the app (assuming it might be an update) it now goes straight to “ Connect to. existing system” or “Learn how to setup a system”  - the Connect option didn't do anything the for the last couple hours I tried - but surprise! I just tried it again to get the response, and it connected!!   Really frustrating - wasted an hour or more, when I just wanted some music while I worked - and the Sonos site was no help at all - at least I didn't have to get the ladder out - 

This suggests a communication issue between your Mac and the SONOS system. Describe your network for us. Model numbers? Additional access points? Network switches?

 I do rarely get the message System not Found or something like that.  After a few seconds the app finds the system.  Sometimes I’m impatient so I swipe out the app and then open it.  That works well.

The network is pretty good - Verizon 5G in, Ubiquiti Gateway, 24 port Poe switch, 10 security cameras, 3 APs, Mac mini, printers, CNC unit, 2 gate controllers - and 5 Sonos speakers - all pretty good stuff, all working well. The frustration is that every time I have trouble with my Sonos, the only support suggestion is to reboot the router, then get my 12’ ladder out to unplug/replug the speakers and re-initialize the system. It’s been a while (maybe 2 years ?) since I last had to do it - but I never want to do it again - I am EXTREMELY happy that the web interface found everything and worked immediately, and maybe, once the speakers were found with that, then the app was able to connect and find everything. But that option (or at least as troubleshooting step) isn’t mentioned in any support option - 

A couple of times the Mac app has failed to find a system on the network, when there have been no changes to said network.

It’s often recommended to toggle the Local Network Access setting to get things back up and running again.

Aside from the reserved addresses, have you looked through the suggested configuration for Ubiquity?

https://github.com/IngmarStein/unifi-sonos-doc

I recommend reserving IP addresses. While the best practice would be to power down everything after reserving addresses (as noted above), in your case this is inconvenient. Typically, IP addresses are “leased” for 24 hours. As a lease expires the unit “renews” its lease and after reservations, you can be sure that the unit will be given the expected address. This will not protect you from duplicates caused by not yet renewed leases, or fixed address units that use one of your reserved addresses (been there, it’s humbling), but after a few days the reserved, leased addresses should rule.

You should also search for “sonos ubiquiti setup” to discover some additional helpful details. Although I’m not currently using Ubiquiti, I had used it for many years and I have friends who use it without any issues.

DHCP sservers can be tricky in non-obvious ways, both the (EOL) ISC DHCP server and the replacement Kea server. Maybe others?

The client is complex too as it can request to keep using an existing address across lease-renewal times, even though a different reservation has been created. A bit in conflict with the goals on page 6 but not page 7.

Just what happens depends on both the server and client versions and configuration.  (Page 12)

Setting the IP reservation and waiting for the renewal interval is not a bad option if manual intervention (like the ladder here) is necessary BUT you should confirm the new address was accepted and being used after the renewal interval passes. 

The renewal interval / lease time is also tricky, defaults are configured into the server but a client can request a different interval. Usually the client will request renewal at half the lease time to improve availability.

Dynamic Host Configuration Protocol

https://datatracker.ietf.org/doc/html/rfc2131. 

Well, I plan on integrating access control and security into my network, but will be bringing in someone who can make sure the ubiquiti equipment is set up properly since this will be a critical service - unlike music - but, I will add getting the Sonos on fixed IPs and possibly it’s own Vlan as part of the project, and keep my fingers crossed - 

With UniFi (another user here) you either Ethernet wire every Sonos or use WiFi, never mix and match as you run into issues exactly as you are describing.

As for powering devices off, power down sensitive equipment likes computers / NAS and then just flip the breaker for at the fuse board a good 30 seconds., saved getting the ladder out. In my house (and probably yours) the electric socks are on spectate circuits so not everything in the house gets powered off.

I hate resetting clocks so I avoid the flip the breaker option. I added remote power switches to all hard to unplug Sonos, some simple switched extension cords, some pretty remote switches where the spouse can see them. Wireless ones are an option but more than I needed.

I love my Ubiquity gear but mixing the latest tech (from anyone) with the older Sonos firmware does take some adjusting.

Luckily the only mains powered clock here is on the oven, which is even better as its own its own circuit breaker. 
 

Saying that IKEA in the EU and UK have some cheap socket adapters which can be controlled by various Home Automation software and support Matter or using a remote control. At £6 a go they are an absolute bargain.

This is a good hint - I think I have 1 speaker wired, with the rest wireless. I’ll keep them all the same ( and set static IPs ) - 

The issue is if you wire one Sonos and don't disable the internal radio it creates an invisible 2.4 gHz network, Sonosnet, that causes other Sonos wireless speakers to ignore your wifi and try to connect to it instead.

Newer Sonos don't use Sonosnet which is a good thing.

 Maybe Sonos should add a way to set static IP Addresses for each Sonos device.  Sometimes reserved IP Addresses lose their reserved status.  I have had that issue on occasion with my ISP gateway ( modem/router ).

Static, set in the device, addresses can bring a lot more aggravation than DHCP which may be odd but usually works.

Setting an internal static IP is an issue too, when you have a screen and keyboard it is easy, without there is no good starting point.

I wonder (not enough to go digging again) how close to the current Linux release the Sonos firmware is. Some of the issues we are seeing might be fixed by Linux updates and we would see new (to us) features.

 Reserving in my ISP gateway does not involve typing in an IP Address.  It shows you the DHCP address the device has now so all you do is check that you want to reserve that address for the device.

 Sonos could do that in a similar fashion.  Show the IP Address the Sonos device has been assigned and allow that to be the static address.

Your gateway is showing you the dynamically selected IP address and letting you set a reservation, that is not a static IP address. Yes, it doesn't normally change but it is only reserved and is subject to the negotiation process in The RFC I linked above. A static address never changes and conflicts with other devices must be resolved at some level.

Yes, that manual reservation process sort of works once you have a DHCP assigned address as a starting point. 

Using a DHCP range IP address a for static assignment is not usually a good thing. Static assignments should be outside tne DHCP range to avoid conflicts.

Then with static IPs you get into the whole my network changed and my Sonos disappeared mess. Sure it could be done but does anyone at Sonos have the skill to do it, and does anyone have the money to pay for it.

 I don’t think my ISP allows he usage of an IP Address outside the DHCP range.  I can test this with WiiM as they have a setting for the IP Address they call “Manual”.

What is your DHCP range set to? Usually it is 100 or less addresses leaving 100-plus available for static (set in the device) or DHCP reservations.

Reservations inside the range can lead to conflicts if the reserved address/device is booted after other devices may have obtained the address it is set to. The DHCP server can possibly be set to not assign reserved in range addresses except to the matching device/MAC addresses. You are stuck with what your server allows and likely can't change the server you are using easily.