Ok, so if the thermostat supports the feature, then SwitchEmergencyHeatAllowed: would be True? And if true, then the value of EquipmentOutputStatus: would be a value neither of us know (yet?) ?
Wonder how to find that value?
thats how i interpret it .. even if possible as the setting for the whole house humidifier is similiar but equipment status does not report anything different.. i had to extrapolate for that based on whether fan was on but equip. status was set to "no heat" and the humid. is enabled.. hopefully it will be better for the emergency heat.
Hey guys. Thanks!
Emergency Heat is not the same as Aux Heat. Emergency Heat turns on the auxilliary heat source and prevents the heat pump from turning on. Aux Heat allows both sources, but not at the same time of course. I see the status "Waiting for equipment" when the system prepares to switch from one source to the other.
I'll get on this the next time the outside temperature calls for auxilliary heat. Thanks!
Here's an article:
The author might know the answer.
Question for @csteele or anyone using his version of the TCC driver.
I have 2 thermostats and thus I would need to create 2 virtual devices. If the polling is set to every 10 minutes, would I run the risk of running into the rate limit? Since the 2 devices will poll individually at different times, I am concerned about running into this. My primary use case is to track the cooling/heating/idle times for each thermostat and not control them via HE.
Thanks.
I have the same issue. I run into issues all the time. I did “configure” them 15 minutes apart so it staggers the poll times. But if I arrive or depart, both need to be hit around the same time. It’s a pain in the butt and doesn’t work half the time. I blame Honeywell, not this device driver.
3 Likes
I've spent the last couple of days converting this driver (for a nearly obsolete API) into a Parent/Child. At this moment, it supports only two children/thermostats.
Although I've coded to deal with a collision in the API communications, since I don't have two Thermostats, I haven't had a good chance to test it and adjust the collision timing. I intend to keep working on it but I wanted to indicate my intent to pursue a new iteration of the driver.
4 Likes
If need someone to test with more than 2 let me know, I have 4.
Once I get two working, I'll expand it to 5.
I want to focus on the first hundred typo's I probably already made. 
Assumptions:
- One ID/pw for all child thermostats (entered into Parent)
- A unique thermostat ID (entered into Child)
Not sure what child processes will get you. I have 2 in one location and a third in another on a 2nd hub. I just have 3 instances of the driver and only set refresh times to 1/2 hour. I don't believe child processes will alleviate the timeout issue. Not if you want them all on the same account. And even then i believe they monitor all requests based on the ip.
Maybe a little less draw and memory in the hub?
It's an experiment, sure.
What I am hoping is that the driver won't contribute to the collision at Honeywell's servers. If 3 Thermostats all try and login using the same ID/pw then that first step has a higher likelihood of Honeywell failing, I assume. My only change to the login, so far, is to create a "refactory period" where login is bypassed and the cookies are reused.
Because I don't have two thermostats, just acres of virtual thermostats my testing doesn't have a real randomization of the incoming requests. Race conditions will be difficult to track down empirically.
2 Likes
I'm not a top user of this Driver But I've switched my use over to the new parent/child version and thus far, can see no difference. Certainly a lot of that is because it's 90% the same code. 
My settings are all "no's" because southern california doesn't need those options for Humidity, emergency heat, etc.
Disabled the old, using the new.
I do have two hubs, both running the new driver. This Production hub as well as my Development hub. Both are targeting the same, single thermostat. There will be a potential for collision at Honeywell's servers as a result, but with the poll times so high, it's quite unlikely. I'm hoping my two testers are going to push it harder than I do
2 Likes
If you need a third tester, hmu. I have two t-stats and frequently run into the logjam that is Honeywell TCC's API.
I don't want to set expectations too high... I started this update to the driver in response to a question about multiple Thermostats. A Parent/Child driver would make it "look better". I think that might be one area I can claim success.
I've known and experienced Honeywell fails a thousand times during development. Three times tonight, as I continue to test. There's nothing I'm doing that will fix the Honeywell side of the connection. As mentioned above, known collisions (simultaneous login attempts - within a second) should be coded around. I took a stab at that, based on thinking I've done over the past year, let's say.
It's also unlikely to have any performance gain, other than saving DB space for duplicate code, as @kahn-hubitat points out above.
TL:DR
The big benefit is the beauty/appearance by having nested devices.
The one thing that has been on my wishlist for this driver would be to somehow consolidate events, especially temperature changes.
For example if you tap the temperature up 4 (or some number) degrees, in my experience it seems to lock you out. The driver is seemingly sending 4 discrete events? The only time I ever have trouble is if I make multiple changes like that. If I go up 1 degree and wait a minute than another degree, I never seem to have issues. Same thing if you switch from OFF to HEAT/COOL and do a temp adjustment, almost guaranteed lockout.
So is there some way to in the driver count the number of temp adjustments in say 10 seconds, then send that one larger temp change (or even all thermostat adjustments) to Honeywell? I am not any type of coder, nor do I know how their API acts, but on the surface this would seem to reduce at least some traffic.
If Dashboards supported numeric inputs, it could probably solve most of this. But in the absence of that, I wonder if this driver could do this event consolidation?
1 Like
Ya just for that reason i use the actual honeywell app for any remote changes and even that fails sometimes. I rely on this driver for monitoring and reporting and thus set refresh to 1/2 hour. I also have a startup routine on hub reboot that stagers the refresh to help avoid too many attempts in a short time. Obviously doesn't help for multiple.bubs/houses.
1 Like
Ok, got that working, I believe. There's a 1.6 second timer, triggered by each UI button click. When that expires, the accumulated settings are sent to Honeywell. That adds 1.6 seconds to a single click... this is the same 'penalty' paid for a feature that we find in adding a double click to Lutron Pico's, for example. But given the cloud round trip for this driver, I suspect it will be invisible for most.
1 Like
I have added support for those additional/optional Outdoor Temp and Outdoor Humidity sensors:
and then after adding a Device Label:
I have neither, so the code has only been "bench tested" so far. Their purpose, as far as I can tell ,is to add a second identically named Attribute that can be used in Automations, Dashboards, etc. In other words, the initial Thermostat child already has an Attribute called "humidity" and thus the outdoor humidity sensor could be integrated with a custom attribute of 'outdoorHumidity' or 'humidity2' etc. however, that imposes extra work on people.
At this point, it feels like I'm done with the conversion. Once I get reports from the testers and resolve any issues, I'll stage a new release under a new Topic. Maybe: "Honeywell TCC Total Connect Comfort Parent/Child Drivers"
4 Likes
Does this mean if we've intentionally spread out commands as to not send too many at once, we should send them at the same time now?
This is SO awesome!!!
1 Like
