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

Is that post in the weather api about line 928 for me? Lol thanks berry

Sorry about that - its not always clear which thread I’m responding to. Yes, please try the line 918 fix, and let me know if it solves your problem. If so, I’ll update the released version.

OK, so I figured that -20 was low enough (the limit is -5 for Fahrenheit users).

If you edit the ecobee Suite Smart Mode SmartApp in the IDE and change line #928 from:

low = -20.0


low = -25.0

Save, Publish and try setting it again…

You mean line 918 not 928 I assume?
I edited 918 and it saved fine

Yes, 918. Sorry for the typo.

Ecobee Suite updated on 7 Apr 2019 at 7:15am EDT

Updates include:

  • Ecobee Suite Thermostat v1.6.24
    • equipmentOperatingState now reports “Humidifying/Dehumidfying” instead of “Humidifier/Dehumidifier” (same context as “Heating” and “Cooling”)
    • Adds support for new attribute schedule and the command setSchedule(JSON_OBJECT) as defined by recent additions to the Thermostat Capability
      • Allows full schedule (program) control from Hubitat users who are using HubConnect to link SmartThings and SmartThings-based Ecobee Suite Thermostat(s) to Hubitat.

Note that setSchedule() is a front-end for the existing setThermostatProgram() and resumeProgram() command entry points, as documented above.

Follows is documentation on the implementation within Ecobee Suite:

Using the new setSchedule(JSON_OBJECT)

