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.
http://thingsthataresmart.wiki/index.php?title=EcobeeSetZoneWithSchedule
Regards.
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):
http://thingsthataresmart.wiki/index.php?title=Ecobee3RemoteSensorInit#Known_issues
Otherwise, you can choose the standalone version which is cheaper.
Regards.
@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.
http://thingsthataresmart.wiki/index.php?title=EcobeeGetTips
Regards.
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.