Oh! I would have to look - pretty sure I still have it. I don't use it any more, as I didn't need it after switching from http to websocket method in HubConnect.
I just use the HubConnect thermostat driver now as I only needed the custom parameters to go one direction (and didn't need the command to set it), which happens automatically when using the websocket connection.
Does anyone know if this error message is important:
Question: How do I find out which device this is?
@srwhite - any clarification on my question about renaming devices? Was it okay to change one of the Device Name or Device Label? Did one of those affect the ability of HubConnect to keep working with the devices?
From my experience, you can rename the devices without issue. The DNI is what you need to be careful with, since that is the device identifier.
newbie to this scene. If smarthings hub connected as a client does it still can act as an independent hub or everything have to go through the server hub? Also can I use smartthings as the sever? Thank you
No, only a Hubitat hub can be the server.
The functionality of the ST hub is unchanged by the addition of HubConnect Remote Client. It’s the act of ‘mirroring’ devices that impact. ST devices, mirrored to Hubitat gain from that. Devices mirrored from Hubitat to ST augment it’s functionality.
Event filter version ready yet?
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.
Download the Hubitat app
