Bad Condition

Programming with the SmartThings API is recommended only for hobbyists with a great deal of patience. Samsung's SmartThings department seems to be the unloved stepchild of the organization's other divisions. Not only is the documentation inadequate and at times contradictory, even the source code of the hub core is inaccessible. Even worse, Groovy's own self-inspection mechanisms have been undermined so that not even go-getters can discover the true names of incorrectly documented attributes.

In the case at hand, a simple API call to ask the hub whether it currently is powered by the grid or the reserve batteries would have sufficed to solve the problem, instead of having to resort to Rube Goldberg-esque solutions such as the one I just described. If the hub code were open, dedicated hobbyists could fill in the gaps in the API on GitHub and make it a much better product.

The app keeps crashing, the web page for developing SmartApps has been cobbled together rather haphazardly, and serious functional flaws are evident (e.g., the Update button for changing a SmartApp's metadata does not work). If you think that developer access will work via graph.api.smartthings.com, you will discover in the forum that you need to stipulate graph-na02-useast1 instead of graph in the United States and graph-eu01-euwest1 in the UK; otherwise, the API won't find the user's hub equipment, who is no doubt busy tearing their hair out in frustration. They should be using the industry standard of sharding via the username instead.

However, there is a dedicated community that molds the breadcrumbs uncharitably thrown to it into working applications. The only correct strategy for Samsung has to be opening up the entire project, including the communication protocols used, and leaving it to the community to transform it into a maintainable platform with a future. There is certainly enough potential.