Why do you have two thermostats shown in the first screenshot?
In your second screenshot, you changed the "TYPE" to Honeywell Parent and saved? It sure doesn't look like it. The text in the parentheses in the main Device page in your screenshot that says (Virtual Thermostat) should say (Honeywell Thermo Parent).
There are 2 thermostats in the first screenshot because I left the first one I created yesterday (see my first posts yesterday on this topic above) there to clearly differentiate between the default driver of “Virtual Thermostat” when the NEW device is initially created vs the device I created yesterday that has the driver already changed to “Honeywell Thermo Parent”.
I think you might be looking at the wrong text as it relates to screenshots, because both screenshots #1 & #2 are clearly noted as the initial details of the NEW virtual device before the driver is changed. Screenshot#3 reflects the “Honeywell Thermo Parent” after the driver is changed and saved.
I stand corrected, but you only get the image shown in Screenshot#4 after you have changed the driver to “Honeywell Thermo Parent”, i.e. the Add Thermostat command is not there with the “virtual thermostat” driver.
Hi. Thank you very, very much.
The text in the (…) below the device was the clue that I needed. I was making the wrong virtual device to start with. I was using a “Virtual Thermostat” (from the beginning of the add device list) and not scrolling all the way to the bottom to find the USER devices and using the (Honeywell Thermo Parent) as the starting point. I told you I was new to this Hubitat stuff 
.
I have successfully created the Parent & 3 Child thermostat devices:
Now I have the correct device text (…) below the Parent device.
Thank you very much. You were most helpful.
Hi - first off thanks for making this integration, this has been really awesome to use.
Is there a way to enforce only one direction of traffic for Thermostat Updates?
What I mean by that is I’d really like my Hubitat to be the Source Of Truth for my temperature settings. But with TCC being what it is, sometimes those calls fail. What I’m seeing looks like the following behavior:
I set my thermostat in Hubitat to 74 degrees → TCC call fails for whatever reason → Polling/refresh happens, which calls TCC and succeeds and sees the old temperature → Hubitat “syncs” with TCC, setting itself to the old temperature
I I tried to include a logs image as an example but the system won’t let me because my account is too new…trying a text block instead (apologies)
command-refresh Command called: refresh() command Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 10:30:01.441 am
lastUpdate 07/30/2026 10:00 AM Living Room Thermostat Last Update was Set to 07/30/2026 10:00 AM Honeywell Redlink 7/30/2026 10:00:02.384 am
command-refresh Command called: refresh() command Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 10:00:01.659 am
coolingSetpoint 69.0 °F Living Room Thermostat Cooling was Set to 69.0 Honeywell Redlink 7/30/2026 9:30:01.370 am
temperature 70.0 °F Living Room Thermostat Temperature was Set to 70.0 Honeywell Redlink 7/30/2026 9:30:01.329 am
command-setThermostatFanMode Command called: setThermostatFanMode(auto) command Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:03.915 am
thermostatSetpoint 74.0 °F Living Room Thermostat Thermostat Setpoint is 74.0 Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:03.331 am
command-setCoolingSetpoint Command called: setCoolingSetpoint(74.0) command Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:03.333 am
coolingSetpoint 74.0 °F Living Room Thermostat Cooling Setpoint is 74.0 Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:03.323 am
thermostatSetpoint 63.0 °F Living Room Thermostat Thermostat Setpoint is 63.0 Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:03.207 am
command-setHeatingSetpoint Command called: setHeatingSetpoint(63.0) command Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:03.213 am
command-setThermostatMode Command called: setThermostatMode(auto) command Thermostat Scheduler: Bedroom Thermostat, Living Room Thermostat 7/30/2026 9:00:02.572 am
In this instance, I have a scheduler automation set up to set both my thermostats to 69 degrees at night and 74 degrees during the day.
What I tend to see is one of them will fail for some reason, and then just never get updated. When I check Hubitat, it says they’re set to the old temperature. If I hit “set to scheduled temperatures”, they’ll update in hubitat but sometimes will revert back after the refresh job runs.
I’ve turned off “Poll Interval” at the device level to try and fix this issue, and I’ve just now disabled “refresh interval” at the schedule level.
My goal with the refresh interval was to have the schedule continually push its value if it didn’t match what TCC showed, but instead it seems like it’s consuming the TCC value and setting that value in Hubitat.
Is there an intended setup for the behavior I’m seeking?
I’m not clear what you need, at least not clear enough to say it can or cannot be…
So instead, let me make sure you understand how the Honeywell cloud works.
Your Thermostat connects to Honeywell’s cloud in some secret way… normally called a proprietary API.
Your mobile device App connects to Honeywell’s cloud and a) gets status, the thermostat’s current conditions. b) receives commands from Honeywell’s cloud.
This App, talks only to the cloud and has no direct effect, to or from the Thermostat. This App, just like the mobile app tells Honeywell’s cloud what it would like the thermostat to do.
Because there’s no direct communications with the Thermostat, I’m not sure making the App hobbled in some way, is going to affect what the Thermostat does.
Thanks for the reply! Sorry for the delay in responding, I had some local emergencies that have now been taken care of but required my attention at the time.
I understand the cloud aspect of this app, I guess what I'm trying to ask is, is there a way for the Hubitat app to continually push its changes to the cloud in the instance of communications loss/failure, or is that what it's supposed to do already?
In my example above I have a schedule set using Hubitat Modes Day/Night. I have two thermostats and have verified that Hubitat can modify the cloud values. The communication between the cloud/thermostat happens on the TCC/Cloud side via the REDLINK gateway. My question is specifically about the communication between Hubitat -> TCC/Cloud.
During the day, I have the app set the cooling points to 74
During the night, I have the app set the cooling points to 69.
One thing I see is that when I "refresh" from Hubitat, it will grab whatever the cloud thinks the thermostat is set to and update the cooling setpoint in Hubitat to match. If my Cooling Setpoint in Hub is set to 69 but the TCC/Cloud setpoint is set to 74, Hub will set itself to 74 to match what the cloud value is. Often with the schedule, I'll see one of the thermostats successfully update in the cloud and the other won't. But if I hit "set to scheduled temperatures", it will update the one it missed, so I'm assuming communications failure in the mode-switch push.
So in my logs what I'm seeing is the cooling setpoint gets set correctly in Hubitat via the schedule, but then it will "refresh" back to the old value a short time later. My theory is that when the Hub mode shifts, the setpoint in Hub gets set but doesn't make it successfully up to the cloud for whatever reason (sometimes the call just fails or maybe I get temporarily blocked by TCC/Cloud's API controls), so the cloud doesn't change. My ask is if there's a way to stop Hubitat from refreshing/grabbing the value from the cloud and instead if there's a mismatch between Hub/Cloud, push the Hub value again until there's a match. My goal is for Hubitat to be my source of truth, or at least try really, really hard to enforce itself as the source of truth (communication weirdness with cloud nonwithstanding).
Does that make more sense as to what I'm asking for? I'm thinking this functionality already/probably exists I'm just missing some combination of configuration to make it do what I want.
in your description, it feels as if you distinctly don't want the set points coming from the Thermostat to update the Driver.
You can experiment by commenting out those two lines (519 & 520) and see if that gets you closer. (My line numbers may not match the exact line numbers on your hub. Just search for that "def getStatusDistrib" text and look 4 & 5 lines below. Just add // to the beginning of each line and save. Then try it. 
Yes, I want the driver/hub to update the Cloud, I don't want the Cloud to update the driver/hub. And I want the driver/hub to continue to try and update the Cloud if the Cloud doesn't reflect the value that the driver/hub has.
I'll give this a try when I get home tonight and report back - thank you!
Reporting back!
In the Hubitat, I'm now seeing more consistently that my mode changes are persisting on the devices - both devices now state the correct temperature during the correct time slots (in Hubitat). So that bit seems more consistent! Thank you!
Having a bit of trouble with the Cloud aspect, though. What i'm seeing pretty consistently is that only one zone at a time will get updated in the cloud, even though both are updated in hubitat at the same time. I'm thinking this may be partially a function of my prior tinkering, though. Can I ask which configuration option sets the Hubitat to PUSH things to the cloud? I may have disabled it - I see one call at my mode-switch timeslot in the logs, and then nothing.
There's "Polling" at the device level, and "Refresh Interval" at the Scheduler level.
Would either of these accomplish my goal of "if the cloud and hubitat differ in values, push hubitat value to cloud"?
"Polling" is the button that causes a poll. "Refresh Interval" is how often the automatic push of the poll button occurs. Ultimately they do the same... push the button to poll NOW, or let the automatic timer push the button for you.
And just to clarify, does Poll mean "push hub to cloud" or does it mean "poll/read cloud values"?
read
Poll means asking Honeywell for your Thermostat data.
Is there anything that would initiate something in the opposite direction (hub -> Honeywell Cloud) other than manually clicking "set" again in the hub device?
