Link to your driver code?, I'll look into it...
Thanks. No huge issue, obviously. But it would be nice to know what about the driver makes the GH app reject it.
1 Like
It appears the the driver isn't maintaining thermostatSetpoint.
https://docs.hubitat.com/index.php?title=Driver_Capability_List#Thermostat
1 Like
That makes sense. Thanks.
As my thermostats are always in AUTO, thermostatSetpoint doesn't mean anything versus the quite meaningful coolingSetpoint and heatingSetpoint. I'm sure that is how I overlooked it.
I'll look at how the generic driver calculates it when mode=auto (I assume it just averages cooling and heating setpoints), and add it in. Should be simple.
I don't maintain schedule[] in the driver either (as it doesn't apply). Guess I should look at that too while I'm at it.
Bummer if there is going to be a significant lift to supporting specific thermostat models. The home hub interface is great, it shows the temp, just won't set it.
Centralite Pearl / Generic Zigbee driver
schedule is not required, don't bother with it.
thermostatSetpoint follows the heating or cooling setpoint, when in auto and the device is idle it's updated based on the last operating mode.
Our drivers and the GH implementation look at and maintain a data variable "lastRunningMode" with "heat" | "cool" to track last operating mode.
You can blame GH's certification process for this, it was a requirement, and one of the reasons cert took as long as it did.
So if you have a thermostat driver, and you want it to work with GH, you need to maintain thermostatSetpoint properly as well as the data variable lastRunningMode
setting lastRuningMode: updateDataValue("lastRunningMode", "heat" | "cool")
reading lastRunningMode: getDataValue("lastRunningMode")
as an FYI, this value is stored in a data variable vs a state variable as data values can be read from apps whereas state variables cannot...
2 Likes
I can look at these, they may not have been updated for GH integration.
1 Like
Got it. Thanks again!
I wouldn't have known about / didn't notice on the in-box drivers the lastRunningMode - so thanks for that!
All easy changes.
1 Like
-
I'm amazed at how quickly this is getting looked at! Awesome!
-
I had the problem with the Thermostat dropping out of the GH integration when I first set it up. I got the same error report. I did it together with the light switches I added. I figured it was something that I did wrong. I went back later and clicked the check mark again and it stuck.
Glad you mentioned that. I would have made it a state and wondered why it didn't work. Didn't think about needing to digest it on the app side...
@mike.maxwell OK, I added lastRunningMode (set via updateDataValue) and it updates as expected.
I also added thermostatSetpoint. I did that as a state, though.
When I add the thermostat to Google Home I still get the same unsupported error. Do I need thermostatSetpoint (and any others) to be data values (instead of states) like lastRunningMode?
I'm guessing "yes".
@mike.maxwell Well, that didn't do it either. Made thermostatSetpoint (and all the other variables I am stuffing values into) a data value too, still get the unsupported error when trying to add to Google Home app.
updated code here:
https://github.com/Botched1/Hubitat/blob/master/Drivers/GoControl%20GC-TBZ48/GoControl%20GC-TBZ48.groovy
1 Like
this is not a state attribute, it's an event attribute
Yup, of course it is - just like all the other setpoint events/changes... Good thing I'm not a professional developer, as I would clearly go broke. 
I added an event creator for thermostatSetpoint, and now I can successfully add the thermostat to the Google Home app. Haven't tested it out yet from Google Home, but that is progress.
OK, I tested it out. It mostly works... Found a problem in my driver, though... Google Home will send decimal containing values as setpoints - especially when you touch the slider "arc" to change the value, but also when hitting + or -.
Some thermostats can not take decimals for the setpoint (at least not when in F scaling). Unless it is an issue with my driver (maybe with my precision calc), I don't think the GoControl can, as I see what looks like the value (e.g. 75.2) being sent to the thermostat, but no setpoint report is ever generated (presumably because the thermostat tossed the invalid input).
So I'll have to put some number validation/massaging into my driver....
It is a thermostat limit. I couldn't wreite a decimal as setpoint no matter what I made the precision setting or value format.
So, for rounding, is there a 'hubitat standard' on .floor vs round/rint @mike.maxwell ?
1 Like
just convert to int on the way in, setpoint = yada.toInteger()
Could do that... But that always truncates, right? Do we really want 77.9 to come in as 77? Or should it be 78?
I would think the latter, and do a Math.rint(degrees)
round it then
LOL. OK. I know either works technically.
I was curious if ther was a 'standard'/preference on Hubitat's side. Because in general I like my user code to work like the Hubitat code whenever possible.
For instance, if you are going to just toInteger() it in your in-box GoControl driver, I will too.
That is awesome news!!!
1 Like
I was just curious if there is any update on this?
2.0.9 will have the ct101 driver
2 Likes
Thanks Mike! I love how responsive you guys are with HE is!
1 Like
