Backing up all routines


(Richy) #1

Does anyone know if you can back up all routines? I have so many apps and routines running that if something glitches or if I have to reset my system I might loose everything. It would take me hours to reprogram it all back.

Thanks

Richy


(Marc) #2

There is currently no migration or backup utility with is a huge architectial flaw right now and is why many of us v1 users are waiting until a tool is made available to move to v2. I cringe at the thought of losing my entire setup and re-doing it. I estimate it would take me a good 16 hours to rebuild everything.

ST promised a migration tool Dec 2015 and failed to meet that deadline. It’s supposedly coming soon, but we shall see.


(Bruce) #3

I recently did this. 160 devices, about 90 SmartApps.

I can tell you this, no tool will save you most of the effort, which is the devices. You will have to do the devices manually one at a time, due to the physical security measures built in to zigbee and z-wave. That represents the majority of the effort.

As for moving SmartApps, there has been some really bad information out there about how to go about doing this. What I did, and swear by, is DO NOT DELETE YOUR OLD LOCATION! Do not touch your old location at all, just unplug the hub. That way, you can still see all of your automations in the old location, to make new ones in the new location. This was the easy part of the migration. As soon as I had the devices added, I’d add the automations, using the old location as a guide.

I predict there will never be a tool to migrate V1 to V2. It makes no sense to invest scarce resources in.


(Marc) #4

Thanks @bravenel. Yes, the migtration tool won’t help with the device aspect. I was just hoping a tool will “minimize” the pain. As of now, my V1 is working pretty good,so I don’t see a huge benefit right now to upgrade.


(Bruce) #5

I didn’t either, until my V1 had the dreaded Err 101 which crashes z-wave repair. At that point, my system was toast, or would become toast with time.


(Marc) #6

Yes, I am waiting for me to basically have no choice :_


(Bruce) #7

But, given that everything I have runs in the cloud, I would say that V2 hub is marginally quicker than V1 hub. That’s non-scientific, and just based on observation, and could be wrong. But it seems a little quicker. That of course has nothing to do with big lags that show up (cloud), or missed events (cloud), or missed schedules (cloud) or user mistakes (me).


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #8

What about migration from a failed V2 Hub to its replacement. Essentially the exact same problem (but much more urgent for the affected Customers!). So the problem is… Pretty darn important.


(Bruce) #9

Perhaps, but there is no golden bullet here. At least not one worth investing in. The devices have to be hand moved. Then they pretty much have hard id’s. So unless they were to completely rebuild their approach to devices just for this problem, you’re stuck. You can’t automatically migrate anything, because you don’t know the device ids. At that point, you are pretty much back at rebuilding your automations.

It was probably a mistake for them ever to bring this up, or suggest they would do it. Frankly, they can’t, and won’t.

The effort would be similar the effort MS put in to create Plug N Play, relatively speaking, but with no upside. All of that effort would only be to benefit this small minority of customers whose hub goes south, for this one day’s effort to rebuild their system.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #10

After manual physical migration, a web based tool could be provided to streamline matching the new Device Object references to the old ones.

This second step is a trivial problem to solve, though it would take some user observation to tune into something that minimize confusion. Then again, that never stopped SmartThings UX division before.


(Bruce) #11

This would be a huge problem, IMO. First, it assumes that you keep all of your old device names exactly, or that this tool encompasses the entire device inclusion and naming process. Then it assumes that your old automations can be reconstructed based on device names alone. Good luck with that. And what do you do, as a support organization, when it doesn’t work? Devote how much support time to untangling a mess?

Were it on my management shift, I’d say 10 ft pole.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #12

Not device names, every device has a unique object ID and I can think of a dozen ways to eliminate ambiguity as Devices are added to the new Hub one at a time.

Anyhow… I’ve offered to put my career on the line a get it done. But that’s not the way corporate organizations work. It’s all about excuses, fifedoms roadblocks, and cannots rather than can-do’s.


(Bruce) #13

And some little thing called Priorities. “The man who’s wise doth prioritize”, said my first boss at Intel.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #14

Agreed; but the highest priority items should be ones with multiple long term benefits. Solving the Device to SmartApp relationship preservation issue would also facility backup and restore of SmartApp configurations.

As well, an agile company must learn how to do many things in parallel in order to scale (to millions of Customers!). Hub failures will become a larger and larger headache with that kind of growth, especially as households add dozens of complex automations.

A migration assistant of the type I describe (especially in Minimum Viable Product form) can be independently developed and tested, long before it needs to be prioritized and merged into a particular production release.


(Bruce) #15

That isn’t really the problem. It’s device in network A (new hub) with same device in now non-existent network B (old hub). How do you propose to line up the ids? How can you possibly do that without rebuilding the entire device ID edifice that exists now? Other than through a manual process where the user picks a device from the old hub to be the device he has now, and somehow this migration tool plugs the new device id into the smartapps that reference the old device. This is not a small undertaking. It would span the entire device inclusion logic, and somehow open a new api backdoor to change smartapp device relationships. Good luck!

Can of worms. Forget it. Isn’t going to happen. You’ve convinced me.

In the end, the user is better off just rebuilding his automations, which is a relatively small part of the job. Heck, even @alex said so.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #16

That’s exactly what I propose.

This is not an overnight or weekend project. But very feasible with 2 full-time engineers or consultants over 2 to 6 months top. Cost: under $500,000. Drop in the bucket.

Like I said… I don’t expect you to do it or pay for it. (SmartThings CEO, however, literally promised it in writing.) And I would take on the task as a contract job, if SmartThings was open to possibilities and exploration of ideas instead of writing off all but fully comprehensive solutions.

I understand your dissent. In a few paragraphs on a forum written in 15 minutes, I can’t possibly prove the viability of the concept to someone who’s set against it. I think a few people are open to the idea though.

I’ve likely pointed out before that I am surprised you don’t seem to have more vision about things like this, given that in a few weeks you, @bravenel, created an 100% native Rule Machine which SmartThings failed to attempt publicly for 3+ years.


My own history is of envisioning 3rd party clients / dashboards for SmartThings in 2013 and exploring the concepts in the old forum. @625alex did such an incredible job of manifesting this vision that I subsequently partnered up with him.


(Jason "The Enabler" as deemed so by @Smart) #18

I had this problem a while back on my v2 hub. I did a total system rebuild.

A couple of weeks later it started again. Luckily this time my trouble ticket landed on the right desk. He found several orphaned devices in my system. Once he deleted those and I rebooted my hub everything was fine.

When things start glitching I send a ticket to support requesting that they search for and delete all orphans in my system.

So far, I’ve been good.


(Marc) #19

I am getting this error constantly when I do a zWave repair: (seems to happen every time on this zwave extender)

Network repair for Zwave Extender [09]: Failed to update mesh info

Is this the error you are talking about?


(Bruce) #20

No, this a garden variety error not uncommon during a repair. I could be that that device needs to be reset, or doesn’t have a good mesh connection to the hub. You may be able to rehabilitate it.

Another more advanced step would be to exclude the device and add it back as if a new device (you’d have to remove all smartapps first that touch the device). That might not help if the problem is a weak z-wave network for that device.