Migrating WebCoRE to a New Hub

#1

I’ve been on and off the phone with Samsung over the course of the past week due to a problem with devices randomly jumping on and off line—often locking up ST routines, WebCoRE pistons, and even preventing control of online devices from the ST app. In one instance, the hub itself crashed completely. The devices may or may not come back online by themselves later, but more often than not I am forced to reboot the hub or physically turn the switches on and off to get them back.

What is most curious about this to me, is that the only devices that ever go offline are my five Z-Wave Plus devices. All of my older Z-Wave and other devices have no trouble.

Working on my own, and with Samsung’s help, I’ve tried literally dozens and dozens of different things to figure this out. (By the way, the support personnel clearly weren’t happy to see that I was using WebCoRE, but eventualy had to admit it was not blame for this particular problem). Their last-gasp Hail Mary is to replace the hub which is a major PITA because ST has never created a workable Backup & Restore solution.

Bottom line here, I want to be sure I’ve thought through the migration, and specifically any suggestions or concerns anyone here might have on the best way to handle the WebCoRE side of the migration. I know I can restore the individual pistons using the backup bin codes, although of course all my device references will be borked. I also know I can make a password protected backup of all my pistons, but as yet there’s no way to restore them. (Hey, @ady624 maybe now would be a good time? :grinning:)

Seriously, if anyone has been through this or thinks they have some ideas as to how to make the process easier – either before or after the migration – your input would be greatly appreciated. I’m am definitely not looking forward to the lost weekend of replacing a hub that may or may not be the actual cause of the problem.

#2

That really sucks!!

Make sure you save the backup codes behind the scratch panels, not the codes shown on the green snapshots.

One method that may work for you is to:

  • setup your new hub whilst keeping the old one live
  • move your devices over via manual reset rather than removing them from the old hub
  • give them the exact same names, case sensitive
  • register the new hub as a new instance in your existing webCoRE browser
  • use the duplicate piston option to move your pistons across

The above will at least save you having to enter all the backup codes manually and should speed things up overall… bit save all your codes anyway just in case.

#3

Thanks, that’s helpful, and a little different approach than I was planning. Can you clarify that second step a little? My brain seems to be a slow burn today. :grinning:

Just got off with Samsung again … more indirect criticism of WebCoRE without any explanation or evidence to back it up.

#4

Do not remove devices from your old hub as they will drop off your existing webCoRE device list, in turn breaking the pistons you want to duplicate across instances.

Perform a manual factory reset on each device without using the ‘exclude device’ option in ST… that way your old hub will just loose communication with the devices but keep the full device list.

You can then add the devices to the new hub and go from there.

#5

Your devices will have new IDs on the new hub, so it really makes no difference. When you import pistons into the new hub, you’ll have to reselect those devices. I’d install the new hub and then manually import each piston into the new hub, selecting the new devices as you go. If you install it on a hub without any devices, just skip the import wizard device selection - you’ll retain the list of device IDs in there, then you can revisit later and reselect devices. Alternatively, if you take snapshots of each pistons in the old hub, then move the devices to the new hub and start importing said snapshots (make sure you use the red ones), then you can use the wizard to reselect the new devices. No other/easier way, sorry.

#6

Thanks @ady624, editing the pistons to reselect all the devices is the part I dread the most. Although I’m told global variables may cause a slight delay in piston execution, I’ve been using them more and more because I find it easier to update one variable than five pistons. Either that or I set a device variable at the top of each new piston so that if I make a change I don’t have to edit every single reference to a particular device in that piston, assuming it is referenced more than once.

Having a global Find & Replace for borked device IDs, and/or a indicator on the dashboard when a piston contains a bad device ID, would both be on my wishlist. But then, even higher on the list would be not having to replace my hub. :grinning:

#7

I had to do a hub replacement early on in my ST “career”. At the time I had about 40 devices. I took me a weekend (starting on the Friday evening) to do the migration.

Since then, I have more than doubled the physical devices and tripled virtual devices, not to mention all the pistons which I havevsince added. I fear the day when I’ll have to (again) migrate to a new hub. Taking into account the time it takes to move to a new hub, it has to be a serious concern to all of us that Samsung has not created a migration tool. It is actually astonishing that such a tool does not exist. I like the platform (and Samsung products in general) a lot, but can’t help to wonder if the lack of a migration tool is an indication of the unprofessional manner in which Samsung approaches the platform. (The issue with ST not supporting Samsung TV’s anymore is probably another example)

I feel for you and wish you luck - there will come a stage during the migration process where you will ask yourself if it is worth the trouble.

As far as you Z-wave issue is concerned: Samsung replaced my hub for the same reason, but I realised afterwards that it was probably unnecessarily replaced. In my experience, the Z-wave issues are caused by either a faulty device or due to a device not pairing properly. I have since had the same issues with my replacement hub (imagine the horror when you see the error for the first time after going through the replacement exercise.).

I have learned to first remove recently added devices and to use the system without these devices for a day or two. In all but one instance the Z-wave issue disappeared and did not return after re-inclusion of the devices. In one instance the issue was caused by a Z-wave switch which became faulty and excluding an re-including it did not help.

Also, try pausing recently added pistons and see if it makes a difference. I will probably not be popular for mentioning this, but I have experienced (obviously due to bad design) pistons straining the hub to such an extent, that the system started displaying all kinds of unusual behaviour and errors. (One such example was a piston which I set up to look for motion from any of my approximately 20 alarm (connected to ST with Alarmserver) and other motion sensors. It caused havoc on my system causing other pistons to not run properly; sluggish responses from Z-wave switches and the hub losing connection with Z-wave devices.)

Point is, make very sure that your hub is indeed faulty, before you embark on the nightmare of moving to a new hub. (I know, I’m supposed to tell you that it is not such a big deal, but I’m sorry, in my experience, it is a big deal if you have Z-wave devices in difficult to reach places like your roof; inside light switch boxes, etc.)

#8

I hate to bring up an old topic, but I am now faced with migrating to a new V3 hub or giving up all together. My v2 hub is randomly rebooting and it is getting to the point where I’m guessing complete hardware failure is on the horizon. [my_rant] I completely agree, the lack of a migration tool after all these years makes me wonder if it worth the investment. This is truly a hobby and the fun factor is there when things work, but all hardware, one day will stop working and a quick way to get a replacement going is a must. In the IT world, we have backups not to brag about the size of our backup :slight_smile:, but a way to recovery from a failed or unforeseen event. [/my_rant]

Anyhow, I’m still on the fence about purchasing the new hub as I’m seeing what it will involve to get back to where I was. I’ll be using @Robin and @ady624 advice on moving my devices and getting webCoRE back up. Fortunately I do not have too many custom DTH’s so hopefully all if not most will work with the v3 hub.

#9

Thanks to @ipaterson, webCoRE backup and restore features have moved on a long way since 2 years ago… you can now download all of your pistons into a single local backup file and restore pistons into your new hub / instance.

You still need to reselect all of your devices, but it’s not all that bad.

The restore process has a handy wizard to guide you through the process.

The worst thing you will face is resetting and re-adding all your devices in ST… yuk!!

#10
#11

@Robin, thanks for the info. Knowing this makes my decision easier to now move forward with a new hub.