Announcement

Collapse
No announcement yet.

Remotely reboot a SONOS device

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dcorsus
    replied
    Originally posted by paul View Post
    Collecting logs right now. Interesting symptom today - the two rooms I most often see the issues exhibit in both started exhibiting a variation - Run an event that sets several things on the speaker - sets a single song to the queue, turns on repeat, sets the volume. Today what's happening is the volume changes appropriately, but queue is not clearing, song is not changing. And this time (this is new), power cycling the speaker isn't fixing the problem. So, something isn't communicating, but certainly in it's most basic form HS is talking to it, as HS has no problem changing the volume.

    I just turned on debugging as requested above, and then ran my event on each speaker, volume changed but nothing else. I'll let the log run for awhile, then will close it up and see what we got.....

    Paul
    make sue you annotate everything so I know what I'm looking for, including perhaps screenshots of the events. Did you see errors by any chance?

    Leave a comment:


  • paul
    replied
    Collecting logs right now. Interesting symptom today - the two rooms I most often see the issues exhibit in both started exhibiting a variation - Run an event that sets several things on the speaker - sets a single song to the queue, turns on repeat, sets the volume. Today what's happening is the volume changes appropriately, but queue is not clearing, song is not changing. And this time (this is new), power cycling the speaker isn't fixing the problem. So, something isn't communicating, but certainly in it's most basic form HS is talking to it, as HS has no problem changing the volume.

    I just turned on debugging as requested above, and then ran my event on each speaker, volume changed but nothing else. I'll let the log run for awhile, then will close it up and see what we got.....

    Paul

    Leave a comment:


  • paul
    replied
    Originally posted by dcorsus View Post

    Well if there is no FW then we can rule that out
    If you look through your current log, do you see log entries of players dropping out and coming back?

    So next time it happens:

    a/ turn debug on
    b/ set UPNP logging to verbose
    c/ turn log to disk on
    d/ do some actions on PI and Sonos controller
    e/ wait about 45 minutes, it will be a big log but might be worth it.
    f/ turn logging to disk off (IMPORTANT it closes and writes to the log file)
    g/ pm log and tell me which player didn't respond to which commands you did at what time

    Questions: what OS are running this on? VMs involved? Any managed switches between HS PC and Sonos?

    Sonos provided a UPNP view in the past, but I can't find it anymore, so they may have removed it The fact that the Sonos app still works is making this somewhat strange. If the HS PC is windows, perhaps install the Sonos App on it, would be curious to see if that would still work. Make sure UPNP logging is set to errors only, at least we can spot UPNP issue if any prior to it all going south on us.

    Dirk
    With the regular log, I don't see any occurrences of speakers dropping out and reconnecting, at least not in the last 24h (and I haven't experienced the problem in the last 24h) - I have an event that restarts the PC every night at 3:30am. This was a catch I put in place a few years ago when something on the box was occasionally scarfing resources and the box had a nasty habit of stopping responding. I suspect it may not still be the case, but the restart never caused issue so I never took it out...

    Running on Windows 7, bare metal (small standalone mini pc) The network between HS3 and Sonos is a pair of Unifi 16 port managed switches (linked to each other in redundant fashion). This is a relatively recent change, it used to be a single Unifi 48 port switch. I *did* find when I made the change that one of the ports would block, which turned out to be a Sonos port, because I have two of my 8 Sonos speakers wired, the rest on SonosNet. I resolved that by changing the switches from using RSTP to just STP (as per various Sonos forum threads on the issue). These chanages can't be the root cause, as the root problem occurred months before I swapped the switches, however it might not be helping matters. I have considered pulling the wire from one of the speakers to see if that resolve the problem, the main two reasons I hadn't done so yet are because:

    1. Adding the second one to a wire (years ago) resolved a long standing Sonos quality issue I had been having previously.
    2. As mentioned, both were connected years ago, and during that time I had years of rock solid stability before the current issues started up

    That being said, perhaps I should give it a try in case somehow a Sonos update has started causing STP-ish issues.

    Definitely, I'll try throwing the Sonos app onto the HS3 server so I can see it is only HS3 that isn't communicating with the speaker, or if it's the whole box, that's a good idea.

    As soon as the problem reoccurs I'll get as much logging as I can and will post....

    Paul

    Leave a comment:


  • dcorsus
    replied
    Originally posted by paul View Post

    Hi Dirk, to answer your questions, I don't have a FW running between the sonos devices and my HS3 server. Firewall is also disabled on the HS server and there is no 3rd party FW running on the box. I afraid I disagree that firewall is the issue here, because there simply is no firewall, hardware nor software, in between HS3 and the speakers.

    I have tried stopping and starting the PI when these behaviours kick in, and have tried restarting HS and the server, to no avail.

    In each case, the only thing that resolved the problem was restarting the individual Sonos speaker. And in each case, the Sonos UI was always still working, from multiple different devices, it was only connectivity between Sonos and HS3 that was broken.

    Things were super-stable for several years, and there were zero changes to the network infrastructure, the Sonos physical or configuration infrastructure, and the Server configuration (even patching) for at least 10-12 months prior to the behaviours starting. The only things that changed in that time were:

    - Sonos firmware updates
    - PI updates
    - HS3 updates

    I have performed a few network changes since then, partially for other reasons, and partially to try to resolve these issues.

    For sure, I can try to get some more detailed logging when the behaviour occurs to try to resolve the issue, I'll attempt to make that happen and will post the results. I appreciate you being willing to take a look.


    regards,

    Paul
    Well if there is no FW then we can rule that out
    If you look through your current log, do you see log entries of players dropping out and coming back?

    So next time it happens:

    a/ turn debug on
    b/ set UPNP logging to verbose
    c/ turn log to disk on
    d/ do some actions on PI and Sonos controller
    e/ wait about 45 minutes, it will be a big log but might be worth it.
    f/ turn logging to disk off (IMPORTANT it closes and writes to the log file)
    g/ pm log and tell me which player didn't respond to which commands you did at what time

    Questions: what OS are running this on? VMs involved? Any managed switches between HS PC and Sonos?

    Sonos provided a UPNP view in the past, but I can't find it anymore, so they may have removed it The fact that the Sonos app still works is making this somewhat strange. If the HS PC is windows, perhaps install the Sonos App on it, would be curious to see if that would still work. Make sure UPNP logging is set to errors only, at least we can spot UPNP issue if any prior to it all going south on us.

    Dirk

    Leave a comment:


  • paul
    replied
    Originally posted by dcorsus View Post

    I sound like a broken record but the largest cause of the symptoms you describe is associated with firewalls and yes, they track source and destinations so you could end up with a specific player being firewalled while others are fine. If you can issue commands but don't get updates, 100% sure firewall! Now it could be that some player is say, wireless and on occasion goes in and out, that the PI over time gets into a state it shouldn't, a long term debug log might catch that.

    When it happens, have you tried to
    a/ stop the FW for at least a discovery cycle (30min 1h) and see if the problem goes away
    b/ restart the PI and see if that cures it,
    c/ restart HS and see of that cures it,
    d/ restart the PC you run this on

    Is this a windows platform? If so, which firewall is active. Do you have a "managed" switch between your HS PC and your player, if so, check what IGMP snooping is set to.

    Just some pointers.

    I wouldn't put a z-wave device to boot the player but see how, apart from the player reboot, you can "cure" the system and then start from there. There is another thread here somewhere where (I believe) Wim was complaining every 10 days or so, he would get into the same situation. I haven't heard from him in months so perhaps the issue is gone. I recommended him (and also you :-)) to turn the debug flag on, log to disk, either do it when stuff doesn't work anymore, or even better, let it run from start-up to when it goes south, then close logging to disk and pm or post the log file. Before you close the logging to disk, issue some commands (play, pause....), take screen shots of player table and UPNP device table and describe which player is not working. Post it all and I'll have a look at it.

    Dirk
    Hi Dirk, to answer your questions, I don't have a FW running between the sonos devices and my HS3 server. Firewall is also disabled on the HS server and there is no 3rd party FW running on the box. I afraid I disagree that firewall is the issue here, because there simply is no firewall, hardware nor software, in between HS3 and the speakers.

    I have tried stopping and starting the PI when these behaviours kick in, and have tried restarting HS and the server, to no avail.

    In each case, the only thing that resolved the problem was restarting the individual Sonos speaker. And in each case, the Sonos UI was always still working, from multiple different devices, it was only connectivity between Sonos and HS3 that was broken.

    Things were super-stable for several years, and there were zero changes to the network infrastructure, the Sonos physical or configuration infrastructure, and the Server configuration (even patching) for at least 10-12 months prior to the behaviours starting. The only things that changed in that time were:

    - Sonos firmware updates
    - PI updates
    - HS3 updates

    I have performed a few network changes since then, partially for other reasons, and partially to try to resolve these issues.

    For sure, I can try to get some more detailed logging when the behaviour occurs to try to resolve the issue, I'll attempt to make that happen and will post the results. I appreciate you being willing to take a look.


    regards,

    Paul

    Leave a comment:


  • dcorsus
    replied
    ...if you are having this situation and you were not logging anything, before restarting anything, turn disk log on, turn debug on, set UPNP logging to "verbose", now leave it for at least 45 min, do something with the PI such as try to stop/pause a player, do something on the player using the Sonos App, after 45 min, turn log to disk off and post or pm me the log file. Tell me which player and provide screenshot of player table and upnp device table (click on button of config page to view UPNP/player devices)

    Leave a comment:


  • dcorsus
    replied
    did I mention ...... you should set UPNP logging to errors only, so at least we can see if/when a renewal is refused, we see an error

    Leave a comment:


  • dcorsus
    replied
    Originally posted by paul View Post
    So, to go back closer to the root of the Original Poster's question, I'm also interested in reboots. Will likely need to use a z-wave adapter for now. I've been having issues where periodically Homeseer will stop communicating with individual speakers. I suspect that something has changed, either in the Sonos firmware or in the Plugin, because for years I had rock solid connectivity between Sonos and Homeseer, but in the last 6 months it's been more flakey. Every once in awhile a speaker just *stops* communicating with HS, but is still working fine in the Sonos UI.

    Sometimes it will be that HS cannot control Sonos (ie. play a song or change volume, but Sonos doesn't respond). Sometimes it will be that HS will stop picking up Sonos changes (ie. triggering an event based on a specific song starting on the speaker). Sometimes both. In either case, if it happens, the only fix is to power cycle the individual speaker. Once it comes back and re-registers itself, all communication is restored. The issue seems to be tied to individual speakers - as in, Speaker A might stop working, but Speaker B still works, or vice versa.

    In all cases, the speakers still appear, and work fine, with the Sonos App.

    Perhaps I'm taking another tangent rather than really getting back to the OPs question, but being able to remotely reboot my speakers would of course help me manage this issue. Ideally though, if I could resolve the root issue then reboots would no longer be necessary.....

    regards,

    Paul
    I sound like a broken record but the largest cause of the symptoms you describe is associated with firewalls and yes, they track source and destinations so you could end up with a specific player being firewalled while others are fine. If you can issue commands but don't get updates, 100% sure firewall! Now it could be that some player is say, wireless and on occasion goes in and out, that the PI over time gets into a state it shouldn't, a long term debug log might catch that.

    When it happens, have you tried to
    a/ stop the FW for at least a discovery cycle (30min 1h) and see if the problem goes away
    b/ restart the PI and see if that cures it,
    c/ restart HS and see of that cures it,
    d/ restart the PC you run this on

    Is this a windows platform? If so, which firewall is active. Do you have a "managed" switch between your HS PC and your player, if so, check what IGMP snooping is set to.

    Just some pointers.

    I wouldn't put a z-wave device to boot the player but see how, apart from the player reboot, you can "cure" the system and then start from there. There is another thread here somewhere where (I believe) Wim was complaining every 10 days or so, he would get into the same situation. I haven't heard from him in months so perhaps the issue is gone. I recommended him (and also you :-)) to turn the debug flag on, log to disk, either do it when stuff doesn't work anymore, or even better, let it run from start-up to when it goes south, then close logging to disk and pm or post the log file. Before you close the logging to disk, issue some commands (play, pause....), take screen shots of player table and UPNP device table and describe which player is not working. Post it all and I'll have a look at it.

    Dirk

    Leave a comment:


  • paul
    replied
    So, to go back closer to the root of the Original Poster's question, I'm also interested in reboots. Will likely need to use a z-wave adapter for now. I've been having issues where periodically Homeseer will stop communicating with individual speakers. I suspect that something has changed, either in the Sonos firmware or in the Plugin, because for years I had rock solid connectivity between Sonos and Homeseer, but in the last 6 months it's been more flakey. Every once in awhile a speaker just *stops* communicating with HS, but is still working fine in the Sonos UI.

    Sometimes it will be that HS cannot control Sonos (ie. play a song or change volume, but Sonos doesn't respond). Sometimes it will be that HS will stop picking up Sonos changes (ie. triggering an event based on a specific song starting on the speaker). Sometimes both. In either case, if it happens, the only fix is to power cycle the individual speaker. Once it comes back and re-registers itself, all communication is restored. The issue seems to be tied to individual speakers - as in, Speaker A might stop working, but Speaker B still works, or vice versa.

    In all cases, the speakers still appear, and work fine, with the Sonos App.

    Perhaps I'm taking another tangent rather than really getting back to the OPs question, but being able to remotely reboot my speakers would of course help me manage this issue. Ideally though, if I could resolve the root issue then reboots would no longer be necessary.....

    regards,

    Paul

    Leave a comment:


  • harvito
    replied
    I have been using SONOS speakers for many years - yes at one time it was difficult to find the sweet spot but these days they all seem to just run. Once the boost came out Vs the bridge things improved - then they introduced the ability to utilize your existing wireless network - mind you I have always used the SONOSNET except when I was beta testing the wireless implementation. I retired my boost and stuck with most speakers being wired when I could and never had issues - I run in two houses - the one in AZ I now use a boost as it is an apartment and I don't have the ability to run able everywhere. The boost works great - The larger the home the more complex things get (obviously) - I just sold a 2000 SQ foot home - okay not huge as in mansion - but I had speakers on the first floor, second floor, basement, garage, and deck area - they were rock solid - SONOS did mesh before mesh was 'the thing' - Great company - Great speakers - Anyway, I agree with @dcorus - SOLID product - I too have no relationship - Buy BOSE and expect no updates within a year - buy SONOS (I have 7 year old speakers) they still get updates and still get better - Now they have in ceiling speakers so no more need to run wires from SONOS amps through the walls. I could go on and on --- I'll shut up now

    Leave a comment:


  • dcorsus
    replied
    Originally posted by upstatemike View Post

    Maybe you are right but with over 100 network devices at this point and mostly all live 24/7 I feel I need to push back on Sonos a little bit on being so sensitive to network environment realities. There are only 3 non-overlapping 2.4GHz channels available and if you use 2 in alternation to space out your wireless access points and one for Sonosnet you don't have much of anyplace left to go to get away from interference. Agree on a single wired connection unless you have players beyond Sonosnet range and I have avoided going to managed switches specifically to avoid causing Sonos issues. I don't see network congestion improving anytime soon so I hope Sonos plans to find ways for their stuff to get along better in an increasingly congested Wi-Fi environment.
    I'm not trying to sound argumentative here but I'm trying to make a point to user who have issues that doing low-latency-synchronized-streaming applications over wireless is a lot harder then just some non-latency sensitive data. I don't believe Sonos is more fickle or "needs to play nicer", the application they support is just a lot more demanding and therefore you may have to give a bit more TLC than your average other app. If you do synchronized audio streaming over a network, newer technologies like MIMO are at times the problem rather than the solution because they were designed around bursty clients as opposed to always transmitting/receiving clients.

    A problem that I do agree with is that Sonos implemented a full mesh approach from day one, which means that any device communicates with any other device so traffic between players scales exponentially. So any event from one player gets transmitted through TCP to all other players. I believe that is one of the reasons, perhaps the biggest reason why Sonos only allows 32 players in a single network. Moreover, to support this mesh, Sonos relied on basic networking principles where players are like switches, so they can forward traffic. You have to give it to them, they do something for over a decade that WAPs today are trying to do (built a mesh and forward or repeat between APS). This strength is at times also their weakness because it requires a 100% properly functioning Spanning Tree and you'll find a lot of postings about Sonos issues around the fact that installations done by us end-users violate the principles that all IT-Networking people learn day one of networking. I actually believe that the reason why most folks suggest you have only one ingress/egress point into the Sonos network is exactly because of (R)STP CONFIG issues. I'm also pretty sure that (at least the earlier devices) forwarded traffic in SW, so any network loop would indeed cause players to crash and restart.

    Anyway, my point being, Sonos does need some more TLC because the real-time behavior is more demanding than a lot of other things, less so because their SW or HW is inferior, to the contrary, I would argue it is pretty robust all around. Because they can forward traffic, having a weak link somewhere might cause the occasional drop of a player or sometimes isolation from the group.

    Dirk.
    disclaimer: I have ZERO relationship with Sonos, just love their product, have them for a decade, have all models except for ZP80 and PlayBase

    Leave a comment:


  • upstatemike
    replied
    Originally posted by dcorsus View Post
    Gotcha on not wanting to crawl into loft space all the time ...

    If you do want to get an idea about the quality of your Sonos network, pick any player's IP address and substitute the xxxx in this URL http://xx.xx.xx.xx:1400/support/review with your IP address, wait until you see the result, click on Network Matrix. If you see a lot of red your network need some TLC.
    To upstatemike : what you describe still smells almost 100% network (config) issues. There have been some excellent postings on this forum about config settings, in general they come down to:

    1) wireless interference gets resolved by picking other channels on Sonosnet or on other (competing) wifi networks in the house. The URL and displaying of the network matrix appears the best way to get on top of things
    2) Mix of wired versus wireline connected players. A few users have empirically shown that the best way is to wired connect only ONE player (or Sonos Boost) and let SonosNet do its thing
    3) Broadcasting/Multicasting issues: I struggled with this myself for quite a while, this shows itself when you have managed switches in your network and really depends on the functions of the switch whether you should enable IGMP snooping or turn it all off. In home networks, I would recommend you turn snooping off, there isn't that much to be saved to "optimize" multicasting to (only) subscribed ports as opposed to replicate it over all ports.

    Dirk
    Maybe you are right but with over 100 network devices at this point and mostly all live 24/7 I feel I need to push back on Sonos a little bit on being so sensitive to network environment realities. There are only 3 non-overlapping 2.4GHz channels available and if you use 2 in alternation to space out your wireless access points and one for Sonosnet you don't have much of anyplace left to go to get away from interference. Agree on a single wired connection unless you have players beyond Sonosnet range and I have avoided going to managed switches specifically to avoid causing Sonos issues. I don't see network congestion improving anytime soon so I hope Sonos plans to find ways for their stuff to get along better in an increasingly congested Wi-Fi environment.

    Leave a comment:


  • dcorsus
    replied
    Gotcha on not wanting to crawl into loft space all the time ...

    If you do want to get an idea about the quality of your Sonos network, pick any player's IP address and substitute the xxxx in this URL http://xx.xx.xx.xx:1400/support/review with your IP address, wait until you see the result, click on Network Matrix. If you see a lot of red your network need some TLC.
    To upstatemike : what you describe still smells almost 100% network (config) issues. There have been some excellent postings on this forum about config settings, in general they come down to:

    1) wireless interference gets resolved by picking other channels on Sonosnet or on other (competing) wifi networks in the house. The URL and displaying of the network matrix appears the best way to get on top of things
    2) Mix of wired versus wireline connected players. A few users have empirically shown that the best way is to wired connect only ONE player (or Sonos Boost) and let SonosNet do its thing
    3) Broadcasting/Multicasting issues: I struggled with this myself for quite a while, this shows itself when you have managed switches in your network and really depends on the functions of the switch whether you should enable IGMP snooping or turn it all off. In home networks, I would recommend you turn snooping off, there isn't that much to be saved to "optimize" multicasting to (only) subscribed ports as opposed to replicate it over all ports.

    Dirk

    Leave a comment:


  • X10Ben
    replied
    I'm hoping my issues are behind me now as we've had a lot of renovation work going on where the electricity was turned off many, many times. To have a clean startup I generally need to power up devices such as my managed switch in a certain order. Plus I wasn't always at home when this was done.

    I have a Play One powered from above in the loft/attic space. If it threw a tizzy I had to get the step ladder out and get in the loft space and power cycle (which was easier than pulling the chord out of the unit as that was a very snug fit)

    Its on a Z-WAVE plugin module now, so no issue when it (if it) happens again.

    Leave a comment:


  • upstatemike
    replied
    Originally posted by dcorsus View Post
    Curious why you would need to reboot players on a periodic basis? I have many and for many years, I've never ever had to reboot one. I suspect if they become unresponsive, there is a network issue hiding and they just become unreachable. There are a few here on the forum who know a lot about troubleshooting network issues with Sonos. Care to go into detail what is happening, when, which players, how your network is built?
    Happy to assist,
    Dirk
    I am using Sonsnet with all IP addresses reserved and yet still occasionally have issues that require a power cycle to resolve. Usually a player will disappear or be unresponsive to configuration from within the Sonos controller. I don't think the root cause is networking but rather a glitch or lockup within the Sonos Player. I only use ZP90 (Connect) and ZP120 (Connect Amp) units so maybe the issues are limited to those models.

    Leave a comment:

Working...
X