Migration to V2 - Hurdles and Best Practices

180 devices! Wow, that’s impressive!

1 Like

I did my 60 odd devices over 2 days.

Day 1 - did the complete nuke of the v1 install, exclude/reset/repair/pray/curse/google got them all reconnected, got basic config done (stuff in rooms, heater control based on doors/weather, and lights based on lux) - couple hours. Before doing the rip dumped as much metadata as I could find from the IDE, still managed to miss a couple apps/behaviour.

Day 2 - detailed behaviour work, figuring out new stuff in the app, more beer.

There are more things that need to happen, but I’m mostly up and debugged. none of my smartapps run locally.

Edit: oops forgot… day 2/3 - regenerate all the damn oauth integrations (Echo, my own stuff running on my server, my local IP webcam, etc.)

3 Likes

Well… at least you got beer. :beer:

3 Likes

I feel like a slacker with my 50 devices but overall it went really smoothly.

Supposedly none of my smartapps are running locally either but my motion based light setups are definitely running more quickly and consistently.

4 Likes

Anyone having problems removing the Hue connect from V1? It won’t let me remove it from app and when I try to remove it from IDE I get this error:

Heuristic completion: outcome state is rolled back; nested exception is org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

Any thoughts, suggestios? I did open a ticket…

Update: I had a bulb linked to SHM when I tested the notification with lights. Once I removed that, I was able to remove the hub.

I was having errors removing Hue this morning. I had to find every place where I had tied one of the lights to an automation, room, etc… and remove them from there and then the Hue connect smart app would uninstall. Same thing with Life360. I finally just removed everything from everything and then clean up went well.

Went ahead with it yesterday, got everything disconnected and reconnected. I had to move the hub around the house to get some of the light switches to disconnect.

Tip for others - Start removing items that are in a fixed location from the furthest away from the hub and work your way in. Yeah, stupid tip but I neglected to follow it :smile:

Tip #2 - Follow the guide and remove all the smartapps first, it prevents errors removing items.

How do you know if the apps are running locally or not? Kill internet and see if they work?

I’ve had issues with GE Link bulbs showing up as “Things”, basically unknown. I added them anyways, and then went to graph.api.smartthings.com/devices and changed their device type to GE Link bulbs. They seem to be working properly after that.

There’s a list in the IDE for the hub that says which smartapps are running locally. Right now it will probably be empty as the only currently eligible smart app is smart lights, and then only if you are not using any custom device types.

I’ve gotten a couple of questions about the “include from the hub out, exclude from the farthest in” tips and what that all means. And I’m too tired to answer them individually so I’m putting the answer here and hope everybody sees it.

Whenever you are including Devices, you should always start at the hub and work your way out.

If you’re migrating from one hub to another and you’re going to use a general Z wave exclude, and go device by device excluding it from the old hub and then immediately including it to the new hub, then you should follow the include tip and start at the hub and work your way out. So you start with the device closest to the hub, exclude from the old network, include it to the new network, then go to the next closest device and repeat.

If you’re working mostly with the zigbee devices these already do a reset that excludes and then includes, so again, you follow the include tip. Start with the zigbee device closest to the hub, reset it, include it to The new hub.

The Exception: You want to completely tear down the old network before you do any includes on the new network

The only exception is if you’re going to completely tear down your old zwave network before you even start on your new network. In that case, things will probably go the most smoothly if you start by excluding the zwave devices that are farthest away from the hub and work your way back towards the hub.

The reason for this is that if you exclude the devices closest to the hub first, the exclude message may then not be able to reach the devices that are farther away. So the exclude on those will fail. Which means When you go to include them to the new controller later, that include may fail because the previous exclude failed and then you have to go through troubleshooting and all that stuff.

SUMMARY: The Include Tip Overrides the Exclude Tip if you’re doing both procedures on the same device in the same pass

So: when you do includes always start with the devices closest to the hub and work your way out.

If you’re going to exclude, and then immediately include that same device to the new controller, go ahead and follow the include advice. Start with the devices closest to the hub and work your way out, doing a pattern of exclude/include on each device as you go.

If, however, you want to exclude all the devices on the old network before you ever start including anything on the new network, then, things may go more smoothly if you start with the devices that are farthest away and work your way back in to the hub.

Then on the next weekend or whenever when you start building your new network, the odds are higher that all the zwave devices were correctly excluded the first time. So you begin the new network build starting with the devices closest to that controller and work your way out.

3 Likes

Excellent guideline

I’d add - when you’re all done, rebuild zwave network. Wait a couple hours. Do it again.

Because even if you started closest first… the mesh might find better paths once everything is in. Do it twice because it might get even better with a better starting point :smile:

2 Likes

I was so excited to see this:

Here is the link to get to the page JD was talking about in case you can’t find it - https://graph.api.smartthings.com/localInstalledSmartApp/list

2 Likes

I just moved my sunrise/sunset actions from routines to the Smart Lighting app and now they are running locally! I wasn’t using the mode changes for anything anyway so nothing lost.

2 Likes

Hi @JDRoberts , I see the link provided in this thread, but where in the IDE did you find it? I’m sure it’s something I glossed over in the documentation, or elsewhere, but where did you navigate to find it?

Completed half of my migration in the record time of…5 hours. And as my luck will have it, the road was paved with many challenges. I now have a lock that was included but doesn’t work, a thermostat that is stubborn and doesn’t want to be excluded, a garage door that cannot be opened on presence.

I have opened at least 5 different tickets, some of which were handled by support amazingly well ( e.g I wasn’t able to delete the location linked to my v1, and the support handled that on the back end within couple of hours after submitting the ticket! exceptional promptness there).

Thinking to open a new thread for ‘struggles after migration’ - but I’ll wait untill I complete the migration.

2 Likes

I found it using the link above.

What’s odd is that I have none. I even removed all my custom apps and device types before moving to the new hub.

Support gave me the link, but you know, I have trouble navigating anyway so I honestly don’t know where it is.

It’s not surprising if you have no smart apps running locally. At this time the only candidate to run locally is the new smart lights solution module. And if you have any custom Device types for any of the device is accessed by that module, it can’t run locally now. it also can’t run locally if you’re using the Hue bridge.

I have 30 devices and done in 6 hours roughly.(haven’t done any smartapps anything yet) Wasn’t pretty excluding devices and trying to add devices. (clearly sometimes my exclusion didn’t work) I think biggest issue is knowing the exclude/include of the different devices you have. Easier to look up first then climb up on a ladder or crawl under sink and try to figure out then. Some sensors required clicking 3x and others just require a push. What be nice to have some standards!
I hope it’s worth all the effort. Guess I’ll see tomorrow.

Roger roger. I have all factory device types and am using routines and the SmartLighting SmartApp. Odd that I would still have no local processing. If I get time I may contact support.

Well not all official device types are created equal. Let us know if you find out which one is the culprit.