That's a whole lot of questions all combined in one paragraph.
Short answers is Yes it can do all the things you ask.
No it doesn't matter which hubs do what tasks you want.
Yes all hubs can be controlled through a single hub.
What intent you use each hub for is solely your own use case scenario:
You can run rules/apps individually on each hub And/OR on a server controlling all hubs, solely your choice.
For example there are some people heavily invested in zigbee bulbs that are not Sengleds which can make terrible repeaters, so having them on their own hub segregates your zigbee mesh away from your other zigbee devices.
I at one time used one hub for wifi/lan devices one hub for zigbee and one hub for zwave. but have since reconfigured it a bit differently and routinely try different configurations.
So it makes no difference which hub things are on? For example, whether Groups of bulbs are created on the same hub as the bulbs, or on a different hub? I thought that it might affect responsiveness, and if/how zigbee group messaging is used, etc.
I was just looking for any recommendations about the best way to lay everything out, so that I can do it that way from the start and not build it now and then bulid it again the right way later.
Correct. I have found that with using 3 hubs trying to do as much of the automation with the devices that are on say hub A having the automations on hub A. But if the automations require devices on a different hub than I will put those automations on the server hub.
The more localized you keep it when you can, the faster the automations will be. Although having the automations on the server doesn't have that much of a noticeable delay.
There really is no right/wrong answer to this. It's solely dependent on your environment/devices/needs.
Like say do you favor zigbee over zwave or no preference?
How much do you plan to expand long term?
Zwave meshes have a 4 hop maxiumum if using zwave how are you expanding and intend on placement of devices in your home.
Are you planning on developing any apps/drivers that you want to keep segregated from your everyday production hubs?
All of these are hypotheticals that only you can decide.
I once thought this as well, then get the brainstorm of trying something different to see if I like it better or not. Sometimes I did, sometimes no.
Two weird problems have arisen since installing the latest 1.5 updates:
Custom Devices being shared FROM a Remote Client to the Server will dissappear overnight - every night. I do have a restart of the socket scheduled each night on each client (at slightly different times). But custom devices FROM the Server remain intact.
I use a HubConnect switch (also linked with SmartThings) to indicate Routines - Good Morning!, Goodnight, etc. This morning, my automations failed because the RM Action that is supposed to turn on the Good Morning! switch didn't turn on the switch, even though it did run all of the other actions in the rule. I tried turning on the switch manually from the web browser, and nothing happened. I tried it from all 5 of my Hubitat hubs (Server and Remotes), and the same thing - the switch won't turn on. I finally tried from SmartThings, and viola! it worked - and the state is reflected to all my HE hubs. BUT - I still can't turn it on/off from any of my HE hubs...I've rebooted them, open/closed the HubConnect apps - nothing works...
You win the award for weird problems today! Are the actual devices disappearing from your server, or just the entries in the custom device configuration in HubConnect? I've not heard of that one before.. Can you run a TSR both before and after the devices disappear and PM it to me?
For #2, what is the driver you are using for the virtual switch? I would like to test with it. I just did a physical device and I could switch from any location (Server, Remote, & ST). I could also switch with a virtual switch too.
#1 - The (all of them) devices just drop out of the list of Custom Devices being synchronized to the Server on each of the Remote Hubs...the devices are still in the Servers' device list (and on the device lists of the other clients' that are being shared from the Server).
For #2, the original switch is a virtual switch on the SmartThings Remote Hub; the master Server uses the HubConnect Switch driver (which I haven't upgraded), and it then reflects the same switch to all 4 of the other Hubitat Remote Clients, which also use the HubConnect Switch driver.
I'm on the road most of today, but I'll try to capture before/after logs if you haven't fixed it by the time I get home this afternoon/evening (depending on traffic).
What's weird is that the virtual switch thing worked fine until I installed 1.5 - looking back at the event logs, it shows that the last time the switches worked was the day before I upgraded...
I wonder - if I change this to be a Hubitat Virtual Switch, and then connect it to all the Remote Clients (including SmartThings) will it work? A hassle, but not really a big deal...
I'll look at recording stuff around #1 a bit later today...
When a device on the secondary hub changes status, should that status update automatically to the primary hub?
If so, that's not what I'm seeing. When I turn bulbs on/off, attached to the child hub, the primary hub doesn't see the change unless I push the sync button in the device on the primary hub.
I attached zigbee bulbs to hub 2, and shared them to hub1.
From the web UI on hub 2, I turn off a bulb. Hub 1 still shows the bulb On. I click the refresh button on the bulb page in hub 1, and nothing changes. If I click the Sync button, the status updates to Off, and an additional line under Current States appears, showing "version: v1.2.1"
Next, from Hub1, I turned On the same bulb. The status on hub1 stayed Off, and no new events were listed for the bulb. On hub2, the bulb shows On, and the event turning the bulb on is listed.
So I can control the bulbs from either hub, but the status only seems to update on Hub2 unless I push the sync button for the device on hub 1.
So if I am breaking this down correctly, hub 1 is able to communicate with hub 2. You can control devices and use the Sync command to request an update from the physical device. Hub 2 is not able to send commands or events to hub 1 which is why commands issued on hub 2 and events from hub 2 are not making it to hub 1.
I would double check the server IP address setting on the remote hub to make sure it's correct. You can always run through the connection setup and re-paste the connection key into the client. It won't hurt anything if you do that again.
Please DM a technical support report so we can take a look at the settings.
This updates improved app cleanup to HubConnect Server, Instance, & Remote apps which will prevent Remote Hub Devices from being left behind and causing failures upon reinstallation.
I have added an uninstallation page for each app. Uninstalling HubConnect from the Server uninstall will remove all instances and virtual devices, completely removing HubConnect from the hub.
This release also fixes an issue on SmartThings where some drivers which require with no parameters were passed null arguments which would cause the device to ignore the command.
So mine was working for a while, but now I'm seeing this "Error: Instance in use by another hub" on one of my remote clients:
After some digging through the code (before I finished this post...), I figured out it was because I changed the name of my hub, and that's apparently what gets set and checked in state.clientMac and accessData.mac in the server instance app. I don't know how this is intended to work, but I assume it might be the MAC address as a unique identifier and not the hub name. All I know is I'm glad I got it working and I'm glad I didn't completely hose my installation for some unknown reason like I thought when I began writing this. In any case, just thought I'd point this out in case this is indeed a problem.
Thanks for the app, as always!
EDIT: In the meantime (or if this is as-designed), I recommend not changing the name of any hubs with HubConenct.
In any case, just thought I'd point this out in case this is indeed a problem.
