And now have a second device online, Other Hub installed and synced to ST, switches working through ST and HE. Woohoo!
1 Like
When I switched from ST to HE last week, I did almost all of my exclusions with ST in one window of my browser, while HE added in another window. Not simultaneously of course.
I'm trying to do a very controlled migration. Initially, I want to move all of the devices to HE, while leaving the automations running on ST hub, using Other Hub as the intermediary. After the physical devices are moved over, I will start moving automations from webCoRE on ST to Rule Machine on HE.
My process looks like this:
- Create temporary virtual device in ST for each device I am moving
- Replace physical device with temporary virtual device to act as a placeholder in the various automations
- Exclude device from ST
- Include device in HE
- Add devices to OtherHub in HE, and let OH create the associated virtual devices on ST
- Replace temporary virtual device placeholders with OH virtual devices in ST automations
- Remove temporary virtual devices from ST
I completed my first phase a few minutes ago, which is 11 of my 49 zwave mains-powered devices. They are evenly spread around my house. Two goals here: begin to create a new HE mesh with no blind spots or gaps, while leaving enough coverage in the old ST mesh to keep from causing problems.
Working on mapping out my second phase and deciding which devices to move.
2 Likes
I'm very interested in numbers 2, 6, and 7 in your plan @destructure00. Are you aware of a procedure to "remap" virtual devices to real ones?
I too want to proceed this way with my own migration. I am deep in learning how HE automation works using virtual counterparts. Once I have confidence in some basic functionality, I want to switch over to the real devices but I do not want to lose any of the work I already did either with regards to automation or dashboards.
Any suggestions or a documented procedure please share! This is encouraging!
Thanks
–Richard
I'm doing it all manually unfortunately. Takes a lot of time. I spent all evening migrating about 20 devices. Still have about 55 to go. Then tackle automation and virtual/cloud devices.
Is step 2 the virtual device just so you don't forget what automatons the original device was in? It seems like extra steps to create temp virt device so I'm assuming it's helping somewhere?
I'm about to do this so I'm watching anyone's posts about their process.
Also how is everyone handling the devices that are not now NEAR the hub. AKA I have some door locks that were easy to include to ST because they weren't installed when I included them...now they are installed on doors that aren't near the hub. Are you guys removing stuff like this and bringing it in near the hub? Taking the hub to the device?
Yes, that's the only reason for the temporary virtual devices. Personal preference for me to do it that way. It creates a lot more work but I'm really trying to keep my existing automations intact and functioning correctly in ST until I can redo them in HE/RM. Other than me being engrossed in what I was doing, my wife didn't notice any difference in our house last night, so that's a win 
Regarding the devices that are far away,...I made a drawing of my house and mapped out the locations of all the devices in the mesh, both mains (repeaters) and battery powered. Mapping out helped me to create a plan on how to remove certain devices from the ST mesh in a way that will keep it functional, while beginning to create a HE mesh that has enough coverage to reach all areas of the house. I found that I have clusters of switches, sometimes 5 or 6 within a few feet of each other. I figured in these cases I can easily remove 2 or 3 to start building the HE mesh without really affected the ST mesh strength. Picture is worth 1000 words, right? Hopefully you can interpret my chicken scratch.
In the pic below, the numbered devices are mains powered and the letters are battery powered. The star is my hub location. The black dots are mains powered devices that I have migrated already, and the X's are battery devices that I have moved. The idea is to create enough of a HE mesh that I can have repeaters ready to reach the farthest places, so I can migrate in place. We will see how well the plan works when I get to the back yard devices 
I also have a spreadsheet that shows all my devices, which phase I'm migrating in (based on my hand drawn map), and which steps in the migration process I've completed. Helps me do groups and keep track of where I am in the process.
ST Rename XX: When I start a new phase, I rename devices in ST that are going to be migrated, adding XX to the front. The idea here is that the old devices that will be removed from ST have a XX prefix, the temp placeholder devices I create will have a YY prefix, and the virtual devices that Other Hub creates will have a ZZ prefix.
ST Create YY: Create the temporary placeholder virtual devices with YY prefix
WC add YY: Add YY devices to webCoRE
ST XX -> YY: Replace XX devices with YY in all automations in ST
WC del XX: Remove XX devices from webCoRE
ST Excl XX: Exclude XX devices from ST
HE Incl: Include devices to HE
HE Name: Set Device Name and Device Label the same (for logging purposes)
HE OH: Add new devices to Other Hub in HE
ST WC: Add the ZZ devices that Other Hub created in ST to webCoRE
ST YY -> ZZ: Replace YY devices with ZZ devices in all ST automations
WC del YY: Remove YY devices from webCoRE in ST
ST del YY: Remove YY devices from ST
1 Like
If I could only get my employees to be as thorough with a plan at work.... 
Yep...that's a process...so I think answering one of my questions. You aren't moving devices closer to the new HE hub to include them. You are slowly building out the mesh and using that to add devices. Which I thought was a no-no. So that will make migration a bit easier.
My original thought was to just go into ST either IDE or APP and record each devices automations since it shows webcore pistons in there also. Then exclude the device from ST and add it into HE and then Other hub. Recreate, etc. But I like your plan and I'm absolutely going to do the MAP. That makes a lot of sense and I think I'll tag differently for Zwave/Zigbee.
Thanks!
2 Likes
It may very well be a no-no and it might not work, not sure about that one. But it's what I'm planning to do, even if it's not best practice. I'm planning to migrate my back yard devices this evening, which are the farthest away and totally dependent on repeaters. I'll post back with my results, good or bad.
1 Like
Other Hub will automate the creation of a virtual switch in ST. I personally used HE for exclusion during my migration, so my automations stayed in place on ST. Then I changed everything over to use virtual switches or in some cases just setup the simple automations in HE and removed it from ST. This may save you the pain of creating the virtual devices by hand. Smart Lighting in ST is very easy to migrate to Simple Lighting in HE so you may find it easier to just create new automations versus changing them in ST to the virtual devices.
I also recommend adding the Zwave Plus devices first before older ones that way you are building a stronger mesh.
I tried excluding one device with a minimote instead of ST and it ended up deleting the device from ST, including removing it from all the automations. Maybe I did something wrong? That's the reason I started manually creating the virtual devices as placeholders, so I had something there to bridge the gap between excluding the physical device from ST and having Other Hub create the new virtual device in ST. I can try another one tonight and see if I have any different results.
Minimotes act as secondary controllers so if its on ST then yes it will also remove it from ST. You need to exclude from Hubitat to keep things in place on ST. But warning here is your mesh will be impacted since it still thinks those devices are active so its important to run a zwave repair in ST after you remove a bunch so things route correctly.
@destructure00 Using Hubitat, Exclude the Minimote or ZStick, if you want it to not notify a primary controller. . Your technique of placeholder virtuals means this step isn't critical to you, but for others following along, looking for shortcuts, migrating the handheld controllers early will save a step.
Other Hub will create virtuals for devices added to the App. (It does not delete them, so if you find you want to re-pair a device on Hubitat, reusing the same name, the virtual will remain on ST BUT disconnected from it's real device on Hubitat.)
I used a completely different technique when I did my migration. I took pics on my iPad of everything. It's the low tech version. 
Thanks guys, that will help save a ton of time.
I have 4 minimotes, already moved 2 over to Hubitat. Can I use the two that are paired with HE to exclude devices from ST and have it work the same as if I were using the HE hub to exclude?
Yes. @destructure00
Anything will Exclude, no change to that factoid... but the ones on Hubitat will "inform" Hubitat that the device was Excluded. Hubitat, not knowing of that device will simply shrug and move along. ( do nothing.)
1 Like
Perfect! That will save a ton of time. Thanks.
It will do that if the Minimote is still in the ST system. Exclude the Minimote first, and join it to Hubitat.
1 Like
Ok I just did one the way you guys recommended and holy cow that's way faster. Thanks.
@destructure00 Hi, Chris. What are you doing for presence in HE? I'm still using your Tasker / Sharp Tools / Autolocation to control ST presence sensors that is linked to HE presence sensors. It usually works, except for the vagaries of Android's power management issues (staying on Oreo for now).
Hey there! I haven't gotten that far yet, still using stock ST mobile presence at the moment (which is terrible). I'm probably going to try Life360, but figured I'd tackle presence after I got my physical devices moved over. Still working on that.
1 Like
