I would be interested to know as well... Hubitat's documentation on it is strange:
It also appears as part of "capability Thermostat" but I haven't found a definition. It could be that specific thermostats report it.. reporting what value is actually set, since heating and cooling setpoints are dependent on mode. If the thermostat is in cooling mode, then the cooling setpoint would be the one in use, and "thermostatSetpoint" might reflect that. However, for thermostats that do not have automatic cooling/heating switchover, "thermostatSetpoint" simply doesn't exist.
I have found that Thermostat Controller uses "thermostatSetpoint" without there being a command in the spec. (There's an implication of "Read-Only" in the documentation for "thermostatSetpoint" since it's defined as being an attribute only. No command to set it. ) It was a problem for me to use my home's Thermostat with the built-in Thermostat Controller.
NONE of the above explains how your thermostatSetpoint is neither the heating or cooling setpoint. Must mean my guesswork is incorrect.
My understanding, so take it FWIW - Normally you have a coolingSetpoint, and a heatingSetpoint, with the thermostat setPoint being equal to the one which corresponds to the operating mode of the thermostat.
Going into the Lutron Integrator child instance and clicking done appears to have synced Hubitat and Lutron but I then set the Cooling Point via Hubitat Device page:
My Honeywell WiFi Thermostat does not have an Auto switchover between cooling and heating. When I query it for status, here's all the responses that contain "setP*"
As a result, nothing causes "thermostatSetpoint" to be set in my driver.
Until last week: * csteele: v2.0.11 populate thermostatSetoint attribute with most recent heat or cool setpoint
I've made a couple of edits to be more included in Thermostat Controller... which seems to use it. Prior to my patches, "thermostatSetpoint" never appeared in Current States column. When I added it to Thermostat Controller, I noticed it appeared. when I looked into my driver to see how it was being set, nothing. Those letters didn't even appear and that driver's been around a while.
Makes me wonder (aloud) if this Lutron device is being used in concert with Thermostat Controller (or Thermostat Scheduler??) because otherwise, it's just an informational piece of data coming out of certain brilliant thermostats.
thermostatSetpoint is an artifact, not what controls the thermostat. The thermostat is controlled by thermostat mode and heating or cooling setpoints. thermostatSetpoint is set based on responses from the thermostat itself. You can see these in the Lutron Telnet device logs.
from Hubitat HVAC device page while mode = off appears to have resolved the issue.
Note: Using the same Set Cooling Setpoint button OR the the Lutron app while mode equaled auto only changed the coolingSetpoint temporarily before it automagically reverted to 74 degrees.
There is a circumstance where the driver will set the cooling setpoint to heating setpoint plus three. This would be in response to setting the heating setpoint, as there is a required separation of 3° for these thermostats. So perhaps this is happening if Thermostat Scheduler is setting the heating setpoint for some reason.
State variables are internal to the driver, and don't necessarily mean the same thing as the Current State (they are not the attribute, nor is the attribute value determined by this). And, State variables are not updated dynamically, whereas Current State is on the device page. The internal state variable "thermostatMode" is set from responses from the thermostat. For most drivers, you should ignore the State variables, as you don't really have any idea what they are for or mean.
Perhaps what happened is that TS thought the thermostat was in heat mode, and sent only a heating setpoint. The driver would respond to that by setting the cooling setpoint to +3° from the heating setpoint (which would be irrelevant if the thermostat was in heat mode). TS sends heating first, then cooling, when both are sent.
