I would encourage everyone to read this part of the SmartThings documentation for an overview of our philosophy.
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.