2 Ecobee Si Thermostat + Geofencing

I am trying to set you geo fencing using the instructions on the blog post here:

I have two ecobee Si thermostat and would like to set it at two different temperature upon the return. The “I’m Back” Action only allows one thermostat setting, i can set both thermostat to the same temperature but I can’t seem to set them to different temperatures.

How do I set it to two different temperatures?

Thanks.

At the risk of getting myself sucked into another large product, I had the exact same situation and desires. The path I chose to resolve this was:

  1. Switch from the ST Ecobee device driver to yracine’s
  2. Modified that driver in a few dimensions to match my own desires (e.g., no weather data, switch from C to F, etc.)
  3. Added command functions for the Ecobee’s standard 4 “climates”: Awake, Home, Away, Sleep.
  4. Wrote a SmartApp that monitored location.mode, and then sends the appropriate “climate hold” command to the Ecobees when the .mode changes.

I also made all the holds “Until Next Transition”. This puts the thermostat configuration back in the control of the thermostat. I can set different temperatures for the two tstats, and I can also set different schedules (have the bedroom warm up before the downstairs in the winter, for example). And if I wake up earlier than the tstat schedule, the temp gets raised early with me.

My version of the ecobee driver is way out of sync with yracine’s, but you can find it here:

And the SmartApp is here:

