HubitatCommunity/HoneywellThermo-TCC

In Hubitat under my created device it says:

State Variables

  • coolLowerSetptLimit : 68
  • Copyright : © 2020 C Steele -- v1.3.12
  • Status : New Version Available (Version: 1.3.14)
  • PermHold : 1
  • coolUpperSetptLimit : 99
  • heatLowerSetptLimit : 40
  • heatUpperSetptLimit : 67
  • InternalName : HoneywellThermoTCC_C
  • UpdateInfo : 01/08/2021

I have both imported the code from GitHub as well as copy-paste from the groovy file for v1.3.14, but it always says there is an update. Am I missing something? Even the code in the file says that it is v1.3.14, but I don't know if that's necessarily where Hubitat gets its version info:

public static String version() { return "v1.3.14" }

Thanks for the cool integration!

Click Save Preferences and wait... watch the right column of Current States.. after about 20 seconds it will update with:

Screen Shot 2021-01-27 at 9.57.45 AM

After those two lines appear, refresh the page...

The column on the right is dynamic.. it gets updated with each new Event. The column on the left, State Variables is NOT dynamic.... you have to refresh manually, but you have to wait for the data to change via Event.

Before:Screen Shot 2021-01-27 at 10.01.10 AM AfterScreen Shot 2021-01-27 at 10.01.24 AM

2 Likes

OK, I did that, waited a few minutes and refreshed the page. Now it shows the latest.

Thanks!

PS: do you have a Hubitat driver that does windows......:wink:

I wonder if others are seeing something that I am. The "followingSchedule" attribute is not updating. I make use of quite a few temp/perm holds and I've found "followingSchedule" doesn't update and it would be better for WAF if it did.

Is it updating for anyone else? If so, I'll try deleting the device and setting back up but it's a big job so I wanted to ask first.

Thanks...

This is an artificial (ie. calculated) event. The Thermostat doesn't actually report this.. it's the absence of other conditions that results in "It's not anything else, so it must be Following Schedule".

The code looks at 3 values reported by the Thermostat...

  • holdTime : Temporary or Permanent Hold exists or not.
  • vacationHoldMode : Vacation Hold exists or not.
  • isScheduleCapable : the Thermostat actually supports a schedule True or False.

When the Holds are zero (meaning false, not true) and the Thermostat supports a schedule (true) [F F T] then what's left is "Following Schedule."

Apparently there's a coding error (ugh :frowning: ) so I'll push a new version.

Screen Shot 2021-11-30 at 3.57.08 PM

1 Like

Thank you for the detailed explanation. I only noticed this when I stopped using auto and started changing between heat/cool based on current temp, current mode, etc.

I truly APPRECIATE ALL THE WORK on this integration. Even though it's WiFi I really like the looks and feel of this thermostat.

I updated this driver this morning and the attribute changed to FollowingSchedule. (It had been previously saying TemporaryHold forever.) My system is currently in a Permanent Hold. I waited for my normal polling update and it's still showing FollowingSchedule. Do I need to do something other than hit initialize, poll, refresh after updating the driver. Thanks.

bummer got excited when i went to the residio ap and now you can import older tcc devicxes into the app..

unfortunately when i went in the newer honeywell home/residio implementation here on hubitat the tcc therms dont show up and it says

i also do see settings in the app for my steam humidifier so was going to modify the honeywell home driver to support that but guess i will need to wait until i can see them in the devices under the integration

Starting yesterday, I lost communication. I see login successful in the logs, but nothing gets set, last updated time isn't changed, polling isn't returning current settings, all I see after the login is this:
Adding cookie to collection

Am I the only one or was there a server change affecting the hubitat driver?

  • HoneywellThermo-TCC
    • Total Comfort API C v1.3.25 (driver)
      Platform Version
      2.3.3.140

I have an outdoor temp sensor and humidifier/dehumidifer on my thermostat is there a way to get a child device that'll show this info too (so I can possibly use it in automations later)

I don't have one, but IF I remember correctly, when you select that option in the driver, it creates children. I merged (pull request) that code in from another's efforts, is the 2nd reason I don't remember it with clarity.

ok thanks, yeah I remember back in the day when I first added this thermostat I thought it just auto populated but this time it didn't look like it did I might have to wait for it to refresh and repoll maybe?

