Honeywell TCC Total Connect Comfort Drivers

Running my Development hub on a 3 min cycle overnight (12hrs) I saw 22 login fails. Of those 2 were duds, didn't recover. For me, it's amazing:

  1. I've never run the poll cycle at 3 mins before. I've tried 10 mins but found it was not to bad at 15. My Production hub runs on a 60 min cycle.
  2. that an immediate retry works.

I'm going to have to finish this and push out another release of the new driver :slight_smile:

2 Likes

nice i run my house with two therms one on a 30 min schedule and one 1 hr.. with the retry code i put in the old one i have no issues.. it would be nice to be able to run it sooner.. does your new driver have all the code of the existing old driver including the kludgy humidifier running code i had to add?

I believe so. It creates the pair of child devices if needed.

1 Like

I've actually just finished back porting the Accumulation Feature and this Rapid Retry Feature to the old driver. Testing is good, so far.

3 Likes

v1.3.21 released 4 hours ago. Includes back ports (from the Parent/Child driver) of an Accumulation Feature and a Rapid Retry Feature, discussed above.

3 Likes

Bit confused... this is the older, single Driver topic. All of the Log.info lines are unqualified in v1.3.21

Over on the Parent/Child topic v2.0.8, all the log.info's are qualified by Debug, which is not the intent.

Is this message just in the wrong topic? I can make a v.(next) that correctly qualifies log.info with TxtMsg.

1 Like

Released v1.3.25 to use "\" for Platform 2.3.3.x compatibility.

3 Likes

on the same vane as above which still is ignoared.. your new change should be this..

and moved down so that the variable has a value
if (isEmergencyHeatAllowed)
sendEvent(name: 'supportedThermostatModes', value: [""auto"", ""cool"", ""emergency heat"", ""heat"", ""off""] )
else
sendEvent(name: 'supportedThermostatModes', value: [""auto"", ""cool"", ""heat"", ""off""] )

Hello,
I have a Honeywell Prestige thermostat with remote sensors linked to it. Can the TCC integration show the remote sensors?
I do have a Honeywell T10 thermostat and that shows the remote sensors fine. I was trying to see if the TCC integration can expose these remote sensors that are attached to the prestige thermostat.

Thank you

It will see the outdoor sensor if you check the option. It will not see any of your remote redlink sensors that are used for averaging or the duct 10k sensors.

Does anyone have a problem with TCC today? My devise stopped updating after midnight today. I deleted and reinstalled the thermostat in hubitat, but its not updating at all. I have the latest hubitat firmware, and V1.3.25 of the TCC driver

dev:938 2022-11-10 06:53:07.671 AM info Honeywell Thermo Downstairs TCC transaction: failed
dev:938 2022-11-10 06:53:07.667 AM info Honeywell Thermo Downstairs TCC transaction: retry login
dev:938 2022-11-10 06:53:07.664 AM info Honeywell Thermo Downstairs TCC transaction: retry login

I'm also getting login fails.

In my case I get something different

I'd have to conclude that Honeywell altered their API.

I think they reduced the number of Cookies they need by one.

I'm getting success by changing Line 792 (of the Parent code, 743 of the Single code) to be 8 instead of 9.

if (cookieCount < 8) {

1 Like

Yes, That worked, thank you, but its not line 792, its 743.

1 Like

It was line 792 for me.

1 Like

792 in the Parent of the Parent/Child version.

The single driver/single thermostat per driver version, yes, line 743.

But independent of line number DID IT WORK? :smiley:

1 Like

Yes it did. Thank you

2 Likes

Worked for me too, so thanks. And thanks for the work on the apps.

Question: I have just a single Honeywell thermostat and am unlikely to add more. I seem to have success polling at 10 minute intervals using the Series 1 (single driver/single thermo) app. That frequency suits my purposes. Is there any reason to migrate over to the Series 2 (Parent/Child) version of the app, or should I stick with the Series 1? In other words, do I follow the golden rule of "If it works, don't change it", or is the Series 1 likely to be abandoned in favour of Series 2 so I might as well just "bite the bullet" and change now?

It's an excellent question...

My answer is poor at best :smiley:

I'm unlikely to DEVELOP against the older (single thermo) driver. When I created the Parent/child, I copied each block, but reorganized it and the result is I can find things faster in the new code. I think the code itself is very similar and in a lot of cases identical. The differences were largely to pass data between Parent and one or more Children and I like the structure that brings.

However, I don't see there being a LOT of growth in these drivers :smiley: and so far, I've backported changes from Parent/Child into the Single. I have no plan to abandon the Single.

I have a single thermo and am unlikely to add more. I have none of the optional items and obviously can't test them, but the community has been great at doing precisely that :slight_smile: yet I use the Parent/Child with the Single still installed and configured, but with it Disabled.

As you can see, the Single hasn't been used in over a month. But I imagine this is a Developer thing to have both to make switching back and forth easier.

Final thought: I think you can wait another few months and see if there's any actual benefit to switching. :smiley: