Announcement

Collapse
No announcement yet.

Plugin's devices no longer able to control thermostats

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Plugin's devices no longer able to control thermostats

    HS version: 4.2.13.0
    Plugin version: 4.2.0.10
    HS server OS: Win10 Pro
    Thermostat model: RTH6580WF (2 ea.)
    Data dump: attached
    Log file: attached

    Description of problem:

    Used v.3 of the plugin for years without issue. Upgraded to v.4 recently and I *think* it worked initially although not certain. Two identical thermostats in vacation property, not used since before PI update to v.4 so no attempts to check or change tstat settings and not sure sure when problem arose. An event sets both thermostats' heat and cool setpoints and permanent hold (on) when we're arriving at the house. A second event does exactly the same with "eco" setpoints when we leave. Otherwise I seldom if ever interact with the plugin except for occasional version updates.

    Updated PI to 4.2.0.10 this morning and saw HS features weren't updating properly. Opened PI config and credentials weren't entered (maybe missing since upgrade to v.4?). Added credentials and both tstats were immediately found. New HS devices/features weren't created--thankfully.

    When I run one of the events to set all heat/cool setpoints, the HS features update to the new values and capi control entries are logged in HS as expected. No errors. But the updates never reach the cloud. Even after waiting through multiple update cycles, the HS features show the values entered by the event, even though the TCC app and web interface never reflect the new values. Only when I click "Update" on the Status feature do the HS features revert to the prior settings--i.e., the actual settings on the thermostat since the new values weren't received from the plugin.

    I believe the trace log should reflect a run of each of the events described above. Thank you for looking into it.

    Honeywell_tstat_dump.txt
    HSPI_SKWARE_HW_WIFI_TSTAT.txt
    -Wade

    #2
    I'm looking into this now - the issue is that I'm sending a request to change setpoint without sending the "hold" part of the command when executing the setpoint change. The reason I'm not sending the hold part is because my interpretation of your thermostat data is that it doesn't support holds.

    "HoldUntilCapable": false <---- this means you shouldn't have "temporary" hold capabilities
    "VacationHoldCancelable": false <----- this means you shouldn't have "permanent" hold capabilities

    (At least compared to my 2 models of HW tstats, both of which say "true" for both of those settings.)

    I also found a "bug" in my logic where I give you a hold device and controls for both temporary and permanent holds even though I don't think your thermostat supports them.

    What model thermostat are you using?

    Can you grab another log file where you don't change the setpoint but instead just send a permanent hold?

    Comment


      #3
      Also: what capabilities does the app/TCC portal offer in terms of holds?

      Comment


        #4
        Both thermostats are Honeywell model RTH6580WF. Here's the manual.

        Realized during testing this morning that I didn't have schedules defined for either tstat. After defining them it appears the hold capabilities are reporting differently. This seems to have changed some of the behavior I reported above, although the plugin hold feature still isn't working.


        Here's what I see on the portal. The other tstat display is identical.

        Click image for larger version

Name:	image.png
Views:	94
Size:	182.0 KB
ID:	1583814
        Temporary hold.
        Click image for larger version

Name:	image.png
Views:	89
Size:	187.2 KB
ID:	1583812
        Permanent hold.
        Click image for larger version

Name:	image.png
Views:	92
Size:	183.9 KB
ID:	1583813​​


        Here's the log where I sent permanent hold to each one from the plugin Hold Type feature. I first set them to follow schedule, though the feature still reported Permanent Hold.

        [ATTACH]n1583815[/ATTACH]
        Attached Files
        -Wade

        Comment


          #5
          Have you restarted the plugin since you made the changes?

          Comment


            #6
            I had not, and doing so has it mostly working. Great! A new Hold Type feature was created for each thermostat, with 3 control settings as expected. These are working, as are the other features' controls. The only thing not working is that the plugin features aren't updating automatically. I.e., if I make changes via the phone app or web interface (or, presumably, at the tstats themselves although I'm not there to test), the HS features don't update to reflect the changes until I manually click Update on the status features. I waited a few minutes and refreshed the HS device page to be sure. Here are my settings:

            Click image for larger version

Name:	image.png
Views:	84
Size:	18.2 KB
ID:	1583844
            -Wade

            Comment


              #7
              Cool - knowing about the schedule causing hold types to not be there is definitely good info for future troubleshooting!

              It will take up to 5 minutes for any external changes to be retrieved by the plugin. You can monitor the frequency and success/failure of each update via the "Status" device's value and "last updated" timestamp.

              Comment


                #8
                Originally posted by shill View Post
                It will take up to 5 minutes for any external changes to be retrieved by the plugin. You can monitor the frequency and success/failure of each update via the "Status" device's value and "last updated" timestamp.
                You're right, I didn't wait long enough. All appears to be working!

                Out of curiosity, why are external changes not updated with each poll?


                -Wade

                Comment


                  #9
                  They are - the plugin polls the website for the latest data every 5 minutes and it updates any changes that it finds on each polling cycle.

                  Comment


                    #10
                    If your question is "why aren't external changes reflected immediately", it's because the TCC website isn't a direct connection, it can only be read via polling. And if you do that too often, your account will get locked out. Hence the default polling interval of 300 seconds (5 minutes) and manual update limit of 30 seconds (since you can get away with it a few times before it triggers a block).

                    Comment


                      #11
                      Thanks. Was misreading or misinterpreting the frequency setting.
                      -Wade

                      Comment


                        #12
                        Closing this as resolved.

                        Comment

                        Working...
                        X