No problem! It was much easier than this will make it out to be, mostly because I'm more than a bit OCD.
I had hub mesh installed, configured, and tested on both hubs before I started. Hint: I got lazy and just enabled EVERY device for hub mesh. More than 500. Big mistake. I suggest you be more judicious than I and mesh only those devices you need.
I decided that any of the rules I have that interact extensively with Envisalink would also move to hub 2. HSM also needs to move to hub 2, which is a bit of a pain since HSM does NOT synchronize with hub mesh.
Before I started, I made a backup of hub 1 and stored it locally. Just in case. And then I made a second backup to the cloud. Just in case. I did mention that OCD thing, right?
I looked at the child devices that Envisalink creates, and I identified every rule I had that interacted with either the Envisalink device itself or any of the child devices. That was easy for drivers because I could go to the driver page and get a list. I took screenshots of everything. Just in case.
I looked at all my rules interacting with HSM - because you need to move that too. I was fortunate because my rule naming convention starts any rule that interacts with hsm by naming it "HSM - whatever."
Then I installed a second instance of envisalink on the 2nd hub, along with HSM.
I briefly shut down envisalink and hsm on my primary hub so I could configure it all on my secondary hub. You can't have more than one hub connected to envisalink at a time. Once I got all the virtual devices configured on hub 2 I used hub mesh to get them all to appear on hub 1, and I re-enabled everything on hub 1, so it would stay up and running while I messed around with hub 2. Each time I flipped the active envisalink connection from one hub to another I ended up having to reboot the hubs.
I took any devices native to hub 1 that either envisalink needed to talk to or HSM needed to talk to and used hub mesh to sync them to hub 2. This included lights, water sensors, extra keypads, more sirens, the works. Once they were available via hub mesh on hub 2, I reconfigured HSM manually. Since I still had it all working on hub 1 I could just open two browser windows side by side and mirror the configuration.
Once the configurations looked the same, I disabled envisalink and HSM on hub 1, rebooted, activated everything on hub 2, rebooted. That gave me a disabled installation on hub 1 that I could revert to if I really f*ed it up, and an active installation on hub 2 that I could test. I called my alarm company and told them to put me in "test" mode until I called them back - so if I screwed up at least the police didn't show up at my doorstep. I did as much testing of basic functionality as I could, making sure I could arm and disarm via HSM and it would arm and disarm the panel, then I did the reverse - armed and disarmed the panel and made sure it all mirrored on HSM. I then went through each Envisalink child device on hub 2 and verified functionality by walking around the house, triggering each sensor, and checking the hub to ensure the events registered.
Once all that was done (and it looks more complex than it was) I cloned each of the rules that interacted with HSM or Envisalink from hub 1, and I did an import on hub 2. When you import a rule it prompts you device by device for the replacement device. In other words, if I had a contact sensor called FRONT DOOR on hub 1, when I did the import it says "what contact sensor would you like to use in place of FRONT DOOR," and I just chose the equivalent sensor on hub 2. Likewise, if I had a rule from hub 1 that used a device that was still on hub 1 but meshed to hub 2, I would select the meshed instance on hub 2. I did that for each of my rules. As I cloned them, I disabled them on hub 1 BUT DIDNT DELETE ANY OF THEM.
Of course, any dashboard tile on hub 1 that pointed to an HSM device or an Envisalink device also broke, so I had to go through and add the new meshed devices to the dashboard and then modify any tiles. I kept all the dashboards on hub 1 though.
Once I was done with all that I created two variables on hub 2, one called "envisalink_status" and another called "hsm_status." I created rules that updated them any time either the evisalink stats or HSM status changed. I used hub mesh to mirror those to hub 1. There really was no reason to do this with the envisalink status since it could be mirrored with hub mesh, but there is no equivalent way with HSM. I figured if I ever wanted to have a rule on hub 1 check the status of HSM on hub 2 the variable was the way to do it.
Finally, I created three virtual switches on hub 1 called "arm home," "arm away," and "disarm." I meshed those over to hub 2 and then created rules that would arm or disarm HSM on hub 2. That allowed me to have rules on hub 1 that would manipulate HSM on hub 2. I could conceivably have done it all with the meshed envisalink driver but I figured this was easier.
Once I had tested everything for a couple of weeks I deleted the envisalink driver on hub 1, along with all the HSM rules and HSM itself.
Whew. I THINK that's it. I made it sound much worse than it was. The nice part about my process is that I did it in stages, testing at each stage before proceeding to the next. It took a few hours over a couple of days but it really isn't that big a deal. Feel free to ask questions. I'm sure you'll have some after wading through my essay.
And yes, my primary hub seems to be running better!
And yes I did buy a third hub as a spare. Technically a fourth but that's another story.
