Hey all,
So as I continue to wrap my head around this… all SmartApps are stored and run from the cloud? Am I correct in assuming that if my internet is down (or the ST servers), nothing works?
How robust have ST’s servers been. Any of you experience outages?
There has been occasional blips. Of course it always happens at the worst times. Just don’t hook up medical equipment:
http://status.smartthings.com/history
I know there has been a lot of discussion about the vulnerability of the cloud. I might be a minority but prefer only the cloud. My philosophy is the Internet is a necessity regardless. It puts pressure on SmartThings to make sure it is always up. I use a Cradlepoint router with 4G access and UPS to address my connectivity.
That is great option if your internet connection is fragile or goes down a lot. We recommend it in those cases. We will always put an emphasis on the smarts of the system living in the cloud but we are researching some strategies for bringing some of the logic onto the hub at times. At the very least, for now, you get a notification if your hub loses connectivity.
We had our Internet interrupted for 10 days from an uprooted tree. That is when I realized how dependent we are to be connected. My family was upset they couldn’t play their games, use Netflix, submit homework, etc. They could care less about SmartThings.
Though most are concerned that SmartThings is dependent on an Internet connection, I’m more concerned that our lives are dependent on it. Thus, I could care less if SmartThings is distributing the architecture in hub II because the bottom line is I have to be connected for other things.
And just think about the fact that our (U.S.) govt. doesn’t consider the largest internet providers in this country as a carrier or utility. I’ve a generator I can fire up when the power goes out, but if my net was down for 10 days I’d have to move to a hotel. Couldn’t work, and 99% of the people I communicate with would think I died.
Go Google fiber!!!
We had our Internet interrupted for 10 days from an uprooted tree. That is when I realized how dependent we are to be connected. My family was upset they couldn’t play their games, use Netflix, submit homework, etc. They could care less about SmartThings.
I’m sure your kids were torn up for not being able to submit their homework 
As much as we might laugh - and I’m sure my daughter would love not to be able to submit homework (the modern equivalent of “my dog ate it”), I’m more concerned about the loss of being able to turn lights on and off (if I have switches replaced). I could care less about music, etc. If I can’t turn a light on, that’s a HUGE problem. We might as well not have power for days!
So, I think basic necessities should be the first things that ST addresses with an outage. Even reverting back to on-off, no dim, basic would go a very long way.
I see your point. Almost all my smart switches also work without SmartThings. If you use a lot of TCP or Hue, then ST is more critical at night at least.
The TCP I have are configured with a regular off/on switch including desk/table lamps. They work fine when the internet goes down. Just no dimming.
By the way, @scottinpollock, would that be Pollock Pines, CA?
Twack
@wackware
It would indeed.
I love that SmartThings is in the cloud. It’s what separates it from the rest and makes it so flexible. Without internet though, it just fails. I would like to think of my SmartThings as a security system too, so if someone cuts my internet, even my alarm won’t go off. 
The ability to have the hub sync with the cloud and copy the logic locally would save the day in this case. That way, if the internet is down it would still work. It would also make actions a little more snappy, especially for users who don’t have incredibly fast internet.
Does anyone know if this is even an idea SmartThings has thought of implementing?
Elk Grove here.
Wow, we almost have a West Coast Users Group now. 
Twack
@beckwith When you say the switches work without ST, I assume you mean they are controlling load, correct? 
Yes, switches load. I have two TCP lights that I use physical switches but they turn the lights on virtually. This allowed me to control a switch without a neutral. As TWAK points out, I can manually turn them on if ST goes out, but not very practical in my case. These are not in critical locations that I would be impacted by a ST outage.
Yeah, I think that is my only option. I have a thread on here about asking about a zwave switch that allows power to always be on but can still work like a remote - offering a way to control Hues (and other similar lights) in recessed cans without worrying about a family member or visitor turning the switch off. However, in that scenario, we would lose local load control and not be able to turn the lights on in an internet outage without using the Hue app (I assume that is local, I don’t have a Hue yet).
I really like the idea of the Hue and the options it allows, but the problem with an internet outage is vexing and will not meet the family approval factor. That’s why I would love to see some minimal functionality when offline - basically emergency functionality with the bare minimum. Lights is pretty much all I can think of, unless someone is using security or smoke detectors.
Could you use a hybrid approach? Have critical lights connected to controlled physical switches and “mood” lights controlled virtually? Eventually, the technology will catch up to your needs. I’ve heard some complain that Hue can’t give you a true white which may be another motivation to use both. Some LED strips are now including separate white as well as the red green blue to address this.
SmartThings can’t handle every situation now, but I personally am thrilled by what I’ve been able to do with it over the past few months. And though it is frustrating to wait for this or that app, device or feature, in retrospect, it has been a rapid pace.
That’s the exact approach I plan on taking if I make it down path far enough. Still working on wife approval factor. 
I fully agree. ST in the cloud is a nice development, testing and collaborative concept; but it’s not good for deployment and production. HA is quickly becoming part of the set of a house “features”, not different from electrical, plumbing, heating; you can’t force a HA system to rely on a cloud account and always on Internet connectivity.
I also have doubts on how the system can scale up if ST becomes reasonably successful and popular; can you imagine having myriads of zwave devices sending events from millions of households which then need to be processed by a single system in the cloud? I don’t see how that can work on the numbers ST can/should reach - and we already had a taste of that when a few weeks ago ST decided to shut down processing of non-state-change events (filterEvents: off) after their servers were brought down to their knees in several occasions…
I would encourage everyone to read this part of the SmartThings documentation for an overview of our philosophy.
http://docs.smartthings.com/en/latest/introduction/what-is-smartthings.html#what-we-believe
Excerpt:
Why Not Just Run All SmartApps on the SmartThings Hub?
Building for the Cloud first allowed us to focus on a more generalized developer skill set for SmartApps (meaning not firmware development) and get a robust solution to market more quickly. We thought that was important because we don’t want SmartApps to be the exclusive domain of firmware developers. We want the SmartApps community to be made up of developers of all kinds, and we’ve put a lot of energy into reducing friction for developers and makers. The Cloud-First approach allowed us to move quickly, and now we can iteratively move capabilities into the hub to support local SmartApps and reduce the dependency on the Cloud where possible.
That said, there are a number of important scenarios where the Cloud is simply required and where we can’t reduce or eliminate dependence on the Cloud, so let’s address each of those specifically:
There may not be a Hub at all! – We are currently witnessing an explosion of connected devices coming onto the market. This include lots of WiFi/IP connected devices from a variety of vendors (everything from plant sensors to garage door openers). The advantage of Wifi devices is that they can eliminate the need for a gateway device (hub) and connect directly to the cloud. We plan to support these types devices, both in a direct-to-cloud model and in a cloud-to-cloud model. When you consider the breadth of devices like this that are coming onto the market, it’s easy to imagine that there will be customers who want to be able to add intelligence to those devices through SmartApps, but that may not have a SmartThings Hub at all because all of their devices are directly connected to the vendor cloud or the SmartThings Cloud. Put simply, if there is no Hub, then the SmartApps layer must run in the cloud!
SmartApps May Run Across both Cloud and Hub Connected Devices – As a corollary to the first point above, since there are cases where devices are not hub-connected, SmartApps might be installed to use one device that is hub-connected, and another device that is cloud-connected, all in the same app. In this case, the SmartApp needs to run in the Cloud.
There may be Multiple Hubs – While the mesh network standards for Zigbee and Zwave generally eliminate the need for multiple SmartThings Hubs, we didn’t want to exclude this as a valid deployment configuration for large homes or even business applications of our technology. In the multi-hub case, SmartApps that use multiple devices that are split across hubs will run in the Cloud in order to simplify the complexity of application deployment.
External Service Integration – SmartApps may call external web services and calling them from our Cloud reduces risk because it allows us to easily monitor for errors and ensure the security and privacy of our customers. In some cases, the external web services might even use IP white-listing such that they simply can’t be called from the Hub running at a user’s home or place of business. So SmartApps that use web services will run in the Cloud as well.
Third-Party Hub/Gateways – We ultimately want to support third-party hubs/gateways/routers built to our interface specifications (for how to talk to our Cloud) that have a range of capabilities. Some may have the ability to run local SmartApps or Wiring, others may not, and we want to be able to handle the full range of scenarios here. That means that in some scenarios, local SmartApps or even Wiring simply may not be possible.
Here’s the problem right there in the first sentence. A successful system should put the end-user’s interests first, not make software developer’s job easier. 