I've never used the Hub Link/Link to Hub apps, so I really can't opine. I use HubConnect and 3 hubs to isolate my network. Wifi/Cloud hub, Zwave hub, and Zigbee hub
2 Likes
On MAN, that's a requirement?? Have to use something to have an opinion.. that's gonna kill off half of my opinions ! 
3 Likes
I just got the email that my second hub was just delivered at my house. Let the fun begin.
I'm starting off with dedicating this second hub to security (SimpliSafe) and Thermostat control - I'm 100% automation based thermostat control*, rather than the thermo itself controlling anything (Ecobee).
*Just a design decision...'who's on first'.
I have used both, and besides the advantages hinted at above--it passes any attribute and can be nade to work with custom devices/capabilities (though I've never needed to) and not just those it explicitly supports--I also greatly appreciate that it does not create a proliferation of virtual devices on the host (yes, you read that right) hub, one for each "shared" device. Instead, it just creates one device on the "guest" hub only, which makes your device list (I know, I know, we're not supposed to look at that or something) a lot cleaner.
It's also getting bugfixes and, maybe in the future, new features. I'm pretty sure staff lost interest in Hub Link/Link to Hub after this was released. 
I'm confused. Event socket let's 2 hubs talk to each other without any apps specifically for that?
Much better to have opinions on things you don't have. If we liked the things we would have them. Obviously if we don't have something we have to justify not having it.
It depends... Hubitat's Event webSocket, when connected to by a client, will send every single event from the webSocket server hub to the client application. So, if all you want is to "listen" and "collect data", then no Hubitat App is required on the server hub. Many of us use this Event webSocket server to collect data directly into Node-Red, and then use Node-Red to store that data into InfluxDB.
However, if you want true two-way connectivity, then an App (like the Maker API, or HubConnect) is required on the hub to receive commands.
Hope that helps to clear things up a little...
1 Like
Well, my second hub came in yesterday. Wow, has the initial startup/registration changed since the C-3 days! Great work from the Hubitat Team.
Only took a few minutes to wrap my head around the Hubconnect app. Once I did, moving apps over to the second hub went pretty smoothly. I've moved over half of them over (completely removed app, devices and code) and WOW what a difference! We will see how it goes over the weekend, hopefully be able to move the rest of my apps over to the 2nd hub.
Once I'm done my config will be:
First Hub - All devices (293 right now!) and a few built-in apps (and Hubconnect)
Second Hub - All 3rd party apps (and Chromecast beta)
2 Likes
I bought a second hub as a backup in case my original should fail.
Because I have a second hub I decided to have all my devices on one hub (#1) and all the rules on another (#2). All rules one hub #2 are duplicated on hub #1 (which has all my devices).
If hub #2 fails I just re-enable my rules on hub #1 and everything is working.
If hub #1 fails I,
soft reset hub #2
load hub #1 database on #2
move my z-wave stick from #1 to #2 (assuming this is not the issue of course).
re-pair the zigbee devices and enable all the disabled rules. (Should only take a couple of hours in theory). 
For me this gives me the redundancy I want in case of hub failure.
I've probably missed something obvious in my theory but to me this gives me the redundancy I want. (Forever the optimist).
Oh, and because I have a second hub, the first one will never fail. 
2 Likes
How have you achieved that? Do you regularly restore a backup from one to the other to keep them in sync? How does that work in terms of device duplication?
I am considering a second hub for the same reason as you, but am now sure how I would set them up. My issue is complicated by the fact that I'm in the UK so and my original hub is a C3 with 2 external radios (Zigbee/US Zwave (with Zwave disabled) and seperate UK/EU Zwave stick). I thought about maybe getting a C5 without a new Zwave stick and put the one from my C3 in that to have Zwave and Zigbee running on separate hubs, but I don't know how that would set up in practice with regard to the Zwave devices being on the "wrong" hub.
Any advice as the best way to set some some of backup/duplicate/load sharing on the second hub would be much appreciated.
My advice is to group devices and their Rules on a hub. In my case I split the house between "upstairs" and "downstairs" but obviously you could choose "north" or "left" or any other arbitrary division. Rooms certainly seem like they belong together, but for me, that hasn't worked out in a 'pure' sense. I have more ZWave than Zigbee by a large margin, therefore I have two ZWave radios on but only one Zigbee. Thus all Zigbee are known to a single hub, even if that Zigbee device is not on 'this floor'. In other words, I was unable to obsess over the division choice. 
If I had to start all over, I would use the Rules to divide. I'd look at the number of Rules (motion lighting, simple lighting too, just using 'shorthand' when I say 'rule') and divide them. I'd put the Rule on the Hub that could directly reach all of the devices within the rule. Motion lighting for example.. maybe it's just two devices, a motion sensor and a switch / dimmer. I'd migrate those devices to a hub and get the Rule going there too. In my case, all rules that include a Zigbee device would go on one hub, the one with the Zigbee radio enabled. Then I'd migrate the ZWave devices for that Rule onto the single hub and that would have everything as tightly coupled as possible. Motion to Rule to Switch/dimmer would be as fast as possible.
I'm not suggesting you duplicate my config.. I'm just trying to offer 20/20 hindsight.
4 Likes
If I just want a second hub purely as a backup can I clarify what I can do?
If I get a new C5 with no external usb radios, restore the latest backup from my existing C3 hub to it then plug both my existing external radios into it will it work exactly as the original?
Would existing pairings to Hue bridge for example be carried over too?
Any update on this or are we forced to re-provision all devices after restore?
I believe the zwave information is stored on the 'stick' so I assume moving the stick to the new hub will take all zwave data with it.
Zigbee information is held in the db backup.
So I think moving the zwave stick, restoring a backup, re pair zigbee devices should do the trick.
Just my thoughts and I may well be way off mark here.
I know that you @csteele and @srwhite have a lot of experience with this tool HubConnect, but I'd like to offer my own personal experience.
After reaching around 170 devices and multiple interfaces (MyQ, Alexa, Google, SharpTools, etc.), and getting many slowdowns (as measured by Hub Watchdog), I decided that enough was enough, and split my load into 2 hubs. (Why didn't I do that sooner?)
[Certainly, Hubitat Management should put on their list of things to do: Hub Load Measurement Software, so that we know when we're getting towards the limits of how much a hub can handle.]
I put all my real devices (around 60% zwave, 40% zigbee), on one hub, and all my rules and interfaces on the other. It was a lot of work to re-write all my rules and interfaces. Also, do a soft reset after all the changes is essential.
However, the early results have been outstanding! (as per Hub Watchdog). It's also been surprising to me how fast that ethernet connection really is - it's like the rules are still on the same hub as the device it's controlling! Amazing - brilliant idea, and a great implementation. Thank you!
P.S. I'm not sure if the way I divided up my hubs is the most optimal, I only know that it works for me. (Your mileage may vary!)
1 Like
In my case I moved my Sylvania lights to a second hub. They are the only things on that hub along with a few repeaters. I have about 30 Sylvania products and this cleared up my problem with dropped devices when I started adding more Zigbee motion sensors. Everything is much happier with two independent mesh networks.
So many ways to plan a system.
I’ve thought about going this route but if your user app needs to integrate with HSM (Like my alarm integration), then does it stay on the primary or secondary? Which one of your devices runs the dashboards?
My division (seems to work):
Server: All rules, groups, scenes, Google Home, Amazon Alexa, Sharptools, HSM, etc., also virtual switches, etc.
(HSM is on this device, but gets inputs from the Remote). HSM is not on the Remote at all.
Remote: All devices (zwave + zigbee) around 120 real devices. The only rule left is Hub watchdog.
Note: I started with everything on the Remote hub. When I finished moving everything off, speed improved. After that, I did a soft reset - and speed definitely improved. (And size of the database dramatically declined.)
1 Like
HubConnect will mirror HSM too. The requirement is that you have a valid HSM on each affected hub. One hub will have a "real HSM" running and it will share state. The 2nd hub will need to have a valid HSM available to mirror into. That means a) installing HSM, and b) configuring it just enough to be valid. Usually this means configuring a device for each state. You may want to create a virtual device with some mnemonic name, and then use that in each 'HSM definition' -- Day, night, evening, away. By having some device in each 'definition' HSM will accept states.
In other words, its HSM's requirement that it be configured to some minimal level before it is valid. Once it's valid then the HSM states mirrored across will have someplace to go. Said yet another way, HubConnect will mirror HSM states regardless, but it isn't much use if those states are ignored.
1 Like
I only have HSM on the server hub. It decides when to do things based on the Hubconnect version of the devices. I don't have it at all on the Remote hub.
1 Like
