I read several discussions about using two hubs but most of them seem to focus on using two in the same physical location. I'm testing out migrating from Wink and I have a workshop that is connected to my house modem via a powerline adapter in my garage, with ethernet cable running to the shop's router. I set up the two hubs without issue in each location. I installed HubLink on the master hub in the house and added the IP address of the workshop hub. Then I installed Link to Hub on the workshop hub and added the IP address of the master hub. I have one switch set up on the workshop hub and in the Link to Hub app I shared the switch. Shared both the vs_ version and the regular version.
On the desktop for the master hub, I don't find the switch.
Also, I installed the Amazon Echo app and shared both switches from the workshop to it and they don't come up in Alexa.
I've tried various combinations of sharing and can't seem to get it to work.
The IP addresses for the two are the same first two numbers with the following for the second numbers
There are two other similar discussions in the past couple of weeks
Also Wink people.
HubLink/Link2Hub are built in apps that were designed to help with migration from SmartThings to Hubitat. As such, they focused on a rather narrow set of attributes to be shared across the connection. HubConnect was born from that limitation. HubConnect is not a migration tool like HubLink is. It's a tool for interconnecting hubs into a larger system. Long term.
It is, as a result, a much larger installation process. Not hard, just bigger... more parts.
There are step-by-step instructions and even a couple videos to assist.
HubConnect v1.5 was just released this morning. Good timing
Thanks, I'll look at that. When searching for linking hubs, the hublink stuff comes up on top so that's what I tried. I'll delete those apps and try this.
There's nothing wrong with using HubLink/Link to Hub as long as it's limited set of Attributes are acceptable. Beyond that limit... is where HubConnect shines.
Possibly, yep. It would depend on some networking that isn't revealed. The hubs need to converse, obviously. They have no route table for us to manipulate. There's "my network" and everything else (default route.)
If you have a PC on the same subnet as one of the Hubs and can reach the GUI on the other hub... then networking is working and the Hubs shouldn't have MORE difficulty.
I don't know a lot about networking. Should I be connecting the workshop hub directly to the line coming to the shop instead of plugging it into the router there? I could add a switch box if needed.
The two hubs need to be able the see each other on the network. If you can ping the shop hub from the house and ping the house hub from the shop you should be OK network wise. If you can't, you will need to rearrange the network to suit.
Getting closer. Got HubConnect installed and I now see the workshop hub on the master hub device list. Don't see the switch that I shared. Have to head back down to the workshop to look at it. At least I'm getting some exercise today walking between the two.
Here's the 'picture' I have in my head regarding your system.....
Hub in your Home, configured as Server. That requires the installation of 4 code modules, minimum... HubConnect Server + HubConnect Server Instance + HubConnect Remote Hub (a driver) + HubConnect Switch (also a driver)
Hub is in your Workshop configured as Remote. That requires the installation of 2 code modules, minimum... HubConnect Remote Client + HubConnect Remote Hub (a driver)
The "Real Switch" is a device on your Workshop Hub and is using a built-in driver.
You've gone into the HubConnect Remote Client on your Workshop Hub and clicked Select Devices to Synchronize to Server and found your "real switch". You've clicked Done a couple times and noted that the HubConnect Switch driver needs to be installed on the server BEFORE clicking Done.
If you didn't install the HubConnect Switch Universal driver on your server.. no worries.. just do that and go back to your Workshop hub and dive down into selecting the Switch again.. you don't have to Do anything, but as you click Done again to get out, the final Done will send the entire list of selected devices to the Server and the server will build the virtual switch on your Server hub.
That lead me to installing the HubConnect switch driver in the master hub. I didn't do that before because the instructions implied it was optional. I'm not at home so I remoted into the house computer to do the install. I can't remote into the workshop laptop so wasn't able to do the next step but I will when I get home.
Hopefully this will resolve the issue, then I can continue migrating the devices there over to Hubitat.
Getting closer. I can now see the switch in the master hub device list. But when I try to turn it on, it does nothing. I added the switch to a dashboard and when I click it, it shows an hourglass and does nothing.
I went to the workshop computer and can control the switch either through a dashboard or through the device properties. And on the dashboard from the master hub the icon changes to show the state of the switch. There is a slight delay though.
The state also changes in the dashboard if I manually work the switch.
I removed the switch from the workshop computer dashboard and no change in the issue.
Still not working correctly. Checked everything up and down. Added a new switch to the workshop hub and went through the process of sharing it with the master hub, including installing HubConnect Pocket Socket driver as instructed in the workshop hub before clicking "Done". The new switch (a GE outdoor plug in module) shows up on the master hub but still can't operate it.
I guess my next step is to install an ethernet switch in the line between the house and the workshop router so I can plug the workshop Hubitat hub into the switch and maybe get it on the same subnet.
The release notes for HubConnect seem to say this isn't necessary but worth a try.
From the release notes:
Flexible oAuth endpoints; Hubs do not need to be on the same LAN or even same location.
Remote hubs can be located anywhere with an internet connection.
The next question will be, can I just change the IP address for the workshop hub in the master hub settings or do I need to start over again?
Assuming that's an accurate description of what you did... it's wrong.
If the Real Device is on your Workshop hub, it needs a "real Driver" -- and probably has one.
The 'other hub' (home in your case) needs a driver too, but there's no real device there. The workshop hub (aka Remote) will send a message to your home hub (aka Server) saying "here's the list of devices here, that are needed there" and Server will attempt to build a virtual device using virtual drivers (aka HubConnect Universal drivers.)
Put the HubConnect Universal drivers on the Server hub for all REAL devices in the workshop.
Put the HubConnect Universal drivers on the REMOTE hub for all REAL devices in the home.
It doesn't hurt to have all drivers on all hubs.. tedious, but harmless (in other words, no need to delete drivers, just keep them up to date.)
Acutally, I stated that wrong. I installed the HubConnect Pocket Socket driver on the server hub in the house as instructed. Not on the remote hub in the workshop. It also wanted the HubConnect Switch driver but that was already installed on the server hub for the previous wall switch I had in the workshop hub.
I'm at work but set up my computers at home so I could remote into them. I installed the two HubConnect drivers on the remote system. Still doesn't work.
I'll go through and install all the HubConnect drivers on both later.
You will see that list of necessary drivers on each hub that has real devices you're sending over the connection. It says to put those drivers on the Server if you are seeing it on a Remote and it says to put them on the Remote, if you're seeing on the Server.
Seems like everything is setup properly and it just doesn't work.
I'm going to try inserting the switch box in there and see if it comes up on the same subnet. Hopefully I can just change the IP address in the HubConnect server for the remote hub and not have to start over.
(in other words, no need to delete drivers, just keep them up to date.)
