Yeah, that's why I asked about fixing the hubconnect thermostat driver?
I understand. I agree it looks like something they would need to add support for in hubconnect.
I could just make the two parameters a state in my driver and make an event, too. But that would only fix it for that single device type, and only when using my user driver.
It would be more appropriate to fix it "right", which would be in hubconnect itself (if possible) since all in-box thermostat drivers have those two values (thermostatSetpoint, lastRunningMode) that need to be present for google home integration to work.
Can a device driver subscribe to an internal event which would update the setpoint and lastrunningmode needed for GH?
This type of add-on attribute has been discussed before, possibly last week, but certainly in the last month. The HubConnect drivers TRY to remain consistent with the Hubitat documentation:
https://docs.hubitat.com/index.php?title=Driver_Capability_List
"lastR*" (the shortest search... ) yields zero hits.
That is NOT saying there can be no deviation, the point is more, how to deviate. If there's no clear specification, how can we be certain we implement it the same (or same enough) as the built in driver?
I point to the Fan documentation as an example of what I'm talking about... Fan Control is all that Hubitat documents. It says there are enumerated values: Off, On, Low, MediumLow, Medium, MediumHigh, High and Auto. Those 8 values, and nothing else. Yet the Built-In drivers support more: SwitchLevel (a dimmer capability) and a matching setLevel Command. The result is, two HubConnect drivers: Fan Controller & FanSpeed Controller. All this does is confuse YOU the HubConnect user. (Doesn't confuse me, I wrote 'm LOL)
It's also the #1 reason Custom Drivers has been included in every release of HubConnect.. to allow individuals to 'bridge the gap' between what Hubitat does and what Hubitat says (documents).
I will go through some Hubitat released (built in) drivers and see if I can identify a consistent approach to the meaning of "lastRunningMode"
In addition, we also ran into a problem months and months ago with a lock attribute: "lastCodeName" -- it wasn't being output as an Attribute. It took a Hubitat release or two to catch up. (I'm not (yet) saying this is that.. but that it might be. Research will tell.)
Good luck. I only know exactly what it does because Mike finally caved in to my bitching and directly told me. 
My first stop was to compare: Generic Zigbee Thermostat and Generic Zwave Thermostat drivers. (sigh) no consistency EXCEPT in there being no such thing as "lastRunningMode"
"data value" NOT an attribute... so I must unfortunately say it's not embedded in EventSocket, much like "lastCodeName" for locks BUT I also think the usage is different and its less likely Hubitat will "fix it".
Yes, because those were never updated to include Google Home support - which is the only thing you need lastRunningMode for*. You don't need it for any in-box function, so I guess it never made the documentation.
There is no "guide for making google home Hubitat integration compliant drivers"... It's trial and error. If the integration rejects the device, we have to ask/beg Hubitat to tell us what parameter it is looking for as there is no documentation.
*EDIT: You may need lastRunningMode for Alexa too - don't know as I don't use Alexa.
Your point about all attributes transfer across is correct but only to the extent they get inserted. This data value isn't inserted into EventSocket as far as I can see... but my research continues.
(If you have a research short cut, so I don't have to spend all day duplicating your knowledge, I'm receptive 
)
There is no link to give - it was just told to me.
lastRunningMode is what Google uses to know how to display the thermostat widget on their display.
It has two valid values - "cool" and "heat". If thermostat is in "auto" you just have to pick either "cool" or "heat". In my driver I pick the mode last actually used when in "auto".
Adding a couple extra attributes to the base thermostat driver is harmless.. If the physical driver never populates them then they're basically invisible to the system. So if that's all that is being asked here it shouldn't cause any issues.
It's only adding or altering the documented behavior of commands that can break compatibility, which is why I take a relatively hard stance on that..
So if we're just talking a couple attribute, the simple test is to add them to the driver and see if that takes care of the integration issue. If you're using websockets you don't even need to alter the driver definition in the app code...
If that's all it takes, then I can get that added to 1.7..
lastRunningMode is needed, and thermostatSetpoint. thermostatSetpoint makes an event when updated, though, so that one would come across "for free" when using socket connections (although not with http/oAuth, obviously).
lastRunningMode does not typically create an event. In my driver I didn't make it a state (so no visual variable to see on the driver detail page), and just do updateDataValue like:
updateDataValue("lastRunningMode", "cool")
Pretty sure my driver mirrors how the in-box thermostat drivers do it - although I can't see the source code, so that is a guess based on external observation.
@srwhite, @JasonJoel isn't talking about attributes. There's a "calculated" data value that GH wants. This is a portion of @JasonJoel code:
// Update thermostatSetpoint based on mode and operatingstate
def tos = getDataValue("thermostatOperatingState")
def tm = getDataValue("thermostatMode")
def lrm = getDataValue("lastRunningMode")
def csp = getDataValue("coolingSetpoint")
def hsp = getDataValue("heatingSetpoint")
if (lrm == null) {
if (tm == "cool") {
updateDataValue("lastRunningMode", "cool")
lrm = "cool"
} else {
if (tm == "heat") {
updateDataValue("lastRunningMode", "heat")
lrm = "heat"
} else {
if (tm == "auto") {
updateDataValue("lastRunningMode", "heat")
lrm = "heat"
}
}
}
}
to show what he, @jpoeppelman1 and @mike.maxwell are referencing.
1 Like
Now I am confused.. Data Values are supposedly private to a device.. How is GH able to see them?
Don't know. But I know for a fact the Hubitat Google Home integration does not work without those lines in the driver, and does work with them in... I put those values in because Mike said they needed to be there for Google Home integration to work.
I didn't expose the whole code for @JasonJoel
The "trick" is to keep thermostatSetpoint accurate. The Data value allows it to be calculated.
I was trying to be quick to head off the confusion and didn't grab every line of relevant code.
Setting data values is harmless in a stub driver, as are adding attributes.. As long as no new commands are being created or re-defined, then it is something that can be considered to inclusion.
I'll copy Mike's statement here, although it was copied above too:
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 lastRunningModesetting 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...
In other words, Google demands "thermostatSetpoint" and Hubitat's drivers implement that via "lastRunningMode"
You know... I never thought about that part. That explains why it isn't a state.... lol
Will the hubconnect generic thermostat driver be updated to include the needed variables to run with GH? Was that a yes? 
It might be another one of those 'slippery slopes' we always hear about.
HubConnect is a 'mirror' of Attributes. "random Data values" are not exposed, thus not considered.
I do not see how a data value buried inside a device driver can make it's way over to another hub using EventSocket. The only potential solution is to 'recalculate' the attribute "thermostatSetpoint" via some implementation... possibly using the 'lastRunningMode" solution.
However, that said, thermostatSetPoint IS an attribute. If the "Real Driver" is tracking 'lastRunningMode' and reflecting that into "thermostatSetpoint' then HubConnect will be 'mirroring' the attribute and have no need to duplicate.
