Yes
1 Like
I see a pattern here. Ask away guys!!
2 Likes
I don’t think I’m giving too much away here.
Just allaying a few fears
2 Likes
@erktrek, @csteele, @JasonJoelOld, @Cobra
Thank you all for your responses. I just ordered another hub...couldn't resist. Not sure how/if I'll use it yet, but very comfortable knowing I'll have a backup hub at the very least.
2 Likes
Am I missing something? Is there a V2 hub on the horizon?
I would think a Hue Hub would be better for this. You get all the benefits and convenience of Hue and it's focused on ZLL.
If you were able to move the stick over from the old hub to the new hub and you had a backup to restore, you would have to do no other work inside HE to get everything up and running again? I thought some of assignments in the DB couldn't be restored that way and would have to be rebuilt?
Is there any chance in the future that we can have a linked garage door opener driver for the Link to Hub App for connecting 2 Hubitat Hubs and a better Omni driver where I can pick what attributes the device supports or have proper virtual drivers instead? The Omni driver works but odd seeing all of the other values and options there that the device doesn't support. Thanks
I bought a second job when I saw this sale and the Link To Hub works great to have a second hub for custom apps and testing.
Just resurrecting this as I'm thinking of ordering another hub as a backup.
My current hub was ordered in April 18 when they were first released to the UK.
My current hub has 2 external sticks, zigbee and zwave, and I believe the latest hub uses an internal zigbee radio but still uses an external zwave stick in the UK version.
So my questions are if I leave things on my original hub taking regular backups to my PC how easy would it be to power up the spare and get things working.
I'm assuming I can transfer the zwave stick to the new hub, restore the latest backup and that would cover my zwave devices. I'm wondering about zigbee. How would that work. Would I just have to pair the zigbee devices to the new hub and that's it. As I've restored the latest backup I'm there.
Just want to get things clear in my mind.
TIA.
Bob
There's so much more available to us today vs 7 months ago.
I think the greatest improvement is HubConnect. You can have both hubs on, and working together as one larger hub. Should one hub die, the entire house isn't dead. Maybe the bigger half 
depending on how you "balance" the devices.
If I were starting where you are starting, knowing what I know now... (vs 7 months ago) is I'd get that new Hub setup as a HubConnect Server (coordinator) and move all your Cloud services to it. Amazon Alexa, Google, Chromecast, Weather apps. You will use HubConnect to distribute devices between the two hubs. Look at each individual app and what devices it's currently using. "mirror" those devices to 'coordinator' and use them in the moved App. (Just disable the App on the original hub til you're confident.)
What this will have done is dedicated your original hub to be a ZStuff Radio centric hub. It will spend all of it's power on getting radio packets in and out. You'll find it's probably faster without all the apps eating CPU power at the expense of Radio traffic. (A radio packet arrives from a Door Sensor, the hub has to send the event to all the subscribed Apps and then the apps eat CPU doing what they do with the event. In the dual hub scenario, the Door Sensor is 'mirrored' to the Apps Hub and all the App work, tiny as it might be, isn't using cycles on the original hub.. it's already back working on the radio queues and the next packet(s)... )
I know this is not answering your migration question, but that answer didn't change over the 7 months except we know that an External ZWave USB gets attached via a special cable and works the same otherwise. Zigbee is still the same as 7 months ago. You re-pair them and they should land right back into their "slots" on the new hub's old DB.
1 Like
Thanks for the reply.
My setup is working very well at the moment, I shouldn't have said that , and the only thing that is giving me issues is Chromecast so your comments make sense on that front.
I may just get one register it and run minimal things so in the event of the original failing I can transfer everything to it and only lose the minor stuff it was running.
Food for thought.
Thanks again.
I have a single Chromecast device (Google Home Mini) defined on 'coordinator' with Chromecast app there too. I then "mirror" that device to my other two hubs so that they can make announcements too. That's all I use it for and even then, not many times a year.
1 Like
You've convinced me guys.
Time to order #2. 
Well I ordered my second hub and I'm using hubconnect to link the two hubs.
I've decided to have all my devices on hub1 and the majority of my rules on hub2 to spread the load.
How I have done it is by replicating all my rules on to hub2 and disabling them on hub1.
So in theory I have 2 identical hubs.
My thinking is if Hub#1 dies, I can just load hub#1 backup on to hub#2 and just re-enable my rules, and re-pair my devices and we are back in working again.
If hub#2 dies I just re-enable all my rules on hub#1.
This means if either of the hub dies I can get my home automations back up and running relatively quickly on the one hub. No waiting for a new hub to turn up. (Well in theory anyway).
1 Like
Consider getting an Aeon Z-Stick and a USB OTG cable.
- Join the Z-Stick to your ZWave network, and get it to be a backup.
- Using Aeon's Backup tool (on Windows) you can make even more copies.
repeat everytime you add ZWave devices.
You know that when the Hub dies, it will NOT be when you have 8 hours to walk around the house re-joining/re-pairing. With a backup ZWave controller and the OTG cable you could be up again in minutes. When the replacement hub arrives, spend the re-joining/re-pairing time getting it back the way it was.
Least that's my plan with my Z-Stick.
1 Like
I really like this idea. It would be very nice if, in the future, Hubitat supported z-wave learning mode and shift controller.
We've been told it's on their list.. just no where near the top.
Hopefully it will be complete at least a week before a bunch of Hubs reach their End-of-Life.
3 Likes
Hate to be negative, but a lot of the posts in this thread reinforce my feeling that the hub needs a faster processor and better specs. We shouldn't need to load balance by adding more hubs. I've only owned my HE for a few weeks, and while I like how versatile the device is, I couldn't help but notice how slow it is to process some fairly simple Rule Machine apps. Things that I think should take tens of milliseconds often take hundreds of milliseconds, which add up quickly if you're trying to do anything other than the simplest of things. I have spent more time optimizing my apps and rules and logic than I have spent setting them up in the first place so that automations happen in a reasonable amount of time. I dream of a new Hubitat hub with beefier specs that could process anything you could throw at it without having to obsess about optimization and performance. Some of my rules have gone from simple to fairly complicated just to make them quicker to process, and I don't really enjoy that.
I totally agree but that is not why I have done it.
My C-3 hub has been running nicely for over 18 months now with no major issues.
The reason I got a second hub was in case my original hub decided it didn't want to play anymore. Then I would have to order another one which would mean I would have no home automations during the time it takes to get another one.
Now that I have a fallback hub I thought I would let it do some work, hence my load sharing.
I also now have a fallback option that would be relatively quick to implement.
1 Like
That hasn't been my impression and certainly wasn't why I 'promoted' adding additional hubs back in June of 2018. I used HubLink and Link 2 Hub, back to back, to accomplish my goals then. It was adequate, but had some large wishlist items. HubConnect was developed and answered all of my Wishlist so far.
The WHY I added additional hubs was entirely focused on ZWave Radio performance. The Hub has nothing to do with that. It's part of the spec from the ZWave 'inventors'. ZWave Plus is 100k bits per second. ZWave and the oldest ZWave are 40kb and 9.6kb
The result is that in any 1 second interval, too few ZWave packets could traverse the network for the responsiveness I wanted.
We all know what it should feel like..put 10 ZWave simple devices (door contact and light switches) on a hub, and you are just NOT going to get faster than that. But at 100 ZWave devices and too many of them being multi-somethings with power reports every half watt and temp reports every tenth of a degree, then the ZWave network (mesh) is swamped.
Cutting back on reports to be 5 degrees of temp and 60 watts of power absolutely make a difference. But putting TWO ZWave networks side by side DOUBLES the available packet per second. Again, the CPU has very little to do with this UNLESS you also add processor hogging Apps and Drivers. Just switching code to use AsyncHttp helps a lot because the processor is not doing "wait for".
For THAT reason, I added a third Hub to focus on just App and 'Cloud' Drivers. I use wx-ApiXU-Driver and it hits 3 different websites to gather it's daily dose of weather goodness, as one Driver example. Any shortcoming in the way that's written falls on my Third Hub, not on my ZWave Radios. ChromeCast, Amazon, heck, even Dashboard, all reside on my third hub. Dashboard isn't even a risky app, but I benefit from it being central to all my devices.
As a BONUS, I get redundancy for hub failure for 'free', but the factors you mention, load balance, processor speed and memory, were NOT factors in my decision. Capacity balance, yes, load, no.
3 Likes
