Hub Link Questions

I've been considering for some time getting a 2nd hub to run all my apps an automations while my current hub continues to actually connect to my devices. I don't know if it's specifically beneficial or not, but I have a large number of devices and I was hoping that splitting out this processing might take some strain off the hardware.

My one question is.. is there an easy way to export/import rules and other apps/settings or does that need to be done manually?

Manual

2 Likes

How many is "large"?

More than 100.

I made a backup of my single hub and β€˜cloned’ it on to another
(I.e restored the old backup to the new hub and renamed it)

The original hub kept the devices but I removed the apps.

My second hub kept the apps and I removed the devices.

I then used hubConnect to send the devices from the β€˜old’ devices h8b to the β€˜new’ apps hub

This worked well for me

Andy

4 Likes

There is rarely any need to use a second hub, though I am sure Hubitat would love it if you bought one regardless. :slight_smile: (Segregating problmeatic Zigbee bulbs to their own network is one reason you might. Running untrusted custom code on one hub only is another. I got my first "second hub" so I could do testing and development on it without bothering my "real" hub. Some people like to split the work between multiple hubs for various other reasons that may or may not be grounded in reality or personal preferences.)

@Cobra's advice is basically what I did when I got my second "second hub," which I did to isolate as much as possible all of my lighting-based automations and devices to this one hub (again nothing most people would need to do, but I wanted these to be as fast as reliable as possible while keeping some custom apps and chatty devices like power monitoring ones on my "main" hub). There are no selective backup/export and restore tools, though staff have hinted that they are experimenting with ideas like this; the hub database has all your hub/location information, plus apps and devices, including complete information for Zigbee devices and not much more than node IDs (and names) for Z-Wave, with the rest of the information you need to actually use the devices stored on the Z-Wave radio itself (built-in to the C5 if you're in North America, so no good way to move, unless you're using an external device like a Z-Stick or in another region--and then there are third-party tools that can back up/restore this, but again it's basically all or nothing).

