Once you get the status update of shipped, start excluding the devices… Buy a six pack or something stronger… Lock down the house and simply get to it… Or may be a few days off… 
2 Likes
@alex should be added to the Guinness book of world records for being the fastest tearing down the ST world in his home and putting it back in 3 hrs! 
I am sure with a migration tool beta may be??? it’s always good to be the king.
2 Likes
I can almost assure you of that!
There is a zigbee installer tool which will let you shift to a new controller really quickly. Control4 has a version. But I’m not aware of one that works for SmartThings.
Similarly zwave controller replication let you transfer control to a new controller very quickly. But again that was not possible with V1. And I haven’t heard of it being added for V2.
All of which is to say I don’t disbelieve that it’s possible to move a large mesh network from one controller to another pretty quickly, but I too share doubts that this can be done with SmartThings.
I don’t know of any way to do it with less than five minutes per device. At 200+ devices, that’s 16 hours right there.
@alex is saying he spent about 50 seconds per device? What did he do, hire the Flash?
1 Like
No, he misstated the facts, for whatever reason. CEO hype. Sad.
Oops I missed the big 
at the end. My comment was meant to be as ludicrous as the 3 hours migration time.
1 Like
Anybody else wondering if there’s a social media intern about to be fired?
2 Likes
I think this is an exception for Virtual Device. You don’t need to uninstall SmartApps in order to move it to another hub (e.g. from hub v1 to hub v2). After changing a virtual device’s “Location” and “Hub”, you can also see its associated SmartApps previously installed on the previous hub.
It’s legit I can tell you all, and I did it alone 
To be fair, I was under duress, since I was leaving my DC home for the move to CA and had to get it done in time to catch a flight.
Warning. tl;dr string of free flowing thoughts below, but I wanted to be open and share my own experiences.
My approach was pretty simple. I unplugged my V1 Hub, plugged in V2 and set it up as a brand new Location. I tackled Zigbee devices first because of the better range, which means all of my door and motion sensors. Those simply need to be reset while the new Hub is in pairing mode, and I’m pretty practiced with our own devices. That went super quick.
Then on to Z-wave in wall switches which was the majority by raw numbers. I then proceeded room by room, emanating outwards from my Hub in order to build the Z-wave mesh reasonably well.
Upon entering each room, I would go to Location Settings -> Hub -> Z-wave utilities -> General Exclude and remove all Z-wave devices in the room in a sweep. Takes about 15 seconds per device. I’d then enter pairing and pair them into the new Hub, naming the devices and putting them in a new corresponding V2 Room while doing it. I only ran into switches in the far reaches of the house, but found that by cycling those switches manually a few times while Hub was in general exclude they would eventually get pushed out. I could have gone faster if I’d been smart enough to use the Aeon Minimote to do the exclusions since signal range wouldn’t have been an issue then joining would have used the full mesh already getting built out.
To be honest, I was surprised at how quickly this part went and would certainly run into issues if I hadn’t been careful/lucky with my radiating distance from the Hub since if I had started at an edge I might have been able to remove a device and have trouble pairing it to the new Hub.
My final steps were the locks. I had the master codes on hand so those took about a minute each.
That’s it in terms of setting up the raw network. The 3 hours did not include full setup of SmartApps, Routines, Modes, etc. Those I did remotely after thinking about how I wanted to approach things using all the new functionality in the V2 app. Smart Home Monitor takes about 2 minutes to install since you can sweep in all of your door/window and motion sensors as a default setting. Leaks, Floods, Smoke all even easier.
The more nuanced decision making came up when considering the new Smart Lighting tools and how I wanted to intersect that with Routines. E.g. did I want my porch lights to come on at sunset via SL or do that with a Routine. Overall I netted out taking care of specific lights and groups of lights with Smart Lighting, and then took care of broad settings like turning off all the lights (and locking doors and arming Smart Home Monitor) upon departure using Routines and Mode changes.
Anyhow that was my own path, probably 5 hours all-in (3 for device pairing and 2 for setup of automations), but I’m up pretty high on the knowledge scale.
We know it sucks not to have a migration tool yet, and are working on it even though there aren’t clear ways anyone in the world has been able to do it with Zigbee, etc. and we actually don’t want to do a 1:1 matching for SmartApps ever since there are such better ways of accomplishing automation given how our platform has evolved over the past 6 months in particular.
I made the call to get V2 out the door despite this since it felt better to enable the rapidly expanding community to access the new functionality vs. wait for the migration tool. We do plan to get one developed by the end of the year, and it is incrementally important since it will also help people who have a Hub that breaks down for some reason and needs to be replaced.
I also know a few of the bugs / design changes that didn’t make it in for 9/3 are important. For example, the lack of a header that collapses upon scrolling in the Rooms and Things views on Android (vs. iOS where it does collapse). Another example is Device Sets, which will be a far superior method of grouping lights together that is meant to fully eliminate the Lights and Switches module on the dashboard. But we are a global company now and it was time to get this out the door and in your hands. It is a huge improvement, particularly for people who are just getting started.
The improvements will be rapid from here. Already an iOS update moving through the approval queue and Android will get an important update addressing top issues this week. We then plan weekly polishing releases for at least the next month or more. Software is easier to iterate and we have much more scale now than in the past, vs. the full release which included an incredible amount of stuff (Hub, video platform, new devices, new certification program, Smart Home Monitor, fully revamped apps on both iOS and Android, our first international expansion) all at once.
I’m incredibly proud of the SmartThings team and our efforts right now. The passion going into making this the most easy and open smart home platform in the world is awe inspiring. I hope the evolution of the products makes that clear and that you all appreciate it even while we work through issues.
Alex
16 Likes
Thanks @alex for your transparency and you should be proud of your team! The platform has improved over the past few months to the point where I am trying to convince my boss to get it over Insteon, Wink, etc. 5 hours sounds more realistic and now that we know the 3 hours only included physical migration, it’s a little more believable
Glad to see updates are in the works and I think you made the right call with releasing v2 ahead of the migration tool since the community is incredibly resourceful and will also figure out the best ways to tackle it. You are also right, this isn’t just about a migration tool, it’s about break/fixes as well. Look at Apple’s iCloud as the perfect example of how to migrate hardware. Apple did an awesome job with iCloud backup and restores and I only hope it can be somewhat as fluid as that one day with SmartThings minus the physical re-pairings.
Me personally…I will wait until the migration tool is out. I don’t feel the benefit if doing all that work with an infant and toddler running around is worth it for me since I won’t take advantage of the video recording yet. I also know there will be some bugs and kinks to be ironed out. I say by January when it’s bitter cold and I am stuck in the house anyway with the migration tool and more of a polished platform would be the perfect time to do this work.
1 Like
Right on and agreed on iOS device migration model. The core challenge has been that the device networking standards do not have good provisions for this. E.g. there is not an established way in Zigbee or Z-wave (let alone Wifi) to emulate an existing controller. In Z-wave, you can go through a process to join a network as a secondary controller and then shift that to become primary, but that won’t work if a Hub died for some reason as you need to have the old controller on hand. On Zigbee there isn’t any such method today.
So we’re pushing some frontiers on it. In our ideal world we could ship a new Hub and be able to have it emulate a users existing network and make device migration completely seamless. Lots of security implications to think about since most of the standards really try to make that impossible. But that would be our ideal.
In some cases we will even be pushing on standards evolution to support it (easier now that we are becoming one of the “big guys” and are on the boards for Z-wave, Zigbee, etc.).
Anyhow, thanks for the kind words and continued feedback. We LOVE our customers and community, and it is incredibly painful to watch some of the flaming as we adjust to this big change, even though I have 100% conviction that we are making the right moves.
Alex
1 Like
Thanks for your recap.
Control4 has had this functionality in their code for awhile now.
But then again, I’d have to pay my dealer to do it.
Could you address the whole local processing of IDE installed community DeviceTypes and SmartApps not available right now and forced to run in the cloud?
This essentially makes most of the reasons why people who use community code and wanted hub v2 local processing a dead issue.
I just don’t see any practical reason why this wasn’t allowed, unless it just wasn’t coded up to be allowed. In that case, was it part of the plan from the beginning?
Awesome. One thing I beg you guys to focus on is Mobile Presence. It’s the achilles heel of Smartthings and it’s such an important core part of home automation. I have not been reliably able to get it working with my wife iPhone’s for the past 18 months and a lot of other community members here have had their struggles too. I am not sure if BTE is the answer due to it’s limited range and only being able to pair one device at a time.
I have worked endlessly with support on it and there is no answers at this point besides asking my wife to rebuild her entire phone and pray it fixes it.
Is this something that will eventually be looked at?
I’m glad to see this acknowledged. While a hardware failure in any situation would sting, I think we can rely on Tech Support to send a replacement very quickly. Without a migration tool, however, the situation would drift into pain mode again, as even a Hub V2 to replacement Hub V2 will require the same minimum 3 5 hours of effort.
No… I’m pretty sure Alex wrote the comment himself, though a review by a social media editor might have suggested that the comment can appear to trivialize the pain involved or oversimplify the process.
Are you referring to the current limitations on which devices and SmartApps are able to run locally?
If so, that is something where we will very rapidly expand the list in the coming days and weeks. Covering anything that is certified and is able to be controlled locally (i.e. any device that doesn’t rely on cloud-to-cloud integration).
The current limitation while we harden the AppEngine component of our Hub firmware is that the local Device Type Handlers and SmartApps are actually packaged in with Hub firmware updates for all users. So we need to proceed with some caution. It also seems further away than it actually is right now since any given SmartApp will fall back to cloud processing if even a single device that it uses isn’t certified to run locally. So even though Smart Lighting works locally, it falls back to cloud if a Hue is included since that isn’t marked to run locally yet (even though it will be soon).
As I said, the list will expand quickly over the coming days and weeks to cover all the most popular scenarios. For me, that means Smart Home Monitor, Smart Lighting, and Routines will all be able to execute locally even if Internet is down.
Our definite goal will be able to support the sandboxing someday so that a developer could get their own SmartApps and DTHs to run locally if desired, independent of what happens across the broad consumer base.
I hope that helps! I will ask Jeff Hagins to write a post on this topic to make everything more clear.
Alex
4 Likes
Understood. That’s a big part of why it’s a priority even though many early adopters will often sort through the migration themselves before the tool exists.
1 Like
Excellent feedback, Alex. While you would be considered an edge case in speed, it was good info for the rest of us.
To that end, with such an environment as HA and IOT, everything is very personal to each user, and homes are unique. There was never to be a silver bullet to appease the masses. I agree to move on, get it out there with hardware, and then iterate the software which is far easier. Its a good order. The masses will be watching how quickly that software process moves to validate that the lack of iteration the last 9-12 months was about v2 and scaling personnel. You have a chance at a big victory the next 4 months. Good luck, we are behind you.
2 Likes
Wait, so this is the limitation, you have to push out the deviceTypes and SmartApps in Firmware?
If that is the case, that finally makes sense. I don’t like it, but it makes sense.
Thanks!
2 Likes
Yes. It’s impacted by the underlying tools in each mobile OS, but we are thinking about ways that we could add new mechanisms to establish presence (e.g. trigger it when the phone is on the same LAN as the Hub). Keep hammering us on this as we now know about being on the same network due to work we are doing to make streaming from cameras faster when you’re viewing while in the home.