Are you doing manual refresh or regular intervals?
I have created 2 devices for my single t-stat. One is used when I want a permanent hold and the other is used when I want a temporary hold. One of the devices is set to "off" for the poll Interval while the other device polls every 60 minutes. I never manually poll them, I only send changes to the heating/cooling setpoints or a cancel hold command.
That helps. Thank you. Also, am I the only one when I use the TCC app directly, I see a bunch of popups about my thermostat not receiving commands (it's happened since I had the device; 7 or so years this month). Do others get this message when they login? I have to hit dismiss like 5 times every time I use the TCC app directly. Also see this message in debug logs when I turn it on for the TCC Hubitat app:
The thermostat did not acknowledge the changes submitted at 8/29/2021 3:00:02 AM. Check your settings and resubmit. If you have received this alert before then you may have intermittant communications issues with your system. For suggestions to resolve this alert check for an alert email, check FAQs or call Resideo Customer Care at 1-800-633-3991.
I will occasionally see this message but nothing like your describing. If I had to guess, maybe a dozen times in the last year.
Likewise.
Ok, I've always seen it hit DHCP every 3 minutes too so but never thought anything about it. I've moved the redlink gateway it to another switch and force speed to 100 and that seems to have fixed the DHCP request issue.
So I have a routine that is supposed to set the temp to 71. It just fired off and didn't take. I confirmed my devices are communicating (i.e. I can change the temp in the app and it displays on the thermostat). Below is what the app shows. I see "302" which is a redirect? Is that normal?
Crazy that setting it to 72 is working...
I don't have any logging turned on so I can't answer your 302 question but, I just fired a rule that sets the temp for night and it executed on the thermostat within 15 seconds.
The Honeywell TCC API is not documented although for a short time someone had exposed some reverse engineered details. Those got taken down years ago... The result is as you'd expect, no document to turn to to say this is what's needed, this isn't AND far worse, Honeywell could have changed their API and would never have mentioned it publicly.
I say all this because the TCC API interface is horrid. Like everyone discovers, for no discernible reason the interface will reject connections. It's known that Honeywell limits use, and so there's a convenient excuse, but in my experience, the rate limit idea is inadequate. I think it does cover a vast majority (95%) of rejects. But I've seen others as I tried to streamline this driver over the years. I tried to determine if there was perhaps a change in the API that was at the root of the problem brought up a couple days ago... couldn't get a good answer because when I'm debugging, I hit the API at a pretty high rate... and get rejects.
I test 3 different ways: Homebridge-TCC, Honeywell phone app and this driver I maintain. I am forced to 'take a vote' when investigating because no one way works 100%. Yesterday, all 3 were failing (rejecting) at a rate I haven't seen in a long time. That allowed me to conclude, Honeywell was the root cause.
Someone in my house manually adjusted the temp today and I used the Driver to set it back. I hadn't touched anything Honeywell related in a day, so naturally my first time worked.
A decade or more ago a friend and I were discussing software debugging and the various methods individuals use. He and I were each managing different groups of developers in the same company and it was fun to compare and contrast... BUT he was concerned about approving expenditures for debugging tools. He would say: "It's a computer, it does what it's told to do. So?? What did you tell it to do?" Meaning the greatest debugging tool is your brain and if only you can think like a computer, the answer is clear. 
So I sat down and did some code review and can see a potential issue with "Resume Schedule." However, without documentation it's very difficult to say what it is supposed to be exchanging with TCC.
I will continue to review this at the rate Honeywell allows. 
Just a Note: "Follow Schedule" isn't an actual command to this Thermostat, as far as I can find. It's the absence of other Modes. It's when the Thermostat is NOT in Vacation Hold and NOT in Temporary Hold. What's left is: Follow Schedule. Seems to work in the sense that I removed a Temp hold and the Status in the driver changed to "FollowSchedule", matching what the TCC App was indicating. 
3 Likes
Really do appreciate your investment. The ST integration stopped accepting my resume schedule commands a few months ago, so I suspect whatever Honeywell changed may have impacted their allowed integrations too.
I may be in the minority here but I have not had any issues with resume schedule and use it almost daily. Fingers crossed that I haven't just jinxed it. 
You doing resume with this integration or the ST one via Hubconnect?
Funny, my TCC integration is working fine if I change my cooling temp from 71 to 72. 72 works fine, 71 returns that odd error code. At least I have an excuse when my wife asks me why it's not as cold as she wants.
Also, I fixed the TCC app error codes by moving the redlink device to another switch and forcing 100MB/s on that port. It's only been broken for 7 years. 
I released 1.3.18 a few hours ago... it's a simple 'clarification' of Follow Schedule.
I redundantly set: Thermostat to NOT in Vacation Hold and NOT in Temporary Hold, when Follow Schedule is selected. I think it's always worked, but I could imagine a scenario in which TCC 'lost' a message when it's rate limiting.
HPM or Import:import:save to get the latest.
1 Like
This integration. I completely shut down Smartthings last year.
1 Like
Hi @csteele - I'm using 1.3.18 and it's working fine. I have the poll interval set to 15 minutes, so the information shown on my dashboard is "behind the times". Do you have a recommendation for a lower poll interval that will work reliably and not cause havoc at Honeywell Headquarters?
Thanks!
I can't say that I do. My use is different from most people because I have my "Production" hub using a poll of 30 min PLUS I have a development instance also polling every 30 mins. I don't have any need for "real time" polling... and Honeywell does "disallow" me occasionally.
You would have to test it out for your use. I know that when I have reason to debug, I'll hit their magic limit long before my debugging is done. That forces me to wait a minute or two between test cycles. I'm almost positive 5 mins would be excessive to Honeywell.
3 Likes
@csteele - My thermostat displays a status message (auxilliary heat on) when the furnace is providing heat rather then the heat pump.
I would love to be able to add this status to my dashboard! Of course I don't know whether this attribute is available - but if it is please consider this request the next time you're fiddling with your superb driver!
1 Like
I'd like to have an alert whenever auxiliary heat turns on (since it starts the meter spinning out of control).
1 Like
Adding an attribute is easy, filling in the attribute with values from the thermostat is easy. HARD is finding out what Honeywell calls that status when it arrives at the hub. My thermostat doesn't have (or use) that feature so I don't know what it's called inside the response from Honeywell.
When I poll my thermostat, I look at the response and then searched for "aux" (looking for auxillary anything) and find nothing. Clearly they spell it differently than I'm looking for 
If you turn on Debugs, look in the Logs for this sort of thing:
dev:1098 2021-11-24 10:44:29.883 am debugld = [fanModeOnAllowed:true, fanMode:0, fanIsRunning:false, fanModeAutoAllowed:true, fanModeCirculateAllowed:false, fanModeFollowScheduleAllowed:false] dev:1098 2021-11-24 10:44:29.879 am debugld = [ScheduleCapable:true, OutdoorTemperatureSensorNotFault:true, SystemSwitchPosition:1, SetpointChangeAllowed:true, OutdoorHumiditySensorNotFault:true, DispTemperatureStatus:0, HoldUntilCapable:true, HeatNextPeriod:90, HeatLowerS etptLimit:40, SwitchCoolAllowed:true, IsInVacationHoldMode:false, IndoorHumidStatus:128, OutdoorTemperature:128, ScheduleHeatSp:67, TemporaryHoldUntilTime:0, OutdoorTempStatus:128, IndoorHumiditySensorAvailable:false, CoolUpperSetptLimit:99, OutdoorTemperatureAvailable:false, SwitchEmergencyHeatAllowed:false, Deadband:0, EquipmentOutputStatus:0, SwitchOffAllowed:true, VacationHoldCancelable:false, SwitchAutoAllowed:false, DeviceID:------, VacationHold:0, StatusCool:0, IndoorHumidity:128, DisplayUnits:F, HeatSetpoint:67, Commercial:false, CoolSetpoint:74, HeatUpperSetptLimit:90, CurrentSetpointStatus:0, DualSetpointStatus:false, ScheduleCoolSp:74, VacationHoldUntilTime:0, StatusHeat:0, DispTemperatureAvailable:true, OutdoorHumidityAvailable:false, DispTemperature:69, OutdoorHumidity:128, SwitchHeatAllowed:true, IndoorHumiditySensorNotFault:true, CoolNextPeriod:90, CoolLowerSetptLimit:50, OutdoorHumidStatus:128] dev:1098 2021-11-24 10:44:29.862 am debugdata = [alerts: , success:true, latestData:[uiData:[ScheduleCapable:true, OutdoorTemperatureSensorNotFault:true, SystemSwitchPosition:1, SetpointChangeAllowed:true, OutdoorHumiditySensorNotFault:true, DispTemperatureStatus:0, HoldUntilCapable:true, HeatNextPeriod:90, HeatLowerSetptLimit:40, SwitchCoolAllowed:true, IsInVacationHoldMode:false, IndoorHumidStatus:128, OutdoorTemperature:128, ScheduleHeatSp:67, TemporaryHoldUntilTime:0, OutdoorTempStatus:128, IndoorHumiditySensorAvailable:false, CoolUpperSetptLimit:99, OutdoorTemperatureAvailable:false, SwitchEmergencyHeatAllowed:false, Deadband:0, EquipmentOutputStatus:0, SwitchOffAllowed:true, VacationHoldCancelable:false, SwitchAutoAllowed:false, DeviceID:864866, VacationHold:0, StatusCool:0, IndoorHumidity:128, DisplayUnits:F, HeatSetpoint:67, Commercial:false, CoolSetpoint:74, HeatUpperSetptLimit:90, CurrentSetpointStatus:0, DualSetpointStatus:false, ScheduleCoolSp:74, VacationHoldUntilTime:0, StatusHeat:0, DispTemperatureAvailable:true, OutdoorHumidityAvailable:false, DispTemperature:69, OutdoorHumidity:128, SwitchHeatAllowed:true, IndoorHumiditySensorNotFault:true, CoolNextPeriod:90, CoolLowerSetptLimit:50, OutdoorHumidStatus:128], drData:[Load:null, Phase:-1, OptOutable:false, DeltaHeatSP:null, HeatSetpLimit:null, CoolSetpLimit:null, DeltaCoolSP:null], fanData:[fanModeOnAllowed:true, fanMode:0, fanIsRunning:false, fanModeAutoAllowed:true, fanModeCirculateAllowed:false, fanModeFollowScheduleAllowed:false], hasFan:true, canControlHumidification:false], communicationLost:false, deviceLive:true]
and send it to me in PM. I'll format it and look for any unique values.
1 Like
its not called aux see the attribute SwitchEmergencyHeatAllowed:false in your output.. that is whether it is enabled in the therm..
what it comes back when on is not the same.. i believe it would be a different number in equipmentstatus but also i cannot confirm as i dont have that type of system either.
1 Like
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?
