I had a cold soldier joint knock my HE off line. Easy fix. It did point out the necessity of keeping a good backup. How usefull is that backup? I have 2 hubs, one has been running the house for quite a while, and rather nicely. The others main purpose has been to just re-boot the main hub, if required. (:8081) Feeling frisky tonite, I loaded the main hubs backup on to the backup hub. Seems to be an exact copy, just nothing works, due to no devices. I had expected that the devices and the referances in RM would have been lost, it seems that they are there, as if the radios where disconnected. (both C4 hubs)
Have I missed the point of hubconnect? can I clone the devices, and use the second hub for experimentation (with RM primarily) and then just move the backup to the primary hub? That seems to sweet. How would they interact if both where live and interacting with the same devices? To good to me true.
Is this an easy way to split the load of the first hub? leave half the rules on the first, and half the rules on the second?
So many questions, I think I will stop here.
Each hub has 3 major portions... the platform OS; the DB that represents YOUR specific hub configuration; the radios and their DB of devices they know about.
A Backup is exclusively your DB and thus the specifics of your hub, your devices, your apps and how those are configured, including RM apps, which we usually call Rules.
Restoring a backup from one hub to another (assuming the Platform version is the same) does exactly what you found. your specific hub is replicated. You also saw how the device know to the Radios did not show up.
HubConnect attempts to solve problems you may not have. HubConnect "mirrors devices" -- it allows a hub with "real devices" to have those devices appear (as virtual) devices on a second hub. Changes made on either hub reflect onto the other. Thus Rules can be run on either/both hubs that each affect a single device. You can have a Rule on one hub that turns on a light at sunset and off at sunrise.. then have a Rule on another hub turn the light off at bedtime and again at 4am. Is that a solution to a problem you have?? I doubt it.
Can you have all your Real devices on one hub along with all the Rules implementing cause-and-effect (Motion causes a Light to go on.) The device can then be 'mirrored' to another hub where Dashboard is running. Or where Homebridge is running. Both apps usually need "everything" selected and displayed. Is that a solution to a problem you have?? More likely
That was exactly the answer I was looking for. The "more likely" solution.
Now on to load shedding, I have found I can kill this poor thing with kindness!
And time for more HE's!
Thank you for a great APP.
Thank you for the help with the logic puzzle I had.
"more likely" I am missing something...
How do the changes made on the client hub, like adding a device, or changing its catagory get reflected on the server hub? Device level changes. Aeon Smart Switch 6 stuck in the power meter catagory, no switch component. change it to "switch" and nothing changes on the coordinator hub. Most of the devices from the client hub (the one with radios, original) show as two of the same name, the second is the HubConnect virtual device. I started by restoring the original hub on to the communicator, then installed HubConnect on both per the instructions. Now trying to split the rules. Trying to figure out how to use the mirrored devices.
First, we have to agree on names of the various pages that define the list of devices that are selected. When you click the "Select Devices to Synchronize to the Server", you end up on a page of "Sensors", "Shackrat Drivers", etc. On that page, at the bottom is:
-= Required Drivers =-
Please make sure the following native drivers are installed on the Coordinator (master) hub before clicking "Done":
So... let's call that page the "Required Drivers" page, ok?
If you then click one of the category buttons, say "Switches, Dimmers, & Fans", the page full of selections are available.
When you click Done, you go back to the "Required Drivers" page. If you ignore the instructions and click Done again, you get to the main HubConnect Remote Client page.
If you click Done there, HubConnect re-sends the entire list of selected devices to the Server. The server goes through the entire list and creates virtuals for any that do not exist. Therefore, if you change the category, thus changing the driver, you must correct that. You can simply delete the virtual on Server and then cause the entire list to be sent again. A new virtual, using whatever driver you selected, would be created. You can also simply change the driver on the Device Info page to match the choice you altered on the Remote.
To resend the list, you must dive down to the selector page, click Done, (verify you've got the drivers installed) and then Done out to the Apps list. Total of 3 Dones.
HubConnect "mirrors devices" -- it allows a hub with "real devices" to have those devices appear (as virtual) devices on a second hub. Changes made on either hub reflect onto the other. Thus Rules can be run on either/both hubs that each affect a single device. You can have a Rule on one hub that turns on a light at sunset and off at sunrise.. then have a Rule on another hub turn the light off at bedtime and again at 4am. Is that a solution to a problem you have?? I doubt it. 
