It is already possible for Hubitat with z-wave (even S2-paired device). And for other zigbee coordinators.
It comes down to how secure the radio database back up is. And off course since both z-wave and zigbee are low power protocols, they are proximity limited.
That is what I am thinking that you would have to be in the building on the network and take the original hub off the air to make the devices flip over. So if there was a special hub that could forcibly take the broken unit off air then it could have a new hub placed on air. It could coordinate this handoff and how it would work our the handoff.
Or even having both hubs on the same LAN they could exchange the link connection but if you made them have to fit inside of a special piece of hardware or even register them with Hubitat that could help secure the radio handoff?
Again I am just bringing this up as a way to bring redundancy to these type of things...
I LOVE THIS!
Please make this work! I had it going with two macs running Indigodomo, so one unit's rules were ALWAYS predicated on the other unit being down (ie: not answering packet calls on the network) then it would take over.
Easy when you can pair the computers to a NETWORK zwave switch. Cos the network zawve just talks IP. But there aren't many of those out there.
That is interesting to think if they were to make it somehow act like a network zwave hub.
I was thinking if this is possible to make a virtual hub and then this virtual hub can be hosted by either C7 at any moment. Just something needs to sync both of them so that both aren't on air at the same time. Also something needs to keep them in sync with software and rules and all that. If one vendor owns all the hubs and has all the redundancy that is huge.
If there was like a multi-hub dock where you drop 2 C7's in and they fit in half way or something and that passes through power. You wouldn't want the same power to both because then you have a single point of failure again. Also you don't want a single network interface you want them to pass through each. But this dock could authenticate both.
Better yet make a dock that is the sync device that connects via z-wave, zigbee, and ethernet. Or better yet wifi/bluetooth and run on batteries. That way if there is a power surge or network surge the device is isolated. Can't get hit by lightning or anything like that too. Then it can verify that it local and can see and monitor all the radios. It can report status back to both units and be the controller of controllers.
All that engineering and (shudder) testing to sell more $150 boxes? I kind of remember block diagrams of Matter hubs coordinating so maybe it's builtin there. More likely to happen there too.
Cool Idea, but I wonder How did we get this far in the conversation and no one has brought up how the drivers and apps are going to maintain/synchronize state and other internal data in realtime?
Hot spare controller/radios is one thing, but a functional system in this setup probably needs the apps and driver code to work correctly too.... it maybe possible, but could be a can of worms, quickly, I think.
I do this with main wifi private ip router both configured identically. But found you also need to reboot all switches because they wont route packets correctly if the mac of the default gw changes.
I.have an at&t access pt with kasa switches behind both routers and any network switches and can swap over remotely.
I also have something similar with my primary public ip router .. i can turn off the primary one and enable secondary .
Ie
Yeah that is kinda what I am thinking of is if there is a second hub completely configured and running identical to the first hub and if the first one goes offline then disable the power to it and enable radio on hub 2.
There would need to be some sort of network monitor device that would sync with both hubs but it would just need a zwave and zigbee client. Then when that device sees something break it would signal the change to take place. If hub 1 is dead then just cut the power to it, if it is on but radios aren't working then tell it to radio down. Wait a minute or two and then tell hub 2 to radio up in cloned state.
If both hubs are running the same apps, same software, same everything then it could just take over seamlessly except for the 1 minute waiting period. While the hub 1 is trying to recover or factory reset then sync again. If it came radio up after factory reset it wouldn't matter because the entire network is running on the cloned network IDs.
After hub 1 either comes back or gets replaced then it can join the network again and be the secondary and just leave hub 2 as primary. Or alert the user and say hey this hub went down but it is now back up do you want to switch back over? If you do then there will be a 1 minute outage and let it do the reverse switch back.
Just an idea I don't know how possible this is but it would be very nice to have redundancy built into the system.
It would be nice.
Not to be negative but I highly doubt they're going to put in the engineering effort required to do that on a $149 hub though. But I could be wrong.
I would fully expect to be able to restore a backup, including radios, to a future version of The hub with different hardware though. So while that's not quite as good as a hot backup, it would be very minimal down time.
Same. For me, it would be icing on the cake if the MAC address of the network interface could be rewritten to be the MAC address of the old (non-functioning) hub. Then I wouldn't have to spend the time to reconfigure my DHCP server ..... and it would be a genuine drop-in replacement.
Glad to see this topic get some further mulling. Brought it up some time ago and got a lot of the same responses. It seems folk worked it a bit more here and proposed some ideas that would be nice compromises for an "almost hot swap".
I get that the boundaries of the standards & specs the industry is working within might not have been thought out as deeply in respect to reliability, resilience, and redundancy. But the standing suggestion that Home Automation is still hobby, not critical application or security worthy seems to be prime for being put to rest in the next rendition.
People are wishing for, expecting, and in fact trying ALL sorts of stuff that in my mind is CRITICAL (especially when it fails to be monitored and/or controlled).
It would be great to see HE find a way to bridge the gaps in a ways that allowed it to claim a superior product in this regard while we wait for the standards to evolve.
Lastly -
Again, I'll say that it is absurd for us to integrate a hub into our homes to monitor and control ALL sorts of stuff (beyond the lights), and not think that should be worthy of $200+. I'm not saying $200 worth of junk that dies in 18 months, I'm saying $200 worth of all the things that folks keep saying "they're not going to put that in this platform at the current price". For crying out loud, what are we spending on GOOD routers, switches, IP cameras, phones, ETC.
EDIT: Would I have two or three hubs at this price? No. But then maybe I wouldn't have to. OR maybe there would be a master at one price and slave at a lower price to deal with those remote or segregation requirements.
The emphasis with HE has always been for "home automation" and not for handling "critical systems". I know it gets a little fuzzy when including HSM but in general this thinking indicates that a hot failover capability even if easily doable would likely still be very low on the priority list.
However if planning on keeping HE for the long term you should probably have an additional activated but offline hub on hand regardless. Also recommend power backups (UPS) for the hub and network and maybe even a good redundant internet connection.
edit: AND a whole home surge protector installed as well.
I am with you all on this for the protect the hub but things will happen and the hub could lock up software wise or eventually someday it will just die. To me having things monitored and managed and having some way to have a second hub to keep an eye on it just makes sense.
I get the standard wasn't written to do this but it seems like it could be done especially if one vendor were to manage both hubs. Even having like a Hubitat Pro hub or something that would let it have this ability.
I have my hub powered using a PoE splitter which powers from my switch which is powered through a UPS. So it is protected power wise but eventually someday this thing will bite the dust and it would be nice to have some sort of backup plan in place before that happens. The backup plan now is to get a new hub and copy over to it but you have to have a cold spare on hand to copy to it. It would be nice to just have it automatically there.
I have to assume (heh) that this feature would be appealing for those who have whole house backup generators - a few hours of hub downtime doesn't matter if you can't automate the important things.
Hummmm,
As I naively ponder this.... being one of the fundamental hurdles to having a hot-swap or fail-over capability between two Hubs.
Yeah, of course we'd need 3rd Party/Zigbee adoption but is this not proof-of-concept on some level?
DO NOT LET THIS DERAIL THIS THREAD....just pointing this out.
Not sure I’m following. What’s the relationship between that thread and this one?
If you have a zigbee-only hub and flash the zigbee radio of a spare hub with the IEEE address of the original hub, you can possibly run both simultaneously (simply turning on the zigbee radio of the hot spare when the original dies).
After looking at Matter/Thread a little bit recently, it does appear that Thread 'might' solve this issue as well. It appears that Thread devices are joined to a Thread Mesh network, not to a single Thread 'hub' per se. A Thread network can have multiple Thread Border Routers, which will connect the Thread Mesh devices to a TCP/IP network. Thus, it appears that the multiple Border Routers must use some form of election process to determine which of them will perform the different roles.
TLDR: This page somewhat pertinent to the discussion about the future of redundancy in Home Automation networks...
At least it appears that the Matter/Thread team has thought about it and has designed things to eliminate single points of failure, where practical/feasible.
I suppose each "border" router can be thought of as being an IP gateway. And as it is possible to have multiple gateways for an IP network (or sub-network), making it somewhat easier to port that concept to Thread.
That is kind of what I was getting at when I originally thought of this. Is that this could sort of sit there and be ready to take over but not active. Then just a MAC address change and bam it is online. If one vendor controls it all then even better and I mean I would pay for backup service so I don't have to mess with it. I am sure most of us would when you have a mega big network of stuff setup it is a pain when something goes down or changes.
There is the whole downtime factor but also the reliability factor but the Hubitat has been pretty solid. Eventually it will fail it is a machine it will break.
Just to have something or have some sort of way to clone the original network then move the controller to a new device and boom you are back.
Download the Hubitat app
