Looking for help in resolving an issue with Smartthings Routines and Ecobee thermostats. I tried support, but have not received a reply for more than a week.
I have 3 ecobee thermostats. I use Routines to automatically run and set temperature on two of them (based on modes that reflect various occupancy scenarios). However, when a routine executes it sets the programmed cooling point to all three thermostats. Even though only one is selected for each routine.
I thought maybe the issue is on the Ecobee side, and so I tried to set the hold temp on one (using Ecobee app). Only that one got affected. So I believe the issue is with Smartthings…
Can anyone shed a light on why this could be happening and how it can be fixed?
Yes, I know about grouping. I do not have a group. I asked the Ecobee support to make sure I really do not have a group on their end and all three tstats are working independently. They have confirmed. Also, as I said, even after that I still tested setting the hold temp on one of them using Ecobee app and it did not affect the other two. Only Smartthings Routines work this weird way… Very frustrating.
Sorry, it was worth a shot. I had a similar issue when I set 6 of them up. I wrote my own app to respond to mode (routine) changes that accommodated different set points for the three different groupings that I wanted. I haven’t gone back and tried the standard app. Good luck.
@yvesracine, thank you for your reply. I was looking at your work with ecobee tstats. I am new to Smartthings and have never tried custom devices… But if you say it most likely will fix my issue, I am willing to try. Will start learning the setup… Thanks again.
@yvesracine, thank you so much. I followed your instructions and installed my first custom device. That has fixed the issue. Now the setcoolingsetpoint works just for the intended thermostat. One question about changing a preference of how long should the hold stay in effect. I set this parameter on each tstat using native Ecobee interface. Will your code override it? I’d rather it won’t because it is different for one of the three. Thanks again.
I’m glad that My custom Ecobee device fixed your issue. As you may find out, it also unlocks a lot of features as My Ecobee Device basically exposes all ecobee3 features (contrary to the stock ecobee device that just exposes not even 10% of its features).
You may also want to expose your ecobee3 remote sensors as ST individual temp & motion sensors.
It says that the indefinite hold is the default. After some testing, I can say that the ecobee APIs will override your default holdType set at the thermostat (not my code).
You can change the device (associated to your thermostat) preferences to switch the holdType from indefinite (by default) to nextTransition (as specified in step 7 of my readme file). I personally use
nextTransition as holdType in order to use my ecobee schedules as much as possible and only override them when I’m away or back home.
P.S. If you need the holdHours holdType or any other ones, then you can set it with a MyEcobeeDevice.setClimate() call, but you’d need to code a specific smartapp to use it. I can give you more details on how to use it if needed.
I installed a couple of your SmartApps. Do I need to enable OAuth for each of them? Also, I am looking for them under the SmartApps menu in the iPhone ST app where I see MyEcobeeInit, but they are not there… Is this the right place where they will eventually appear or somewhere else?
(1) No, you don’t need to enable oAuth unless specified. The only case is for My Ecobee Init.
(2) If you have upgraded to the new UI, click on the Smartapps link in the upper section of any of the following screens: Home & Marketspace, and then MyApps (last item in the list). That’s where all the custom smartapps from the ST community will appear (in general).
(3) And, don’t forget to ‘Publish for Me’ any installed smartapps otherwise you just won’t see them!
@yvesracine, I wanted to use your ecobeeResumeProg for various scenarios based on mode changes. I have three distinct modes, and so I decided to install this SmartApp three times, each under a unique name. So, I changed the name in the code before installation. After I successfully installed them, I configured each as I needed - resuming programming of specific tstat(s) on specific mode(s). For example, the initial state is our vacation home is unoccupied with three tstats (main floor, master bedroom, and upstairs). When I arrive, I only want to resume programs on the main floor and our master bedroom, not upstairs. When people who I rented the house to arrive without me, I wanted to resume climate programs on the main floor and upstairs (if they are with kids), but not in our master bedroom.
@vitaly, when I read your requirements, I only see 2 distinct use cases:
(1) When you come back as owner, you want to resume your main floor and MB thermostats
(2) When tenants come back, you want to resume your main floor and upstairs thermostats
So, based on your use cases, I only assume that 2 instances are enough.
I don’t have any details on why you’ve defined a 3rd instance…Is it based on a different mode? How is it different from the other 2 use cases above?
BTW, you don’t need to make any changes to the code in order to create a new instance: just ‘assign a name’ to it in the last page of ecobeeResumeProg. The name should be different for each instance.
P.S. In one specific instance (for example when you come back home), I’d recommend to also use motion sensors (if you have any) as ST hello modes are not always reliable, especially if they are only based on presence sensors such as smartphones (whether iOS or Android).
The third use case is whether the renters are with the kids or not. The kids room is upstairs. Sorry I was not specific. But you have answered my question - separate instances are indeed needed for my scenarios. Plus it is good to know that changes to the code was not necessary.
For now I don’t have a motion sensor. I do have a separate Honeywell security system, though. My next project (when I come back to the vacation home in October) is to see if I can add a Z-wave board (L5100-ZWAVE) to the existing security panel. I don’t know what that panel is, but will find out once I am in the house. If I succeed then I will have an ability to use motion sensors (I think). Any suggestion on this?
@vitaly, if you are planning to buy the L5100-ZWAVE module,and hook it up to your ST hub in order to get your security zones’ status, then hold on as this solution will not work.
The L5100-ZWAVE is a z-wave controller and the ST hub does not support controller to controller communications.
I’m not an expert in Honeywell as I have a DSC alarm system, but you should look up your options (which could be limited depending on the type of alarm panel you have) in the ST community forum. You can start here:
I’ve documented what I’ve done with my DSC alarm panel here:
I have been using the L5100 for the past 4 years for the alarm function and the Zwave. I recently bought the Smartthings hub and transferred all devices. If I make the Honeywell a secondary controller will I be able to activate or deactivate the alarm from the Smartthing app? If not, what would be the benefit to making the Honeywell a secondary controller? Thank you.