Ecobee integration: another example of moving backwards to move forward?

When NewApp was introduced, we found that the Resume function was no longer implemented in the app UI. However, Webcore’s resumeProgram() continued to work, and I leveraged that. Fine.

At some point last week, the ecobee integration in NewApp just stopped working, status was checking continuously. So I went into the Linked Services and had to re-authenticate - I presume a backend/driver change. Now I find that not only does webcore resumeProgram() function no longer works, but the integration no longer offers the feature of the previous @ecobee integration to choose whether changes in ST are temporary (overridden by the next schedule change) or permanent until cancelled.

So now, if I’m going to make a change in an ST Automation to temperature (e.g. to lower the thermostat when everyone leaves), I have to know the time of day/schedule in order to set it back. I can’t automate resume schedule, or automate set schedule to Away and mode to Home when I return.

Anyone @SmartThings have a solution to this use case?

This is a big usability gap. Approaching death by a thousand cuts, as ST and vendors seem to keep implementing just the basics and losing the value-add.


I ended up using the Ecobee Smartapp which will soon be deprecated with the end of Groovy. I actually contacted Ecobee support and made the suggestion that they implement the full capabilities into ST but they didn’t seem very interested.

1 Like

The same thing pertaining the the permanent hold occurred with the Honeywell thermostats as well about six months ago. Discussed here:

I haven’t worked with thermostats, but I do know that ‘resumeProgram()’ was a custom command. The thermostat capabilities have evolved considerably since then. Does one of the greatly expanded selection of thermostat modes not do the job? Naturally ‘resume’ seems interesting, but as I say I haven’t worked with thermostats so it is just as likely to be unrelated to the issue at hand.

Modes, like OFF/HEAT/COOL/AUTO? Those have always been there.

However, switching to OFF and back to HEAT, for example, does not put the thermostat back on it’s built in schedule - the override sticks.

I feel your pain @Bry

Worse for ecobee:

It is a near death experience for Neurio, probably same for ecobee once they close. Explains why some have seen a lack of interest by ecobee in improving support for their product.

Yes, I was querying if perhaps all three dozen or so weren’t around when the original integration was created, and perhaps if they had been there would never have been a need for a custom ‘resumeProgram()’ command.

thermostatMode is arguably intended to handle it since it includes manual, resume and schedule as modes. That’s also the capability that swaps between heat and cool though. It really seems like they just tried to cram every possible ‘mode’ into thermostatMode without considering whether they represent different dimensions of control.

I’m using a separate custom capability for my zwave thermostat to toggle between manual/schedule/eco modes separate from heat/cool/off. Could certainly use thermostatMode to handle it all by making use of cool/autocool/energysavecool and heat/autoheat/energysaveheat modes, but I don’t think the family would be able to remember which one they’re supposed to choose.

You can set in the ecobee app to only hold until the next schedule event.

Good thought! However, this only effects changes made through the ecobee itself/ecobee app. Smartthings changes are still defaulting to permanent hold.

My guess is the ecobee API allows the sending application to choose whether or not the hold is temporary or permanent, and the folks that modified the integration recently decided to force it to permanent (thanks SO much).

At least with Honeywell, you can still set the permanent hold and the resume program from within IFTTT. I just re-enabled a couple old applets, and they work fine triggered by location.

I somewhat solved this by using Rules in ShartpTools to override the Thermostat settings. It somewhat mimics resumeProgram.

Right, I guess… if the only way is to make a smart thermostat dumb, and just take over its schedule top to bottom

Ecobee also has an IFTTT implementation that I could leverage to make up for ST’s shortcomings. I may give that a try. I’ve never had to resort to needing IFTTT until now, shame.

Same issue… I have home assistant running with a smartthings integration (uses SmartThings Web API). Eveytime something like this happens. I fire up a new integration into home assistant and rip it out of smartthings. The ecobee integration is super powerful in home assistant, a definite upgrade!

Omg tbis is driving me nuts. My resume just stopped working the other day in webCoRE. Is there any work around and other device handlers that it works with

Did you also need to re-establish your login to ecobee in linked services recently?

By “stopped working” do you actually mean the function is no longer exposed? I have Honeywell thermostats, so I do not know if this applies to Ecobee. SmartThings removed the resume program capability. I wound up using IFTTT, as it still works there, at least for Honeywell. Something to check/consider.

I had to re authenticate. Then it stopped working. I still see the option in webCoRE. The piston runs but doesn’t change the ecobee. I will check out ifttt thank you!

This whole thing makes little sense to me. I would think that the only reason such a function would be removed is if ecobee re-wrote the driver in Edge and just didn’t expose this function. But I don’t think any vendor is doing that yet. Why would ecobee invest any time in releasing a different version of the old Groovy drivers? Especially since they don’t even seem to make time to respond to support questions in a timely manner.