The choice by SmartThings to define the argument to setSchedule() has allowed me to implement an incredibly flexible way to utilize this command to change the currently running program on your Ecobee thermostat(s). The single argument passed can be a String (e.g., "Home"), or a List (e.g., ["Away", "nextTransition']) or a Map (e.g., [name: "Sleep", holdType: "holdHours", holdHours: 6]).

  • Only the first argument (name) is required, and it must be one of the supported Program/Climate names for the target thermostat - or - the word “Resume”. By default, the supported names are (Home, Away, Sleep, Resume), but the list will automatically include any other Programs/Schedules/Climates that you have defined on the thermostat(s)
  • The second argument (holdType) is optional, and must be one of “nextTransition” (temporary hold), “indefinite” (a permanent hold), or “holdHours” (hold for a specified number of hours, obviously).
  • With the holdType being "holdHours" the third argument (holdHours) is the number of hours you want the hold to last.

These arguments can be passed programmatically as their respective data types (String, List, or Map). But to make this implementation even more powerful, it allows you to pass a String that looks like JSON, but isn’t necessarily pure JSON. In this manner, virtually ANY programming interface/language can be used to change the currently running program/schedule. For example:

String Argument Translates to
“Home” [name: “Home”]
“[Home]” [name: “Home”]
“Home,nextTransition” [name: “Home”, holdType: “nextTransition”]
“name:Home,holdType:holdHours,holdHours:6” [name: “Home”, holdType: “holdHours”, holdHours: 6]
“name,Home,holdType,holdHours,holdHours,6” [name: “Home”, holdType: “holdHours”, holdHours: 6]

As the second example implies, the argument String can be wrapped in one or more pairs of brackets ("[…]") or even braces ("{…}").

This design provides ultimate flexibility for programmers and end users alike, and allows Hubitat+HubConnect users of the reflected Ecobee Suite Thermostat device to pass simple strings without sacrificing functionality.

About the new schedule Attribute

Since HubConnect doesn’t reflect ALL of the attributes provided by the Ecobee Suite Thermostat device, I have chosen to somewhat overload the meaning of the schedule attribute. Under normal operation, it will merely report the current Program Name (Home, Away, Sleep…). But during a Hold event (or an Auto Home/Away event), the content will expand to be more descriptive, as in Hold Home until 6:30pm or Hold Away forever. SmartThings users get this additional information from the currentProgramName and statusMsg attributes which are displayed in the SmartThings Classic UI.


Can generic (dimmer) vent(s) be used in the Smart room helper? There doesn’t seem to be an option for that like the “Smart Vents Helper”

Hey, @Automatic00-

I just posted Smart Room v1.6.12 which now supports “generic” vents (dimmers).


I have been trying to install this and I have run into a snag. After I go though the API Authorization I can not save. Not being able to save means I can not select a thermostat to control

If you have multiple SmartThings locations, be sure that you are logged in to the one you are trying to add this to.

Also, check to see that the temporary test devices have been deleted - it creates these to make sure you have everything installed correctly. If not, they won’t be deleted and you won’t be able to save.

Also check to be sure that you have installed all of the Helper apps and both drivers - otherwise it won’t work.

If all else fails delete everything from the IDE and start over again.


Removing the test devices worked. I guess it was late and I was tired and overlooked that. Thanks!

No worries - no matter how hard I try to ensure that this doesn’t happen, it seems that the test devices cause problems for at least 1-in-5 new users…

Thanks so much for making this! It was working fantastic until 3 days ago, I simply had 2 helper apps for when ‘I’m away’ and ‘I’m home’ to set the thermostat to away (hold) and resume sched. appropriately.

For some reason even though my ST automation routines triggered, along with the helper apps, nothing changed on my Ecobee 4. I went into the helper apps to change it to trigger from routine to ST mode, but now I can’t seem to view/modify or even delete the helper apps.

Would anyone happen to have any suggestions? I looked at live logging via the IDE and have this as well when I try to enter any helper app.

10:53:06 AM: info Updating API status with [apiConnected:full, lastPoll:Succeeded]
10:53:06 AM: error refreshAuthToken() - HttpResponseException occurred. Exception info: groovyx.net.http.HttpResponseException: Bad Request StatusCode: 400
10:53:06 AM: info Updated 2 objects (46ms)
10:52:59 AM: error java.lang.NullPointerException: Cannot invoke method sort() on null object @line 590 (getEcobeePrograms)
10:52:59 AM: debug getEcobeePrograms: returning null
10:52:59 AM: debug No programs yet, adding to the list
10:52:59 AM: debug Getting list of programs for stat (EcobeeTherm: My ecobee) with DNI (ea6ee399-fd2a-48c9-879a-1a457069e234.511816792637)

And the error screen when I click on a helper app:

It now keeps spamming this every few seconds:
10:55:06 AM: info Updating API status with [apiConnected:full, lastPoll:Succeeded]
10:55:06 AM: error refreshAuthToken() - HttpResponseException occurred. Exception info: groovyx.net.http.HttpResponseException: Bad Request StatusCode: 400

I have a helper app setup to turn off/on based on window sensors. Lately I noticed that it does not turn it back on and says “reservations prevent running on command”

Having some trouble with random disconnects. It will just stop talking to the ecobee api. No errors or anything. Sometimes resetting up my ecobee credentials fixes it. Sometimes I have to do this more than once to get it going again. Very annoying. I had a different handler before that would at least tell me when it disconnected.

The ecobee cloud service has been quite unreliable over the past many months. Many have been the times that the ecobee mobile app cannot connect.


Can this control other settings like screen brightness and timeouts?

Edit: Looks like Follow Me is listed as read/write (see https://www.ecobee.com/home/developer/api/documentation/v1/objects/Settings.shtml) but I don’t see the brightness (unless I missed it).

Nope - I haven’t implemented screen brightness or timeout control.

You do NOT have to re-login or re-authenticate when the link/server goes down. Just have patience…it will automatically reconnect when the Ecobee servers come back online.

You can check the bottom of the display and it will tell you the status of the link.

I stopped the nagging notifications back when the Contact Book was deprecated.

I also donb’t mark the link as fully Down unless I get an unrecoverable error (authentication failure). Server timeouts are normal - I just keep trying. Maybe I could add a “nuisance notice” if the recovereable errors persist for (a configurable) number of minutes, but it would have to be an SMS message…I refuse to do a ST notification because it hammers every user in the location.

Some other automation/helper has taken out a reservation that prohibits anyone else from making a change.

I probably should implement a “clear all reservations” function/button…

If you look in the IDE, My Locations > SmartApps (for your location) > then click on “Ecobee Suite Manager” (or whatever you named it), you will get a popup of the full status for the controller app…scroll down to the State section, then to reservations and you’ll see some JSON with your thermostat ID, and an APPID for each reservation that is being held. If you can figure out which Helper SmartApp is the culprit, usually opening and re-saving that app will cause it to clean up its reservations.