I literally cannot like this enough. This is EXACTLY the issue with ALL ‘cloud’ based HA hubs. Why oh why anyone thought it was a good idea to start out like that I have no idea… There’s no point in Home Automation if by the time it turns on a light for me I could have just walked over and turned it on myself.
With the Hue lights, they are INSTANT. It might seem small and whiny to want my light bulbs to react instantly but it has a HUUUUUUUUUUGE impact on the end user experience.
The claimed “cloud latency” is somewhere around 1/10th of a second*. Unless you’re the flash, you’re not going to notice that being reduced to nearly 0.
What we usually “see” for lights triggered via motion sensors is pretty much all on the latency of the motion sensor in detecting you, and the latency of zwave or zigbee messaging, and the 2/10ths of a second (2 messages) for the motion event → cloud, cloud → switch event transfers. ALL you get rid of is the 2/10ths of a second if you get rid of the cloud.
A lot of people have reported latency with The Big Switch of a noticeable pause much greater than just hitting the Things tile. So it’s not just an Internet lag, it’s cloud. I see this occasionally at my house, although it varies a lot. But sometimes it’s a timed 3 seconds. Whether that would improve with local processing, who knows?
Let me clarify and apologise, that was a bit a bit of an unwarranted ‘attack’ on ST since I don’t even have the hub yet, that was actually an attack on Wink though I understand ST users have experienced similar issues, sometimes lights taking up to 5 seconds to react.
Regardless, using ‘the cloud!’ is still a silly idea for home automation, do you know what reacts in less than a nano second 99.99999999999999999999999999999999999999999999999999999999999999999% of the time? Going back to dumb light switches.
Or candles.
Seriously, I haven’t pressed a light switch in a couple weeks. But they are there should I have a burning desire to use one. Then again I am trained from several years of motion sensitive office lighting to do things like wave my arms around when a light turns off for no apparent reason 
Anyway, yep, it would be great if stuff worked a wee bit faster, and a lot more consistently. I still contend that a careful examination of event times should show that things are moving along at faster than human perception speeds inside the system - and latencies outside the system are often more to do with mesh network speeds and detection speeds (for motion based stuff, anyway) then anything caused by being in the cloud.
But hey, it’s all conjecture.
Here’s an example from this morning’s event logs
2015-07-01 5:19:51.139 AM PDT - motion detected (motion sensor)
2015-07-01 5:19:51.279 AM PDT - (switch) got On() command from smart app
2015-07-01 5:19:56.519 AM PDT - (switch) says it's on
So there is .15 seconds between motion being detected and switch getting on command. the 5 second delay in the switch saying it’s on isn’t due to “the cloud” - it was told to turn on .15 seconds after motion was detected - that’s what we’re going to get rid of in Hub 2.0.
No, walking across the room to turn on the light switch takes several seconds. By then, ST will have turned on those same lights from detected motion. It’s amazing how quickly one gets spoiled by this, and the very idea of using a light switch recedes. My wife has not been a fan of my “experimenting” with ST. But, she’s the first to ask why the lights didn’t come on in a room I had not even automated (yet).
Most of the time I get response times from ST well below 1 second. But, there are times it becomes 2 or 3 seconds, or even more. I’ve played with this enough to be certain those slow downs are the ST cloud. @Ben once said, in response to a complaining post I’d made, “this isn’t the expected behavior” (i.e., slow). Expected or not, it’s reality. It would be excellent if ST always gave 200 or 300 ms response times, and often it does – just not reliably.
And then there’s me… 
It takes me literally 4 to 5 minutes to physically turn on a standard light switch, if I can do it at all. And it’s tiring. (I’m quadriparetic, in a wheelchair with limited hand function.)
Touchless switches are better, the Amazon Echo is better yet. It’s now the preferred light control method at my house. 
To an extent, yes.
Someone somewhere make a very good point about home automation, I cannot remember where though. It was basically along the lines of “The moment you have to pull out your phone or fall back to how it was done before, home automation has failed” and he made a sort of good point, though I realise it’s never going to be as reliable as a switch+wire+bulb.
Also, please don’t get me wrong, this is unwarranted of me to be saying this on an ST forum, I’ll make it clear again, I don’t have any ST experience, just Wink so it’s unfair of me and I also want to make it clear that I’m all for home automation though I’m not quite as setup as you guys yet, mine is mostly bulbs:
29 Bulbs -
4xCree
20xGE Link
5xPhilips Hue
3 Locks - All Schlage… which I haven’t setup yet.
4 power strips -
4xUbiquiti mPower Pro (accessible over Ethernet and Wifi)
My next phase is motion sensors but I’m holding off to see what ST has in store for the next gen or seeing how the Gen6 Aeon MultiSensor works out. Very exciting times.
And honestly, given the zwave device update hack of using delaybetween to request a configuration report after sending the command, I’d suggest that accounts for most if not all of the 5 seconds…
WAN latency has never been the most concerning bottleneck… We may not have the best broadband in the world, but it is fast enough to support AJAX instant search results as we type in the Google search input box.
I think the experts say that < 300ms response is essential for acceptable lighting response. Glad to see examples of 150ms
(The frequency of WAN hiccups is probably also pretty low, though frequent enough that Netflix buffers at least 30 seconds.)
The performance with the SmartThings cloud based solution is inconsistent response due to load issues. Google & Facebook don’t exhibit this too often, but they have more server resources and perhaps better scaling architecture.
The main advantage that Hub V2 brings in this regard: infinite distributed scaling: a new dedicated processor is “brought online” for every new customer. It’s quite possible that 80% of the performance benefits of Hub V2 could have been achieved by placing these processes & processors in data centers, rather than the “edge” (customer homes). But the extra 20% is likely worth the complexity of physical distribution, especially if customers are willing to pay a premium margin.
Are there other ways that ST could have or still should scale? I certainly don’t understand why scheduling queues fall more than 20 seconds behind, but perhaps that is just a peak-load problem that is inefficient to resolve with over-resourcing.
The risk of distributing processing hardware is non-trivial, though. Hardware breaks. Firmware updates get corrupted (hi there, Wink). Hardware upgrades are costly. That’s why the cloud has become popular for many many services. Hybrid architecture will be a huge improvement for SmartThings once it settles in… And if they got they architecture right, and disciplined operations.
Wait… what? I have to relearn how to use the app? /end-sarcasm
Someone analyze this data… What is the real average WAN/Broadband outage probability for any day?
Well, that is true. Anything that hits web services or other cloud services will obviously need internet access. And then again - all events still do go to the cloud.
Are events going to the cloud asynchronously? The hub isn’t waiting for those events to be acknowledged – it just sends them? Obviously, the mobile app can’t update the UI for things until those events get to the cloud and thence to the mobile app.
Correct - this is not a bottleneck for control and automation in most cases. It is for notifications and logging.
I agree with Ben on this: if you have a lot of devices to migrate (and, don’t forget that there is no migration tool), why would you consider Hub V2, when Hub V3 based on the Artik chip will probably be released sometime next year?
The whole migration process could be even more painful when moving to Hub V3 (it’s a totally different chip AND cloud architecture)…
So, why do it twice in a relatively short timeframe?
The way I see it, by releasing Hub V2 for new customers, the existing Hub V1 customers could also benefit from better performances in the cloud w/o having to migrate to Hub V2.
What is then the marginal benefit for existing Hub V1 customers to migrate to Hub V2 (apart from video streaming)?
Better latency? Maybe, but let’s see the metrics first…
I’m sure that SmartThings has already done some extensive QA testing (including some performance and load testing) on Hub V1 vs. Hub V2.
If they can share some latency metrics (even compiled in a LAB environment), existing hub V1 customers could then make a better decision…
My 2 cents.
We’re launching a newly imagined SmartThings mobile app for Android and iOS (WP coming after).
We’re launching new platform features. Combined with the new app, we’ve referred to some of these changes as our “next-gen UX”. This includes us reworking a lot of the basic functionality and the layout of your SmartThings system on your phone and in the cloud.
The app is my biggest problem with SmartThings. I can’t wait to see what’s in store!
Thank you so much for listening. I will do a label dance to the SmartThings gods in your honor.
Agreed - much more interested in the new app at this point. I’ll wait a bit for hub 2 to “mature”
Today is April 30th. So I guess the Hub 2.0 will be released today? 
Sorry to be the bearer of bad news, On March 31st, we made an official announcement on our blog, referenced below incase you missed it.: