No migration tool yet? Then we need this instead...SmartApp Settings Documentation

Question for @alex, @Ben

OK, I get it that there is no migration tool. Although, it amazes me that the standards organizations didn’t conceive of the need to replace a bad device! (but that is a different topic altogether!)

I understand I need to exclude and include everything. I even agree with @alex that he wanted to review all the smart apps and kind of start fresh. So, I understand why we are where we are.

However (and others have discussed this here before, but I’m directly asking this), what we need is a SmartApp “export documentation tool.” This should be MUCH easier to build than the full migration tool.

Via the IDE simulator, what can’t we just select one (or all) SmartApp and export the interface WITH the selections? There is no re-inventing the wheel here. Everything is in the IDE - the interface for the SmartApp is in the code AND the settings are there as well.

Am I missing something that is harder than I think? If this could be done, it seems like it would be an awesome feature for people making changes to their system at any time…or maybe wanting to “backup” setting by taking a snapshot prior to making changes to see how they work.

This feature could even be exposed in the mobile apps itself and the settings could be emailed to the account holder. Support could use it to export and email it to a customer with suggestions highlighted for change (which would also help teach the customer things as well).

I HAVE to be missing something here. It seems like this would have been created already. It seems like a great interim step until a migration tool of some sort is in place.

1 Like

@alex, I’ll buy the RedBull and a pizza for locking a programmer in a room for a few hours to bang this out. It doesn’t have to be pretty, just simple.

1 Like

I made a similar suggestion based on my extensive background as a database manager. And admitting the details would take a few days and right resources to figure out. I don’t feel that I am over-simplifying…

So: There are obviously non-technical factors involved here, especially when the need for any large portion of migration automation has been known from the day Hub V2 development was announced, while the CEO with over 200 Devices doesn’t find migration to be as arduous as everyone else knows instinctively.

I firmly believe that a solution based on my suggestion would cut the effort by around half, and that with a small engineering team could have been built in a month or two in parallel with the hub testing. That id due to the huge advantage of the Cloud — all the required Device and SmartApp configuration data is in one place able to be manipulated by SmartThings programmers arbitrarily (ie, just map and move reference keys from one object to another).

I’m game, if SmartThings is…

Well, actually, I think:

  1. It is better and worthwhile to put small team together to do this, as then we combine the expertise and knowledge of STs backend database and web client API and reduce risk.

  2. I believe in being paid what I’m worth, and I think migration tools are of tremendous measurable value to Customers and support staff.

Migration tools are decidedly not trivial. And while one is needed, and being worked on, it doesn’t make a lot of sense to invest time on an interim solution.

Lot’s of folks here were clamoring for the new hub, so I think it made sense to release it without the migration, given that it is not ready. Gotta Havits can get it now, and folks that prefer a less laborious upgrade can wait. At this point, the new h/w is not that compelling of an upgrade anyway. My guess is they have a lot to do before most users will even notice a difference.

1 Like

SmartThings obviously does not hesitate to build and release “interim solutions”.

  • many reported quirks in the new App are promised to be in development for fixes.

  • the new Hub has significant limitations as to what will run locally because local code is packed and pushed with the firmware, thus deferring the ability for ad hoc Community developed Device Handlers and SmartApps to take full advantage of Hub V2’s number one feature (reduced latency and increased resiliency).

I have no problem agreeing that SmartThings appears to have no issues with releasing unfinished products; just look at the majority of their integrations that simply do not support what the devices are capable of. But shipping half finished, or with known bugs is different than sitting down and writing code that can’t be leveraged down the road. That is what I consider an ‘interim solution’; building something you know is going to hit the bit bucket sooner than later.

For me, this is something to be avoided at all cost other than loss of data or operability. I suppose you could consider having to redo everything from scratch as data loss, but not when folks aren’t required to upgrade (which is the case here).

Obviously there are a lot of factors to consider with respect to investigating in the development of a partial migration tool similar to that I described above.

Totally acknowledge that avoiding disposable effort may be the reason here and you could make that choice.

On the other hand, I actually don’t think the interim solution would be disposable, with at least a lot of knowledge gained, and possibly even all the code reusable!

In my opinion, this particular “interim solution” effort would be worth the cost for a few reasons. Certainly no one is forced to upgrade, but that does not negate the benefit and goodwill such a tool would bring to loyal and enthusiastic early adopters who have suffered from time to time due to the limitations of the Cloud-Only architecture of Hub V1.

Also noteworthy is that the arduous migration process is apparently required for replacement of failed hubs as well, even Hub V1s.

And even “interim” is subject to definition. SmartThings is casually quoting that the full (?) migration tool will be ready by the end of the year. I think we have plenty of precedent that that projected deadline is likely to slip… Perhaps significantly. Not holding my breath, and thus more and more folks will give in and migrate manually.

Possibly, but that is still their choice. There is (currently) no compelling reason other than non-rechargeable, battery backup to upgrade to the v2 hub. That may change before the official migration tool is offered, but what if it doesn’t?

I honestly don’t see this being that big of a deal at the moment, and heaven knows I have been one of SmartThings harshest critics, but I have no problem cutting them some slack here.

