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?
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…
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.
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…
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
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…
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…
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).
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.
Or, they just need to contribute to My Ecobee bundle as this feature has been implemented for a while (and many others)…
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.