Honeywell TCC Total Connect Comfort Drivers

[csteele]

I you look at the Parent device, States shows several items but one is:

• deviceSetting : {0={HeatSetpoint=null, CoolSetpoint=null, StatusHeat=null, VacationHold=null, StatusCool=null, TemporaryHoldUntilTime=null, CoolNextPeriod=null, FanMode=null, SystemSwitch=null, HeatNextPeriod=null}}

That is the "accumulator" and will always show as all = Null since they get cleared, ready for the next batch, as the last thing after each Send to Honeywell. I expect to get get questions about what it's for since it appears to never change. You'd only have 1.6 seconds to see the change

[brianwilson]

So my use case is when I leave. I change the setpoints for both heat/cool on both thermostats, so this is what I was doing before:

If I take out the delays, I assume all of these commands would use the same session info, and I assume instead of 2 calls to each, it would do these in 1 call to each thermostat?

Also, what should we set refresh to if we have more than one? Set them the same or different? If we do a refresh on one, will it get the data for the other and populate it without a refresh on the 2nd thermostat?

[csteele]

Yes, I'd reduce or eliminate the delays.

Maybe:

@brianwilson

will it get the data for the other and populate it without a refresh

The Thermostat Child drivers are intended to be independent. Each button press in a Child Device Info page, or injection via automation, hits the Parent (where all the work is done) with the child's ID. Everything is saved/stored, acted upon, using that ID.

[csteele]

No news is good news?

Is it OK for me to release?

[neonturbo]

I would be willing to test if you don't have enough testers.

[csteele]

Released:

[RELEASE] Honeywell TCC Total Connect Comfort Parent/Child Drivers

Today I'm releasing a new version of the HoneywellThermo-TCC driver. It's main purpose is for multiple thermostats on one account as discussed: The original driver uses an old, perhaps obsolete, certainly deprecated, unpublished Honeywell Cloud API. The Honeywell server(s) reject automated logins regularly. The solution seems to be "don't hit the login server too rapidly". Adding multiple copies of the original driver would certainly allow logins virtually on top of each other, causing more…

[kahn-hubitat]

Its not clear .. so are you using different set of apis or the same ones?

[csteele]

Same.

For a single Thermostat home, like me, using this version should benefit from the Accumulation feature only. Even the number of lines of code are quite similar.

~1000 for v1.3.20

~800 for v2.0.3

• 220 for the child driver.

There's easily 20 more lines of comment in v2.0.3, which also means they are quite similar in impact on the Hub. It's the 2nd thermostat where the big gains occur. Using v1.3.20 would use ~2000 lines of code while v2/0/3 would be ~1240

I have two hubs that are talking to the same Thermostat using the new driver. My Production hub is on a 60min poll cycle while my Development hub is on a 30 min cycle. I have received the dreaded "failed" only once in 12 hours. If I wasn't the developer, I probably would stick with the single driver because I rely on the built in schedule, now that I've got it set to my liking. I have no automations at this time aimed at the Thermostat. That said, I created in my head an automation I'd like to try.

Device Stats:

As you can see, the new driver has overtaken the old because it's polling twice as often However, 0.047% is a very tiny number.

[kahn-hubitat]

The damn honeywell home new driver is no better .. I hate honeywell... If it wasnt for my integrated redlink therm with steam humidifier .. sensors in the ducts and outdoor temp i would punt them.

I just added code to the honeywell home driver for my two wifi therms in our condos in FL to only put out the error message if it fails on the refresh retry as that one is failing regularly also and i am tired of seeing the error in the logs. I assumed the newer t6 apis would be better. Shame on me. Why dont they invest in some servers to handle the bandwidth or get some decent programmers.

sigh...

[csteele]

As you might expect, I spent a LOT of time clicking on the new driver's buttons to be sure they worked as expected. Across a 2 hour development session, I'd probably hit Honeywell 200 times. In that time I'd get 3-4 Rejects. I'd always just hit the button again as soon as I got it. It certainly was under a second later, 90%of the time that was good enough, it would make the connection. I remember one time I got rejected twice in a row. For the most part though, Honeywell took the beating I gave.

What I can say is that I saw a pattern in how the fail worked. I think I can exploit that to handle retries better... earlier in the process. But first, I'm listening for issues with what I just barely released

[brianwilson]

I was going to say I only see about 3-5 failures a day across my two devices. I was wondering if you’re capturing the failures and resubmitting the info again after some sort of cool down time. It seems to be working great for me thus far, but I only use in automations and don’t use the Hubitat thermostat UI To make any changes.

[csteele]

@brianwilson

I was wondering if you’re capturing the failures and resubmitting the info again after some sort of cool down time.

There's code in there for that (that I didn't write, a pull request) that I never saw get used during the new development. It probably solves a problem I don't hit, because I'm such a minor user of the driver. but watching for it, caused me to see the pattern I mentioned above.

[kahn-hubitat]

I wrote code in the original driver that senses a failure and retires after 5 minutes.

[csteele]

I never saw it 'trip' in the few instances when I was rejected during development of the new driver.

          log.debug "Scheduling a retry in 5 minutes due to Unauthorized!"
          runIn(300,"refreshFromRunin")

I was certainly looking at Scheduled Jobs a lot, but never saw either the message or the runIn. Which is not to say it never happened, just that I never saw it.

[kahn-hubitat]

It keys off.a. specific error message it is conceivable that has changed .

[darby427]

csteele.. thanks! much more reliable!

Can redlink wireless temp sensors be accessed? I am guessing no since you cant see them from the webportal.

[csteele]

@darby427

redlink wireless temp sensors

Never hear of one before this message... so I'll go with your research.. not in Honeywell's portal, then the API this uses won't see it either.

[brianwilson]

If you mean the outdoor sensors, yes.

[csteele]

I started to research my idea to be more resilient on login failures... I set the driver to poll every 3 mins. Not a single error in 2 hours. Darn Honeywell, so unreliable, they won't even fail in a reasonable time

[darby427]

This is for the IAQ prestige which is the two wire with the EIM.

Prestige® 2-Wire IAQ Kit + EIM & 4 Sensors | Resideo Pro Pro

They make indoor sensors that can be used as a remote to control the thermostat or be agregated.

C7189R1004 - Honeywell Home C7189R1004 - RedLINK Enabled Wireless Indoor Air...

But like you say since the web login can't see it most likely it can't be done. Although the funny thing is the outdoor sensor is red link as well and it's seen..