This is a whole industry issue. IoT is struggling. There are early adopters, but the masses could care less. I have spent thousands on a smart house this past year. Now that most my house is automated my spend will probably be a couple hundred a year.
With IOS 10, I think Apple has done the very simplest connected home automation well. They will sell some additional hardware with watches and an iPad on the wall as a control center. The rules engine is extremely simple, but it will work well enough for many people. Everything runs locally, but you do have out of building controls as well. So far all the individual devices that I’ve looked at are very good quality. I don’t see anyone saving money because there is a brand premium on these. But it will be fun and practical. And easy to use.
I don’t think it will meet the needs of most of the people on this Forum. Too simple, too expensive, and not enough device choices. But I think it will create more adoption of home automation.
So then it will be up to the next tier, including SmartThings and Insteon, to communicate their value proposition to those interested in something more powerful.
Home automation and IoT are NOT synonymous. Unfortunately, SmartThings has made their home automation dependant on the IoT. That’s a mistake; requiring needless complexity and IP traffic they can not reliably support.
Philips Hue got it right… running everything locally, unless you’re out of the house. Gawd help SmartThings if they choose to get deeper into HA.
It is unclear to me why SmartThings bet their whole platform on IoT that they clearly have been unable to satisfactorily support. I suppose it is based on big data and revenue generated by it. Google will soon be in the game, and they will be able to scale the big data whereas SmartThings hasn’t.
My feelings are that unless we see a major change in SmartThings strategy, they will be extinct within the next 2 years.
I know I have been considering HomeKit now as someone in the Apple ecosystem. Trying to decide how much complexity I really need. I want to still love ST, but the relationship is getting worn.
I struggle in HomeKit with the number of bluetooth devices in what I am reading…that apparently don’t report data unless you are near them (makes sense), so without a true hub other than the Apple TV it feels like perhaps its not going to be automated enough and remotely accessible as deeply as I want.
HomeKit is very simple, but it works well for most device categories. The Bluetooth sensors are completely useless, however.
On the other hand, the Wi-Fi sensors for ecobee work just like they work in any other platform.
And Phillips just today announced a Hue motion sensor to work with its bridge. We don’t know yet if that information will also be available to HomeKit, but at least it’s there for the Hues.
But, yeah, if you’re relying now on a bunch of different sensors, HomeKit isn’t going to meet your needs at present.
Speaking as an engineer, I’d be willing to give Robert Parker a year to get the culture changed from a proof of concept company to one driven by customer experience.
Of course engineers never get to make those choices, so Samsung will probably give him less time than that.
And he may focus first on getting things right for Samsung TV/camera owners, which isn’t a bad idea if he can actually succeed. There’s still a market space there and it would be a good fit with Samsung. But it has to be focused on QOS, reliability, set up simplicity, all that. It can’t affect customer evaluation of the television overall.
So it’s a challenge, but I imagine it’s an interesting one.
My 2 cents on migrating from the v1 to v2 (essentially hub replacement), it was painfully long. A few things I did to make it smooth:
- Added the new hub to the same account
- Have 2 phones running the ST app, on one open the old/dead hub and on the other open the newly added hub
- Open the IDE and click on the old/dead hub, for each device click an open in a new window and see list of connected smart apps
- Using the ST phone, one by one delete the device from the old hub and then add/pair it to the new hub
- Once that’s complete use the pages in step 3 to go an add all the SmartApps back for each device
- For “phone” presence device I went the old hub page in the IDE, copied the device DNI and created a new mobile phone presence device in the new hub and added the copied DNI to it and then deleted the device from the old hub. At first it shows as “present”, then you start the ST app on the respective mobile phones and it works perfectly.
One thing to note, if you’ve got a large multi floor house and you’ve got stuff all over, I would start by adding the PASSIVE devices FIRST to the new hub and starting with the FURTHER device. Reason being when a Z-Wave device in paired/included it sends a NIF (Node Information Frame) command to the hub to identify and include itself. NIF frames are NOT re-transmitted via active repeaters, hence this is why they say that new z-wave device should be very close to the hub when pairing it because the NIF needs to go straight to the hub. Hence if you don’t have any active devices in your network the chances of pairing a far away device with the hub increase dramatically. I was pretty much able to pair devices 3 floors apart using this strategy (because I REFUSE to remove all my z-wave device just to repair them). Finally I just had one device that was 4 floors apart and couldn’t pair, the good news is that the v2 hub runs on a battery, so I just took it up to the top and plugged it into the hub upstairs and completed the last pairing.
Finally then add the active repeater devices starting with the further away one (for the same reason as above) and work you way closer. After all this I did a Z-Wave Network Repair and so far I’m pretty impressed with the v2 hub. The mesh appears to be stronger, things are running faster, even custom DH’s seem to be responding better. So far so good.
This is no longer true with zwave plus.
More importantly, though, the protocol you describe only works if every device is within one hop of the hub. If your top floor far corner is more than one hop from the hub, it cannot be paired in place without a repeater.
Also, for most devices which are already wired in place, a minimote can be used for exclusion/inclusion. You shouldn’t have to carry a hub up three floors.
So a quick update on this, creating a new mobile presence device and copying the DNI does work fine until the v.2.2.0 app update. So if you look at the Mobile Presence DNI it looks something like this
The hubID is a unique mobile presence string assigned for a hub. So all mobile presence users on that hub will have the same hubID.
If you want to use the same trick to migrate your mobile presence devices from one hub to another, you first need to add a “real” mobile presence device (likely you own mobile from which you control the ST account, that will be the first mobile presence which will automatically get setup on your new hub). Look the DNI for your mobile presence on the new hub, extract the hubID from that string and then you can use that to replace it in the DNI for your other mobile presence devices from your old hub and create new devices in your new hub with the DNI from the the old hub but replacing the hubID with the new one.
Hope this helps.
Due to unusual, intermittent, but persistent problems keeping my hub online SmartThings finally sent me a new hub. Sadly, only after I received it did I discover there is no way to replace the existing faulty hub with the replacement. Starting over is not an option I am yet mentally prepared to do. I about 50 things including a 5 number of Enerwave relay switch modules wired behind the wall switches. I have several times used the IDE to add functionality I learned I could have from reading these forums, but I did that somewhat blindly by carefully following instructions, versus understanding everything I was doing. I am not prepared to completely rebuild this configuration. I am not confident I know everything I must do to make it happen.
I notice the most recent post in this thread is over a year old. What currently is the best process to replace a hub? 2.0 to 2.0 hub? How can writing a migrating tool and instructions possibly be difficult for ST to do? Why have they not done it? Why would anyone buy this system if they every knew if a hub failed they have to start over?
Thanks for the help. Help I hope I get.
Because they don’t know.
Because there are few viable comparable alternatives (the pros of SmartThings outweigh the drawbacks by far, IMHO).
Because the average SmartThings customer has fewer than 15 Things and thus “starting over” is relatively trivial.
Because even the CEO with well over 100 Things honestly said that his migration / hub replacement was accomplished in only a few hours.
Because “ya gotta have hope”: Hope that your Hub won’t fail. Hope that SmartThings will eventually deliver a migration utility … before your Hub fails and before you wish to migrate to the next Hub version.
I hear rebellions are built on hope…
I saw some discussion recently about Z-Wave Smart Start which would theoretically help in a migration for the in-wall type sensors. It doesn’t help the migration of automations, but that’s where tools like WebCoRE have stepped up to offer solutions. I’m honestly more concerned about the back-end issues that the community can’t build work-arounds for.
What I find most surprising is that it seems, due to lack of any apparent effort to ease migration to a new SmartThings hub, that the SmartThings folks appear to be the last people in the tech world to figure out that great migration tools help keep customers locked into a manufacturers product line. Having to start from scratch invites customers to once again check out the competition, both direct and indirect.
Dare I ask? What back-end issues are you referring to?
Mostly these ones:
iOS 2.5.0 - Release Notes - (Acessibility)
As well as some mesh issues that I can’t find any specific threads from.
I see this at work all the time. If the hub fail rate is 1/10000 and there are 100000 hubs, that’s 10 failures.
At four hours (probably a high estimate considering average user) a hub to replace, that’s 40 hours of work net.
How long would it take to develop the utility? Even at one million hubs, OR 1/1000 failure it’s still only 400 man hours. Even at 1/100 hub failures it’s 4000, which is two engineers full time for a year.
Sure, there’s marketing and goodwill, and sure you could argue my estimates. But we don’t really know the numbers do we? It’s easy to armchair this decision. I’d still buy ST today, nothing compares and I’ve replaced it once (upgrade). I actually enjoyed revamping my setup.
Just another opinion…
I do want to add one addition to my post. Upgrades from one hub to another by choice by ST customers is inhibited by lack of upgrade utility. So if 80% of the 100000 (or whatever number you use) customers want to upgrade, each of them has to make the estimate if the time for them is worth it. If the difference between is say 10% or 50% won’t due to the hours of work, then that could add a lot to the argument. For this reason, I think ST should do it for their own benefit.
However, it still stands to reason that it isn’t always a simple decision when you look at the data. Engineering resources are precious, even when it seems obvious to the individual customer, it’s not always good for the masses who need other things like reliability, features to support their favorite products, and updates to keep up with OS changes.
ST hasn’t shown any interest in iterating on their hub design to drive an upgrade cycle. The only feature of a v2 hub that I would be interested in is local control… except it’s been years and ST’s version of “local control” is still complete BS.
It doesn’t seem to me like $79 hub sales make ST any money at all. The profit driver for any cloud-based home automation company is always going to be monetizing user data. ST gets the exact same data off of my v1 hub as they do off of a v2 hub.
I totally agree with this approach. Perfect can be the enemy of good, in this case greaet!
Yup… Pretty much exactly what I suggested (and was willing to help build, frankly…) in August 2015:, with plenty of willingness to have a few brainstorming sessions, and lots of flexibility and experimentation and alpha testing, before doing the “rocket science”. And yes… NASA is just a few miles away from SmartThings HQ.