Perhaps it is a group setup through Groups and Scenes? But appears as a different type of device on the remote hub? @YapFlapper ?
1 Like
Nice idea btw.... Were you referring to Groups and Scenes app? Or something else. I know for my Harmony Hub I only needed to set the parent device up in Hub Mesh, all the component / child devices came with it. Does a group behave the same way?
Yes using groups and scenes app on the source hub.. then the group device shared via hub mesh.
No for the other thing - the grouped devices stay local to the hub since there are no child devices to bring over. It's just a link to the group device on the source hub... I think.
I am not privy to the details of course but the behavior is consistent with my expectations..
1 Like
I once had 3 hubs, currently down do 2 seriously considering going up to 4.
My current Hubs are set up with one as as server, doing all the operations, and one for devices to live on. They are connected with hub mesh with no issues what so ever. If I add two more, one would be for cloud devices, the other would be for testing and development.
Optional use:
1 Like
I made the mistake of showing the picture you posted to my son. He laughed and then said "Oh, so you started that thread, right?" Asked him why he thought that and he pointed to:
"OK. I am an idiot..."
It's my fault, I raised him. 
4 Likes
I am sitting here laughing with you.. I am in the same boat. Bought a second hubitat with the sale. Now, I need to justify it. 
4 Likes
So I have 3 hubs here...
- Hub1 does all my security devices -- windows, doors and perimeter lights.
- Hub2 does all my non zwave/zigbee devices like echo speaks which I share via hub mesh between hub1 and hub3
- Hub3 does all my interior lights and other non security related lights/devices
I would buy another hub if it was ever $99 in the UK 
Then why upset the apple cart? Keep the second hub as a spare or use it for development if you get the urge to write some more advanced automations or drivers.
I got myself into a pickle a few weeks ago working on a driver that got caught up in an infinite loop and every few ms it wrote a log entry. It didn't take long to overwhelm the hub and bring it to its knees.
If I had a development hub, I would have simply pulled the plug and if it corrupted things, did a factory reset. Fortunately, I was lucky and the hub eventually responded to a reboot and no damage was done.
4 Likes
Three hubs here too. One is my prod region. The second is semi-prod (maybe we'll call it the acceptance region?) where I run a few things that are just nasty performers and I don't want them interfering with the primary hub. Maybe I'll eventually get them working smoothly and promote them to prod, or maybe I'll give up and shut them down. The third hub is definitely unit or integ, where I can play with things without breaking automations and taking a hit on WAF. Modifications in prod and acceptance require change control (WAF), whereas in unit I can do whatever I want. I do have hub protect on all three, not really sure why. Force of habit I guess.
2 Likes
In my experience I've found the "best" multi-hub setup to be "by location" followed by "by device type" (Zigbee/Z-Wave/Cloud).
If you keep your rules local to each hub and use hub mesh your setup becomes very resistant to complete failures.. with increased range, reduced overhead through a divided workload and the ability to update each hub independently. Downsides are potential RF interference if hubs are too close together.
Going "by device type" is a good way to keep like devices grouped and managed. Less likely for one system to take out the other. Downside is rules are more complicated as they need to be shared between the 2 hubs, possibly adding more overhead on one or the other. This system works well with a yet another HE hub or other centralized controller like Node-RED.
1 Like
