This thread indicates that some routers (eg Ubquiti and another) can’t be trusted when displaying info about Bound Sonos devices.

Try my iOS app to find your devices and their actual IP addresses: https://apps.apple.com/us/app/phonos-plus/id1511326524

I’ve seen the same, @achillesuk: most of the time my router shows our Arc soundbar with its assigned static IP and sometimes it shows with the the subwoofer’s assigned static IP.

The IP addresses you’ve assigned (by MAC address) are copacetic, they’re just not displayed correctly.

I read about those threads, but that’s new behaviour for me, I never had a problem in the past. Note that I was using myTuner Radio, and not TuneIn. MyTuner doesn’t work anymore for stations outside the UK so I am stuck with TuneIn. And that doesn’t always work.

I wonder if when jumping from one IP to another, that creates a conflict on the network, because say the beam is on .90, and now it jumps to .92, however Beam’s internal address is still .90, therefore it clashes with what the router knows. I don’t know, more investigation will be needed from Sonos to debub its guts.

The router interface is most likely doing a best guess of what the device to display is based on information it contains. The devices aren’t actually changing their IP addresses and the router has no actual concept of what is a beam, sub, surround speaker.

An old router I had which supported device maps could never get it correct as it’s hardware MAC address to manufacture device lookup tables were older than the manufacturer MAC addresses used by my devices.

In my dhcp server no matter how many speakers I have switched on, only one is easily identifiable as a Sonos device from its host name. They all perform dhcp requests using the device name SonosZP regardless of what they are named in the Sonos app. I currently have 4 speakers switched on and only one has an identifiable name. The Mac/IP address with the host name attached is the last speaker that performed a dhcp request.

How the Sonos apps groups, organise or names the speakers is irrelevant to my dhcp server and router which just need to know the relevant ip/MAC addresses.

From the network overview in pi-hole it is even messier as it keeps a history of when a device last was last seen and how long ago. This also shows all 4 speakers are sending the same host name in dhcp requests. The 3rd device has had 2 different IP addresses assigned in the past year, so shows them both.
From both the information above and below there is no realistic way to present a sensible device map of my network.

On an internal network it is usually quite rare that always on devices change ip address, even without setting static IP addresses. By design when a lease expires a device will send a renew request rather than actually releasing it’s current ip and requesting a completely new one.

Restarting a consumer router will often cause new addresses to be handed out because the list of active leases isn’t saved before a reboot. This provides a window of opportunity for a previously switched off device to request an address already in use or for the dhcp server to actually assign new addresses rather than accepting the renewal.

Hopefully Sonos support can identify what is happening. A problem with the generic ‘Something went wrong’ error is it provides nothing helpful for a technically minded user to troubleshoot as it has no context or indication which part of the app had something go wrong.

On the flip side, detailed errors presented to non-technical users on mass market consumer devices are equally unhelpful and can look intimidating. Having a simple method to dump relevant diagnostics data with contact info for support is often beneficial if it isn’t a simple issue a user to remedy.

Sonos seems not to work well on some networks when using the default DHCP address assignment method.

That is usually solved by setting static/reserved IP addresses for ALL Sonos devices. Follow that by powering down ALL Sonos, restart the router and power up the Sonos. That is needed to lock in the new settings and not keep using the previous ones.

The above will sort any address assignment issues but may not clear up any display issues on your router if it still gets confused by the way Sonos does networking.

Thanks for you suggestion @Stanley_4 , however as I mentioned, all my Sonos speakers are on static IPs.

I saw that but wasn't sure you had done the required rebooting since  you'd done that and the jumping could be from that.

Also I tend to post the steps to a lot of topics that mention possible addressing issues, might help someone finding the topic from search.

The router interface is most likely doing a best guess of what the device to display is based on information it contains. The devices aren’t actually changing their IP addresses and the router has no actual concept of what is a beam, sub, surround speaker.

An old router I had which supported device maps could never get it correct as it’s hardware MAC address to manufacture device lookup tables were older than the manufacturer MAC addresses used by my devices.

In my dhcp server no matter how many speakers I have switched on, only one is easily identifiable as a Sonos device from its host name. They all perform dhcp requests using the device name SonosZP regardless of what they are named in the Sonos app. I currently have 4 speakers switched on and only one has an identifiable name. The Mac/IP address with the host name attached is the last speaker that performed a dhcp request.

How the Sonos apps groups, organise or names the speakers is irrelevant to my dhcp server and router which just need to know the relevant ip/MAC addresses.

From the network overview in pi-hole it is even messier as it keeps a history of when a device last was last seen and how long ago. This also shows all 4 speakers are sending the same host name in dhcp requests. The 3rd device has had 2 different IP addresses assigned in the past year, so shows them both.
From both the information above and below there is no realistic way to present a sensible device map of my network.

 

On an internal network it is usually quite rare that always on devices change ip address, even without setting static IP addresses. By design when a lease expires a device will send a renew request rather than actually releasing it’s current ip and requesting a completely new one.

Restarting a consumer router will often cause new addresses to be handed out because the list of active leases isn’t saved before a reboot. This provides a window of opportunity for a previously switched off device to request an address already in use or for the dhcp server to actually assign new addresses rather than accepting the renewal.

 

Hopefully Sonos support can identify what is happening. A problem with the generic ‘Something went wrong’ error is it provides nothing helpful for a technically minded user to troubleshoot as it has no context or indication which part of the app had something go wrong.

On the flip side, detailed errors presented to non-technical users on mass market consumer devices are equally unhelpful and can look intimidating. Having a simple method to dump relevant diagnostics data with contact info for support is often beneficial if it isn’t a simple issue a user to remedy.

That’s true and I’m glad I’m not the only one seeing this: all my Sonos speakers are identified as ZonePlayer ZP 1000.

It's a one time extra step per SONOS device, but I give custom device names to each device in the router's DHCP table. (Such as: “Kitchen-L”) Currently a very quick way to display device Room names and IP addresses is via the web controller.

SUB and Surrounds will connect directly to the soundbar via a private 5GHz link. Eventually, the router may assume that they are inactive or don't exist.