It is, but I'm working on a couple side projects right now (Netatmo & Automatic Pro) that will integrate into HubConnect. Just want to get the integration code tightened up.
I've updated/recreated HubConnect Videos because v1.7 will significantly alter the method of connecting Hubs. The new method guides you through the steps, not exposing the key before it's fully ready to be used.
The first half of this video shows how to add the Code and enable oAuth, which for anyone who's done it already, won't be a mystery. 
About 1:40 into the video is where the connection method starts for http (oAuth). Remember, for first time installations of HubConnect, we recommend using http (oAuth) because of its simplicity, both in clicks and in connection transport mechanism. The "connected" validation words use http and thus using http (oAuth) uses the same path.
HubConnect Server Hub Install Video
An entirely new Video demonstrates the 'upgrade' from http (oAuth) to HubConnect Server (proxy).
NOTE:
HubConnect v1.7 is not yet released. Following the steps of the video will still only install v1.6 for you.
Hi,
I'm having issue getting buttons from smartthings to show up in the smartthings Hubconnect app. I have the universal device driver installed. Anyone have any ideas on how to troubleshoot this issue? It's the new EcoSmart Zigbee Remote. I also have a post over on the smartthings community forums.
A fix for this will be in the upcoming release of 1.7
In the meantime you can fix it yourself.
@srwhite or @csteele Is there anyway you could add the “bulb” capabilities of dimming up & down to the RGBW driver? I added it myself when I realized I would otherwise have to put all of my RM rules for button controllers back on the “lights” hub. It works, but I‘m worried there will be problems down the road with me including lights into the rgbw category and then switching to the modified driver afterwards.
On a different note, can you update the HubConnect Thermostat driver to work with Google Home? There is another post about how the "lastRunningMode" and "thermostatSetpoint" vars need to be stored within the device state and data stores.
==============================================
"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..."
Just note that if you are using the web/event socket connection method, the lastRunningMode comes over automatically, so no change needed.
If you are using the HTTP/oAuth connection mode, though, yes, you need a driver that adds those values.
I'm using the socket method with the stock thermostat driver (GC-TBZ48). Will lastRunningMode still come over or do I need to use your custom driver? I have three hubs when publishing out to Google. Zwave hub to HubConnect hub to isolated Cloud hub.
It should come over with the in-box driver. I think... Bottom line, if it makes an event for that it will come over. If it doesn't it won't.
I haven't tried thermostats in Google home since writing my driver. And I only did it then to verify it worked (which it does). So I could be remembering wrong.
It's not coming over in the stock driver. No data present in Data table on device page. Thoughts?
Probably need a custom driver then. 
Lol, of course! Are you sharing your thermostat with your custom driver or hubconnect device driver through GH integration?
I only tested my custom thermostat driver with google home directly, not through hubconnect.
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.
