SmartThings Community

[RELEASE] Free Ecobee Suite, version 1.6.**

askalexa
thermostat
smartapp_hvac
dth_hvac
project_hvac

(Mavrrick) #249

Barry,

I have a situation where I have the smart contact helper enabled with the purpose of turning off the HVAC when a door or window is opened for a period of time. It seems to work great if let’s say a door is opened and them closed and nothing else happens, but If I have more activity like the same door is opened twice or multiple times it seems to get tripped up and turn off the System. I seem to have this happen allot because I have a dog that likes to go in and out a good amount. All I have to do to get the system back in a good state is just open and close a door, but I would like to know if this should be expected


(Barry) #250

Do you have a delay time set for both open and close conditions? You might need to make them longer…


(Mavrrick) #251

The delay timer to turn it off is 3 minutes. The delay to turn back on is set to 0


(Barry) #252

Try 3 and 3 or maybe even 5 and 5…


(Barry) #254

Tony-

thermostatOperatingState tells you exactly what you want to know - it changes each time there is a call for heat or when the call for heat is satisfied. You might see it change as a result of a timed event, but that would only be because the timed event called for heat and/or the timed event changed the setpoint.

I know it is correct, because thermostatOperatingState Is what controls what the device shows (in the SmartThings DTH) when it is heating/cooling etc.


(Mavrrick) #255

can you explain why changing the delay to turn it on to 3 min is going to help. Your default values are 5 min to turn off and 0 to turn back on.


(Barry) #256

I made the suggestion as a possible quick solution to the problem you described.

The default values are what I thought reasonable for “normal” door usage, where the door doesn’t get open/shut in rapid succession. The on delay was added specifically a year or so ago for someone else who had a similar situation as yours. By delaying the “on” activity, a race condition is seemingly avoided.

If that doesn’t resolve the problem (or if you are unwilling to try it), then I’ll need you to set the debugLevel (in Ecobee Suite Manager/Preferences) to 5, and then capture Live Logging for the Open Contacts helper while you recreate the situation that incorrectly turns off the HVAC.

FWIW, SmartThings events (like door opened or closed) do not always get reflected to apps in the order they occur. They are also asynchronous, so an instance of Open Contacts can actually be handling Door Opened and Door Closed for the same door at the same time. The delays (in part) help to mitigate the situation…


(Mavrrick) #257

No worries. I already implemented the change you suggested. I will see if it makes a difference. I was just curious as to what logic was involved with how that would help. Thanks for the explination, and great work on the Ecobeee suite.


(Brandon L) #258

@storageanarchy I just wanted to see if your DTH & SmartApps can address my use case.

I have used SmartThings to trigger away and to resume for a while now with another DTH that has a limitation of not being able to use a global hold type of until next scheduled event while still making my away hold stick forever. I’m using WebCore for the logic and it’s been great, except recently the change to until next scheduled event had limited the usefulness of away. Can your DTH set away indefinitely, and resume while passing commands from the ST app and connected Google Home/Assistant that only hold until next event?


(Barry) #259

I’m not quite sure I understand the question, but let’s start here:

  1. You can specify a (global) default hold type to be your choice of:
    • The setting in the thermostat
    • The setting in the Ecobee Suite Manager parent application
    • A setting specific to each Ecobee Suite Thermostat device
  2. Choices are Permanent/Indefinite, Temporary/Until Next Program, Hourly (some number of hours, also configurable).
  3. Programmatically (e.g., via WebCoRE) you can specify the Hold Type for any call that sets a hold (setpoints, programs/climates, fan mode/circulation). Selections are as in #2; default if not specified is based upon #1
  4. Each of the Ecobee Suite Helper SmartApps allow you to specify the hold type that you want for each selected action
  5. Vacations are supported as a Hold type. Unlike other Hold types, Vacations cannot be overridden by another Hold - a Vacation Hold must be explicitly cancelled before you can successfully set another hold (no matter where the hold request comes from - Alexa, Google, another Helper App, WebCoRE). API commands are provided to create and cancel Vacations

That last one is important because of one design decision I made. Ecobee thermostats implement a concept of “stacked” Holds - that is, if you have a Permanent Hold set, and then manually/programatically change a setpoint (creating a Temperature Hold) that hold is “stacked” on top of the current one. So if it is temporary/hourly, when this second hold expires, the stat returns to the original hold. And in the case of a Permanent Hold, the only way out is to ResumeAll back to the currently scheduled program, and then apply the new/requested Hold.

