Announcement

Collapse
No announcement yet.

'Speak Something' ... someone please put me out of my misery

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

  • 'Speak Something' ... someone please put me out of my misery

    Rule one, don't tinker if it works ... which I have and now it doesn't work :-(

    I've done a spring clean and purged/recreated events and updated my naming conventions. However I thought I'd put everything back correct. I obviously haven't as I literally cannot see the wood for the trees. Grateful if someone can point me in the right direction. Thank you.

    1. Here's part of my event which gets triggered when the garage door opens … (I can confirm the event fires off because device values pre and post this part work accordingly and the Z-Wave motion triggers)

    Click image for larger version

Name:	a.PNG
Views:	266
Size:	17.9 KB
ID:	1312634

    2. Here's my config

    Click image for larger version

Name:	c.PNG
Views:	229
Size:	51.6 KB
ID:	1312636

    Thanks for looking.



    Attached Files

  • #2
    Just checked against my Sonos announcements, and I cannot see anything wrong. Can you see any error in the log ? Have you tried adding another action, just to see if the event really fires. I normally add a pushover message, to quickly see if my event has fired as it should. If your event does trigger, I am lost too...

    Comment


    • #3
      Thanks for the quick reply mikee123

      No errors in the log and both pre and post actions as shown here work.

      Click image for larger version

Name:	d.PNG
Views:	233
Size:	54.5 KB
ID:	1312640

      Comment


      • #4
        Have you tried disabling the PI, then enabling it again, that sometimes has worked for me when I had no announcements

        Comment


        • #5
          Do you log the event to ensure it is running?
          Will the event Speak thru the HS Speaker client itself? Is so, sort of has to be the PI.
          Real courage is not securing your Wi-Fi network.

          Comment


          • #6
            Turn PI debug flag on, trigger event, post log

            Comment


            • #7
              Thanks every one …

              Attached Files

              Comment


              • #8
                Originally posted by X10Ben View Post
                Thanks every one …
                Is the office player on-line AND reachable? What is the player table showing (bottom of config page)? Which PI version is this? Which OS?
                Try to change the source player from office to say Hallway and try again.

                Comment


                • #9
                  Yes the Office player is reachable and works. All showing online in the config table. PI version is 3.1.0.28. OS is Win 10 Pro 64 Bit.

                  I've tried the Hallway player still no joy. Should I delete the SONOS PI .ini file and restart HOMESEER?



                  Click image for larger version

Name:	e.PNG
Views:	192
Size:	38.6 KB
ID:	1312920

                  Comment


                  • #10
                    The log file showed no events or any activities for that matter coming from the Office player. You could delete the sonos.ini file WHEN HS3 is not running, but the log didn't show evidence of corruption unless you deleted manually devices from the device management page or moved or restored databases. So before we delete things, if you use the device control functions and say you issue a play or pause command by clicking the controls of the Office player on the HS device management page, can you control the player? More importantly, do the states of the device update properly? If you can control the player but the status isn't updating you have almost 100% sure no firewall allowance (assuming no DB corruption). Is your Firewall allowing the PI all access? Note it is the hspi_sonos.exe that needs allowance.

                    Comment


                    • #11
                      Its working! Not sure what's happened.

                      dcorsus sus, I done what you suggested, controlled the SONOS from the devices page. No issue there. So didn't bother to delete the .ini file.


                      I started playing with different players in the group and this done nothing. So I then done another group. Which worked. Swapped it all back to the original and it worked.

                      Happy again …. so thanks for all your help!! :-)

                      Comment


                      • #12
                        I have similar issues here. Once the sonos plufin is running for around 10 or more days, updates of status fail, including speak commands, that do not get executed or get a timeout. All players show no errors. But the status of devices are off sync. I can check this especially on my playbar, which seem to report a old status - TV is on and TV Input should be the status as the sound is going over the playbar, but status show different.
                        Restarting the plugin solves the issue, no need to delete the ini file. Status of the playbar in this case shows TV input as it should. I have worked around this by restarting the plugin once every week.

                        Wim
                        -- Wim

                        Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
                        650 devices ---- 336 events ----- 40 scripts

                        Comment


                        • #13
                          Originally posted by w.vuyk View Post
                          I have similar issues here. Once the sonos plufin is running for around 10 or more days, updates of status fail, including speak commands, that do not get executed or get a timeout. All players show no errors. But the status of devices are off sync. I can check this especially on my playbar, which seem to report a old status - TV is on and TV Input should be the status as the sound is going over the playbar, but status show different.
                          Restarting the plugin solves the issue, no need to delete the ini file. Status of the playbar in this case shows TV input as it should. I have worked around this by restarting the plugin once every week.

                          Wim
                          Hi Wim, unless this is a Linux set-up, your description matches 100% a firewall problem. Remember: the default behavior of a firewall is stateful, which means that ANY incoming message to an unknown destination is actively refused UNLESS there is "history". History or state is established when a local source initiates a connection (message) to an outgoing destination. The firewall works on the principle that if the local source initiated the communication, it must be OK and therefore subsequent messages from the destination to the source are allowed. After a fixed timeout of no activity, the "state" is removed in the firewall and all incoming messages are actively refused again. So unless you have set your Ethernet port to a trusted "private network" (if you use Windows defender) OR the FW was instructed to allow explicitly messages to the application (in this case HSPI_Sonos.exe), after a period of inactivity, all autonomous messages to the PI are dropped by the FW and the PI is not getting the proper state of the player. Unless you have HSTouch screens and you periodically look at state of devices, this mis-configuration goes mostly unnoticed until an announcement is handled. That's when a lot of things start going wrong because the PI has actually no idea what the state of your players are and starts doing wrong things, mostly leading to announcements not working at all. A restart of the PI tends to get it going again for a while because at restart, the PI establishes all the TCP connections with all the players so the FW is fat and happy, but after a fixed period of inactivity on behalf of the PI, the FW does what it is supposed to do, refuse incoming traffic unless told differently.

                          Hope this helps,

                          Dirk

                          Comment


                          • #14
                            If it would have been a firewall issue, calls would be blocked from the start, not after 10 days of running. This really does not fit a firewall issue - as it would be weird that the firewall would spontaniously discover issues after 10 days?
                            Every reboot of HS, every restart of the plugin solves the issue? There is no way this has anything to do with firewalls. Not local nor public.
                            I have double checked the local windows firewall and all is allowed for the HSPI_Sonos executable, without any restriction. Even both public as local network are enabled.
                            I do have HSTouch screens active and at the moment the issue occurs, the state the plugin is showing is faulty, it shows the last speak action and not TV Input. The plugin just stops updating the devices, that is how I recognize the issue. And as said, restarting the plugin does solve the issue.
                            It is really not a firewall issue, otherwise it would still continue block updates of the state, even after a restart.......

                            I am quite sure that after the long run, the plugin just gets out of sync for some reason, but it is not sa firewall issue, otherwise I would have other issues as well.

                            Attached Files
                            -- Wim

                            Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
                            650 devices ---- 336 events ----- 40 scripts

                            Comment


                            • #15
                              Originally posted by w.vuyk View Post
                              If it would have been a firewall issue, calls would be blocked from the start, not after 10 days of running. This really does not fit a firewall issue - as it would be weird that the firewall would spontaniously discover issues after 10 days?
                              Every reboot of HS, every restart of the plugin solves the issue? There is no way this has anything to do with firewalls. Not local nor public.
                              I have double checked the local windows firewall and all is allowed for the HSPI_Sonos executable, without any restriction. Even both public as local network are enabled.
                              I do have HSTouch screens active and at the moment the issue occurs, the state the plugin is showing is faulty, it shows the last speak action and not TV Input. The plugin just stops updating the devices, that is how I recognize the issue. And as said, restarting the plugin does solve the issue.
                              It is really not a firewall issue, otherwise it would still continue block updates of the state, even after a restart.......

                              I am quite sure that after the long run, the plugin just gets out of sync for some reason, but it is not sa firewall issue, otherwise I would have other issues as well.
                              When you restart the PI or HS, the PI INITIATES the connections so the firewall is fat and happy until its state times out due to inactivity, then it actively blocks. I have have no stake in arguing whether who is right or wrong, I do spend my free time responding though with what I think is the right solution. My posting is based on the tons of postings people made, which, with these symptoms, almost ALWAYS turned out to be firewall issues. There are easily a few hundred of users out there, probably close to a thousand and those that complain that after xx days/hours the PI doesn't update state BUT they can still control the device but all is well after a restart (on Windows), as I said 100% firewall. In fact I have seen cheap/free FW software go bunkers after many days, can't say I have seen Windows defender issues unless not configured properly. Why, sorry can't explain what exactly windows defender does compared to McAfee or other Firewalls. I see 6 entries in your firewall, I would have expected 2 or 4 not 6. What is the difference? They should be ALL ports UDP and all ports TCP for private or public (prive of openbaar).

                              So here is what we can do, next time, the PI doesn't update state, turn debug flag on, issue some commands FROM the PI to play/pause etc. note whether that works and take note whether the state updates or not. You can as a try disable the FW and see if it works or not, although I have to admit I'm not sure what state the actual TCP connections might be in at that point. If you cannot control the player, check the state of the players in the player control table, if they got lost on the network, we have another issue.

                              So if you can check what the difference is between the 6 entries in your FW rule table, you can reduce it to 2, one for UDP all ports, one for TCP all ports and with profile set to all (prive, openbaar, domein)

                              Dirk

                              Comment

                              Working...
                              X