...say for large projects, and your current hub is barely able to handle your setup and you need to make thing more stable?
Can I use a second hub and make it act like a slave to the main hub? Meaning, I don't want to have 2 completely separate systems.
For my current situation, my current project has lights, switches, motion and vibration sensors, smoke detectors, several sirens and all that.
So I figured, I can offload some stuff to a 2ndary hub.
I was thinking of dedicating a 2nd hub just for the security and fire alarm sensors as these are very mission critical. But my sirens and some panic buttons are on the main hub and i can't transfer em. Also on the main hub are RULES and CONDITIONS that also relates to the security sensors.. and these things i can't move to the 2nd hub for personal reasons.
So yah, how can 2 hubs be elegantly combined to work as one? Hopefully have 1 dash board for all too!
Oh and not to mention, the 2nd hub must also be able to take advantage of the main hub's established and stable mesh network already! (I can't create another repeater network for the 2nd hub specially since most of the devices on the latter are battery powered and therefore non-repeating)
You can't spread a mesh network across two hubs; each will have its own. You can share devices and select other events (e.g., mode changes) from one hub to another using Hub Mesh or similar solutions:
You will need the device -- whether directly added or shared via Hub Mesh -- on the hub where the automation resides, of course (a hub can't use a device it doesn't know about). In your case, this may mean moving some of your automations to your new hub. In many cases, this may mean doing so manually. In others, you might be able to export the app on one hub, import it on the other, and remove it from the original hub if that is successful (for simple apps, this effort may not be worth it).
But it might be worth looking into why one hub isn't working for you now. What model do you have, and what model are you considering getting? If you have a C-8 or older hub, a C-8 Pro has beefier specs and might be fine on its own if it's not a mesh network problem. If you are dealing with that kind of problem, what kind of troubleshooting have you tried? It may come back no matter what hub (or possibly combination of hubs) you use if you don't.
All of what you describe is not just doable, but ordinary to do via Hub Mesh. With one exception:
That part isn't possible IF I am interpreting those words as you intend... You will have to setup the second hub individually, there's no "remote control" of the hub from one to the other. If you put a siren on hub 2 and it dies, you will have to replace it from hub 2. To be clear I'm going to say, Hubitat hubs make a distinction between Administration and Use. As an administrator, you can, via Hub Mesh, share devices as if by magic. From a use viewpoint, you can't really tell which hub is doing the work. However, all of that gets setup as an Administrator, each portion on each hub.
But you're mostly describing, in your wish list, Use type functions and all of that is doable.
I have 3 active hubs. One has all my standard Z-Wave and Zigbee devices. The other has all non-standard devices (ex.: problematic or spammy Zigbee devices from Aquara, Tasmota devices, etc.). Finally, the 3rd hub has all my Automations, integrations to Hue and Lutron as well as to the other 2 hub, so it has all devices.
This setup has been working very well for me with over 700 devices (including virtual devices) shared between the 3 hubs, and over 900 apps/rules on the 3rd hub (C-8 Pro).
I am a very active hobbyist… I have automated pretty much everything in our home that it made sense to automate, while setting things up in a way to be as practical as possible for all. We are 5 living in this home and have not had too many complaints. (When I do, they get resolved quickly…)
I have lots of small automations rather than few complexe ones, so that likely ups the number of apps & rules.
Amazing.. it's nice to see someone actually done it haha
so your rules on the 3rd hub has not issues getting triggered or sending commands from/to devices on the other hubs?
I'm trying to understand how does your, say, motion sensor on hub 1, triggers you rule on hub 3? How do you add the trigger in those rules? or do you have to deal w/ triggers over http links/api?
Likewise, how can a rule on hub 3 control a light on hub 1?
Here is an example using three hubs. Hub 1 has the sensor, Hub 2 has the light, and Hub 3 has the rule. Sensor fires on Hub 1, and since it is meshed to hub 3, it can send a message via ethernet that it has fired. Hub 3 sees it has a rule to activate the light on Hub 2, as Hub 2 has its light meshed to Hub 3 also.
You begin by setting up the Hubs to permit the sharing of "real" devices. Hub Mesh is that tool. You enable it on all of your Hubs and that allows you to pick what is shared to where. After setting up Hub Mesh, NOTHING is shared. You have to permit a device to be shared. Let's imagine you have a wall switch on Hub 2. On Hub 2, because that's where the real device is already working, you permit it to be shared. At that moment, all the other hubs know about the device but ignore it. It's just in a list of potential devices. On Hub 3, you accept the device from Hub 2 and from that moment on, Hub 2 considers it exactly the same as any real device. Then, on Hub 1 you permit the motion sensor to be shared. It is instantly known to all the other hubs. Again on Hub 3 you accept the device. Now you can create a Rule that watches the Motion sensor and controls the wall switch.
In this example, Hub 1 allows 1 device (motion) to be shared. Hub 2 has 1 device (switch) shared. Hub 3 has zero devices shared but it accepted two shared devices.
Even with a single hub you can mimic the behavior. Create a virtual switch and create another virtual motion sensor. Now create a Rule that watches the virtual motion sensor and controls the virtual switch. That's it. All Hub Mesh does is implement the creation of virtual devices as needed and then transfers Events between the hubs to keep the virtual devices matching their real counterparts.
