Any way to get ST to follow ecobee hold rules?

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 ?

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.

1 Like

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!

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.


1 Like

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.

Of course, a schedule needs to be run at certain period of the day.

Multiple schedules can be defined in the smartapp (up to 12)…

The screenshots show the fan options for a single schedule. The fan options can be different
from one schedule to the next.

Each schedule can be associated to any given climate/comfort settings at ecobee for scheduling.


Does your DTH support the above screenshot of mine regarding default hold times when set in ST (or can you setup a default hold time within the DTH)? Thats the primary thing I need at the moment.

If I just have an ecobee and 1 sensor, I would need the $20 package?

HI @ranova,

As I wrote to you earlier, the holdType parameter can be defined to be whatever you want (indefinite, nextTransition, holdHours: X hours, dateTime).

Refer to the ST community wiki for all the holdTypes supported (within the DTH).

If you want to expose your remote sensor to ST, then you’d need the My Ecobee device with the remote sensors smartapp.

However, please take note of the following ecobee APIs limitations (not my code):

Otherwise, you can choose the standalone version which is cheaper.


@ranova - As I noted above, wiith my (free) DTH you can current set the default hold duration to either “Until next…” (e.g. temporary) or “Indefinitely” (e.g. permanent) for any holds set using the DTH UI or programmatically.

An upcoming release will add selection of 2-hour, 4-hour or “N-hour” holds. At that point, the DTH will also default to use whatever is set in the thermostat, with the option to override within the DTH (ie. thermostat can be configured to use 2hourHold by default, while ST DTH can be configured to use “Until next program”…).

To be clear, I am in no way trying to create a freeware equivalent of Yves’ work - I am simply trying to create a better freeware DTH implementation than that provided by SmartThings, following (more or less) the “less is more” model of simplification. In this case, adding support/flexibility for mode Hold duration options seems a logical extension.

If you need the functionality that Yves provides immediately, then you can certainly purchase his fine work; if you can wait, I’ll get the features supported “soon”.

The fan options are optional settings that you can choose to override your current fan settings in a given schedule.

If you don’t need them, you don’t specify any value. The fan options can be configured differently from one schedule to the next.

@ranova The free version I have been producing also supports the exposure of Ecobee remote sensors (with the same motion-reporting limitations Yves has noted above) as temp/motion sensors within SmartThings.

It also allows for the thermostat itself to be exposed as an external/separate sensor, reporting the actual temperature of the thermostat, not the calculated value that is displayed when sensors are included in the Program. (I suspect Yves’ version does this also.)

Oh yes, you can choose to expose or not the thermostat’s main sensor for its motion/temp capabilities.

That’s up to the users to decide what’s best for them.

My Ecobee device also keeps a lot of stats related to the ecobee’s sensors (min, max, avg) as they are used for providing ecobee comfort tips.


1 Like

thanks for all your guy’s responses. Do you happen to have a timeframe when that release might come out? I added all the handlers of yours last night but I havent added the device in ST yet.

Based upon my travel schedule, the referenced update for hourly hold times will likely will be out by mid-next week.

And how does that matter at all Yves? It is opensource, he is free to reuse it. That was the main reason I developed the code to begin with.

I don’t care if he calls himself the author or not. He made significant changes from my original code, which was also derivative of SmartThings original code. So he is well within his rights to call himself the author of his version.


That’s OK if you’re ok with it. Anyway, he inherited that same design flaws from the original code. No offense, but your code is overly complicated and it creates unauthorized issues as posted in the forum.

That’s fine. I can be the kettle and you can be the pot. Your code was super complicated (can’t speak to its current state).

Had you chosen to work with the community instead of against it then perhaps we would be here bickering and instead could have made even bigger advances. So why don’t you stick to your code and let others be with their code.

A lot of the complexity came from the existing ST DTH/SmartApp. My original goal was to roll the code back into the main branch, but ST seems incapable of working with community developers to actually incorporate enhancements. If I had to do it over again, I would have started from scratch instead.

Btw, starting a sentence with “No offense” doesn’t take away from the offense you are trying to convey.

For you, my code looks complicated but don’t forget that it brings tons of more features…

And, no more unauthorized issues…

EDIT: BTW, I said no offense, because I know that your code was based on the ST original code which has many issues in terms of features and authorization logic.

Go into the device tab in the smart things webpage and go into your ecobee device. Click edit in the preference column and change the holdType value to “Temporary” and you are done.

This doesn’t seem to work anymore. I recently had to delete and re-add ecobee to ST after many years and now when ST changes the temp, it’s “holding” and is not able to be changed except manually.

holdType in Preferences via the ST IDE is set to “Temporary”, but that doesn’t seem to be honored.

I wonder what changed recently here? I suspect others won’t see this either unless they need to add a new thermostat or delete/re-add themselves.