Announcement

Collapse
No announcement yet.

Support for Set Drying Mode command

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

    #16
    It's just a property of the device - it's not currently accessible to you.

    As far as "an API call to fetch this data", the answer is "no" - Honeywell does not offer an API for TCC devices. You'd need to essentially reinvent the wheel and write your own plugin.

    What are you hoping to get out of that data that isn't already exposed via devices?

    Comment


      #17
      I was hoping that somehow the t-stat reports out some (other) parameter that is different when in DRYING mode versus OFF mode. Right now in the web page and in the INI file, OFF and DRYING are identical. Also looked at values of OPEr MODE, OPER STATUS, STATUS, and SYS Mode when in the different modes and OFF and DRYING are still identical. Even if there was, I still could not put the t-stat in DRYING mode.

      I also looked at Kumo Cloud setup and it does support drying mode but only from the cell app. No way I know of to access the phone app dashboard from Homeseer. Also it would cost $300+ to go that route. Also looked at Cool Automation software and hardware. They have a channel to Homeseer but would also be north of $300-400 to implement.

      So I am taking another route. I can generally tell what mode the t-stat is in from your plug-in except when I am in DRYING mode. So I thought all I really need to do is come up with a way to put the t-stat in drying mode right at the t-stat as there does not seem to be a way to do it otherwise. So I need a way to "push the button" from Homeseer. Enter SwitchBot; an automated button pusher. It is a small module with an "arm" operated by a servo that will rotate out and back when activated. It is paired to a hub that provides a connection to the internet. Placed close enough and strategically over the MODE button on the t-stat, it can push the MODE button as many time as I need. So I could use your plug-in to put the system in COOL and also check to see if it is in COOL. That would be my baseline. From there I have HS press the button twice and I am in DRYING mode. I can't verify it but need to trust it is. From there it is three button pushes to get back to COOL mode. I will be using IFTTT to detect a trigger in HS. That will run a scene on the SWITCHBOT system that will run a button push "N'" times.. I have tried this out using my porch lights and when I turn them on, the SWITCHBOT module runs three cycles of button press. A bit of a Rube Goldberg setup but it works and is quite inexpensive compared to the other (almost) solutions.

      So in the interim I was still hoping for a data difference some place as it might be more reliable.

      A questions for you. Looks like the update time for your plug-in to "notice" a mode change could be up to 240 secs (preferred setting)? Does Honeywell get annoyed if you check TCC more often then that? How much could I push that to run more often without them locking my account?

      Thanks for all your help so far.

      Comment


        #18
        Yes, it could be up to <polling frequency> seconds before HS notices a physical change on the thermostat. And yes, they get very annoyed - that's why there are so many max/limit/queue settings. There have even been people who got their accounts locked out and had to call and convince Honeywell to unlock it again.

        And I'm 99% sure you wouldn't find anything in the data, so if it were me, I wouldn't spend my time trying to solve it that way.

        Comment


          #19
          I think I had recently come to that conclusion as well. Will let you know how the button pusher works out.

          Comment


            #20
            Originally posted by cbabkirk View Post
            I think I had recently come to that conclusion as well. Will let you know how the button pusher works out.
            Hello,

            First I wanted to give you an update that I was able to implement the robot button pusher (Switchbot) device to select the Drying mode on the t-stat. I had to revert to using the Webhooks option in IFTTT as it seems the native Homeseer trigger actions in IFTTT are broken as indicated by many here that discuss that trying to use a Homeseer device on/off action is unreliable. Thanks for all your help to determine what was possible and what was not.

            Second, I believe when I first installed your plugin, the root device would report connection issues with the Redlink Gateway. I have had a few gateway off line errors since and the root device remains in an "unknown" status. Should the root device report things like connection problems and if so, what steps should I take to get it back reporting correctly again. I have tried stopping and restarting the plugin. I have tried deleting the t-stat, clearing any residual devices, and recreating it. I have tried stopping the plugin, deleting the t-stat, removing the INI file, restarting the plugin, and recreating the t-stat and still just get "unknow" for status of the root device. Is some other device suppose to report connections issues?

            Comment


              #21
              Originally posted by cbabkirk View Post
              Second, I believe when I first installed your plugin, the root device would report connection issues with the Redlink Gateway. I have had a few gateway off line errors since and the root device remains in an "unknown" status. Should the root device report things like connection problems and if so, what steps should I take to get it back reporting correctly again. I have tried stopping and restarting the plugin. I have tried deleting the t-stat, clearing any residual devices, and recreating it. I have tried stopping the plugin, deleting the t-stat, removing the INI file, restarting the plugin, and recreating the t-stat and still just get "unknow" for status of the root device. Is some other device suppose to report connections issues?
              The root device used to report connected/disconnected, but because for both HSMobile and HS4 we're not supposed to have status or controls on the root device, and because I NEVER saw anything other than "connected", I dropped that feature a while back. The "Status" device should report failure if any command doesn't succeed.

              Comment


                #22
                Hello....now I am on a quest to tell if the comm is lost between the t-stat and the gateway. In the data you display under "Current Thermostat Data" for the root device, you include a "communicationLost: parameter "false" or "true". How do you collect that thermostat data? Is that kept in an INI file someplace (something I could query)? Is it a web call? How can I get access to the status of that parameter. I know it is the status I need because the status changes to "TRUE" if I kill the gateway.


                Originally posted by cbabkirk View Post
                Hello,

                Do you keep the "Current Thermostat Data", listed under the Honeywell WiFi Thermostat tab of the root device, in an INI or LOG file on the HS server? I would like to scan that query response for values. Is there something like an API call that can be made to just fetch this data? I am using some of Jon's data scraper software to look through files or webpages.


                { "success": true, "deviceLive": true, "communicationLost": false, "latestData": { "uiData": { "DispTemperature": 76, "HeatSetpoint": 70, "CoolSetpoint": 76, "DisplayUnits": "F", "StatusHeat": 0, "StatusCool": 0, "HoldUntilCapable": true, "ScheduleCapable": true, "VacationHold": 0, "DualSetpointStatus": false, "HeatNextPeriod": 88, "CoolNextPeriod": 88, "HeatLowerSetptLimit": 63, "HeatUpperSetptLimit": 83, "CoolLowerSetptLimit": 67, "CoolUpperSetptLimit": 87, "ScheduleHeatSp": 70, "ScheduleCoolSp": 76, "SwitchAutoAllowed": true, "SwitchCoolAllowed": true, "SwitchOffAllowed": true, "SwitchHeatAllowed": true, "SwitchEmergencyHeatAllowed": false, "SystemSwitchPosition": 2, "Deadband": 3, "IndoorHumidity": 128, "DeviceID": 5005471, "Commercial": false, "DispTemperatureAvailable": true, "IndoorHumiditySensorAvailable": false, "IndoorHumiditySensorNotFault": true, "VacationHoldUntilTime": 0, "TemporaryHoldUntilTime": 0, "IsInVacationHoldMode": false, "VacationHoldCancelable": false, "SetpointChangeAllowed": false, "OutdoorTemperature": 128, "OutdoorHumidity": 128, "OutdoorHumidityAvailable": false, "OutdoorTemperatureAvailable": false, "DispTemperatureStatus": 0, "IndoorHumidStatus": 128, "OutdoorTempStatus": 128, "OutdoorHumidStatus": 128, "OutdoorTemperatureSensorNotFault": true, "OutdoorHumiditySensorNotFault": true, "CurrentSetpointStatus": 0, "EquipmentOutputStatus": null }, "fanData": { "fanMode": null, "fanModeAutoAllowed": false, "fanModeOnAllowed": false, "fanModeCirculateAllowed": false, "fanModeFollowScheduleAllowed": false, "fanIsRunning": null }, "hasFan": false, "canControlHumidification": false, "drData": { "CoolSetpLimit": null, "HeatSetpLimit": null, "Phase": -1, "OptOutable": false, "DeltaCoolSP": null, "DeltaHeatSP": null, "Load": null } }, "alerts": "\r\n\r\n" }

                Comment


                  #23
                  I'll have to add a separate device to expose that.

                  Comment


                    #24
                    I tried turning off my gateway but none of the existing status devices changed in any way. I was hoping that one of those would detect a com error. I did get an email from Total Connect that an attempted change could not be completed. So adding a new device for "communication status" would be much appreciated. Not urgent.

                    Comment


                      #25
                      When the STATUS device reports "Success" or "Failure", what is it checking and what does a status of Failure indicate?

                      Comment


                        #26
                        That the last command received an error reply from Honeywell's servers.

                        Comment


                          #27
                          Thanks for the context. It usually recovers fairly quickly.

                          Comment


                            #28
                            Originally posted by shill View Post

                            The root device used to report connected/disconnected, but because for both HSMobile and HS4 we're not supposed to have status or controls on the root device, and because I NEVER saw anything other than "connected", I dropped that feature a while back. The "Status" device should report failure if any command doesn't succeed.

                            Hello,

                            I seem to be getting a rash of Status conditions recently. The status will change with a value of 2 and report "Failed". Sometime later (sometimes less than a minute and sometimes several hours) it will report "Success". Usually this happens with no action on my part and can happen overnight or during the day. What should I be looking for as a cause for it to report "Failed"? Since this is just monitoring, it does not affect the operation of my heat pump. Is there a logging mode I can turn on that might offer more context?

                            Comment


                              #29
                              Yes, there's a very detailed trace log (see the sticky "having problems?") that should give us a good idea what's happening.

                              Comment


                                #30
                                Originally posted by shill View Post
                                Yes, there's a very detailed trace log (see the sticky "having problems?") that should give us a good idea what's happening.
                                I will give that a try and get back to you. Thanks.

                                Comment

                                Working...
                                X