@csteele I have been using the TCC driver for a while without issues. Now however I have 1 of my 2 that will work if I'm pushing the buttons on the device page but it does not seem to receive the commands from WebCoRE. Nothing was changed. Things I've tried so far, changing the polling rate, moving the offending device to it's own MyTCC "home" and login with a completely different email. Writing a brand new Piston that when a light switch turns off it sets the thermostat to cool and tells it to set 80*. (Hard to screw that up for testing.) The HE dashboard reflects the new settings but the device does not. I also tried operating it from the TCC iPhone app and a computer browser. All work. I don't get why it won't recognize the WebCoRE commands. Ideas? Thanks! I am using the Nov/22 update to the driver as well.

Also just set up a Basic Rule in HE for it to set cool and set temp to 74. Same thing, dashboard reflects correct info but thermostat remained unchanged.

I'm exploring this.

It's always a possibility that Honeywell changed their end. I'll experiment with my development system and see if anything pops out.

Thanks! @csteele I'm going to try to move from HPM WebCoRE to native. Any suggestion on that? I forgot to mention here that one of the ladies living under my roof pressed some buttonage. I hit cancel and set the offending unit to Off and it seems to now be responding as normal,

I doubt the "Rules Engine" you choose will make a difference. That's one of the advantages of using drivers.. everything is abstracted. What's available for Apps, including WebCoRE and RM, are the buttons found on the Device Info page. Your finger clicking the button or WebCoRE clicking the button does the same thing.. it does whatever the driver dictates for that button.

Everything was working for me during my testing, except Honeywell. They seemed to be having difficulties with login. They use a convoluted login process that requires accepting 8 cookies. 5 of them are generic but 3 of them are unique and for most of yesterday those unique ones were not being generated by Honeywell, thus causing login to fail. This is highly normal, it's how they rate limit their users. What was unusual is for them to thwart logins for 15-20 mins at a time.

I've had an item on my ToDo for at least a year, but it never made it to the top of the list. Because I was spending so much time trying to test, I actually had the time :smiley:

At a very high level, this driver either asks for status or sends a command to set the Thermostat. When sending a command, every option is included, mostly with null values. Like this:

body:[
       DeviceID:xxxxxx, 
       DisplayUnits:F, 
       SystemSwitch:null, 
       HeatSetpoint:null, 
       CoolSetpoint:null, 
       HeatNextPeriod:null, 
       CoolNextPeriod:null, 
       StatusHeat:0, 
       StatusCool:0, 
       fanMode:null, 
       TemporaryHoldUntilTime:null, 
       VacationHold:null
     ], 
     timeout:10
]

Yesterday I finally made the modification to optimize for non-null and now it looks like:

body:[
       StatusHeat:0, 
       StatusCool:0, 
       DeviceID:xxxxxx, 
       DisplayUnits:F
     ], 
     timeout:10
]

Given the drastic change, I'm going to keep this in Test for a while to make sure there are no unintended consequences in Honeywell's API. Given that this optimization hasn't been done before, it's possible Honeywell is relying on receiving nulls. My testing so far suggests this works, but I haven't tried multiple combinations.. edge cases. It doesn't seem to make any difference so I may decide to keep it under my hat. It's not like saving 50 characters from a couple thousand exchanged per communication is going to make a difference. My ToDo list item was more along the lines of "What if Honeywell doesn't like nulls? What if Honeywell misinterprets certain combos of nulls?"

Now I know, from limited testing, that their API deals with nulls, putting this change into the "sweet" category vs beneficial category. :smiley:

If I had to guess, I'd say Honeywell's login issue plus "pressed some buttonage" would be the most likely cause. :smiley:

1 Like

Interesting. I wonder why only the 1 thermostat was working. Even when I switched the non working one to a brand new Honeywell account it continued to not work until I pressed cancel and turned the thermostat to off on the device itself. Oh well, all seems to be functioning as normal now. (Knock on wood! :slight_smile: )

Your Thermostats communicate to Honeywell's cloud. This driver communicates with Honeywell cloud. If your thermostat is not communicating with the cloud, commands cached out there don't make it. Cancel probably reset the communications to Honeywell cloud... if I had to guess. :smiley: but it's just a guess.