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

Devices & Integrations Community Created Device Types
, , , ,
446

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.

3 Likes