Support for Set Drying Mode command

[cbabkirk]

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.

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" }

[shill]

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.

[cbabkirk]

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?

[cbabkirk]

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

[shill]

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.

[cbabkirk]

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.

[shill]

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?

[cbabkirk]

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" }

[cbabkirk]

Hello again. After several calls to Honeywell support it appears that even if the (Mitsubishi) t-stat I am using or even if I was to use a Honeywell WiFi t-stat that supported the drying mode, the TCC app does not know about other modes beyond OFF, HEAT, COOL, AUTO. Also the Mitsubishi t-stat I got with the system only talks REDLINK 1.0. There is a newer REDLINK 2.0 that supports from functions. Not sure what they are but would not matte in this case.

My next step is to consider if I can use a WiFi app to control my heat pump as a second t-stat in the system. Not sure that would be allowed. If so, perhaps I can use one of the other plugins that can talk to a WiFi t-stat and hope that the drying mode is available. Stay tuned...

[cbabkirk]

Stay tuned. I haven't thrown in the towel just yet....thanks for all your guidance so far.

[shill]

The only difference between the two is actually a querystring parameter of ?page=1, which seems unlikely to actually have any influence on controls. Plus as you say, with no button to push on the website, there's not much I can do, I'm afraid. Appreciate the update and the attempt to get to the bottom of it!

[cbabkirk]

I talked with Honeywell tech support today. Not much joy there. He seemed to think this might be configurable and asked me to select some icon or buttons that were apparently on his TCC dashboard but not on my TCC dashboard. He had me log out and back in hoping the interface would update and show the desired SETTINGS icon but it did not. So we concluded that his interface could only support the four modes that are also present in your plugin. If you are using a method that mimics the user operating the TCC client, there is no hope of pressing a button that is not there.

I did run some compares on the page sources for each mode as I noticed that when I was showing the SYSTEM modes on the client dashboard, and I selected any existing mode directly on the thermostat, the appropriate button on the TCC dashboard would light up (as you would expect). If I selected DRYING directly on the thermostat, all the buttons go dark. It seems the dashboard received a direction but there was no object to display.

Also the differences in the page source show a difference between mode OFF and mode DRYING. See excerpts below...

OFF MODE

Control.Model.set(Control.Model.Property.systemSwitchPositio n, 2);

<li class="rightborder"><a class="culture-link" data-ajax="false" href="/portal/Account/ChangeCulture?lang=en-US&amp;returnUrl=%2Fportal%2FDevice%2FControl%2F5005471" style="text-decoration: underline;">English</a> </li>

<li><a class="culture-link" data-ajax="false" href="/portal/Account/ChangeCulture?lang=fr-CA&amp;returnUrl=%2Fportal%2FDevice%2FControl%2F5005471" style="">Fran&#231;ais</a></li>



DRYING MODE

Control.Model.set(Control.Model.Property.systemSwitchPositio n, 2);

<li class="rightborder"><a class="culture-link" data-ajax="false" href="/portal/Account/ChangeCulture?lang=en-US&amp;returnUrl=%2Fportal%2FDevice%2FControl%2F5005471%3Fpage%3D1" style="text-decoration: underline;">English</a> </li>

<li><a class="culture-link" data-ajax="false" href="/portal/Account/ChangeCulture?lang=fr-CA&amp;returnUrl=%2Fportal%2FDevice%2FControl%2F5005471%3Fpage%3D1" style="">Fran&#231;ais</a></li>

I am not expecting that any of this helps but thought I would share what i found. I am wondering if a different thermostat would cause the TCC client to show the DRYING mode.

Also the MAC address and code registered in the TCC client are for the REDLINk gateway and not the thermostat. The thermostat I am using is a direct connect to the air handler. When you "operate" the TCC client from your plugin you are seeing the t-stat via the gateway. Not sure if that is a reason the the client cannot see the DRYING mode. Adding a device in the TCC client says that a WiFi t-stat or a Redlink gateway are valid choices.

-Cliff

[shill]

They don't offer an API at all. The plug-in works by simulating user behavior on the website. Not sure they'd even be happy that it existed...

[cbabkirk]

Time to call Honeywell tech support and ask for an API call that will fetch this. I'll let you know how this works out. How to you currently fetch the Current T-Stat data in the root device? Form TCC or other?

[shill]

4 and 5 both mean auto. One means auto (currently cooling), the other means auto (currently hearing). That was a pleasure to figure out once upon a time!