Migration to V2 - Hurdles and Best Practices

I was able to get my 35 or so devices done in about two hours. I now need to go back and setup all the automation.

The only thing I couldn’t get re-joined is my aeotec home energy monitor v1. I need to get that one figure out.

1 Like

Great, got one of those too! Lemme know what you come up with?

I am going to install my v2 hub at a new location and keep the old location as is minus some sensors. Will it be possible to have an Amazon Echo at each location? Maybe I need to put each of them on a separate amazon accounts? Or do I just need to make sure not to duplicate device names and each Alexa will be able to control all of the devices at both locations?

The way smartthings authorizes third-party services like Amazon echo, or IFTTT, it appears that no matter how many different third-party accounts you set up, you will only be able to authorize access to one of your smartthings locations per smartthings account.

So each echo will only be able to work with one of your locations.

And even if you set up two Amazon accounts, you still can only get to the one smartthings location.

I think if you set it up as two different smart things accounts then you could certainly assign each echo to a different Amazon account and assign one echo per smartthings location.

The problem comes when you only have one smartthings account.

1 Like

If I can figure it out I’ll post back. I’ll also ping support after I get the hub if I can’t get it to work.

See the following thread

I’ve got two v1 hubs at two locations and have worked this issue with support for awhile. Currently its just not possible without having 1 location per SmartThings Account. Now what I will probably end up doing is have one location utilize native echo integration, and another use a hue emulator method. I suspect that should work fine since there are two distinct OAUTH smart apps involved there (1. echo and 2. Custom REST endpoint) but I’ve yet to reconfigure the emulator solution I had setup prior to native echo integration. keep in mind this will (should) work for echo but not for other integrations like IFTTT, SharpTools, etc… For those I simply have to pick a hub whose devices I want to interact with at any given time.

As far as v2 goes, if having any of these services for both of your hubs right now is important and worth the hassle of having two smartthings accounts then I suggest you combine the creation of the new account with the migration of devices to v2. Like the v2 migration, the implementation of getting a new account requires a device tear down/re-setup. Piggy backing that process onto the migration’s tear down would be best. If you can wait then hopefully enough people getting v2s will become multi-hub accounts and it will drive prioritization of a resolution to this unanticipated limitation.

3 Likes

Thanks that saves me quite a bit of testing and head scratching.

1 Like

The other one I have that caused me a few minutes of trouble was the Nyce window / door sensor. Push the inside button 10 times fairly rapidly and wait until the lights flash 3-4 times. Then take out the battery and put it back in about 10 seconds later. It will come right up in the discovery.

You forgot beer for step 11 after every xx devices (you pick the value). I did over 180, devices not beer. Not fun, but I was stumbling afterwards. Surprisingly everything worked when I was done!

9 Likes

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