OK, I hate to beat a dead horse on this one since we’ve talked about it so much. However, it is now two months into the new year and I was checking on the status of the Hub Replacement Tool.
I still have my v2 Hub sitting in a box because I didn’t want to have to start from scratch again. However, I’m more concerned what happens if something goes wrong with my Hub and I have to replace it.
So, where do we stand on this tool?
It still doesn’t exist, and likely won’t until v3 or v4 imo
I won’t repeat myself in detail, but I think it would go a long way if SmartThings started from the Cloud (database) outwards on this: i.e., A non-trivial part of device-swap (or device-transfer) effort is migrating its properties (name, configuration parameters, room) and SmartApp associations (i.e, it should not be necessary to remove a Thing from every darn SmartApp before it can be removed from a Location …
All the above is just data manipulation. Really “easy” (IMHO), given some thought and clever effort by the folks that know the structure of the object database.
The physical migration has completely different issues due to Z-Wave and ZigBee security / transfer protocol issues. But why ignore the possibility of simplifying one part just because the second part is hard?
My v2 hub is also sitting in a box waiting for the migration tool. I agree this problem needs a solution. It would not be good if my hub failed and I had to start from scratch.
I swear @ben said it was slotted for end of year (i.e. Jan '16). I guess not.
Mine is in a box also. I refuse to do days of work for little benefit. I’m waiting for a migration tool, my current v1 hub to break or a better product from a competitor. When one of those 3 happen, I will do the work. The thought of programming every rule and smartapp again scares me more than the zwave and zigbee rejoining.
This is the part that made me insane. The fact ST is cloud based makes this so much more condusive to migrating data.
I agree with @tgauchat, this should be “straightforward data manipulation.”
Aren’t we part of the way there with the “replace device” button I see under some Things? I assume a SmartApp is attached to the UniqueID of a device. I understand that a Z-Wave or ZigBee device pairs itself with a hub, but the SmartApp association is strictly at the software level.
So, associate all the SmartApps and Things over to a new Hub at the software level. Then, one by one, select a Thing and say “replace this device” or “move this device.” I then un-pair it from the old hub and run the association with the new one. It then puts it “in the same slot” as the Thing that was being replaced and I don’t have to touch any of the SmartApps. This is so important because some devices are associated with a dozen or more smart apps, including OAuth apps like an Amazon Echo, Harmony Remote, SmartRules, etc. There exists a lot of stuff OUTSIDE of SmartThings that would need to be completely rebuilt as well without a tool.
Yes, I’m over simplifying it and there is probably a lot of backend code involved. But still, this seems quite straightforward. I don’t need to move a device from one hub to another without un-pairing it. I get it that it needs to be re-paired. That happens with Bluetooth and people are used to that process.
So instead of coding the perfect process that copies identifiers between hubs, blah, blah, blah…create a process that does 90% of the work and all the consumer needs to do is un-pair and re-pair.
What am I missing here? I must be missing something because this is the kind of rough design that someone puts together during a hackathon.
Perhaps you’ve found what’s missing… This is the kind of project that gets done when a couple engineers are freed from the constraints of product management. “Shake for Tile labels” was another example. A trivial incremental feature could have been modified (ie, a label-view toggle menu item) was never implemented until a complete overhaul of the mobile App.
The impression I have is SmartThings wishes only to provide migration tool when it does everything… The partial solution requires too much compromise from perfection 
.
LOL… When has anything come out of SmartThings that did everything? I have seen only half baked offerings, from the platform, to the integrations, to the mobile apps.
Hmmm… Quite true.
Well, perhaps we’re damned either way then. Migration tool was promised by the end of 2016 2015 by the CEO himself, in writing ~Sept 3rd. Perhaps we would have not have been satisfied with a “half baked” tool… But after nearly 6 months, we’ve not even seen flour and eggs.
Since I’ve had to re-set everything up a couple of times now, I’m very efficient at it! My “total rebuild” time is now less than a day, from a starting point of several days to migrate to a new hub. Yay Efficiency! hahaah
I had to RMA a defective v2 HUB for a new v2 HUB, even that swap was painful.
permission errors deleting locations and hubs… really?!
This product will fail, because unless you are 100% involved with browsing these forums and using developer tools it’s useless.
I had to contact support to remove the old hub from my account.
At this point, i would take half a solution. I realized I’m going to have to do some work. What I just want is that one-for-one swap within a SmartApp from the old device on the old hub to the new device on the new hub. I’ll do all the other work, excluding and re-paring the devices, etc.
Where the concern is about reinventing the wheel is that the other house members (wife, daughter) are all happy with the system now. Going through issues would be a step backwards.
Also, there is no easy way to document all the settings in all the SmartApps.
Yup… And I offered to SmartThings to be the Designer or Product Manager for this feature. I’m in the Bay Area and affordable – just also lend me a couple engineers and cooperation from the related teams.
ST knows how to reach me.
I hope you mean 2015. because he’s got some time if he promised to have it done before the end of 2016 
I also am looking forward to eliminating the upgrade nightmare. It is a huge amount of work to remove all devices and exclude all z-Wave devices then remove Smart Apps and start again. I have devices high in rafters not easy to reach, so for me it means taking life in hand and start climbing. Changing batteries is hard enough and maybe once a year for those up high. But this migration manager should have been in development from the day V2 was thought up.
@joelw135, I definitely think your scenario is the harder one and the one they are trying to code for. Basically, they would have to make the new hub look exactly the same as the old hub to those devices, which I think will be very difficult to implement and not run afoul with the standards.
I’m really hoping they at least take us half way there with the swap out option so that SmartApps don’t have to be recreated.
I’m guessing you have done some research on battery longevity of devices. 
Yes a matter of fact I upgraded to some of the newer multi sensors as the batteries last longer. I have also modified different devices to run on plugin power supply going into a UPS. Of course this isn’t very practical as it means 1. must be near an outlet 2. must not exceed certain distances 3. Must have a big group of devices near the UPS other wise I need lots of UPS systems. I have one device that is located in my attic very high in the vaulted ceiling which takes climbing skill and that is connected by wire instead of local battery to a UPS made for extreme heat and cold. I happened to get one via military surplus and replaced battery and a few damaged parts. But the climb is nearly 25’ from rafter to rafter in a dark space. I dread the update to V2 but I love a challenge. ST should have not mentioned that the software would be available as it has gotten many people angry. Also removing chat as limited the number of upgrades as people are waiting days if not longer for support. Google searches of people complaining are numerous. I want ST to be the best possible and this is not what people were expecting.
I think the biggest problem is that the V1 to V2 conversion user subset is probably quite small at this point relative to the entire user base. However, this same tool would be used for hub swapout generated from support ticket, which is why I’m confused why it doesn’t exist yet at least in some basic form