Announcement

Collapse
No announcement yet.

Honeywell plugin exits shortly after HS3 restarts

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

    Honeywell plugin exits shortly after HS3 restarts

    Folks, I am having issues with the plugin shutting down shortly after HS3 restarts.

    I am getting this message in the logs: [5342530]Excessive thermostat commands detected - shutting down.

    Now, no thermostat commands are being sent as far as I know. What dos the error mean?

    I did redo some IP addresses today, including that of the HS3 machine, but I don't understand how that could cause this problem.

    All the polling etc... parameters are not close to minimums.

    thx
    mike

    #2
    That's really just there as a defense against a runaway event that's triggering way too often, usually by mistake...

    Comment


      #3
      Well, it's being triggered everytime I start up, so the plugin is not working for me I do have 8 thermostats though, could that be a problem?

      thanks,
      mike


      Comment


        #4
        Shouldn't be, as there need to be 25 commands (by default, unless you changed that value) before it freaks out. Check the Wifi Tstat INI file in your HS3\Config directory to see what it's set to (changes will be overwritten if the plugin is running, so if you want to try a higher number you can change it up to 50 in the options page or just edit this and then start the plugin.

        But even with 8 thermostats that should only be 8 commands... I'd need all the info from the "Having problems? Read this first" thread to provide any more help, though.

        Comment


          #5
          Well... After the plugin dies, you can't access the plugin's config page or the options pages to change the settings as defined in the "Having problems?" thread.

          I did find that if I turn off the plugin and then reenable it, the config and options page are available for a few seconds, and I managed to change the settings and capture the log info! It's attached...


          thanks!
          Attached Files

          Comment


            #6
            BTW, it looks like not all the log data was being captured by the download button before the plugin terminated. I have attached more info from the system log that I cut and pasted.

            thanks
            Attached Files

            Comment


              #7
              Shill, do you need any more info from me?

              Thanks!
              Mike

              Comment


                #8
                Originally posted by fresnoboy View Post
                Shill, do you need any more info from me?

                Thanks!
                Mike
                Just had a chance to look through this and unfortunately as you noticed the actual log file only shows it starting up then you downloading the file. If the log setting was left on TRACE then the plugin log file will have what I need, you just need to let the plugin start and wait for it to crash, then grab the file off the server. If it's not on TRACE, you'll need to edit the HSPI_SKWARE_HW_WIFI_TSTAT.ini file in your HS3 config directory and set the LogLevelFile option to 6, then start the plugin.

                Comment


                  #9
                  Sigh, this is painful. The plugin keeps crashing without letting me get the crashing event captured and letting me download the log before it goes unresponsive.

                  What I did was start the plugin, and then kept hitting download log until the plugin hung and wouldn't respond. I have attached a zip of all those downloads.

                  Why doesn't the plug log to the main homeseer log, so that if it does the log file is already written somewhere and I wouldn't have to try and fetch it before it dies?

                  Attached Files

                  Comment


                    #10
                    That's why I suggested you NOT use the download button but instead just grab the file off the server. And it can log to Homeseer but it doesn't allow me to put as much information that way. You can try turning up the other log setting and maybe I can get something from that, but I strongly prefer the plug-in log for real troubleshooting like this.

                    Comment


                      #11
                      Ah, sorry about missing that. Attached is the plugin log from the server.

                      thanks!
                      Attached Files

                      Comment


                        #12
                        Hi... Any updates? Can I provide you any more info to help debug this?

                        Comment


                          #13
                          Sorry, let this drop on accident. And I can't see anything in that log file that would be causing a problem. It only shows 4 commands being added to the queue. The default max queue size is 25 requests; did you change this? Best bet in your situation would be to leave the plugin stopped and look at the INI file directly, and if it's set to a low number, reset it to 25.

                          Comment


                            #14
                            Originally posted by shill View Post
                            Sorry, let this drop on accident. And I can't see anything in that log file that would be causing a problem. It only shows 4 commands being added to the queue. The default max queue size is 25 requests; did you change this? Best bet in your situation would be to leave the plugin stopped and look at the INI file directly, and if it's set to a low number, reset it to 25.
                            Thanks for the update! yes, the max queue size was set for 2. I think I had reset this to the minimum trying to debug the earlier signin issue awhile ago. There is a warning that having these set too high could cause the honeywell to blacklist you, so I had all these cranked down. I have reset the queue size to 25, and the plugin no longer exits. Why does the plugin exit if the max queue size is set too low? Seems like a log entry would be the more appropriate thing to do.

                            thanks
                            mike

                            Comment


                              #15
                              The reason the queue exists is to prevent flooding Honeywell with requests, typically caused by a runaway event with bad triggers/conditions - the kind of thing that happens frequently when creating new events. When it seems a bunch of events pouring in, it triggers a "circuit breaker" and just shuts down to give you a chance to fix it. The lower you set it, the lower your risk tolerance for getting your HW account locked.

                              Comment

                              Working...
                              X