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.
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.
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.
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.
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
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.
