I was looking at the device Thermostat attributes and then when scrolling down a bit in the documentation, I saw more capabilities for Thermostats but they seem to overlap the attributes from the main Thermostat capability.
So my question is, do I have to declare all capabilities in my device driver (all thermostat related) or does using the first thermostat capability with all it's attributes alone is ok?
Second question, why do all the other capabilities exist if they just overlap the main one? Are they for declaring only the ones supported by the actual device so that they don't show up in current states.
@mike.maxwell
Can you confirm - what is the reason for the "thermostatSetpoint" attribute? Was this just an old attribute that is now replaced by coolingSetpoint / heatingSetpoint?
If not, how is thermostatSetpoint supposed to be used and what's the interaction between coolingSetpoint / heatingSetpoint?
I'm assuming the model is you would want to use either (i) thermostatSetpoint; or (ii) coolingSetpoint / heatingSetpoint, but would not use both (i) and (ii) for the same device. If that isn't the case, it seems it would be some complex programming to set it for a heating / cooling device operating in "auto" mode. There seem to be no "official" developer docs on how these interact - or did I overlook it?
its not an old attribute, in essence it should reflect what is being displayed on your thermostat display.
This is due to HVAC thermostats having separate internal commands for setting the cooling and heating setpoints, but most only have one display value, which is based on the thermostats operating mode.
A driver needs to maintain all three attributes, the value of thermostatSetpoint must reflect the current setpoint value (heating or cooling) depending on the thermostats current operating mode, ie heating or cooling...
A question remains - what are you supposed to do if the Thermostat is in auto-changeover mode, and the room temperature is currently in the dead zone between heating and cooling? At that point, you don't know if the next event will be heating or cooling. I think what makes sense is to assign it a "null" or "undefined" value - but that doesn't' seem to be explained anywhere.
On this point, I'll raise a related side-topic - the Hubitat Driver Capabilities list. It would be great to see that updated to add a "units" section and an "Implementation Notes" section. A couple of months ago, I posted some edits to the Driver Capabilities List wiki to add these - I don't know if that is still being considered -- the Wiki indicates it still has to go to a moderator for approval - but it would be great to have someplace where this kind of understanding could be posted (so you don't have to repeat it)! In particular, it would be great to have the "Implementation Notes" section link to a (moderated) wiki page for each Capability.
When this happens the HVAC unit is idle, and you simply don't don't do anything, none of the set points have changed, nor has thermostatMode...
null and undefined aren't values defined for thermostatMode or thermostatOperatingState so any apps which may use either of these attributes aren't going to do well if they see a null or undefined value here.
A special case exists when thermostats have and are set to auto mode, you need to manually track the mode so you know how to update the setpoints, we do this via updateDataValue("lastRunningMode",lastRunningMode)
Thermostats are probably the most complex drivers to implement correctly due to all of these operational complexities.
Further to what Mike said, this depends on the thermostat itself. Generally, it will internally be in the last mode that it operated in, heating or cooling, while idle in the deadzone. So the corresponding set point will be reflected in the attribute thermostatSetpoint. The thermostat itself doesn't know what comes next, so no one else does either.
Agreed - they certainly are complex. I was asking just to make sure I've implemented thermostats correctly in my homebridge - hubitat plugin (homebridge-hubitat - npm) -- which I think I have. HomeKit has a similar structure with a heatingSetpoint, coolingSetpoint, and a thermostatSetpoint, but they use them differently. In HomeKit, if you are in "Auto" mode, you use the heatingSetpoint and coolingSetpoint but the thermostatSetpoint has no function. However, if you are in Heating-Only or Cooling-Only mode, you use only the thermostatSetpoint (and heatingSetpoint / CoolingSetpoint have no function) -- instead, you have to look at another variable which tells you the current operating mode. From your description, I think I've mapped all these correctly.
