The SmartThings Cloud-First Approach

We’ve seen concerns expressed by a few folks on the dependance of the SmartThings solution on our SmartThings Cloud, and so we wanted to specifically address these concerns, provide additional detail, and explain the benefits of our approach.

As a starting point in understanding our approach, it is important to recognize that we believe strongly in the separation of “Intelligence” from devices. We believe that the time has come when devices themselves can be limited to their primitive capabilities (open/close, on/off, heat/cool, brew/don’t brew), and that the intelligence layer should be kept separate. By doing this we allow the intelligence (or application) layer to apply flexibly across a wide range of devices, and make it easier to create applications that interact with and across the physical world. In many cases, we also benefit from lower-cost end devices, less maintenance complexity and longer battery life.

A Phased Implementation of our Technology

We made the decision at SmartThings to support a “Cloud First” approach for our platform. This means that in our initial release, there is a dependency on the Cloud. SmartApps run in the SmartThings Cloud, so for everything to work, your hub does need to be online and connected to our cloud.

Our architecture is designed in a way that abstracts away from the details of a specific device (Zigbee, ZWave, Wifi/IP/UPnP, etc) and allows the developer to focus solely on the capabilities of the device (lock/unlock, on/off, etc).

That architecture looks like this:


Applications, or SmartApps, sit on top of that abstraction layer and the result is that SmartApps are easy to write, debug, and test in the SmartThings Cloud.

We made the decision to limit SmartApps to the Cloud in our first release because it allowed us to focus more on the experience of writing the applications and less on the mechanics of deploying that logic locally to the hub.

That said, we are actively considering implementation scenarios whereby we can distribute SmartApps to and execute SmartApps locally on the hub. These scenarios include two implementation concepts:

    1. First is support for local “Wiring”. What we call SmartApps Wiring is a feature that will allow simple SmartApps to request that certain “event-to-action” sequences run as close to the physical devices as possible. Wiring supports scenarios such as “when motion is detected on motion sensor A, turn on switch B” and allows those rules to be deployed locally within the hub.


  1. Second is full support for SmartApps event handlers locally in the hub. In this implementation, we would support the automated deployment of SmartApps event handlers (which are components of SmartApps) to the hub itself, further reducing the dependency on the SmartThings Cloud.

In all cases, we obviously recognize the critical scenarios where a loss of communications with the SmartThings Cloud could have a degrading impact on critical, local use cases and are being deeply thoughtful on how we minimize the risk of disruption.

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 I want to 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.

Lastly on this topic, keep in mind that because of the Abstraction layer, SmartApps developers never have to understand where or how devices connect to the SmartThings platform. All of that is hidden from the developer, so that whether a device (such as a Garage Door opener) is Hub-Connected or Cloud-Connected, all the developer has to understand is:


And that is really important to our vision of keeping it as simple as possible for developers, makers, and power users who want to write their own SmartApps!

Macro-Benefits to the SmartThings Approach

At the end of the day, there are a number of important benefits to the overall SmartThings approach that I want to summarize here.

    • Bringing Supercomputing Power to SmartApps and the Physical World – No matter how much computing power we put into the SmartThings Hub, there are scenarios where it simply wouldn’t be enough. Take for example the ability to apply advanced facial recognition algorithms to a photo taken by our SmartThings Camera (stay tuned) to automatically determine who just walked into your house while you were away. In the Cloud we can bring all necessary computing power to bear to solve for just about any problem, but if we are limited to local processing power in a hub, there will always be limits.


    • The Value of the Network Effect – Our vision is to make your Physical World Smarter, and we are doing that not just for our Hub and Devices, but for lots of different devices and scenarios. The easier that we make it to create that intelligence (through SmartApps), the bigger that ecosystem of developers and makers will be. As a consumer that will mean the power of choice and the ability to solve real problems with a solution that most fits your unique needs. As a developer or maker it means broad access to consumers and distribution channels for your product.


  • Increased Ease of Use, Accessibility, Reliability & Availability - By centralizing many capabilities into the SmartThings Cloud, we increase our ability to monitor, manage, and respond to any failures or other issues. More importantly, we can simplify the customer experience and make our solution easier to use than ever before. Further, we ensure that customers have an increased level of access and visibility. This is not a new trend. There are lots of examples where on-premise capabilities have migrated to the service provider because it improved the overall service reliability and customer experience. From Voicemail to email and web hosting to doing your taxes, local capabilities turn into successful centralized services when there are additional customer benefits to doing so.

Hopefully that clarifies where we’re starting, where we’re heading, and why some of the choices will likely never be either / or, but a range of functionality that elegantly spans from the local environment into the cloud.