Announcement

Collapse
No announcement yet.

Remotely reboot a SONOS device

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

    #16
    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

    Comment


      #17
      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

      Comment


        #18
        ...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)

        Comment


          #19
          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

          Comment


            #20
            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

            Comment


              #21
              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

              Comment


                #22
                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

                Comment


                  #23
                  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?

                  Comment


                    #24
                    So..... where does the log get saved when you close off the log? Dumb question I know, but I can't find a readable log. There's HomeseerLog.hsd, but that's not text readable....

                    Comment


                      #25
                      Originally posted by paul View Post
                      So..... where does the log get saved when you close off the log? Dumb question I know, but I can't find a readable log. There's HomeseerLog.hsd, but that's not text readable....
                      <hsroot>\html\Sonos\Logs

                      Comment


                        #26
                        Ok. Here's a URL attached with a Zip file that contains the following:

                        - harley_event.png - the event that sets up sonos in Harley's room
                        - zander_event.png - the event that sets up sonos in Zander's room
                        - SonosDebug.txt - the Sonos debug log
                        - HomeSeerLog.hsd - the homeseer db log that includes the timeframe of the SonosDebug log. If you don't have a tool to read it and want to read it let me know and I'll see if I can extract what's needed from it.

                        Basically, the above two events do this:
                        - Trigger either manually or when the specified white noise track gets turned on by other means
                        - Unlink "Harley's Room" from any other rooms it might be grouped to.
                        - Set the volume
                        - Clear the queue and setup the specified white noise song by itself
                        - turn Repeat On

                        I did the following:
                        Sept 6, afternoon:

                        - 16:00:25-ish - Turned up volume via Sonos Controller in Harley's room (is reflected in debug log at 16:00:26)
                        - 16:00:51 - Ran HS Event "Harleys Room Play White Noise"
                        - Result was that the volume lowered to the specified level in her room, but the playlist did not change.
                        - 16:01:18 - Ran HS Event "Zanders Room Play White Noise"
                        - Result was that the volume lowered to the specified level in his room, but the playlist did not change.

                        There was a lot of stuff in the middle of all that, that I had difficulty interpreting - perhaps you'll see something that pops out at you (?).

                        http://www.fielding.ca/SonosDebug.zip

                        Regards,

                        Paul

                        Comment


                          #27
                          Weird that the URL link at the bottom kept strippign out the file, but I think I successfully have the URL added to the message now....

                          Comment


                            #28
                            Originally posted by paul View Post
                            Ok. Here's a URL attached with a Zip file that contains the following:

                            - harley_event.png - the event that sets up sonos in Harley's room
                            - zander_event.png - the event that sets up sonos in Zander's room
                            - SonosDebug.txt - the Sonos debug log
                            - HomeSeerLog.hsd - the homeseer db log that includes the timeframe of the SonosDebug log. If you don't have a tool to read it and want to read it let me know and I'll see if I can extract what's needed from it.

                            Basically, the above two events do this:
                            - Trigger either manually or when the specified white noise track gets turned on by other means
                            - Unlink "Harley's Room" from any other rooms it might be grouped to.
                            - Set the volume
                            - Clear the queue and setup the specified white noise song by itself
                            - turn Repeat On

                            I did the following:
                            Sept 6, afternoon:

                            - 16:00:25-ish - Turned up volume via Sonos Controller in Harley's room (is reflected in debug log at 16:00:26)
                            - 16:00:51 - Ran HS Event "Harleys Room Play White Noise"
                            - Result was that the volume lowered to the specified level in her room, but the playlist did not change.
                            - 16:01:18 - Ran HS Event "Zanders Room Play White Noise"
                            - Result was that the volume lowered to the specified level in his room, but the playlist did not change.

                            There was a lot of stuff in the middle of all that, that I had difficulty interpreting - perhaps you'll see something that pops out at you (?).

                            http://www.fielding.ca/SonosDebug.zip

                            Regards,

                            Paul
                            quick look seems to suggest that the track is not found. Is the MusicDB gone or not up to date OR the track info somehow changed?

                            Comment


                              #29
                              Originally posted by dcorsus View Post

                              quick look seems to suggest that the track is not found. Is the MusicDB gone or not up to date OR the track info somehow changed?
                              Hmmm. The song is definitely still there - I can play it manually, and I’m confident it hasn’t changed. Could it be some issue with the way the nfs mount on the Sonos side mounts the share it’s getting it from? I’ll do some digging on that to see if something has gone squirrelly there.

                              Certainly a different issue than my original concern, when I next run into the issue where it doesn’t talk at all to the speaker, I’ll do a debug run again and also maybe try a localized controller on the server to see if there’s any communication issue there....

                              thank you for looking at the log!

                              Paul

                              Comment


                                #30
                                Originally posted by paul View Post

                                Hmmm. The song is definitely still there - I can play it manually, and I’m confident it hasn’t changed. Could it be some issue with the way the nfs mount on the Sonos side mounts the share it’s getting it from? I’ll do some digging on that to see if something has gone squirrelly there.

                                Certainly a different issue than my original concern, when I next run into the issue where it doesn’t talk at all to the speaker, I’ll do a debug run again and also maybe try a localized controller on the server to see if there’s any communication issue there....

                                thank you for looking at the log!

                                Paul
                                If you say “I can play it manually”, is this through Sonos app or player control? Use the player control to navigate and see it still there. I suspect your musicDb somehow got corrupt, so recreate it. You can also create the event again see what track you get. If there is only a letter off in the track info, it won’t be found anymore

                                Comment

                                Working...
                                X