thermostatOperatingState missing an enumeration (offline)?

#1

BLOT: I’m not sure if this is a bug in webCoRE or a bug in Universal Ecobee Suite.

I have this piston below to let me know if I have any doors or windows open when the HVAC kicks on.

image
image.png1178×681 40.4 KB

I’m using @storageanarchy’s Universal Ecobee Suite on SmartThings (and on Hubitat, but this piston is still on ST). Right now both of my ecobee3s are turned off as the temperature outside is perfect. So I don’t expect this piston to fire.

However, today it did fire, telling me there were windows open while the tstat was “offline”. I thought I’d just select that as an additional value in the “is not any of”, but I “offline” isn’t an option:

image
image.png779×622 21.4 KB

Unfortunately, I started looking into things and lost the logs showing “offline”, but it really was there. I got it three times this evening. But I’ve not been able to reproduce the value again.

The source of the options in that drop down is from this enumeration at line 2540 of webcore.groovy:

thermostatOperatingState : [ n: "operating state", t: "enum", o: ["cooling", "fan only", "heating", "idle", "pending cool", "pending heat", "vent economizer"], ],

The code in Barry’s ES certainly understands “offline” (from ecobee-suite-thermostat.groovy):

        standardTile("operatingState", "device.thermostatOperatingState", width: 2, height: 2, decoration: "flat") {
                state "idle",                                           icon: "https://raw.githubusercontent.com/SANdood/Ecobee/master/icons/operatingstate_idle.png"
                state "fan only",                                       icon: "https://raw.githubusercontent.com/SANdood/Ecobee/master/icons/operatingstate_fan_on_solid.png"
                state "heating",                                        icon: "https://raw.githubusercontent.com/SANdood/Ecobee/master/icons/operatingstate_heat.png"
                state "cooling",                                        icon: "https://raw.githubusercontent.com/SANdood/Ecobee/master/icons/operatingstate_cool.png"
                state "offline",                                        icon: "https://raw.githubusercontent.com/SANdood/Ecobee/master/icons/black_dot_only.png"
                state "default",                                        icon: "https://raw.githubusercontent.com/SANdood/Ecobee/master/icons/blank.png", label: '${currentValue}', defaultState: true
        }

But at line 1204 in his code is this comment:
// now update thermostatOperatingState - is limited by API to idle, fan only, heating, cooling, pending heat, pending cool, ventilator only

That implies “offline” shouldn’t be a possible value and that webCoRE is correct. But the value “offline” definitely was visible today, so maybe webCoRE should allow it as a selection. I’m not sure if this is a bug in webCoRE or a bug in Universal Ecobee Suite, or both.

To fix this, I considered adding “offline” to enum at line 2540 of webcore.groovy.

Instead I just flipped the logic in the piston:
image

#2

Offline is not a valid value for that field (which is a predefined capability). So the writer of this driver took liberties to create a new state that capabilities says you should not do…

#3

Yes, it’s not a valid value according to this doc and thus this would be a bug in ES.
https://docs.smartthings.com/en/latest/capabilities-reference.html#thermostat-operating-state

I didn’t realize that values outside the defined enumeration could even be stored there.

#4

You have made an incorrect assumption that if the operating state isn’t “idle” or “fan only”, then your HVAC is operating - this is not necessarily true. If you want to write code that does something if a certain state exists (e.g., “cooling” or “heating”), then you should check for the presence of those values - in this way you future-proof your code in the event the definition is expanded.

FWIW, there is nothing that states that an attribute can contain more values than are currently defined - additional attributes and attribute values can be added at ANY time. And in fact, the current definition includes operating_state values that are not supported by most thermostats (pending_heat and pending_cool).

I will not be changing my Ecobee Suite, so if you want to use your code as it is, then please install some other Ecobee integration…

#5

That is exactly how I’ve worked around this (as you’ll see at the end of my initial post).

I am curious when Ecobee Suite returns “offline” in this value – because it was only a 2-3 times over a series of days. Most of the time it was returning “idle” when my Ecobee was turned off.