@joel_eggenhuizen (et al.):
Folks here have the right concept: Using the REST API, SmartThings exposes a heck of a lot of views of status and some degree of control of your “SmartThings” (i.e., any object known to the Hub that can be exposed through access tokens).
Regarding your comment comparing UI approval to the iTunes approval of Apps; the comparison is more like Dropbox approving various Android apps and web project management services direct access to your documents, or backup software that writes directly to Dropbox, etc. (i.e., Dropbox provides a Windows Explorer / Mac Finder plug-in and a web interface for managing your files; but anyone with an API key can develop alternate front-ends.
There are hundreds (thousands?) of examples of this; to varying degrees of applicability to SmartThings.
So the model and the building blocks are in place, but various questions remain which need time to explore:
- Is enough of SmartThings "exposed" through the API to produce rich and comprehensive interfaces? I believe, for example, that "Add / Discover Thing" is not exposed, and there are decent reasons for this; but it is an example limitation. But what about useful "hidden" attributes of devices, or ways to tune the refresh rates, etc.?
- Will SmartThings ever change the API or add restrictions (or fees) that essentially destabilize alternate front-ends? A real-world example of this, if I recall, was changes that Netflix made to the ability of developers to read users's movie watching history or similar. Some developers wrote fancy reporting tools or queue management tools that were completely disabled by Netflix's unilateral changes.
- Is the SmartCloud (through which the API connects) robust enough to handle requests that are not tuned the way that the proprietary GUI (iOS and Android Apps) are written?
- Is there ever going to be a way to talk directly to the SmartHub on the user's LAN, instead of requiring the extra latency (and connectivity risk, and security/privacy risks...) of the SmartCloud?
- Is it conceivable that SmartThings might actually "open source" the SmartCloud so that developers could provide alternate cloud servers (including internally inside corporate networks, or in a VAR (value added reseller) infrastructure, or on a PC in a consumer's home? If not "open source", would SmartThings consider offering these options for purchase? Consider that "Github" is an excellent web-service, but it can be purchased by businesses desiring their own internal git servers (lots of important reasons businesses desire this ... all the benefits of Git, fewer risks, though maintenance of the servers is now a cost...).
- What are possible partnership and revenue models that SmartThings can facilitate for UI's? I think it is pretty obvious that SmartThings is putting a lot of thought into how "SmartApps" can be published and revenue collected for the developers; but if "good" alternate UI's come along (possibly produced by competitors -- e.g., control your SmartThings through the GUI of WigWag or Ninja or Control4, ...) SmartThings needs to have a strategy and policies in order to keep the ecosystem organized and maintain profit in a sustainable and fair manner.
Many ways to look at this problem; but consider this: While there are various standards of steadily improving rigor for “things” (Zigbee, Z-Wave, Bluetooh, IPlo?), there aren’t any standards for the presentation layer that allow seamless plug-in of already connected Things from one hub to another, with or without “cloud” involvement.
Standards at this level may be overly restrictive and take far too long to stabilize; yet that would give the most “plug-and-play” functionality for UI components. In the meantime, though, either well-resourced and/or highly-creative and motivated UI developers are going to build or extend their frameworks to interface with proprietary and/or open, but published, interfaces, such as the SmartCloud API.
My assertion is that it is reasonable for these enterprises to hope for a revenue stream from their efforts.