Hub Protect - Best Practices for the closest thing to a "Hot Swap"

If it hasn't been done (and I'm not seeing where it has) can we get a thread going where those-in-the-know would recommend the best course of action to being up & running within an hour of losing a hub to hardware failure.

Right off the bat I'm thinking Hub Protect should be offered with a "spare hub at subscription" option if folks wanted to be able to recover a lost hub quickly. I haven't subscribed yet but I am realizing that if/when a hub ever craters I'm going to be in a pinch waiting for the replacement hub to arrive. So buying the spare with the subscription and then the subscription replacing the spare. (Yeah, I've actually come to rely on the two hubs I have in service. Don't have as many end devices as a lot of you, but the ones I have are critical to me. Isn't there a beer commercial that goes something like that.)

So having a spare device in hand....and assuming a fairly stable system/app environment (not messing with things constantly).... what might be a reasonable monthly procedure one could go through to actually have that spare "somewhat hot to swap" in case of failure of a hub in critical service?

Given the way this all does, or doesn't, already work...could one download using Hub Protect to that spare hub and have the hub brought up to a semi-operational state with some way to prevent it from trying to start pairing with the array of devices in the mesh (bad given there's already an in-service hub)?

Maybe a) an option to turn the radios off in the backup without turning them off in the active hub prior (that doesn't seem like that could be done given the way most backups work), or b) doing the download and make the spare hub operational while sitting under a metal bucket :rofl: and then quickly unplugging it so there's no chance it makes radio contact.

So then what kinda problems might occur if one was running an early version of the hub, or would that be a moot point? Version 5 hub in service, V8 sitting hot as a spare, say a V9 sent as a replacement in the future. I guess software-wise you'd always be backing up an old platform, would that bite ya in the rear when you are downloading to the next hardware V up?

This might appear to be pushing the edge in requirements...but it is consistent with my thoughts in other threads where I am really really serious about recovery after power disruption or system failure and wishing to tighten the time to getting everything back online if a hub craters at a really bad time. I bet there are a lot of you who would really be inconvenienced, or worse, if you had to wait for a replacement hub to get things back up and running.

So starts this thread....we'll see where it leads:

1 Like

not that I'm here offering any useful information, but I too wonder about this very thing. Just commenting to follow along to see where this leads. For now I just have my spare hub sitting next to the active one that ill periodically turn on just to keep its firmware up to date with the active hub. I typically download a backup of the active hub when updating the firmware. Haven't had any issues yet knocks on wood

It seems more what you're talking about is failover. I'm not sure that could be done with the way z-wave and zigbee work. Regardless of the way you go (hub protect or not) You will have to completely reset and re-pair any zigbee device you have. As you pointed out in z-wave there would be competing radios. I don't believe there is any way to update the radio database if the radio is off. I think it's simpler at this point if you want a spare, buy one, buy hub protect on your existing hub. Should a failure occur, restore from back up, re-pair zigbee stuff... move on. Should be doable quickly

2 Likes

Hot swap, not full failover. But alas, there would be the re-pairing of the Zigbee devices no matter what you do...as they'd all know the last hub they were paired to.

But no harm in brainstorming this just in case there's something that comes up after thinking about it a bit.

It just occurred to me that one possible trigger of HE failure could be proximal lightening induced surges that are often just enough to take out sensitive electronics, either via the power or the LAN (UPS or not). Just as HE is designed to work without the Cloud I don't want to depend on my LAN or my local Internet provider to come back up so I can reconstitute a new hub from the Cloud (Hub Protect).

(Everyone that doesn't live in a large metro area raise their hand :stuck_out_tongue_winking_eye: )

I think the z-wave settings are only stored in the cloud backup, not the local backup so regardless you'll need to connect to the cloud to restore the z-wave radio

1 Like

Ah, didn't know that. Even more insight coming through here. I am so trying to stick to Zigbee and that's another reason.

Failover?! um. get a battery backup was what I was told. and that it was too much to have stored state ... and not in this price range. Get a control4 maybe?

That's not correct, There was extensive discussion about this point, and it was made abundantly clear that there is no practical way to deal with any form of automatic restoration after a power outage, If the power goes out, when the hub starts again it makes an orderly startup. It is unrealistic to expect something other than that.

It's also the case that Zigbee devices are tied to the Zigbee controller and cannot be automatically joined to a different controller. So no hot swap is possible for Zigbee.

1 Like

Wouldn't it be nice if the Zigbee radio IDs & controllers were designed such that the ID could be unique + secured but changeable on the platform so that the hub and controller could change...but from the devices viewpoint they're still talking to yourHubxyz123. Kinda like a WIFI SSID. Probably oversimplifying here. But anyway.

This is already possible since the network ID & security keys are all "in software". What's difficult is that most Zigbee devices, including coordinators, have their 64 bit address burned in at the factory.

So while the network ID and security keys can be easily moved to a different coordinator, any device that has the original coordinators' 64 bit address stored would need rejoining in order to get the new coordinators' 64 bit address.

Some coordinators do allow the 64 bit address to be software driven, for example the Conbee and Raspbee. You can backup and restore across versions as well as between old and new hardware using deCONZ which is pretty cool. I went from a Raspbee to a Conbee II a while back which was seamless. Similarly I had a failed Conbee II stick after I managed to fry it, new one from Amazon and load the backup and everything was up and running again.

Interestingly the Nortek combo stick supposedly also allows a one-time re-burn of its' 64 bit address, so technically you could read the stick configuration and clone it to a new stick.

Thanks for the explanation. So a MAC address is a reasonable way to think of this.