Right now, I can’t promise any level of support, but perhaps if there’s enough interest, we can work with Yves to get this forked merged back in… The install instructions are the same as Yves’ (which you can find here: https://github.com/yracine/device-type.myecobee).

Enjoy!

Hi storageanarchy,

Actually my ecobee device also supports the 4 standard climates (Awake, Home, Away, Sleep) and can display them on the UI. My current device also supports Farenheits, but not on the temperature Tile (as for the moment, there is no dynamic tile that allows to switch from Celcius to Farenheits or vice versa in the smartthings UI framework).

If one wants Farenheits instead of Celcius, he/she just needs to remove the comments beside the temperature tile in Farenheits and put the Celcius temperature tile as comments.

As for jx99’s requirements, your smartapp (GreenSmartEcobee.groovy) would be a nice foundation or you can reuse a smartapp that I’ve developed called ecobeeResume.groovy. You can install it twice with different settings under different names (ex. ecobeeResumeKitchen and ecobeeResume2ndFloor).

My 2 cents.

Yves -

First - allow me to formally thank you for your efforts on your Ecobee device - you have clearly invested a lot of time working through the various intricacies of Ecobee’s APIs.

THANKS!!!

And indeed - I have noted that my version of your driver is based on an older version…I have no excuse other than I grew weary of re-adding my changes after each time you updated yours (especially when you/we hit the max-number-of-lines-of-code limits of the ST IDE). My delta is too far removed from your current to even attempt anything but a manual merge.

Where our approaches differ is where we assign control - you have evolved your device to be the primary control point for your Ecobee thermostats, while I have evolved it to keep temperature and climates controlled by the Ecobee itself and its Climates - via both the Web interface and the iPhone application.

Your approach of hard-setting the temperature holds also inhibits the Ecobee from pre-warming/cooling in advance of the scheduled transitions; my approach allows for early transitions to scheduled Climates while still anticipating my scheduled arrival home and/or wakeup time.

Oh, and I prefer a more simplified tile page, with fewer options.

We each choose to utilize our Ecobees differently, no big deal.

One thing you should consider, though, is updating your version to support all of the defined Attributes for a ST thermostat - most notably the thermostatOperatingState attribute and its pre-defined values. This is the standard published for Thermostats, and people are starting to utilize these in SmartApps.

Thanks again!!!

OK, thnx for the input. I will look into thermostatOperatingState. Regards.

Thank you for the tips. Last night I tried using two “keep me cozy” smart apps to change temperature for “Home” and two “keep me cozy” smart apps for “Away”. The geo fencing works, i can see it change modes – however, for whatever reason, either the smart app is not working right or the ST ecobee device driver is not working right. Sometimes the temperature doesn’t change, and sometimes it sets and hold only one of the thermostat and sometimes it changes it to the target temp but the target temp gets reverted a second later.

I am a newbie to this, this is my first ST hub and first ST device. I will try a different driver later this week and see if that fixes the issue.

Hi storageanarchy, I added the getThermostatOperatingState() to get the basic
thermostat state (cooling,heating, fan only).

However, to get the full equipment status, you’d need to call getEquipmentStatus() which give the full list of equipment running including HVAC, fan, humidifier/dehumidifier, HRV/ERV and aux heat.

For the moment, I prefer to display the full equipment status in the UI (as my dehumidifier/HRV are connected to my ecobee thermostat).

With dynamic tiles later, this may be customizable.

Regards.

Understood…but for me, it’s more important to get the status reports into SmartThings attributes/events so that they can be used in automation.

The Ecobee apps (web & iPhone) provide (almost) all the flexibility I really need to monitor and modify vacations/climates/groups/events so I’m less interested in replicating everything as ST tiles.

Ultimately, and to be mass-market successful, SmartThings has to make standardized automation that works for every thermostat (Nest, Honeywell, Ecobee, etc.), and for this to work, every thermostat’s SmartDevice has to support a common set of basic primitives, no matter how hard (or easy) it is to implement. For me, Nest is far too limited; Ecobee is at the other extreme. I love the flexibility you’ve built, but much of it isn’t necessary for generalized HA.

That said - please don’t stop…you are pushing the envelope of what can be done with ST in multiple dimensions, which will help us all in the long run.

TTFN!

Ok, I agree with you about Nest vs. ecobee (flexibility wise).

But, I think that the Smartthings platform should not be limited to home automation alone (residential market).

The corporate market should also be a target, and what I’ve built with the ecobee device can be used for Small & Medium businesses as well.

Being able to control multiple thermostats through groups and the iterate functions could be a step toward that market.

My 2 cents.

Thanks both of you for the work to build the custom ecobee device! I too want to install one of your guys’ drivers to see if I can set it up how I want.

The general idea is to override the ‘home’ / ‘away’ mode of the thermostat in certain cases based on a motion sensor. Eg. If I come home early, then the thermostat should change to ‘home’ mode earlier for x amount of time, then revert to whatever the schedule is on the ecobee.

I’m trying to install @yvesracine driver – in step 2 it says to create a new device type by visiting https://graph.api.smartthings.com/ide/devices. However, when I visit that I get a “Sorry, you’re not authorized to view this page.” Is there something I need to do to to allow me to create a new device type? I tried clicking ‘Add developer access’ on the profile page. I got a “Developer access granted” message, but the device-type URL still says access denied. Any ideas?

Hello tinypocket,

You’d need to create a developer account and log in prior to do anything in the IDE.

See https://www.smartthings.com/developers for more information. For registration to get IDE access,
go to https://graph.api.smartthings.com/

Regards.

Hello tinypocket,

For your use case with the motion sensor, take a look at the smartapp ‘AwayFromHome’ that I’ve developed under https://github.com/yracine/device-type.myecobee/tree/master/smartapps.

You can customize it according to own requirements. It’s a bit similar to what you want to achieve. You just need to add the ‘BackToHome’ logic and remove unnecessary logic for your use cases.

‘ResumeEcobeeProg’ could help you also for the ‘BackToHome’ logic.

Regards.

Hi Yvesracine,

Firstly, a big thank you for device type and all the work you have done. I have gotten to a place where I am trying to get the thermostats (I have two thermostats) to resume program when people return home. I don’t have any motion sensors at this point. So, I was wondering if I could just make these small changes and if the program will still run properly after that. I added “required:false” to motion sensor and “multiple:true” to thermostats. The changes are shown in the code below.:

preferences {

section("When one of these people arrive at home") {
    input "people", "capability.presenceSensor", multiple: true
}
section("Or there is motion at home on these sensors") {
    input "motions", "capability.motionSensor", title: "Where?",  multiple: true, required: false
}

section("False alarm threshold (defaults to 3 min)") {
    input "falseAlarmThreshold", "decimal", title: "Number of minutes", required: false
}
section("Resume Program at all ecobee thermostat(s)") {
    input "ecobee", "capability.thermostat", title: "Ecobee Thermostat", multiple: true
}
section( "Notifications" ) {
    input "sendPushMessage", "enum", title: "Send a push notification?", metadata:[values:["Yes","No"]], required:false
    input "phone", "phone", title: "Send a Text Message?", required: false
}

}

Regards,

Hello jx99,

I made a change to ecobeeResumeProg to set the motion sensors as required:false. Please copy and paste the latest code at github, and publish it.

The script should work fine for your use case as it can resume the program on all your thermostats
even if you give just one thermostat as input. It uses the iterateResumeProgram function which iterates on all thermostats for a given ecobee’s client account.

Regards.

FWIW, you may wish to consider that you might return home during a time when your thermostat is scheduled to be in an away mode. Or, you might leave in the morning before the “Away” climate kicks in on the Ecobee. In this case, you don’t really want to Resume the program, you want to set a hold event to the temperatures defined in your Home Climate.

In my implementation, I simply monitor the location mode changes, and set the thermostat to the appropraite Climate using the “nextTransition” setting for SetHold events. It’s pretty simple code:

    def changedLocationMode(evt)
{
     log.debug "changedLocationMode: ${evt}, ${settings}"

      if ( evt.value == "Home" ) {
        def endTime=timeToday(morningEnds)
        
        if (now() < endTime.time) {
            log.debug "Awake"
            ecobeeThermostat.awake()
            sendNotificationEvent("And I set ${ecobeeThermostat} to the Awake program.")
        } else {
            log.debug "Home"
            ecobeeThermostat.home()
            sendNotificationEvent("And I set ${ecobeeThermostat} to the Home program.")
        }

      } 
      else if ( evt.value == "Away" ) {
        log.debug "Away"
        ecobeeThermostat.away()
        sendNotificationEvent("And I set ${ecobeeThermostat} to the Away program.")
      }
      else if ( evt.value == "Night" ) {
        log.debug "Night"
        ecobeeThermostat.sleep()
        sendNotificationEvent("And I set ${ecobeeThermostat} to the Sleep program.")
      }

      ecobeeThermostat.poll()
    log.debug "Exit changedLocationMode"
}

Note that this doesn’t necessarily directly map to Yves’ current implementation (I haven’t completed my rework of his latest yet). But you get the idea -

Some caveats:

  • Holds aren’t permanent, so if you are going to be away for more than a day, you need to set a vacation instead. Otherwise, the thermostat will click through its regularly scheduled transitions, independent of your location.mode
  • This approach lets you set the scheduled transitions to be in advance of your expected return/wake up time so that the thermostat can pre-heat/pre-cool. This is pretty sweet - the Smart doesn’t change the hold (or scheduled) temp display, but it does start heating/cooling in advance of my return.
  • In my version of setClimate(), I first run resumeProgram() to clear any running overrides, then check to see if the scheduled climate is the same as the desired one. If so, I avoid the superfluous setHold(), and just let the thermostat carry on as scheduled.

I hope to get Yves’ latest converted for my uses soon…I’ve had problems in the past with the multi-thermostat support (I just run 2 instances of the device and 2 instances of my Green Ecobee SmartApp), but maybe I’ll try again…

Yves,
Thanks for the making the changes.

Storageanarchy,
I agree with your approach of having the thermostat be in control and changing setting the mode.


What I was trying to accomplish was to switch off (or set it at a higher/lower temperature so it doesn’t run) when the last person leaves and switch it back on when the first person returns. ST has a message feature that allows you to set temperature for home or away but i had a problem because I had two thermostat and it wouldn’t allow me to set them to different temperatures – I had to set them to 2 degrees difference so that they would switch on and off at the same time and not have “hot zones/rooms”.

This thread was the most useful in getting me closest to what I was trying to do. I tried the ST device type and couldn’t get it to function properly. I had many communications with ST tech support who was very responsive and after using yves device type, it worked so well, i wrote to ST tech support and told them to use yves device type instead of writing their own for ecobee (apparently they didn’t know yves had written one and told me they were going to check it out. They also suggested that yves submitted the device type for inclusion into their community device type / smartapp).

I now have this running with (a) messages setting the temperature for away and (b) yves ecobeeresumeprog to resume the ecobee program when the first person returns. It would be great at some point to have ecobeeresumeprog detect for a change in mode from away back to home and use that to activate – at the moment i have to manually select the presence to monitor for the app and each time i add or remove a person, a guest in the house, in have to do so in the ecobeeresumeprog and the messages. It will be better if the ST messages controlled the mode Away, Home, etc and have ecobeeresumeprog detect that change in mode and activate the ecobeeresumeprog.

Hello jx99,

I’m testing a new version of the eocbeeResumeProg that will resume the prog if the mode is set to a given target such as ‘home’.

I’ll let you know when it’s ready.

Bye for now.

Hello jx99,

Please grab the latest ecobeeResumeProg code at

https://github.com/yracine/device-type.myecobee/blob/master/smartapps/ecobeeResumeProg.groovy

And, let me know if it works for you!

Bye for now.

This is a very interesting thread but I have a question not related to the devices but the application of these schemes? Is this a quality of life issue that y’all are trying to solve for or an effort to save on utility bills? Here in the Southwest the main utility cost is electricity, due to the air conditioning needs, and moving the temps around as is being talked about here would undoubtedly cause increased utility bills. Now this may not hold true for heating a home with gas or oil as there is no On Peak/Off Peak pricing but the best strategy in cooling is a simple one and accomplished by a programmable thermostat with no need to integrate to HA.

Now all that said I could use this to implement a strategy to turn off the AC and on the whole house fan when a window is open and there is a certain temperature differential but that will have to wait until I need new Tstats as there is not enough gain to warrant the purchase of Smart thermostats.

Hello petersbc,

To answer your question, we do this for comfort and a bit for saving $$. I have the same strategy for heating/air conditioning as I don’t want to heat/cool my house when nobody is at home. It really depends on your lifestyle: whether you have a fixed schedule vs. your family members have different schedules from one week to another. The ‘Away’/‘Home’ strategy can help you save as a thermostat’s program sometimes cannot be as flexible as your schedule.

For cooling, I also use 2 ceiling fans in my upper floor to circulate the air when the temperature or the humidity reaches a certain predefined level.

And, I turn off my thermostat if some of my doors/windows are open after 10 minutes (input parameter)…

Regards.