Before I begin, please note that there are known “issues” arising with the ecobee plug-in due (primarily, but not entirely) to the responses the app receives from the ecobee API. I’ll be detailing how I work around some of these surprises using the awesome Reactor plug-in.
Some of these anomalies include:
- Authentication key PIN needing renewal after arbitrary periods (usually weeks);
- ‘Mode’ being wrongly reported as (null) during any type of manual override;
- App throwing several error types during otherwise normal phases;
- Mismatch between list of possible ‘Modes’ vs. “House Modes” (e.g. “Sleep” is “Night”);
- Existence of ‘Smart1’ mode in place of (or in addition to) ‘Vacation’;
- Representing ‘Modes’ internally as text (e.g. ‘away’) instead of integers (e.g. 2);
- Behavior of that 4th ‘Mode’ relying on how your ecobee ‘Comfort Activities’ are defined;
But if I had to boil down ecobee plug-in’s behavior to the most noticeable vexation, it is that if Vera changes anything (Temperature, FanOn, etc.) during one of the “Comfort Activities” you’ve declared on the Thermostat (or in your ecobee.com account), then instead of ‘Home’, ‘Away’, or ‘Sleep’, the app will consider your ‘Mode’ to be (null). This can be a challenge to deal with from the standpoint of, say, Reactor – since incorrectly testing for a (null) value (represented in the Reactor plug-in as the null string “”) may return TRUE when you expect FALSE (e.g. the comparison “{list/array} [CONTAINS] {hMode}” where hMode=“” => TRUE!).
In practice, this only becomes a problem if you indeed base any Reactor routines on what ‘Mode’ your thermostat is in; for instance, having Reactor force Vera’s House Mode to match whatever your ecobee device changes to, as I do. For most users, that’s an unlikely use case.
But if you do, and you’d like to know how I work around the (null) ‘Mode’ anomaly, I begin by declaring several Expression variables in Reactor:
One or more of the variables act as safeguards and/or triggers in a Reactor condition subgroup called ‘Run A/C Fan’ – reacting to turning ON a virtual switch (this device, known to my Alexa as “House Fan”, self-resets in 30 seconds):
So saying, “Turn on house fan” (or otherwise turning on the virtual switch manually or with a Scene) provides 30 seconds of air movement,
but only if there has been a match between ‘House Mode’ and thermostat’s ‘Mode’ for a number of seconds, to avoid potential conflicts of operation.
Only then does the corresponding .TRUE activity group execute:
Notice my use of the (expressionless) variable ‘acModeOrig’ to temporarily store (and later restore) the prevailing thermostat ‘Mode’, just as ‘Auto’ negates the ‘Continuous On’ request. I also include a superfluous ‘Delay’ which makes sure the virtual switch is returned to OFF, as I really don’t like the fan running this way for longer than 30 seconds at a time (this activity gets used in other Reactor routines as well, you see).
Hopefully this write-up leaves you with more questions answered than new questions!!