For me, this was confusing, especially if the wife tried to use the thermostat to override the current temperature setpoints. So, I took the decision to ALWAYS flush the stack whenever a request to setThermostatProgram to anything different than the current hold program and holdType. This may be a problem for you, because if you are in Hold: Away (Permanent) and Google asks for Hold: Away (Temporary), the permanent hold will be overridden. If that is in fact a problem, let me know, as there is a workaround, but it’s possible you don’t need to know the complexity.

If you could share some details about your intended use case, I can more confidently give you a suggested approach using my Ecobee Suite. Since I invested in this primarily because I wanted a more intelligent handling of SmartThings Modes and Ecobee Programs when I am home, while keeping the thermostat in “Away” when nobody was home for several days, I’m pretty sure your use case is covered (although maybe not the way you have envisioned it).

Hope this helps…


(Chris) #260

I am on the latest 1.6.16. I get the same error message when there are no helper apps also.


(Barry) #261

I think maybe you should uninstall everything and start over.

Please, follow the instructions in the documentation to do that (basically, remove everything in the reverse order you created/installed it). Then, reinstall again, meticulously following the installation instructions.


(Brandon L) #262

This is exactly the information I was looking for! Thank you for being so detailed, it really is helpful.

My setup includes:

  • Google Home Minis
  • WebCoRE
  • Life360

After many issues with Samsung’s location services I use Life360 as a presence sensor, I have no smartapps except for those required to get devices into WebCoRE. Presence is passed to webcore and actions are triggered via logic there when the home determines it’s empty (all people gone) or occupied (at least one person home). The Ecobee’s internal settings are set such that holds are until next event. The current DTH I’m using defaults to all holds being permanent, which is great when setting away, but not when I holler at Google to make it X degrees warmer/cooler (which routes from Google to SmartThings to the DTH) and thus sets that change as permanent.

So the solution I’m after is a simple DTH that allows me to keep the Google-routed and SmartThings-app triggered changes as Temporary, while still allowing WebCoRE-programmed settings of away to be set as Permanent. Returning from away is as easy as a resume command that wipes all holds and voila.

I try to make the Ecobee do all the work (minus location based away) so I don’t have to fight against the way it’s meant to be used or update temperatures or schedule in more than one place.


(Barry) #263

Then you should have no problems with my DTH. Set the default hold type in my Suite to Temporary, so that stuff from Google/SmartThings expire at the next scheduled program change, and have WebCore make a (custom) call to set the Away program with the Permanent flag…

FWIW, you should be able to install my Suite alongside whatever you are currently running, then change the device that you have WebCore and Google pointing at. Then you could test it out before fully disassembling what you currently have…Once satisfied, you could then remove the old DTH.


#264

Anyway to figure out why my ecobee (3 lite) keeps turning on to auto mode when I turn off the thermostat? I’m using this smartapp and I don’t have anything changing the thermostat ( like webcore).


(Barry) #265

Try setting Debug Level 5 in Ecobee Suite manager, then monitor live logging for Ecobee Suit Manager and Ecobee Suite Thermostat.


#266

I messaged you as to not take up the thread. Thanks


(Rob) #267

I’ve successfully created webCoRE pistons that set a temporary hold for Ecobee programs like this: setThermostatProgram('Home', 'holdHours', 1)

…but how do you set a temporary hold for specific temperatures? It doesn’t look like ‘setTemperature’ works or I’m using an incorrect syntax. I’m sure I’m missing something simple, but I can’t seem to find it in the ecobee documentation either.

Thanks for your help!


(Barry) #268

Setpoint operations are as defined by the SmartThings “thermostatSetpoint” capability.

You need to call:

  • setHeatingSetpoint( temperature, holdType )
  • setCoolingSetpoint( temperature, holdType )

where holdType is one of indefinite, nextTransition, or an integer number of hours to hold

You can call one or both, if you only call one, the other will remain the currectly scheduled temperature, and if you call both, you should do so one after the other, and the actual hold type will be the one specified in the last call.


(Rob) #269

I don’t see the setHeatingSetpoint() or setCoolingSetpoint() commands in webCoRE. Am I missing something? I do see setHeatingSetpointDelay(), though.

There is a Set Heating Point command, but there’s no way to add parameters to it. The hold type defaults to whatever the DTH or SmartApp is set at in the app.

Thoughts?

Thanks for all your work on this! :+1: