C’mon @JDRoberts. This is your chance to calm down the community before we go insane over thinking things. We need a FAQ. Sad part is the hub is not even around for another month … or two… or?
1 Like
There are plenty of people in this community that have gone through the pain, so why not making them share their experience before we start panicking. Or maybe if they realize how all over the place we are they would do something to help us.
1 Like
A little premature for a FAQ considering that no one (not restricted by an NDA…) has received Hub V2 yet!!!
The migration process could be different from V1 in non-trivial ways. It’s good to be proactive, but, heck, if we were really proactive, then someone would have written a migration tool by now! 
2 Likes
LOL!
The difference between field engineers and, well, pretty much everyone else is we don’t document things that don’t measurably exist. We leave that to salespeople, tech writers, and the clergy.
There is no answer to a FAQ until there’s a device drawing power. Anything sooner than that is just marketing. 
7 Likes
I’m afraid it’s not possible to write a 3rd-party migration tool because device creation is not exposed through public API.
A little premature for a FAQ considering that no one (not restricted by an NDA…) has received Hub V2 yet!!!
As far as device inclusion/exclusion goes, the V2 hub is no different than V1. I don’t think standard Z-Wave features are covered by NDA.
They most certainly are. I’d advise you not to reveal anything about V2, including that which you just revealed. There is no grey area.
1 Like
Don’t be paranoid, Terry. I revealed nothing that has not been revealed before on this forum. 
1 Like
I’m very paranoid when it comes to legal documents. Samsung has much better lawyers than me. Much. And insurance.
I wouldn’t even reveal that I was in the Beta if I were under NDA, which I’m not, so I can reveal that.
I’m very serious.
What Beta? I think you’re making too many assumptions. 
1 Like
Guys, if you are uncomfortable sharing general guidelines to prepare the community for the migration, it’s ok, just wait. I thought that getting in the mindset that the experience will be painful when IT comes out, would be a good distraction for the time being.
This is the “get your friend to punch you in the shoulder so you are distracted from the headache you have from drinking too much beer” protocol? I think I remember that from college. Or maybe not. Some of it is a little fuzzy. LOL 
3 Likes
My advice regarding Z-Wave network migration is not V2-specific. It’s based on my prior experience migrating Z-Wave network from Vera Lite to SmartThings (V1) to Staples Connect to Vera Edge and back to SmartThings. I cannot comment on migrating Zigbee network as don’t have any Zigbee devices to speak of.
To move a zigbee device you need to do is delete it from the host controller and follow the manufactures guidelines for resetting the device and then getting back into paring mode.
As far as mass migration tools:
Maybe for SmartApps and settings this might be possible. But for the devices this would be a non-trivial process. The hub itself has paring information as well as the individual devices. So much that could go wrong there.
But not rocket science. Seriously.
We can put a probe on Mars…, etc.
Lock some clever people in a room. Pay them well. Write a click-by-click utility that doesn’t require the Customer to deconfigure and redo all of their Shortcuts AND SmartApps and Groups and Labels.
Geesh. A lot could have be done at the back-end in terms of creating a “replace” utility tool, that would hold the Thing record open until the Device had been joined to the new Hub.
Yes… I’m just brainstorming, but that’s my profession. Just don’t think about the problem, think about the possible solutions.
2 Likes
I’ve had the experience of tearing down and rebuilding on a new hub; my system had over 120 devices. These were both V1 hubs. I can share a few things from that experience:
- Figure out a good naming system for your system and devices; I use the room name or area name with a digit, e.g. Office 1, Office 2, etc, where there’s no point in giving them distinct names, or if there are distinctions, e.g., Kitchen counter and Kitchen overhead, use those names.
- Write things down about your existing system before setting up a new hub. These are things like SmartApp settings for devices, modes, times, dimmer levels, etc. You will need a complete list of your installed SmartApps and settings to guide rebuilding your system. I printed key pages from the IDE and then annotated them.
- Every device is going to have to be reset before it can be included into the new hub’s network. Look up the instructions for how to do that for each type of device you have.
- Include your z-wave repeaters (if any) first, from closest to furthest from hub, including powered z-wave devices that act as repeaters. Include passive z-wave devices last.
- Perform z-wave network repairs from time to time as you build your z-wave network. Take a break.
- It’s good to have a Minimote for Z-Wave inclusion / exclusion; this application alone justifies purchasing one.
This exercise is best done with no one else home.
10 Likes
There are solutions, but none of them are going to be click through wizards. It is possible to join another z-wave network and then remove the origin hub. I have done that with Centurylink’s home security controller and a wink hub. In the end it was easier to exclude and repair.
Given that all of the devices must be manipulated during exclusion, not sure how you would automate that part. Outside of cloning the old id, state tables, etc over to the new hub; you are going to have to go through an exclusion process.
1 Like
There’s no reason that the back-end data couldn’t be 100% cloned from 1 Hub recordset to the new one. – All that is needed is to create a temporary set of Device Records, if foreign key constraints can be temporarily disabled during the account’s migration.
I’m 100% serious:
Given full access to the SmartThings device Cloud database for a single account…
Very rough pseudo code / sketch:
Lock the account and database for migration mode, limiting what functions may be performed; disable foreign key constraints. Add a friendly alternate candidate primary key – heck, use the Label Attribute (e.g., make the user ensure all the Things have a unique name by using the existing Properties/Rename function in the UI). Add a temporary column to mark “devices set for replacement”. Remove the device but don’t delete any of its Cloud data. Add the device to the new hub in a temporary table row. Prompt the user to confirm or assist in matching it to the non-deleted Device record by using the unique friendly-name key we ensured above. Move the data from the temporary table to the correctly keyed record in the existing device table, thus resulting in it having the same main primary key (Device GUID).
All related records (Events, Shortcuts, Group, SmartApps, etc.) require no further updates as all their references to the Device are via the unchanged GUID.
1 Like
I just have a few thoughts to add to @bravenel 's excellent guide…
A) Amazon Echo has difficulty with device names that have number delineations like “kitchen 1” and "kitchen 2. " if you plan to use echo, use distinct device names without numbers for each device.
B) battery powered devices are going to drive you crazy if you have more than two or three of them. They always go to sleep at the wrong time. And they use their previous configurations until they completed their previously defined sleep cycles, which can make it difficult to get them configured to new parameters.
Pretty much the only way around this is to start with the skeleton that @bravenel defined: pair any device that is mains-powered (can repeat) working out word from the hub until all of these devices have been included.
Now go back and do the battery powered devices, but do them one at a time, and complete both inclusion and any necessary configuration immediately after putting the batteries in. You’re still going to work outward from the hub, but don’t do a bunch of inclusions and then come back and try and do configurations, because some of the devices will have gone back to sleep again. You need to instead take one device, pair it, configure it, and then move onto the next.
C) there’s a big argument between theoretical network designers and field engineers as far as how often you need to do a network repair while you are building a new network.
Theoretically, to maximize efficiency of the network, you should do a network heal after every new included device. But in practice hardly anybody does that in the field.
So that gives you two choices: do a heal each time you move to a new hop ring, or wait until the end, and then do several repairs in a row.
Whether you choose one of these three options or yet a different one, just be aware that a best practices recommendation is probably going to do A lot more iterations of a network repair than you were planning on.
http://www.z-wave.info/book-z-wave-basics/buch-z-wave-grundlagen-kapitel-5/
D) in addition to all the documentation that @bravenel recommended, I personally have a rules spreadsheet which is really just a scheduler record, and shows me by hours and mode what my various events are.
The only point of this is that until we actually get the V2 to play with, we don’t know whether the rules will be set up in the same way that they were set up in the V1 system.
We already know there are some weird deviations between, for example, shortcut groups versus hello home action. If there is a new interface, and we don’t yet know whether there will be, it could be that some of those deviations have been regularized. Which might mean rules are entered in a different way. I’m not saying they will be, I’m just saying that for me personally, I like to have a record to look at which isn’t just screenprints of the existing system but is in fact a use case logic I was using when I set up that prior system. But that’s a personal choice.
3 Likes
While this is really great and obviously expertly informed advice, @JDRoberts, do you really think that the “average SmartThings Customer” is going to go through this much effort … or even understand the steps?
The key value proposition / market positioning of SmartThings is ease of use – especially the absolutely essential simplicity of adding Devices.
The “average SmartThings Customer” has no clue what a “Z-Wave Repair” is, and the majority of ST customers have never even attempted it once, in place on Hub V1, let along multiple times during a laborious conversion process.
This is not just realistic for the vast majority of the 100,000 Hub V1 Customers that SmartThings has, a bare fraction of which have even signed up for the Community (there are 10,000 “users” on the Community and, of course, most are not “active” and will never see a FAQ).
I wasn’t talking to 100,000 people.
I was adding a few notes about my own practices when setting up my z-wave network for the people reading this topic. 
As far as how much work it all is, with the exception of the multiple Z repairs, it’s all work that has to be done anyway.
People who have battery-powered devices and need to configure them should know that it’s easier for them to put in the battery, pair that device, and configure that device, before moving onto the next battery-powered device.
The alternative, which a lot of people try, is pair all the devices, and then go back and configure them, often as part of adding Smartapps. And then we get a lot of questions in the forums about why the configuration isn’t working.
Remember that some of these devices do require being reset to factory specs prior to inclusion. Not all of them, but some do. And if you reset them, they may not have the parameters that you want to operate them with. So, if you know that they’re falling asleep may be an issue for you, and you know that the easy way to deal with that is to immediately configure the device as soon as you have completed its join to the new network, well that’s only a benefit.
But it’s always a personal choice as far as what anybody wants to do. I personally don’t do a network heal after I add every single device when I’m moving a bunch of devices from one controller to another. I do them in hop rings. 
Carry on!
1 Like