Conceded that you’re not the target demographic for the concern (and solution) that I address.

Compared to Mike with 40 hours of effort; much of which my proposal could have completed alleviated…

And Geko…

With all due respect, it took me the better part of a solid day to reset my system up on the new hub. I could have returned it and kept things as they were, but I chose to deal with it. That same choice is available to all.

But as per @scottinpollock’s observation, who is it that really has a need to upgrade from V1 to V2?

1 Like

This does appear to be the “question of the week”, but obviously the Hub V2 brings the “average user” (i.e., not us folks who customize and install non-official stuff) lower latency and higher reliability… And eventually more.

Whether or not this is “need” vs “want” is difficult to judge, but apparently there were enough existing customers who were on the trigger to upgrade and clear out the shop.

Not to mention the enthusiastic impatient expectations of 1500+ posting in this below Topic alone…

Anyhow… Discussions continue there suggesting that a migration tool will arrive by the time we feel compelled to upgrade based on improvements and activations of additional Hub V2 features. I’m less confident, while at the same time think my plan would be a step in the right direction regardless of who it helps and regardless of the Z-Wave and Zigbee device transfer issues which make up less than half of the migration effort in a highly automated home.

And with due respect, I feel there’s nothing wrong with suggesting that SmartThings is not doing the best they can to help those customers who upgrade have the most effortless and pleasant experience, with a feasible compromise.

I’ll just agree to disagree at this point, but appreciate the input you gave. Thanks.

OK, I’m reining this one back in a bit. This thread was meant to discuss a small tool that I feel would be helpful to customers and support even when a migration tool is in place. Although I very much respect everyone here (since you are all smarter than me on this), there are other discussions regarding the migration tool.

As an IT director, I backup and export things all the time. I just feel that a simple extract of SmartApp settings would be beneficial for many. This extract would be completely readable by anyone. For example, @bravenel’s wonderful Brighten When Open SmartApp that was a very welcome (and enchanting, to my wife and daughter) addition to our setup might look something like this:

SmartApp:  Brighten When Open
author: "t***@*****.net"

When This Door Opens...
    Sensor Door- Hall Closet

Select dimmers to brighten...
    Switch- Foyer

Set for specific mode(s)
    Home Evening

That is simply a combination of the SmartApp Preferences section and the settings for each preference. This is all that is needed. Obviously, some better formatting, such as bold and italic or color where necessary to identify each preference name and setting - I couldn’t do much in the code formatting here.

Something as simple as this would help everyone. I especially would live it when I decide to troubleshoot by removing several SmartApps and then re-adding them one at a time to determine where the conflict is. Or, just printing it all out so you could lay it on a table to figure out the conflict.

I would think that would be immensely valuable to support as well.

BTW - @bravenel’s SmartApp noted here is pretty damn useful and I recommend it to others. It really gives the house a “smart” feeling and people notice it all the time and comment on how cool it is that the closet knows we need more light. (The coat closet doesn’t have a light inside, but there is a recessed light right outside the door)

This really feels like it is a few hours work by a decent programmer to come up with a rough working version of this to begin testing. I’ve done web and database development before, so I have just enough insight here to be dangerous. :wink:


Actually, I stand corrected. This exists right now…it just needs a bit or polish (to make it more easily readable) and a way to mass select several SmartApps at once and then print or save them to a text file (or something like that). It’s in the IDE under Locations…Installed SmartApps.

@alex, @Ben - all we need is a way to easily save this info. It would be very useful to many.


As do I.

Hey Brian!

Thanks a ton for posting man! I appreciate your candor while providing a real world interim solution.

I’m going to ask around to see how much lifting this would take.


OK, I’m reviving this topic. I know some people will think I’m beating a dead horse here, but I feel it is really important and I see some pieces of the puzzle already in place. For example, the Replace button in some (but not all) things. How can this process not be extended from Replace to “migrate to new hub in account”?

Does the replace button preserve all links to existing SmartApps so I can truly replace a malfunctioning device without reinventing all it’s settings? If that is the case, why can’t this be extended to a migration tool since it already does part of the job?

Am I missing something so fundamental to the platform that is preventing a migration tool as we are approaching close to a year since v2 was launched?

1 Like

The replace button runs a Z wave replace hub utility which works quite differently from what you might imagine. So the replace utility itself would not be a good basis for a migration or restore tool.

In zigbee, each device has its own unique identifier. In zwave, each device is assigned a network ID by the hub at the time of initial pairing.

When you do a Z wave replace, the assumption is that an old device has become unusable and is no longer on the network. The human is supposed to have removed it physically.

Then when you run the replace, the hub first sends out an “are you there?” Message to the old device that you are replacing. If the hub does not get an answer, it then goes into join mode. The human should then put the new device into join mode. The hub then adds the new device to the network giving it the network ID that had Been previously assigned to the old device. And that’s it. You’re done. It never touched the smart apps at all. It is up to the human to make sure that the new device is exactly the same model as the one being replaced.

So the replace utility can only work with zwave devices. And all it does is take a previously used device ID and assign it to a new device.

It’s useful, but not the basis for a restore or migration utility.

1 Like