Like him, I'd also recommend HubConnect over Hub Link, assuming that you are OK with the license and the need to run third-party code (Hub Link and all drivers are built-in and officially supported in that sense, but staff have even recommended HubConnect to others in the past and lots of people are using it with success). It's a bit newer and more powerful, and it supports more devices (and doesn't create annoying "virtual shadow devices" on the host hub), so I'd at least give it some consideration even if you decide not to use it.

2 Likes

I am one who NEEDS more than one hub. I do, really. I have at least as bad a WAF requirement as anyone.

About the time I hit 80 devices the limits of ZWave's low communications speed surfaced. The hub, any ZWave controller, can fill the radio channel. Swamp it really. The radio is uni-directional (half-duplex) and it is either listening for traffic from potentially chatty devices, or sending. Too much chatty subtracts from the channel's sending ability. Delay in the send means the lights come on noticeably late. WAF plummets.

It was quite clear to me that another ZWave radio would double packet throughput. I split my houseful of ZWave devices between two hubs. Then a third to handle all the 'questionable' apps and Internet facing traffic.

Yes, I could try and live in a house where 3-5 second response is normal. In fact, I did try. But now I don't have to. I get reasonable 250 - 350ms Cause-and-Effect.

That was choice I faced. 3-5 seconds, or 1/4 second. I didn't HAVE to, but I did choose 1/4 :smiley: more than a year ago, now.

Right this minute, there's no one moving around in my house.. not even the dog. I just watched the Logs and 10 seconds went by with no events. One hub can handle that, no question. But an empty house is not why I am automating. I'm automating for when the house is full. I'm automating for the few parties we have, where guests go into a bathroom and I NEED the light to go on before they can find the switch. :slight_smile:

8 Likes

I am going to quote your saying that from now on rather than saying it myself. BOOKMARKED!! :wink: :clown_face:

See, now THAT makes sense to me. Two radios, each one has to do half as much work as it did before. Totally logical. If you have enough devices to warrant two hubs, then your house is big enough for two independent mesh networks (for each protocol) to exist side-by-side.

In my humble opinion, there is one more factor that makes this approach technically possible. That is the speed of instructions over wifi versus those zwave delays.
I'm amazed that an automation such as the one below, works as fast as it does:

  1. on hub #1, I press and turn on a switch. That is sent over to hub #2.
  2. on hub #2, a rule is triggered, to turn on several other switches.
  3. that message is sent from hub #2 to hub #1
  4. on hub #1 , hubitat tells those other switches to turn on.
    All that happens, as if it was all on one hub, not 2, with no appreciable delay.
2 Likes

I have a similar situation, although 'inverted' might be better...

I came to Hubitat with zero Zigbee devices and no real intent to buy any. It's not a Zigbee vs ZWave thing with me, but I do not like the bulging wall wart style that Zigbee has forced upon me.

I got a couple of Iris v2 motion sensors and did really like their battery life and responsiveness. I hate the look of Peanut plugs, and especially the desire of my family to imagine them as optional and unplug them. I still do not have enough Zigbee to warrant a second mesh. Therefore all of my Zigbee is on a single hub. It blows my entire "hub per floor" plan :smiley:

A motion sensor physically located downstairs needs to turn on a light downstairs. But the Hub with Zigbee is upstairs. Therefore, the flow, for me, because of the late addition of Zigbee to my home, is to go from Hub 1 (motion) to Hub 2 (server/coordinator) to Hub 3 (light). The logic is on Hub 3, so all it sees is a Motion event. It has no clue it originated 'two hubs west'. :slight_smile:

And of course it's as fast (human perception wise) as if it were on a single hub. I could easily 'cure this abomination' by abandoning strict "hub-per-floor" and move the downstairs light to the Upstairs hub... but really, it's so fast, why take the time to Exclude a Zwave device and Include it. Those are 10's of minutes I'd never get back. LOL.:slight_smile: So yes, I concur.. "no appreciable delay" is cool indeed.

2 Likes

But it isn't faster...as some people claim. So, if it's the same, then why divide them? If you have one hub for all devices, then there is a driver and an app managing that. Then on the other hub you have an app and a driver and then your rule. So, if we're not talking about radio bottleneck, why have 2 hubs?

Of course it's not faster, it's really slower. But, there is no "appreciable" delay.

The reason that I went from 1 hub to 2 is because I was starting to get the "slowdown" disease.
You're perfectly correct that I shouldn't have had to do that, but it was expedient to do so.

P.S. Big Kudos to @srwhite for having conceived of, and implemented HubConnect, the great software that makes it all possible.

I'm not convinced and no one can prove that that is the solution to hub slowdowns. Don't you think if it was Hubitat would just come out and say it? I mean, they are in the business of selling hubs after all.

1 Like

Well, it's still in its early stages, but my numbers from Hub Watchdog clearly show that my zwave response time has improved dramatically since I did the split.
I have all my devices on Hub #1, and all my rules (and external interfaces) on Hub #2.

Yes, I should not have had to do that, but it does work for me!
Your mileage may vary!

You have the same number of devices talking through one radio. How would this get better?

Let's just agree to disagree. You've never going to convince me through feelings or anecdotal evidence that 2 hubs are better than 1 until you get into the uber device setups. If you want to prove it to me, show me evidence. But until someone does, I'm sticking with what makes logical sense.

Objectively, my Hub Watchdog numbers are MUCH better after the split.
As to why, I have a theory, but it's just a theory without any conclusive proof.

I have around 80 "real" zwave devices and around 60 zigbee devices. I believe that there is some sort of limiting factor at play when everything was on one hub. Perhaps it was a chatty device, perhaps a rule that was using up valuable cycles, perhaps some sort of resource leak with the external interfaces (alexa, google, life360, myq, etc.).
Separating out the devices from the rules gives me that much more resources - and it takes much longer to run out of resources.
Please forgive my lack of preciseness as to the cause - nobody really knows. All I know is that for the price of less than 2 switches, I have a solution. That's a good bargain in my book!

Yes, it's OK to agree that we can disagree on this matter.
Also, I'm sure that Hubitat management is working as hard as they can to get to the bottom of this issue. I wish them only the best of luck in hunting down this bug and squashing it!

2 Likes

That's false logic. Using that argument, why buy a quad core CPU when you can do the same work on a single core? You cannot draw a generalization into hard truth like that. It's all about parallel processing and it really doesn't take a "loads" of devices to see the benefit.

Example... Z-Wave is not multithreaded.. That is a fact. The hub sends a command and waits for a response, then sends another, and so on. Schlage locks are a good example oh how this breaks quickly... If I have 4 locks to control concurrently, and split them across two hubs, they will always respond quicker with 2 hubs than one.

Plenty of posts around here about that. Accept what you will.. However I don't understand your recent crusade against those who enjoy multiple hubs.

2 Likes

But what you're failing to take into account is the additional app and the additional driver you're adding into the mix. You make it sound like Hub Connect doesn't do anything. It does. it has to subscribe to every device's events on the originating hub. That means whenever there is an event it spins up and send that to the other hub. Then, the other hub has to have an app to receive that and then a driver to get that event into something that the second hub can use to do something with.

So, yes, you have 2 processing centers but you've also doubled the amount of things that have to be processed. So, in the end, it's a wash.

Because I see people who have absolutely no need to have two or three or more hubs getting them because they think it will make their systems faster. And I think it is irresponsible for those that know better to let them believe that.

You have your opinion. I'm not allowed to have mine too? Seems like awfully big double standard to me.

Using websockets the processing time is literally milliseconds. I've benchmarked it and the HubConnect 2.0 actually exposes those performance metrics based on RTT messages at the hub application level.

  • proxyJitterMS : 1
  • proxyLatencyMS : 42

I would say it is splitting hairs over an additional 42 milliseconds of delay.

That's a pretentious statement.

You are allowed to have an opinion. The difference here is that I do not feel it necessary to preach the benefits of multiple hubs.. Others will discover it for themselves..

2 Likes

I have the same reaction... I created a support ticket back in early to mid 2018 for a 27 second delay from motion to light. I documented it to support. I routinely saw 17 second delays. Normal was the same as now... perception wise.. roughly 250ms (1/4 second).

So the best was 250ms, the worst was 27 seconds.

Three months later I had a HubLink/LinkToHub connection on two hubs and my RANGE was 250ms to 1500ms (1.5 seconds). I have said all along that multiple hubs do not make things faster. That is impossible. I have said, all along, that multiple hubs reduce the range.. the variance.

250ms to 27000ms
250ms to 1500ms

I do believe that is an 18x improvement in.. what factor is that.. what name? Reaction? Responsiveness? Consistency?

Just as multiple cores hinder or help, depending on the cost of core dispatch, multiple hubs have the same curve. If I were to dedicate a Hub to just that one documented case... would I get another 18x benefit? Certainly "maybe" but also "pretty unlikely". So unlikely that despite having 2 extra hubs that could be thrown at such a test, the time spent Excluding, then Including and then letting the test run for a month or so, would not be worth it to me.

1 Like