Update: This post was modified/clarified based on info. provided by @aaiyar , below
I suggest a new defined deadband attribute for the Thermostat capability (suggested attribute name "minHeatCoolDelta"). This defines the minimum difference between the heat and cool values in "Auto" mode.
This is a fairly "standard" feature of a thermostat that supports the "auto" mode and automatically switches between heating and cooling. Many "commercial" thermostats support a deadband and it would make sense for the driver to know its value so it can better operate with the underlying physical device. The "units" for deadband should be the same ("°F" or "°C") as for the temperature and setpoints. If the underlying physical device doesn't support or report "deadband" then its value should be 'null' or it should be settable via the Hubitat web interface (I realize that part is driver-implemented).
The operation it regulates is pretty simple
minHeatCoolDelta must be a positive non-zero number.
coolingSetpoint and heatingSetpoint must be separated by at least "minHeatCoolDelta" degrees.
If coolingSetpoint is adjusted (lowered) and new coolingSetpoint is less than (heatingSetpoint + minHeatCoolDelta) then the heatingSetpoint must be lowered to maintain minHeatCoolDelta.
if heatingSetpoint is adjusted (raised) and the new heatingSetpoint is greater than (coolingSetpoint - minHeatCoolDelta) then coolingSetpoint must be raised to maintain minHeatCoolDelta.
As a further suggestion, I'd also add range attributes "minCoolTemp", "maxCoolTemp", "minHeatTemp", "maxHeatTemp" which establish the heating and cooling ranges -- Thermostats typically enforce some type of range and it would be helpful to have this info in the corresponding Hubitat device.
Hmmm...nice idea but looking at the Ecobee API attributes I don't see "deadband' at all. I did a test to put into auto and made a call to the api and nothing indicates the range where the HVAC will remain idle. Or maybe I am missing something. Here in the Midwest most don't use "auto" and the HVAC installers recommend not to use it to prevent AC damage in winter or furnace runs in the middle of the summer when you have your windows opened.
It is in Honeywell and others. I realize that it may not be in "all" which is why I suggested a "null" value be used in systems where the physical device doesn't report it or it be user-specified if the underlying device doesn't support it.
I think Ecobee may just not being exposing it but I agree it's got to be there somewhere I did find compressor protection:
- compressorProtectionMinTemp : 35.0
- compressorProtectionMinTime : 300
Most thermostats will simply honor the new requested setpoint and simply adjust the other setpoint to maintain the proper separation between the two setpoints. No need for Hubitat to reject the new setpoint. Let the thermostat handle it automatically.
Now, if you're referring to Hubitat's Virtual Thermostat, I would agree that it should implement the same logic when set to AUTO as most thermostats, including the ability to define a heatCoolMinDelta between the two setpoints. I have never used the Virtual Thermostat...so I don't know whether or not it does this already.
AFAIK, ecobee refers to what Honeywell calls "deadband" as the "Heat/Cool Min Delta", and this is definitely exposed in the ecobee API
I just tested my Ecobee by changing the heating setpoint on the actual device. It accepted the requested change and adjusted the cooling setpoint to maintain the Heat/Cool Min Delta. This is exactly how I recall my Nest thermostats also working.
You're correct, I checked and that is also how my Honeywell thermostats work. I'll correct the original post
I actually like the "heatCoolMinDelta" phrasing better - it seems to more accurately convey what this is. I've changed the original Post to indicate this.
Thanks found it and the value is being returned in the API call:
That appears to be the default value on my Honeywell T6 thermostat as well.