Exactly and never has this been such an issue as it is now with this awful migration experience.
New wiki FAQ. (The topic title is a clickable link.)
Well, I started making changes and just ran into all sorts of weirdness so I was trying to undo things and then ran into trouble doing any of that and things were bound together but yet I couldn’t get rid of any of them. Was really frustrated. Sooo… I deleted everything it would let me delete and then hit the reset on the SmartThings Hub and just started 100% over from scratch. I have to say that I have half the number of devices in there as I didn’t use many and since I’ve done it, I’ve just had a lot better experience. It took a day to do and that included trying to delete stuff the right way and getting frustrated. I know that may not be a good thing you want to hear but it may be worth it in the end instead of fighting everything along the way. Just rip the bandaid off, start over from scratch, and everything will be clean and pretty. I’m glad I did it now that I’m done.
I keep uninstalling the classic app, then having to install it back because either something doesn’t work in the new app right or I just can’t find it. Is there a way to force remove a Zwave device in the new app or through the IDE? I had a Zwave device that I wanted to remove and when I deleted it from the new app, it just deleted it. No exclusion mode or option to “force remove”, just delete and gone, but obviously it was still in the Zwave network. I had to make a dummy Zwave device in the IDE , then use the classic app to force remove the dummy device to clear it. I know you can use the IDE to put the hub in exclusion mode, but what happens if you have a failed node that needs to be removed? How do you get rid of it on the new app?
You can also put the hub into exclusion mode from the new app. Open the Hub in the new app, hit the 3 dots in the upper right corner, select Z-Wave exclusion.
I was having all sorts of wierdness with mine which is what drove me mad and I just gave up and reset everything to start from scratch. Now things are just working and I’m having a much better experience.
Thanks, I see that option to put in exclusion mode as well in the new app, and tried that first, but what if the device fails to exclude? How can you remove it with only the new app and IDE? Every other hub I have dealt with had the option to “delete failed node”, and this option was in the classic app after an unsuccessful remove, but does not appear anywhere in the new app. I don’t have a ton of devices, but it would still take a good part of a day to get it all reset and reconnected. I’ve read posts on here about some people with 150+ devices. Plus all the complex automations and Webcore they have setup. The solution can’t be factory reset the hub and every Zwave device you have every time there’s a problem with the Zwave network.
When you look at the device (open it up) in the IDE, does it tell you that it is in use by anything? It will be at the very bottom called “In Use By”.
Well the device is gone now so unfortunately I can’t check it anymore if something was there, but that is a good point to check there because I think where you are going is that if it is use by any automation or smartApp it won’t remove properly right?
Yeah that’s right. If that device is in use by anything else, it has to be removed from whatever is using it first. Once that section is empty, then you can freely remove it. The problem I had was that I couldn’t figure out how to fix mine as I was getting errors on both ends. I couldn’t remove it from what was using it and I couldn’t delete it because it was in use. Drove me nuts so I nuked it all by hitting the reset button.
This is a HUGE issue with the New App. You have no idea what SmartApp is using a particular device unless you go into the IDE. Also, if an automation runs, you have no idea what automation triggered the event.
Very hard to troubleshoot issues and impossible to delete certain devices.
I was successful in manually converting all of my Routine, Scenes, SHM and Locks without using the migration tool. But now I am at a crossroad. I have read other threads that there is no need to run the migration after if you have manually migrated. @nathancu I respect your strong ST knowledge and opinion and was wondering if there any other evidence to this? I would hate to break what I have now working.
Knowledge - ha! Opinion, I have a ton of it. (Thank you though)
My Opinion comes from what I’ve seen in IT and developer support over the years. I will begin with I DID migrate my location after getting pretty much to the same point you are.
I did this because given my understanding of what the migration process does - and more specifically DOESN’T DO. I felt fairly confident that after Routines, Scenes, Presence, SHM and Locks were done, there wasn’t anything left to break. The migration doesn’t MOVE any devices. (evidence, if you are logged in to both, you see the same device list) New and Classic both come in from different endpoints, yes but they talk to the same ‘stuff’ in the cloud. Sure enough when I pressed the button it went VERY quickly and I was left pretty much where I expected to be.
Why did I do it?
I spent ~13 years in Enterprise IT product support for a LARGE software publisher. What that experience taught me - even the BEST developers ABSOLUTELY SUCK at testing. (I cannot overemphasize that point enough, they mean well but it’s impossible to account for all variables.) They make a lot of assumptions about the state of a system when they write code. They shouldn’t, but that’s beside the point. They’re human, they do.
So lets assume we’re two years down the path - sometime in 2022, and we’re all through this migration mess. Some whiz-bang developer comes up with the latest new feature but guess what - new feature ASSUMES that all users of SmartThings are either new users since October 2020 and the location looks like X OR they were Pre-October 2020 users and therefore the location was migrated, therefore all of these (insert hidden attributes marking a migrated location) settings apply. (See where I’m going here?) You didn’t ‘migrate’ and therefore didn’t attach any number of hidden attributes we as end users don’t know about to your location. Install the new whiz-bang feature and BOOM something catastrophic happens and hoses your location… Yes we hope testing catches it, but see above…
(I once completely SMOKED, figuratively, not literally, about 500 desktop computers in one night making an incorrect assumption doing a product uninstall. Did I mean to - no! But, that didn’t keep me from spending 48 hours straight reinstalling Windows NT workstations for my employer from scratch…)
So one of my personal tenets of IT from that experience became:
It is in your best interest to put your configuration (in this case read: location) in the closest to pristine or closest to EXPECTED configuration as possible to eliminate as many variables to troubleshooting as you can…
Should you HAVE to - absolutely not! But do I?
Considering how much of a ROYAL PAIN IN THE BACKSIDE troubleshooting the unknown is or in this case a hub migration / reset currently is? (ahem, @blake.arnold, -poke-) You bet I do. It’s purely defensive.
I don’t think there’s going to be a choice. The things the migration tool hits are all Classic only. There’s no interface for them in the new app, so they can’t leave anyone behind. When they sunset Classic, I think they’ll just hit the button for everyone who didn’t hit it themselves. So do you want to have control of when the button is hit, or do you want to have it happen in an overnight batch job with no feedback as to whether it was successful (except for all your lights going haywire while you’re sleeping)?
Yes I agree with your comment “developers ABSOLUTELY SUCK at testing” In my years of IT I also learned that negative testing is not performed enough either. So I will heed your warning/advice and will push the migrate button.
Opinion… The word was opinion… I also coupled the action with a couple preparatory shots of whiskey. Can’t say it helped but it certainly didn’t hurt.
Make sure that you remove from the Classic what you migrated manually, or else you’d have duplicates. I didn’t remove mine and then ran the migration, the clean-up is not fun.
I am not looking forward to the day when the IDE goes, as there will be no troubleshooting. I hope they are planning to hire a bunch of support reps, because they will need every one of them to tell people what app turned their bulb on.
I imagine they will add many of the features to the new app that are currently missing and before IDE disappears:
- hub reboot and other hub management tools from IDE
- ability to create location modes
- what device is used by which apps/automations/etc
- set temperature scale
- any many more surprises
Have been thinking positive for five years, what a heck, ten more years is not a big deal
I imagined they would add many of the features to the new app that are currently missing and before the Classic app disappears.
That didn’t work out so well.