Personally, I still prefer THIS:
http://hubconnect.hubitatcommunity.com/import.php
Copy each row into the appropriate Import field and bingo.. 
Feel free to ask Steve, but until I started using that.. I was KING of getting the imports wrong.
That is exactly what I used..
Server is 1.6.3 and Server Instance is 1.6.4, etc.
Okay, so I have the right version, I am going to wipe the new hub and put the client software on it and the server on the hub with the devices and see if that works. I sure wanted it the other way though.
It should not matter.. really 
I typed this elsewhere but HubConnect Apps build a "highway" between Hubs. It follows a Client Server model. BUT the traffic ON the highway does not. That traffic is bidirectional.
So once you have installed the Hub Driver on each hub, added the Remote Client App on one and the Server & Server Instance apps on the other, and enabled oAuth on all -- you can build the highway.
Start with http(oAuth) because it's the simplest. Then switch to Event Socket if you desire. You'll have to re-build the highway.. but the traffic using it won't need any change. (Re-build the highway == create and paste the new Key.)
1 Like
I have the Server on the hub with all of my lights and the remote on the hub with all of my rules and end devices and all has been well.
It truly doesn't matter to HubConnect.
Where it matters, in my opinion, is when there are 3 or more hubs. With the Server being the center, each Remote hub can only mirror to Server, that hub tends to get 'everything'. That hub is a good place to 'branch out' with connections to Homebridge, Dashboard, Alexa, etc. Those apps that also seem to be the recipient of 'everything'.
That's a lot of busy potential on a hub that is also trying to keep your ZDevices at max speed.
1 Like
Well that is where I was trying to get to. I bought a new Hubitat hub to get to that and wanted to include another hubitat hub and a SmartThings hub but I wiped and installed 3 times trying to make the new empty hub the server without success. I just wiped it again and set it up as the client and pushed 164 devices to it and it is working now and updating device state properly. Now I have the problem of getting my SmartThings hub in the mix.
I've been using this awesome product for a few months now, but noticed within the last few weeks no updating between hubs... I have to routinely hit the sync button and its becoming more of a problem... That was between two hubitat hubs.... I can't remember when the latest update to the most current stable build came out, but it might have been around then when I started having the problems... Maybe I didn't update something correctly?
Anyway, I've been bearing it and patiently waiting for the release of version 2 hoping that would fix the issue... I also just added a smartthings hub last weekend to the mix... I have a lot of devices in places that I don't want to disappear and have to re-configure...
One thought though, and maybe its the root of the issue, I installed the automatic rebooter app around the same time as I did a bunch of code updates.... Trying to stop the increasing slowness issues with my hub, I have it automatically reboot in the early morning daily... I do see errors around that time in the log as both hubs reboot a minute apart... But then the errors go away...
However, the automatic flow of information is not happening unless I hit sync...
edit: If I disconnect the hubs, like what was suggested above, will I lose the existing devices I have shared? I haven't tried that as I have them all neatly setup on dashboards and also using HousePanel...
1 Like
Believe it or not your post is encouraging to me. It means that others are seeing this issue. I think I am going to wait until Steve @srwhite has had a chance to look at this before I continue. I would much prefer to have the hub I bought to be a server to be the server. Thanks for chiming in.
1 Like
Yeah, i'm seeing it too (not updating between hubs). I run 2 hubs. Thought it was just me.
2 Likes
No, you will not lose any existing shared devices, but it will not fix the issue either.
They became uncontrollable for me. Luckily, the only thing on the hub was HubConnect and wiping it wasn't a bit deal. I promise you this though, Steve will get to the bottom of this. I would wait to hear from him.
You're right, of course, the 2530 posts are a roller coaster of emotion, certainly a better love story than Twilight. 
Thanks for your help - sorting through things again, the problem was indeed adding the necessary drivers in the hubitat server BEFORE hitting save in the smartthings app. Works like a charm now.
1 Like
That's for sure.!!
Ok, If installed and uninstalled this three different times, and can get it to work. My goal is to have zigbee bulbs on my original SmartThings v2 hub, and have buttons and switches, etc on HE control them. My ST and HE hubs are on the same GIG ethernet switch, and my bulbs say local via the ST api page.
So.... Why does it average about 1500ms (1 1/2 seconds) to turn on or off a device when I do simple lighting rules to do very simple things?
Further, if I eliminate ST with another HE hub, would I see the same results? My whole reason for switching over to this platform was local processing. It is blood boiling when I press a switch and 4-5 seconds later one of the two lights turn on. ST alone was soooooooo much better than this!!!!! Please give me hope....
My lights turn on in 250ms. That's a quarter of a second.
You have plenty of hope.
Ignoring the round trip over the internet for SmartThings, there's not a detectable difference. Because of the Internet, and the variation thereof, usually I'd say 500-750ms and much longer if ST's cloud is down. As a result, the all local element of Hubitat increases repeatability/consistency.
What you can do is create a virtual switch. Add it into your motion lighting Rule, so that both the real light and the virtual switch are turned on/off at the same time. Which comes on/off first? And by how big a difference?
@csteele is that HE to HE that you are seeing 250ms for a light to turn on or do you get that with Smarthings to HE.
If I understand things correctly the smarthings to HE is cloud to local where HE to HE is local to local.
@csteele, your edit answered my questions, thanks.
I just tried it.. not a perfect test..
I have a Hank RGBW bulb that lives on a Hubitat Hub and is mirrored out to ST. Clicking on the ST App's tiny button, the light comes on in a perceptible half second. The cloud must be quick today.. helps to be :38 mins past the hour and nobody's Automation fires at 38 mins past the hour I guess.
It's also a dimmable bulb so the ramp time (set to zero) isn't actually zero. I tried it about 5 times to get a larger sample of values.
We have seen more than a few reports which turn out to be 'disassociated' devices. Let me explain... HubConnect is an App. It creates Child Apps (Server Instance) and child devices. In this case I'm focusing on child devices. Again, there are two 'types' of child devices... the HubConnect Remote Hub (virtual hub driver) and all the devices we mirror from hub to hub.
The child device MUST retain it's child condition. A disassociation of the device from the App means that the app can't send data to the device.
We've seen the virtual hubs somehow become disconnected. BUT it's relatively easy to cure, and also harmless (minus the few moments it takes to do...)
On both the Server and the Remote, in the device list, find the HubConnect Remote Hub device and delete it.
Then simply go into the Server Instance and into the Remote Client and pretend to copy (paste) the key. (Dive into the menu system to that depth.) Then click Done and Done and the devices will be recreated.
Remember, I'm not suggesting you need to copy/paste the key, just get that far into the menu system.
