Doesn't really matter for those of us not beta testing. Until it is released to the masses, I can't get overly excited. 
I was thinking, at the time, "it won't come out of Beta til it goes in.. so.. SOON, please" But only typed one of those words. Because i just know you're listening in to what I'm thinking, right? 
Heya Jason, do ya have that custom driver on ya by chance? Node-Red doesn't seem to be getting the correct temps from HubConnect, and I'm wondering if it's a driver issue.
It's on my github, but here is the forum post. I couldn't comment on the Node-Red side, as I don't know exactly how you are getting values from Hubitat to there. I sue Node-Red extensively, but the devil is in the details, as they say.
Sorry - I meant for a custom driver on the server side of HubConnect. I have your Enhanced GoControl on a Remote Hub, and on the Server I'm currently using the default HubConnect Thermostat driver. Is that what you're doing?
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..."
