Sonos Devices not found in player table

[chrisgla]

Thanks. I noticed Sonos has now also added the option to disable Wireless in the advanced room settings now- you used to have to use the hidden command.

Attached files- a couple of things stick out:-
1) looks like something is bound to use loopback address whilst another reference is to the fixed IP (192.168.178.220)
2) I'm not sure what the missing files are.

Mar-26 9:39:26 PM

Warning

File does not exist: /usr/local/HomeSeer/html/images/HomeSeer/status/angle-position.png

Mar-26 9:39:26 PM

Warning

File does not exist: /usr/local/HomeSeer/html/images/HomeSeer/status/seismic.png

Mar-26 9:39:26 PM

Sonos

SetHSDeviceRefPlayer called for zone - Living Room Sono with HS Ref = 670

Mar-26 9:39:25 PM

Starting Plug-In

Plugin Sonos started successfully in 58 milliseconds

Mar-26 9:39:25 PM

Sonos

InitIO Called for Instance = RINCON_000E582A753C01400

Mar-26 9:39:25 PM

Sonos Warning

Warning in InitIO for Instance = RINCON_000E582A753C01400 received (192.168.178.220), which is a different IP adress from it's server binding ()

It's worth saying that so far I've not even had to ssh into the host as the Homeseer PI3 image build has been so good- burnt it to card and started configuring z-wave.
So the machine is really very vanilla...
Only plugins are Z-wave, JowiHue and Sonos.

[dcorsus]

So there is good news and there is bad news.

The good news is that all the screen shots look good. The not so good news is that at init the MC discovery that got blasted out to everyone resulted in zero responses, so sorry to say but I suspect still something in your network settings. However the screenshot seems to indicate that all players are on line, was the screenshot of the player table perhaps taken before the restart or at some other time?

The fact that all seem to work after you restarted the players still make me think that your MC trees are pruned (not technically correct language for L2 optimization) over time. I would think that when you restart the player, the player will do what the PI does, subscribe itself to MC address .250 and perhaps the IGMP query setting doesn't prevent it all from aging out. I need to Google a bit to see whether IGMP Queries, how they are being treated by L2 switches, which in your and my case are cascaded L2 switches. This MC is a L3 application and my CCIE days are now nearly 1.5 decade ago :-( so snooping was around but more for L2VPN optimization.

Not sure what else to say. Not sure you turned the debug flag off or left it on, if you left it on, did you see more entries over time as players are discovered by the periodic MC alive message they sent?

There are plenty of users of the PI, a bunch on Linux, I would suspect a number of them on a RPi. I personally run it under Ubuntu and have no issues with discoveries (unless I had my switching doing snooping).

The warnings on the IP address binding are benign, I fixed that in the next release (yet to be posted). The other warnings on missing files are reported by HS and they come from their web browser support, that a page is being rendered that has objects on them that are not found on the local file system.

[chrisgla]

Sorry. I tried multiple attachments but they never got added to last post...trying again

[dcorsus]

Have you tried to turn the IGMP querying off as well. If there is no snooping, not sure what IGMP querying would do ......

Note: suggest that each time you try a change on your network that you restart HS (or at least the PI).

[chrisgla]

I'll try swapping out the local switch for an unmanaged in the first instance- that's an easy fix. It has a Sonos and Homeseer locally connected to it.

I've made a little bit of progress- I found the other thread on bindings and noticed I was set for DHCP- I had a reservation set on router. Tried setting IP manually. locally and also enabled "System is Discoverable Using UPNP".

Rebooted after this and I now have all players in the linkgroup configuration table.

Then tried adding a speak to an event no luck. Tried adding $SONOS$TTS1$ to link to the group directly, still no luck.

I still don't see anything in the "Connected/Added Speaker Clients"- I'm out for a couple of days and will try the switch change on return, if that works I'll go in and mess about with IGMP or Wireshark it.
I
Thanks for the help...

[chrisgla]

OK, thought I'd reboot one last time- I now have TTS from event!
The only change I'd made was to try adding "$SONOS$TTS1$" again to reference the linkgroup directly.

I can disable logging and go away happy. We'll see if it stays reliable, if not I'll look at multicast again...

Cheers!

[dcorsus]

Good idea to try it first without a managed switch, take it from there and see what happens ....
The "system is discoverable using UPNP" is an HS thing, nothing to do with the Sonos PI. It will trigger a response to a UPNP discovery which can be used by UPNP controller (the Sonos PI or my MediaController PI) to find the HS app. As a side note, HS is violating the proper UPNP protocol that's why HS will not show when you use proper UPNP tools, just FYI,
Have you read the help file? I'm not sure we're applying the right way to set up a TTS action, for that I would need to see a screenshot of your announcement event. I noticed in the screenshot that you have the right syntax but can't tell whether the event is constructed properly. You create a fake speaker client that is attached to a speak event, the help file should show you how.

Obviously, if the PI has NOT discovered the player on-line, nothing will work, so pay attention to the player table to make sure the player shows on-line. It showing up on the HS devices page or in drop down menus just means it was discovered (and added) at some point and HS devices references were allocated to the players but if the PI thinks the payers are off-line .....

[tenholde]

https://en.community.sonos.com/troub...protocol-16973

[chrisgla]

https://en.community.sonos.com/troub...protocol-16973

Thanks again, but I really don’t need STP. I’ve spent months of my life debugging spanning tree problems for different customers and in the house prefer to avoid the need for it- but you need to understand the consequences.
Sonos rolled out an upgrade a while back that defaulted the WiFi to on and due to the limitations of cheap switches I had at the time it ended up shutting down the wrong port in the network and confusing me for a while until I realised what had happened.

You need STP if you use Sonosnet or have other potential loops- but not if you have only single cable connections and no mesh.

[tenholde]

Thanks again, but I really don’t need STP. I’ve spent months of my life debugging spanning tree problems for different customers and in the house prefer to avoid the need for it- but you need to understand the consequences.
Sonos rolled out an upgrade a while back that defaulted the WiFi to on and due to the limitations of cheap switches I had at the time it ended up shutting down the wrong port in the network and confusing me for a while until I realised what had happened.

You need STP if you use Sonosnet or have other potential loops- but not if you have only single cable connections and no mesh.

As I've said, RST required when MULTIPLE wired connections

[chrisgla]

As I've said, RST required when MULTIPLE wired connections

Yes- but that’s multiple wired connections to a single device, ie that could create a loop. It is not meeded for lots of single routes to multiple devices.

Really sure of this- and what would be happening if STP was wrong.