If that’s the key value proposition of SmartThings, they’re doomed: both OOMI and HomeKit have far simpler device add processes. (Oomi’s is patent-pending.) For that matter, both vera and Fibaro are at least as easy for adding a zwave device as SmartThings, and easier for some device classes.
To me, it looks like the key value proposition of smartthings is the openness and flexibility of its multi protocol platform, combined with a DIY price point.
But “all home automation is local.” It may be that the value proposition is different for different people, depending on their background and use cases.
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
I don’t dispute that you are helping a lot of folks out… On this topic and countless others. Don’t get me wrong… This Topic will be appreciated by many, and I’m probably interrupting
Oomi doesn’t exist yet… And HomeKit barely exists.
I certainly think that SmartThings actually is focused on the DIY novice market, even if with questionable success. Ease of setup is the #1 reason for good reviews (partly because reviewers don’t go much further than that!!!).
I can only assume that the majority of “average Customers” (i.e., a non-trivial number of which are novices and most certainly ave never signed onto the API website) have a trivial number of Devices and SmartApps installed, and thus a full manually cascading remove and re-installation / reconfiguration of every single shortcut, group, and SmartApp won’t be a deal-breaker. SmartThings has this data (number of Devices and SmartApps for every account) and was able to make an informed decision that even slightly assisting migration tools were not worth the the effort.
Not my circus, not my monkeys, I guess.
My background is in large database management. I have done obscure data migrations and subsequent integrity validations. I actually enjoyed it… Set manipulation is inherently fulfilling.
It’s incomprehensible that this wasn’t addressed pre-release. I suppose those who are rushing to upgrade know what they are getting themselves into. Or maybe a lot don’t. New Customers won’t have to deal with this until some have Hub V2 failures and are told that installation of the replacement requires hours and hours of tedious effort.
Just like TV install services. People buy a Roku, a sound bar, and harmony. A lot of people can put all of that together themselves, a fair number of people pay somebody else to do it.
I also wanted to mention that migration of smart apps would be specific to smartthings and could potentially be done as a software option. Or, you know, maybe someDay we get a rules engine which allows us to copy rules, in which case things get a lot easier.
Unfortunately, it does not work well with “intelligent” controllers that have a lot of metadata associated with each device. I.e. if you shift Z-Wave network from one ST hub to another, you’re going to end up with multiple “Contact Sensors”, “Switches”, etc. and will have to figure out somehow which is which.
CORRECTION: @JDRoberts reminded me that ST hub does not support Z-WAve Controller Replication command class, so controller shift is not even an option with ST hub V1.
ST hub V1 does not support controller replication, and as the current primary it would have to give the permission. We don’t know yet whether ST hub V2 will support controller replication or not. While it would be nice to have, it still wouldn’t help migration from 1 to 2 unless they go back and also add controller replication support to V1. And even then you’d still have the metadata issue you already mentioned.
While we are talking about migration… How do we handle virtual devices? Will they just show up on the new hub? Or do they have to be deleted and re-created as well? I have plenty of virtual devices that i use. Any guidelines on that from anyone?
Is there yet a fix for the forever open bug where you can’t delete a device that was authenticated with IFTTT or Ubi? I have a few stranded dead devices that still have the IFTTT (and I think Ubi) smartapp associated with them. I can’t successfully uninstall the smartapp thus these long gone Things can’t be deleted either. I tried removing the devices within ST – IFTTT authentication, not used in any IFTTT recipes. But ST still won’t uninstall the smartapp and won’t let me force delete the device. These devices still show IFTTT as an installed smartapp.
I think the workaround to the long standing bug is to remove the entire IFTTT authentication with ST. i.e. remove the SmartThings channel from my IFTTT account. I can’t afford the pain of doing that since I have so many recipes and Things connection. Doing so would blow away all my IFTTT recipes for ST devices. I would rather just update those recipes to point to the new devices on the new v2 hub if I upgrade. The migration would be even more unnecessarily painful if I also need to destroy all my IFTTT SmartThings recipes which allow integration with a couple dozen of my things with other services.
And before you say politicians are just salespeople, no, they’re not. I’ve occasionally come across an honest salesman, I’ve never wanted to slap some sense into a salesman and an idiotic salesman has never made me cringe in embarrassment for how my country is portrayed on the world stage.
Virtual devices itself needs to be readded to a different location. If it’s custom SmartApps or Device Types, you don’t have to reimport the codes. Anything that doesn’t depend on a hub can be migrated now by creating a new location and leaving it hubless.
I believe that new hub has to be installed in the new “location”, which means that you have to re-install all SmartApps and re-add all devices. You may be able to run two hubs in parallel and gradually migrate your setup, but locations cannot share devices or SmartApps. If it’s too much pain, you should wait for the migration tool to become available. No one said you must upgrade your hub on day one. Your V1 hub will continue to work.