SmartThings Community

Any way to get ST to follow ecobee hold rules?



I use Actiontiles as our primary home control in our place to control all our devices so I have an ecobee tile there via Smartthings.

However, when a temp is set with Actiontiles/ST, it sets that temp on hold indefinitely. This is terrible and luckily I do have a lot of other stringify flows that resumes the thermostat when we are all away or going to bed.

Within the Ecobee settings, I have set my “Hold Action” to 2 Hours. (When you change the setpoint outside of the schedule, it will be effective for…) so the expected result is that when a temp is changed, it will resume schedule in 2 hours. When set within the actual ecobee app or through voice via alexa, it works as expected.

Is there a way to get ST and effectively Actiontiles to follow the 2 hour rule?

(Yves Racine) #2

Hi, you’re probably using the ST stock device which doesn’t allow you to change your default holdType settings (by default, any hold set through the ecobee APIs is indefinite).

To define your holdType to be for 2 hours (any custom value) or till the nextTransition at the thermostat, you’d need the custom DTH I’ve developed for the last 3 years:

For more details on the holdType input parameter for My ecobee Device, refer to the ST community wiki:


Check this

There’s also a Free ecobee dth that you can try out and see if it meets your needs
[RELEASE] The Best FREE Ecobee DTH and Helper SmartApps - Now with Ask Alexa Message Queue Support, and an Enhanced User Experience!.
If it meets your needs drop a beer or coffee :coffee:️ donation:).


Thank you both, Ill take a look more into this!

(Barry) #5

I’m the latest author/contributor of the Free, no-strings-attached DTH refrenced above. While it does not yet support setting Hold Hours, this is in final testing for release soon. Meanwhile, it does support Hold Until Next Transition/Scheduled Event.

My DTH also avoid another confusing feature of Ecobees - that of “stacked” holds. For the native Ecobee apps, and at least some of the other available SmartThings DTHs, Hold requests are “stacked” on top of each other - so if you set a hold Indefinitely, then set another hold for 4 hours, after three hours, you will be returned to the Indefinite hold. This gets even more confusing using Holds and Vacations. My DTH instead maintains only a single Hold - in the above described case, the 4-hour hold will REPLACE the indefinite hold. Most people find this more consistent with their expectations.

Whichever way you choose to go, I’m sure your problems with ActionTiles can be addressed such that you can set the hold with ActionTiles and have it return to the previously scheduled program at your expected time…

(Yves Racine) #6

Actually, with my Ecobee device, you can maintain one “hold” only or stack them up… It’s really
up to the users to choose what’s the best method according to their use cases.

device.setClimate(…) // will pile up the “holds” like in the original ecobee feature
device.setThisTstatClimate(…) // maintain just one hold at any time

These methods have been around since the 1st version of My Ecobee device…

P.S. It’s the most comprehensive ecobee implementation and it can grow with your requirements as you want more and more from your ecobee thermostat.

I’ve developed also a lot of smartapps to control smart vents, humidifer/dehumidifier/HRV/ERV, fan/damper/evaporative cooler switches in conjunction with your ecobee to maintain the best comfort at your home.

And, there are some upcoming releases with a new manufacturer soon that will give you even more options with my zoned heating/cooling solutions.


(Yves Racine) #8

Just look at the list of supported commands and you know what I mean by comprehensive:

I have some happy contributors who have been using my solutions for more than 3 years, like this one:


(Yves Racine) #9

You seem to conveniently forget that most of your “supposed” code was developed by @StrykerSKS

It’s much easier to take over someone’s else code and make it your own than come up with a genuine good design. So, you’re not the author, but the co-author at best.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #11

Give one or both of the enhanced DTHs a try and be sure to write if you find that there’s still a gap in the UI that ActionTiles needs to consider filling.

ActionTiles recently enhanced our Thermostat Tiles significantly in our latest Release (v6.6), but that led to a few additional feature requests. I’d not be surprised if there will be more.

(Barry) #12

