Second hub without second ZigBee/Z-Wave network?

🛎️ Get Help
1

Since the HE hub is on sale again, I'm thinking of getting a second one--mostly because I'm totally crazy, but also because I think it would be nice to test things on without disrupting my "primary" hub. I'm thinking testing custom apps, and maybe moving over things that might be more intensive (like webCoRE, and possibly Other Hub, MQTT Bridge, and HomeBridge apps, though I have no proof that the last three are problematic and even webCoRE is fine now--but what if my lighting automations were millseconds faster with fewer event subscriptions on the primary hub?).

However, I really don't want to set up a second ZigBee or Z-Wave network. What I'm thinking would be neat is to just use the second hub as a ZigBee repeater (and possibly Z-Wave, though I have enough of those around my house already and don't need any more; I doubt Hubitat officially supports being a secondary controller, if that's how this would work, as most hubs don't, but I don't know). Options I know for sure would work are:

  • not using the ZigBee/Z-Wave radios on the second hub at all (no stick? can I buy it that way? :slight_smile: ), doing everything on the second hub using the LAN-based Hub Link app; or
  • creating entirely separate ZigBee and/or Z-Wave networks on the second hub and likning as needed (but this is less desirable as I'd much rather either have nothing or create a stronger, Xiaomi-compatible ZigBee mesh for my existing network than create another--I really don't need three ZigBee networks in my house, plus lots of neighbors' Wi-Fi and my own).

I guess to make it act like I want, as a repeater without an additional network, it really boils down to:

  • Can the ZigBee stick on the second hub just be joined as a "device" to the first? (Z-Wave would be OK too, but I don't care as much). I understand this would prevent pairing devices directly to this hub; I do not care about that.

I know there are a few people here, at least, who have two (or more?) hubs, and I know staff who know how the product works often read this forum, so I'd appreciate any advice. I may also just stick with one hub like a normal person, but the thought of a second to experiment with is too tempting at this price...

2

I'd advise against.

I have two Hubitat hubs. I do not have them joined to the same ZWave network. (ZWave is my preferred protocol. Zigbee is disabled on my "first" hub. Zigbee and ZWave is enabled on my "second" hub. -- don't really want to use "primary" or "secondary" because those words are already misunderstood.)

It seems to me you're hoping that a second hub will magically offload tasks from the main hub. Won't happen. There is nothing in the ZWave spec to permit that. Hubitat, with Link to Hub/Hub Link offers a really slick way of doing this, BUT it does not offload the burden on the Radio Sticks.

I have a houseful of alternate HomeAutomation hubs. I have one that does have a ZWave stick joined to my first Hubitat hub's network. Therefore, I have BOTH of what you are describing. I have a "secondary" and I have a "second." My first and second Hubitat hubs are interconnected via Link to Hub/Hub Link (bidirectional.) I also have added Homebridge to the second, recently. (It's been on the first for a long time.) I used WebCoRE extensively on SmartThings, never used it on Hubitat... ever.

Therefore my experience is adjacent to your vision, but not exactly alike. Close enough though, that I don't feel I should withhold my advice.

The limiting resource, for my home, is the Radios. Zigbee or ZWave, there's just a limited number of packets per second (PpS) possible. It is nice to imagine that doubling the radios would increase the PpS, but at this time, can't happen.

Hubitat has great programmers and sure, they could detect that a command for Device X that is on the far end of Hub Link, COULD use this hub's radio in parallel, but nothing of that kind is possible today.

You (and I) would like a "Secondary" (proper case) but a ZWave secondary (lower case) is nothing like that. Nothing.

In fact, the word secondary in the ZWave spec is darn close to being synonymous with "useless." It receives a copy of the paired DB from the primary and never updates it. If you Include new devices the secondary will NOT be informed. It requires intervention at a layer above the Radio stick to cause the secondary controller to once again, ask the primary for the FULL DB. Which promptly begins to go out of date.

1 Like
3

Sure, we would sell you a hub with no stick for $74.95.

No. Hubitat doesn't support this.

4

Thanks to both for the answers! Good to know that the stick can't be joined as a "device" to an existing HE setup (just seemed like it would be an alternative to an XBee or an Iharyadi "environment sensor," two of few repeating devices known to play well with Xiaomi devices).

I wasn't really hoping it would be "magically faster"--aside from the webCoRE meltdown a couple months ago (and yes, I know I take the risk by using custom apps), my hub is usually pretty fast, but I'm still contemplating the idea of a second one to play with (and what if I did just use the first for lighting and other automations I want to be fast, and have others sent over the LAN to the other, which can have all the event subscriptions it wants, and I won't care of it's a few milliseconds slower).

I'm probably going overboard and don't really need this, but I can't say it isn't tempting. :slight_smile:

5

Go for it! I have two HE hubs, one for production and the other for development and testing. It has already saved me a few times from messing up the production hub. No more disruptions to the family, and it is nice to be able to test new firmware

1 Like
6

Exactly why I also have two hubs.
I do all my ‘playing’ on my test hub.

WAF take a serious dive if I mess up the ‘production’ hub

Andy

1 Like
7

Secondary hubs are super useful.

If your primary controller dies, another controller can become the primary controller even when if the primary goes away suddenly ( it can even re-key the network if needed ).

The network copy that occurs when a controller first joins? That copy can be extended by numerous methods. A well designed controller will ask for updates to the network every so often.

Also? If the controller receives a message from a node it doesn't know anything about it can easily add that node the moment it realizes that it exists ( with S1 security it can communicate with the node securely, because secondary controllers should request the S1 network key when joining the network ( FWIW Smartthings, Vera, and Z-way do this correctly )).

If a secondary controller does become primary without a shift?

It can easily probe its own network to determine what is attached ( and if you want it can change its node id to 1 ).

FWIW a "shift" is how one primary makes a secondary controller the primary ( in a clean manner ).

Secondary controllers can also be of value if they are a part of a platform that has applications that another platform lacks.

If you worried about a secondary controller adding more overhead to the network, you can always have it not associate itself with all of the devices on the network. Associations are a "need to know" relationship.

While SmartThings doesn't advertise its hub as a viable secondary controller, it does. Any hub that is faithfully, or even semi-faithfully, executing the z-wave standard will.

8

So all the cool kids now have at least 3 hubs.. True aesthetes go with 4 or 5.

The madness never ends. :crazy_face:

2 Likes
9

You aren't talking about the same thing. :smiley:

My first Hubitat was joined to my single StaplesConnect/OpenRemote/Smartthings/Wink ZWave Network as a secondary controller, in March of 2018. My purpose for each of those hubs or controllers was to eliminate all the others. Only Hubitat has been able to accomplish that and allow me to power off all the others. In June 2018 I factory reset my Hubitat hub and did a standard migration of my devices.

In other words, I know both sides of the ZWave Secondary Controller myth. :smiley:

Hubitat, Iris, Wink, SmartThings.. none have a backup/replacement/redundancy option. Vera seems to, (but because I don't have one, I don't know that as fact.) HomeSeer has OZWCP 'integrated' and it's low level commands can cause a 'shift' but to do it fully is a multistep affair and see only a tiny few indicating success.

The reason?? It's not part of the Spec. Nothing in the ZWave spec even has a 'glancing blow' on the idea of a redundant/replacement/backup controller. The Spec does cover the low level commands that can be stitched together into a replacement option. (Vera's method.)

It's common, in fact certain, that a completely new ZWave network will have the primary controller use Node 1. So common in fact that some devices have made the mistake of hard coding node 1 as the controller. The result is that above an beyond just getting the ZWave DB off the 'stick' and onto another, is the need to somehow get that new 'stick' to use node 1.

For those of us using Hubitat as their primary hub, the ability to 'interconnect' the hubs and save and restore Hub DB backups is extraordinary. Nothing has solved the 'dead zwave controller chip' problem within Hubitat's universe, yet, there are things that can be done to mitigate, albeit via a convoluted process.

We each could purchase an Aeon ZStick and using the Zensys Tools, cause the existing primary controller inside Hubitat to be copied. Then, using Aeon's ZStick backup/restore software, copy that for safe keeping.

Should disaster strike, the Aeon ZStick could be 'edited' to have Node 1 deleted and to be the next node number. Joining your brand new Hubitat replacement hub to the ZStick would cause it to be a secondary BUT at node 1. Then the steps to cause a controller shift would be able to get the new hub ready for a restore of the DB from the dead hub, with all the devices known to both the internal ZWave controller chip and the Hubitat DB.

All Theoretical at this point, however, :frowning:

When I think about this situation, focusing on murphy's law that predicts the failure will occur only when I have zero time to go through a replacement cycle. I think... I should get a several more Hubs and reduce each Hub's influence to just a handful of devices. If I put only 20 devices on each hub, I'd only have to migrate 20 devices on a failure :smiley: Brilliant huh? I'm calling it the "Thousand Dollar Backup Technique"

TL:DR
@brian1 Hubitat has none of the 'features' you mention, exposed.
@erktrek brian's message has nothing to do with multiple hubs interconnected. It's great instruction on 'what could be' but right now, we have none of it available directly and the indirect method (OZWCP or Zensys Tools) is painful.

3 Likes
10

I know but couldn't help myself! :wink:

The distributed hub configuration IS very useful though. Not to provide protocol/device redundancy/backup but to help with device & network stability and reliability and in the case of 1 controller + 2+ client setup also help isolate cloud connected apps/devices. Also should help with upgrading/replacing hubs too.. less devices to migrate.

11

@csteele
I have sucessfully ‘cloned’ my z-wave stick using the aeon backup/restore tools.
No need to ‘join’ the stick to the z-wave network.
With a C4 hub it is possible to backup the stick and restore it to another.
Swapping the sticks over once shut down.
Upon reboot, Hubitat does not seems to know the difference (as the cloned stick also thinks it’s node1)
In fact, my z-wave hub has regularly had it’s stick ‘swapped over’

Andy

2 Likes
12

Yes, that's perfect.. but for C-5 and users of the Nortec Stick, one has to first get the DB onto an Aeon. UK, OZ and other regions had the C-4 come with Aeon... saving a mighty big step :smiley:

13

@csteele Could you please outline what you did. I have OZWCP running with an Aeon stick. I see all the devices connected to the HE hub. This almost seems like it would be possible to "back up" the HE hub. Yesterday I did run an include on HE and the Aeon stick was picked up as a Zwave device. I have since excluded the Aeon stick from HE.
Added:
I can see current states of devices and read power readings on my Aeon HEM and smart energy switch.

14

I have yet to ever find a device that does this. I have seen platform software that made this mistake, but I have never seen a device that did this. ( I know that HAS had this bit of dogma in its documentation at one point, but they have since removed it; I believe it was based on a misunderstanding about how GE switches provide instant status by way of how they broadcast their NIF ).

There is a set of rules which determine which controller is the primary controller, and you do not need zensys to invoke the rules ( I have never used Zensys to do this ). Z-way has an expert interface where you just select one option to shift the network. SmartThings has an option on the utility page in graph ( I can't remember which of the options are overloaded). Harmony's hub has option in its app. Vera is the same.

The ZWave spec certainly does highlight backup/replacement/redundancy. It has more detail on replacement than the other two; how a new SUC can be added, and how it can become a SIS is very well documented. I am not sure why you don't believe that this wasn't a thought out process. In S1 there is even a path for one controller to take over responsibility for the Network Key. Leviton had a public document for installers at one point which was better at describing this than the standard itself.

How backup is done is documented, and a number of controllers do support this ( look at the serial protocol for a hint ).

Aeon's ZStick supports backup, you can make a backup and restore it to another ZStick. Aeon provides an application to do this, so there is no need to use Zensys. The Razberry and Z-way UZB both have apps which can do a backup.

Redundancy is weak, though all of the tools are there. It would be vendor specific since it would need to integrate with the specific Platform. Replacement works well enough; I don't think any consumer wants to pay for a NonStop like solution.

Yes, Hubitat has a problem with almost all of this. There is a flaw/bug in Hubitat's platform implementation where it doesn't handle devices that it discovers on the network. It will accept messages, but it won't allow any responses ( unless,... it is a GE NIF broadcast, their sniffer code seems is set to react regardless if it sees one of these ).

FWIW Z-way's expert interface allows you to pivot SUC/SIS to any node ( the expert interface is open source, and it is the basis for at least one of the Z-wave installer products ). I have a memory that OZWCP can do this as well, but I hacked the code up a lot the last time I tried to make it work.

Silicon Lab's PC Controller should be able to do this as well ( it is the modern version of Zensys ).

If Hubitat did allow you to pass along any Z-wave commands to the Z-wave network, then it should be pretty simple to write an app to do Shifts and pivot SUC/SIS.

Because the Z-wave spec was not made public for most of its life, a lot of misunderstanding has evolved into dogma.

FWIW the reason a controller is node id 1 is because it is the first node to enter into a network, so it is assigned the value 1; node id are handed out sequentially ( and eventually node id will wrap and begin assigning from open numbers starting at 1 ). One exception to this is that a device can be added to replace an existing node, in this case it will use the node if of the device it is replacing. There is also an exception where you can add a Virtual Node at a specific node id.

15

You'll find it odd that I agree. :smiley:

However, as a Hubitat user, I wish I did not have to know or care about what the Series 200/300/500 chips do. I wish I never have to run OZWCP or Zensys Tools. I wish I had chosen to get a Z-way and saved myself the trouble of those tools.

As a Hubitat user, I want an ability to migrate MY HUB (which by design contains a ZWave chip, that I wish I didn't need to know about) from a dead hub to a living hub in 30 mins.

All the underlying ZWave chip stuff I touch on tangentially in my desire to 1) highlight that Hubitat hasn't offered anything, yet. 2) that there is a cruel way to give yourself a backup of the ZWave chip's DB, and 3) to differentiate the rather new use of multiple hubs, to gain a performance improvement, while 'accidentally' easing the "Our House is dead because the Hub died" drama.

I didn't fully read your post, but I can tell from the parts I did read, that I 100% agree. It could be I was just imagining I was trying to say something similar but give it to you that you said it better... or at least shorter! :slight_smile: