In case anyone else has this issue. If you set the system type to the wrong setting for your a/c the heat will pump out when you have the cool setting on.
1 Like
Yeah... That would definitely do it.
Question: Does anyone have more than one of these thermostats? I have had one for a few weeks and everything works fine on the heat pump in my bedroom, but I am unable to pair a second one to replace my main home thermostat.
It just blinks "Failed" after I attempt to pair. I've already tried to exclude it first before I pair it but that didn't help. Also tried the factory reset.
1 Like
I have 3 of them running
OK, I figured that wouldn't be a limitation. Any thoughts as to why the pairing would fail? This was an Amazon Warehouse one and it seemed to be paired previously, hence the exclusion when I started. But I've attempted to pair at least a dozen times with no luck.
Maybe just defective?
It is possible it is defective.. Amazon has been known to re-stock returns.
i know it's crazy to circle back on this 5 months later but I can confirm this on my 2 thermostats as well. default CDelta Stage 1 ON is 1, but I hit configure and now it defaults to 2 every time I set to 1. Not sure how to get around it because I liked how my system was running before. Now everything is too hot.
Follow up - I was able to get the C Delta Stage 1 ON to retain a value of 1 by resetting the thermostat manually at the device.
process to do so is on page 16 from the docs: https://www.gocontrol.com/manuals/GC-TBZ48-Install.pdf
Seems anytime i set any other advance configuration, either at the device or from the driver in Hubitat, it changes the C Delta Stage 1 ON value to 2 and won't let you revert. If you do a reset and then don't touch any other settings, it will keep the default of 1.
I was hoping to raise my minimum run time from the default of 3 minutes to a higher value, and also play with the C Delta Stage 1 off value - but will stick with the default.
NOTE: If you have a Heat Pump, Make sure to change your system type in device settings from Standard -> Heat Pump. I forgot to do this once and blew a 3A fuse on my blower. Luckily, i had a spare.
@JasonJoel - you mentioned somewhere that you had moved some of your SensorCal logic to NodeRed. Do you have a flow that you can share? Curious how you are doing this...
1 Like
I don't have the flows handy anymore. That was 2 thermostats ago for me. 
There wasn't much to it though. Every 5 minutes I looked at the delta between desired temp sensors and thermostat temperature reading, calculated the new sensorcal to use, and wrote it to the thermostat.
Ha! What are you running now?
edit: thought I remembered you running 4-5 of these?! 
I have 4 thermostats.
I replaced the GoControl when I couldn't ever get the delta setting to stay at 1. Sounds like you found a workaround for that. 
I'll try that on my dev GoControl thermostat I still have later.
Then I went to Vivint CT200. Worked pretty well, but they have an annoying habit of resetting the setpoint semi-randomly at times on SOME (but not all) thermostats.
So, back to Ecobee for now (local integration done via homekit through Home Assistant, so I don't have to rely on Ecobee's semi-unreliable cloud).
1 Like
Why do we do this to ourselves?! 
1 Like
Apologies in advance if this isn't the right place to post this.
I have been having the issue with the GoControl where, despite being set to Auto, it seems only the cooling setpoint updates in the morning from 70 to 77, whereas the heating setpoint fails to update from 65 to 69, so I have to manually do the latter each morning. At bedtime, both the heating and cooling setpoints seem to update back down as desired. This is all controlled via the stock Thermostat Scheduler app, and I confirmed in the logs and details that the app itself is updating everything correctly. I also confirmed by debug logs that indeed only the cooling setpoint on the device seems to update and not the heating one. I also confirmed that the values match between the device details in the console/logs and on the device itself. I don't know much, but this felt then like a potential issue with the driver.
So then I found this thread yesterday, and was hopeful that maybe it would solve the issue! But I installed this new driver (made sure to hit configure), and the issue persists this morning. Does that mean it is not a driver issue, or just that it didn't fix it or that I didn't install it correctly?
I had forgotten to re-enable debug logging last night, so I can confirm tomorrow morning whether the logs for the thermostat indeed still reflect updating of only the cooling and not the heating setpoint.
Finally, I have no idea what this setting means or if it's relevant, but I see "Change Over Type", set to "CO w/cool". I just changed it to "CO w/heat", the only other option. Would that be relevant here?
So I noticed an issue with this driver while in use with homerbidge/maker api. It would not auto update the thermostat modes. For example homerbidge would show cooling when the thermostat was in heat mode on the visual tile, but if you clicked into the tile it would show the correct heat set point but says cooling.
If I went into the device and clicked refresh it would update home bridge. I ended up editing the driver to run a refresh every minute in several spots. Just an FYI in case anyone else runs into this issue.
runIn(1, refresh)
I had the same issue with trying to get the " Temperature Report Periodic
minutes" to stay at 1, it would auto revert back to 5 minutes. I ended up just hard setting it in the driver to change the default value and auto push it.
I just replaced my flaky Honeywell thermostat after 6 years with this hardware and the Advanced driver.
There have been some very odd temp settings arriving at the thermostat in C. It also doen't like 0.5 degree settings in C?
I use Webcore to control the thermostat and weird things are happening.
I set the temp to 13 at night and it gets set to 0.
I set temp to 16 in the morning and I get 68! Imagine my heating bill. I manually have to set it all the way down to 16.
In the day and evening I set to 18 and 19 repectively and those numbers arrive unharmed.
The only thing I see is that the 2 good ones are defined s Dec and the 2 failing ones are Integer. There is a fifth one that is 15 and sets the temp to 0.
So, Ill convert them all to Decimal and see what happens but you may want to look into this?
EDIT: Last night I sent 13 and 0 arrived and this morning I sent 18 and 20 arrived.
Here is a past log of sending 16 and getting 68 sent.
dev:122021-01-09 08:01:58.340 infoThermostat temperature is 17°C
dev:122021-01-09 07:50:43.708 infoThermostat thermostatSetpoint was set to 18°C
dev:122021-01-09 07:50:43.705 infoThermostat heatingSetpoint was set to 18°C
dev:122021-01-09 07:49:21.305 infoThermostat thermostatSetpoint was set to 68°C
dev:122021-01-09 07:49:21.301 infoThermostat is heating
dev:122021-01-09 07:49:18.059 infoThermostat thermostatSetpoint was set to 68°C
dev:122021-01-09 07:49:18.057 infoThermostat coolingSetpoint was set to 70°C
dev:122021-01-09 07:49:18.055 infoThermostat heatingSetpoint was set to 68°C
dev:122021-01-09 07:20:13.710 infoThermostat temperature is 16°C
I think I figured out the 20 degree setting.
I have a WebCore piston that won't let anyone manually set the thermostat to above 20. It saw 68(F) go by and set the temp to 20 as an override.
I've gone to the Generic driver for the moment to see if anything changes fot the better.
Dumb question, does this Thermostat have a humidity sensor in it?
No
Bummer
