Anybody here use Honeywell Wi-Fi Thermostats and the Total Comfort Connect app to link to SmartThings? I also use Tasker & SharpTools to control my Thermostats. If somebody leaves, I make changes. When they return, I revert to the standard Thermostat schedule. This was possible because one of the commands available in Tasker/SharpTools was “resumeProgram”. However, possibly after a SmartThings update the other day, this option is no longer available. There are now only about 12 options available to control the Thermostat when there used to be 24 until a week or so ago. I only noticed this after SharpTools starting throwing errors when I ran my Tasker Task.
Anyway, I have deleted the Thermostats from SmartThings and reconnected TCC. When I do, SmartThings says that it’s not fully operational in the US. How can that be? It all worked a couple weeks ago.
Anybody know if there’s anything I can do about it? This is now a real PITA without being able to resume the standard schedule. I can still set heat and cooling points with ST, but then it creates a permanent hold on the Thermostat which I can only turn off manually now.
P.S. Update - By the way, I just tried to create an automation in SmartThings using the Thermostat and resumeProgram is not one of the options. Obviously, it seems like SmartThings removed this option with the latest update. Sigh. So, I think I’m screwed and there isn’t a way to fix this unless SmartThings fixes it.
I too have a Honeywell Wi-Fi thermostat. I feel your pain. I was using webCoRE to issue the resume schedule command. Until about four months ago when something changed. Now I can’t use resume schedule.
Dang, that’s what I was afraid of. I was going to check it in WebCore but figured it wouldn’t work there if it didn’t work in SharpTools or in a SmartThings automation. I don’t understand why functionality keeps being taken away. Oh well.
Exactly the same situation here. The legacy thermostat seems to have been replaced with a web placeholder and, as you say, the resumeProgram option is no longer there. It was the only way to revert to the standard schedule. It’s a real pain now it’s gone, although I only had a couple of routines that used it.
The other issue I have noticed is that changes made directly on the thermostat or via the TCC app take forever to be reflected in ST (either in the app or on webcore). I have a couple of alerts that get generated if the two thermostats I have are running in inconsistent modes (i.e. one set to cool and one to heat) or when a setpoint is moved outside of specific values. These alerts no longer fire because the updates don’t get to SmartThings!
I noticed something else, maybe. Although I used to set the thermostat via webCore when I’m away, I decided to do it within the automation. When I used to set it with webCore, it was set as a PERMANENT hold. I just noticed that when set by an automation, it’s a TEMPORARY hold. I haven’t gone back to webCore to see if that’s changed. Maybe it’s always been this way but I didn’t realize it as I always used webCore?
So it seems that using both webCore and the ST app now results in a temporary hold when you change the setpoint. The temporary hold expires at the next programmed schedule change.
It sure did. A temporary hold doesn’t really have much value, at least to me.
And now that I am paying attention to it, ST is not picking up the proper cooling setpoint. From what I can tell tonight, it still is reflecting the last setpoint that it set. The problem is at after I returned home I cancelled that temporary hold, but ST has yet to update to the proper value.
I can’t set a temp on the Thermostat using ST. The thermostat shows as connected but when I change the temp I get an error that the thermostat is not “connect” (it’s a typo in the error message; it should read connected). So, I can’t see if it’s a permanent or a temporary hold…
Mine will still set it, but won’t pick up a change made out of ST.
An additional problem is Google Home apparently obtains setting information from ST. So if ST doesn’t update to the correct setpoint, GH will provide incorrect information if you ask it what the setpoint is.
Thanks, unfortunately mine are not wifi, they are the Prestige IAQ where the thermostat connects to it’s own receiver network cabled to the router. Not sure if that can be added. Think it takes a cloud integration.
Plus I’d still like to get the old ST functionality back.
I think reporting to ST is just a massive delay. When I went to bed last night, ST still hadn’t picked up the setpoint from a manual adjustment around 9 pm. When I work up this morning, it was correct, so it EVENTUALLY updated.
The solution that I have implemented is to have a webCore piston run every 5 minutes and “With Downstairs Thermostat and Upstairs Thermostat” do “Refresh”
This then polls the two thermostats and updates ST with the current temperatures, setpoints etc.
ST then triggers various other pistons reliably. If I have need to cancel a hold and resume the previously scheduled program then this is done using a simulated switch. When this simulated switch turns on then IFTTT runs the “Resume Programmed Schedule” action against the relevant thermostat.
Finally the simulated switch is turned off.
It’s a bit clunky but it does the job. Obviously I wouldn’t need the 5-minute refresh if the integration between ST and TCC worked as it used to…
You got me thinking when you mentioned using IFTTT. Obviously, the “Resume Program” function is still exposed, but ST is no longer displaying it. I found that it’s still exposed to the SharpTools Rule Engine; however, it’s not functional, presumably because Sharptools is really an extension of SmartThings whereas IFTTT is not.