In the case of changing the heating/cooling/thermostatSetpoint, there shouldn’t be anything that ActionTiles needs to do - at least, not to support the “generic” functionality of thermostats as defined by SmartThings. The issue here is in how long a Hold is supposed to last, which SmartThings does not define. So, it’s pretty much up to the DTH implementation to address the default Hold duration when (for example) temperature setpoints are changed from the currently-defined Program (which Ecobee calls “Climates”). Forcing complimentary apps (like ActionTiles to utilize the custom DTH API calls to make things happen (as in Yves’ example of setClimate() vs. setThisClimate() ) simply won’t scale.

Fortunately, SmartThings is starting to expand the definition (and capabilities) of their model thermostat. The latest additions allows DTH’s to expose the Modes and Fan Modes that the DTH/thermostat supports - hopefully soon they will also expose Programs and perhaps even Hold durations. Until then, DTH’s have to present a logical simplification for apps to access using only the ST-defined API calls…

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #13

This is something we appreciate across the board (especially as various new complex “official Capabilities” are introduced by SmartThings).

If they are incomplete, it has been a mixed blessing that DTH developers can put in any random ad hoc Commands and Attributes they need. It adds a lot of powerful immediate functionality, but, indeed, it does not scale…

(Yves Racine) #14

I really don’t share your optimism regarding the ST expansion in terms of thermostat capabilities. I have always strictly followed the existing ST standard capabilities (here is a good example: do you know that thermostatSetpoint should be the median between the cooling/heating setpoints where the thermostat is set to ‘auto’?)…Well, it’s important to know when you want to control the smart vents in ‘auto’ mode (especially when you are doing proportional control of the vents in a zone).

An ecobee thermostat and a z-wave thermostat are too different beasts (even a Nest thermostat is not currently able to support the resumeProgram command as an example)…So, there is no way that ST will able to standardize every aspect of a smart thermostat like ecobee.

However, to make all the ST thermostat DTH’s code more compliant, I suggested more than 2 years ago to introduce the concept of metacode (on top of the existing metadata section) to force the implementation of all the ST thermostat’s capabilities in all thermostat DTHs.

The same concept could be applied to other ST standard sensor/actuator capabilities…

Still waiting to see any action on the ST side…


(Barry) #15

Thanks, Yves- I have been wondering about that and I couldn’t find that info anywhere in the documentation.


Just to clarify, your DTH does not yet follow Ecobee’s current hold settings shown here? i.e. if I set my temp within the ST app or Actiontiles, it will not currently follow the set ecobee hold rule?

(Barry) #17

No, the DTH does not use the preferences setting - that setting is only used by the device and Ecobee apps.

With the currently available version of my DTH, you can only select Temporary (until the next scheduled activity) or Permanent (until I change it) as the default for a hold.

An upcoming update will allow you to select a number of hours as a third option. (There is no easy way for a ST DTH to implement Decide at the time of change - you have to choose before setting the hold).



Would it be possible to add a condition to the smart circulation to run at certain time of day?

I ended up doing a new mode and switching to it as a workaround with webcore but wondering if ‘run only between this x and that y time’ tweak ?

(Barry) #19

I will put it on my backlog, but I probably won’t get to it any time soon (sorry, other priorities).

Meanwhile, perhaps consider creating a new Program/Climate on your thermostat (e.g. “Circulate”) and add that to your Schedule for the desired times/days. Then use the Helper App to change the circulation duration.


Writing steps for others maybe or just so that I don’t forget the process for future reference:

On Ecobee:
Added a ‘Circulate’ custom Comfort Setting aka Program that starts at 1PM.
I then added to my ‘Circulate’ to my Schedule on certain x days.

On smartthings>Ecobee>Smart Circulation>
Only when Eco… Program is selected ‘Circulate’

This should do it, until the backlog item gets implemented. Thanks much!

(Yves Racine) #21

Or, they just need to contribute to My Ecobee bundle as this feature has been implemented for a while (and many others)…

In EcobeeSetZoneWithSchedule:

  • Go to Schedule Setup>Fan Settings>Enter a value for Fan Min Run Time.

  • Users can also indicate a temp differential between all their indoor ST connected temp sensors (not only the ecobee ones) over which they want to override the current fan mode and run the fan (optional)

  • And, specify an outdoor temp threshold over which they want to override their current fan settings and turn their fan on (optional)

  • The predefined ecobee fan settings will resume when the conditions are no longer met.



The screenshots show that it also doesn’t have the ‘only when time is between x and y condition’, not sure this would help my use case, the ‘Smart Circulation’ helper child app already covers everything on the screenshot except for the ‘Outdoor temp’s threshold for Fan Mode’ but not needed for my use case.