It didn't appear to work, though harder to tell now that it always says connected
What I did:
I hit disconnect, it said disconnected. Then went out of the client app.
I went into the server app, toggled it from websocket to OATH and then back - that's the only way I've found to get the "change IP" button to appear.
Note: As far as I can tell, my connection code isn't changing. There is a static one for OATH and one for Websocket. Your comments make me think I should be generating a new code somehow.
I then put the websocket code into the client app. It said connected (falsly). But none of the device's IP's changed. Also, I am still missing the connection device on the client hub - remember I deleted it before speaking with you.
I was originally hoping to transition completely from SmartThings to Hubitat however I quickly found that Hubitat's presence sensing via the app and geofencing is, to be kind, somewhat lacking.
Even using the excellent "Combined Presence" App to aggregate the mobile device geofence with the mobile device's wifi connection left me with plenty of sporadic false departures throughout the day. By contrast, one of SmartThings' strengths (for me anyway) is in using the mobile app as a presence sensor. It's rock solid for me and my wife.
Likewise attempting to use the community Wemo devices for native Hubitat support is just an exercise in frustration. At any given time I might have some, all or none of my Wemo devices talking to Hubitat while the Wemo app can see and use them all just fine. So I set them up again in SmartThings and now I have 100% of my Wemo devices responsive all the time through HubConnect.
HubConnect allows me to keep best of breed - I get the tremendous power and local responsiveness of Hubitat Elevation combined with some of the more robust and mature features from SmartThings.
Hey @csteele - How are you handling multi-floor Hue Bridge connections? I have a number of Zigbee bulbs connected to my Hue Bridge, some on both floors. When/If (probably when) I begin to split into one hub per floor, it might not be quite as cut and dry, unless the Hue Bridge is capable of connecting to multiple hubs?
That is another possible use for a hub though - a bulb hub. Just another way of splitting things up. It could work, or I then again I could be looking at a 4-hub scenario soon.
Yes, you can install the Hue Bridge integration app on as many Hubitat hubs as you want. I wouldn't recommend doing it with polling enabled on a ton of hubs since that's likely to create more traffic and be more taxing on the Hue Bridge than it needs to be, but there is nothing stopping you from authorizing as many third-party apps (that's all Hubitat's integration is--there are lots of them for Hue on various platforms) as the Bridge can handle, which I'm sure has a theoretical limit in its database somewhere but nothing here from a practical perspective.
Or if you were asking about multiple Hue Bridges: Hubitat's stock Hue Bridge integration can (as of an update made a while back) handle multiple Hue Bridges--or, to be clear, you install an additional Hue Bridge integration app for each Bridge and choose the one you want as you finish installing the app. (And not to plug myself, but my CoCoHue app can also handle multiple Bridges--one child app per Bridge.)
Both ways work. I've also experimented with a Hubitat hub dedicated entirely to smart bulbs as an alternative to a Hue Bridge, but I eventually moved back to Hue. Even with only bulbs all on their own network, some Zigbee commands seem to get lost sometimes in my experience (from a user perspective, not something I saw via sniffing)--e.g., an on() would get there, but a setLevel might have to be sent twice for it to actually work. The fact that my Cree bulbs still managed to fall off on this Hubitat despite never having problems on Hue also played a part in this decision.
Yeah I remember reading this about using an HE as a bulb hub. I will likely keep my Hue Bridge (only have one) and it's good to know I can install it on more than one hub. It's a decent piece of gear - never had a single hiccup.
You won’t like the Hue lights on hubitat. The Hue bridge does an amazing job that can’t be replicated on hubitat. It has around a 50 device limit though. I have 22 Hue lights on Hue and around 60 Sylvania bulbs and 8 repeaters, pkus 20 zwave switches/dimmers and smoke detectors on one hubitat and about 60 or so zigbee end devices plus 8 repeaters on another hubitat. I divided up the rules so rules involving zwave devices are on the zwave hub, rules with Hue lights are on the hub with Hue integration, and the rest I just split. I’m pretty sure you could integrate one Hue with 2 Hubitats, but it would be another device polling the Hue bridge.
I obviously could be wrong - but I believe the code you sent me to unhide the disconnect switch shows "connected" no matter if it has or not. Because it says connected and it isn't.
If helpful - the whole purpose of this was to setup a new hub. The new client Hub easily connected to the Server Hub. The old Client Hub still doesn't want to connect.
I'm more than happy to keep playing, if it helps you debug anything. But if not, it's not a huge deal for me to start from scratch on that one hub.
I also am trying upgrade from 1.5 to 1.6. I don't show a URL when I try to do the import on the remote client. If I remember correctly I cut and pasted everything in and saved it initially. Can I just do the same thing to upgrade?
At the URL above, there's also a link to a page full of the Import URLs. Copy a row from that page, paste it into the Import field, Click Import, Click Save.
Thanks - looks like everything installed correctly but I have a question. In the update documentation for updating the HubConnect Remote Hub, it shows adding a new driver. Is that correct? I now have 2 drivers installed. Looks evident when I run the system version report.
You all know how I like teasers... I thought I would provide one for another experimental feature coming to HubConnect soon...
If you ever have wanted to be able to see where the devices on your server hub come in from and which hubs they are shared out to, this report is definately for you!
A red box indicates the device is inbound (shared from the remote hub).
A green box indicates the device is outbound (mirrored to the remote hub).
No color (grey) indicates the device is not used by HubConnect.
LOL
I've also experimented with a Hubitat hub dedicated entirely to smart bulbs as an alternative to a Hue Bridge, but I eventually moved back to Hue. Even with only bulbs all on their own network, some Zigbee commands seem to get lost sometimes in my experience (from a user perspective, not something I saw via sniffing)--e.g., an 
