I just ordered an additional HE Hub/Stick as a backup thanks to @bravenel 's post Hub Sale! (Wifey is gonna kill me btw...Haaaa) , and am wondering how you all manage your contingencies. Do you just keep the 2nd system unopened on the shelf in case you need it, or do you keep it's firmware and DB current with your current production HE? AND...if there is already a guidance document out there for this, please point me in it's direction. Any input would be greatly appreciated!!
I bought 2 hubs pre-sale sadly. I am using them each to provide a strong mesh network for a set of devices in a given area. Will also link the hubs for simple stuff like maybe mode changes.
In my case I have one in my basement and one on my 2nd floor.
The really nice thing is 2 days ago had my 2nd floor hub go down (faulty power supply) but my downstairs continued to function. Rebuilding will be less painful (replacement on the way) since all of my 100+ devices do not need to be paired again.
If you want to go this route and you don't have a network connection to your 2nd hub you can use a powerline adapter.
You could also use the extra hub for experiments and dev if so inclined.
I purchased my 2nd hub to use for development with the back-of-my-head idea that if the first should fail, I have a spare.
I have never used Zigbee because since 2014 I used multiple hubs from multiple vendors to get the mix of features I desired. In 2018 I got back to one hub only and decided I wanted to give the tiny zigbee motion sensors a whirl. Well now I'm cooked. They work well but they are on my 2nd hub and I'm now leaning towards making the 2nd hub my 'upstairs hub'.
That will mean I'll need a 3rd hub, right?
When are the new Hubs being released?
Whewww...too many hubs too little time!
I can sell you 2 hubs if you like.
I was thinking of getting a second hub just for 3rd party apps. Is that possible? Could they be linked in some way to coexist in such a way that important automations weren't affected when 3rd party apps make it difficult?
Yes and No (You already knew that was the answer, right?)
Yes, you can install all the third party apps on a 2nd (or 3rd ) hub. They have nothing to work against. You'd have to use Link to Hub to get all the sensors to the 2nd Hub and to then have virtual (linked) devices to be driven by the Apps.
Your gain is in the isolation of Third Party Apps. But you're not completely un-affecting the original hub. It's got, in many ways, double the task.. it has to take each event and act upon it for the local apps (now including Link to Hub) and then react to virtual (linked) changes.
Is it an overall improvement? I'd say.. it depends on the quantity of Virtual (linked) events that get generated. I believe our biggest constraint is the Radio. I've said this elsewhere but here it is again.. we have gig everything all slamming into a 40kb Radio. Offloading the apps to another hub doesn't alter that.
If your use of ThirdPary Apps is limited to just a handful of Virtual (Linked) devices, you'd be on the net positive side. But if what you plan on putting there is something like Homebridge, that encourages selecting "everything", then I think you'd be at no gain.
I could have told you they would go on sale as that is what always happens the week after I purchase anything!!
Some folks are using the 2nd hub in order to improve Zigbee bulb performance like @mike.maxwell.
Are these extras? Or have you decided that Hubitat is not for you? Or are you hoping the new hub is worthy of the upgrade? Just curious...
I have 3 hubs, 1 the production, 1 the development (I don't know anything about coding).... and 1 because I wanted to help HE, honestly I had no reason to buy it, I will sell 2 of them, not sure yet if the last one too. I been with mixed feelings lately.
Equally important to me...will the new hubs coexist with existing hubs? I was thinking about getting a 2nd hub to use as a "Zigbee bulb hub" and maybe a 3rd as a backup (probably left unopened on the shelf). The sale makes it very tempting to do this now, but what if I want/need to add one of the new hubs to the mix down the road? Will they all play well together?
I think the chances are very low that the new hub will be incompatible - why kill the momentum?
Not sure how you would migrate if the new units have internal radios..
Also worst case you could always link to the old/new hub like we could with ST (& HE).
The existing hub is pretty complete. Yes it's a "something else" box converted to our use, it has some 'round the world oddities, where there's only one Zigbee USB worldwide but various ZWave USB required.
What would you add? If it were my project, I'd do exactly the same as everyone does.. latest (probably meaning faster) processor and more memory. But those are at a cost and only today @bravenel suggested we're not hitting the limits of the hardware.
There's cost in the USB dongles (plastic cases) that (while not much) would be eliminated. Unless of course the new hub had to be a bigger bit of plastic, I'd use that cost savings to offset the processor/mem to the extent possible. (10 cents of plastic isn't going to boost mem or processor much )
But the end result is pretty much what we see in the pics and the (teaspoon of salt) reporting. Same as we have, but all in one. For me, I think the BIG miss would be in duplicating what we have vs what could be.. which in my mind would have included the Lutron Clear Connect Radio (same as Staples Connect had.)
My scenario above wasn't well thought out, so let's go with something simpler.
If I simply want to replace my existing hub with the next gen hub (just because), would it be possible to use a backup from my existing hub to migrate rules, installed apps, etc to the new hub? I understand the devices themselves would likely need to be paired to the new hub because of the radio change. While that's somewhat annoying, I'm less worried about pairing compared to rebuilding the logic in the rules themselves and installing apps/drivers again.
I suppose I'm also curious how this currently works for a basic backup scenario with two identical hubs.
Techive Hubitat review
My plan with my 2 hubs is keep everything as local to each as possible. So the backups would also be local for each.
I don't know if you can link to more than one hub at a time - I'm not quite ready to start linking yet so haven't gotten into it.
I will say the larger number of devices you have the more painful re-including becomes. So not just rules etc. If you have multiple hubs then you can do it hub by hub instead of all at once.
I wish there was a better way to manage migrations etc. Even ST struggled with their efforts.
I shortened your query to be able to answer twice...
If your current Hub dies, you'd unplug the USB Radio Stick, and put it into the new one. Then you'd copy a saved backup to the new hub. You'd be running equal to what was... at the moment of backup.
Not as easily because, as you note, the DB that resides out on the Radio stick can't be plugged in, we presume I'd like to think that Hubitat thought of this scenario and has at least ONE USB slot in the new hub.
The current hub can have at least 2 ZWave Radios. The one inside the Nortek USB stick and something else. If you boot with 2, it uses the something else first and ignores the ZWave radio in the Nortek stick.
I can't see Hubitat discarding that code by not having a USB. But it's ALL speculation by me.
Since we can easily assume they are as smart as me... if not 10x smarter.. then they will have a process.
ZWave does support Controller Shift, and although their ZWave tools are lacking, it's theoretically possible they will code that up in time for the new hub.
Just keep in mind if you are thinking of a second hub for load balancing, you can't transfer ALL device types from hub to hub using the HubLink / Link to Hub... It is mainly geared around physical zigbee and zwave devices, not cloud integrated devices (even if using a HE built-in cloud sync app like Ecobee integration).
For instance, you can't transfer an Ecobee thermostat from one hub to another hub... I mean you can transfer the temperature, but not things like thermostatoperatingstate, coolingsetpoint, etc.