It’s been a busy semester and I haven’t been able to find time to write. And the longer I wait, the more I feel like the next post should be really good to justify the gap. But, now it’s Spring Break and maybe I should just write something bad just to take the pressure off. 🙂 Here goes.
Yesterday, I was fortunate to have a visit from the former CTO of iRobot, the makers of the Roomba vacuum cleaning robot and perhaps history’s only profitable robotics company. Tom Wagner stopped by mainly to talk about the Human-Robot Interaction initiative my colleagues at Brown and I are trying to sell. But, since he was there, I took the opportunity to tell him a bit about the end-user programmable devices project. Blase Ur participated from Pittsburgh via a robotic telepresence device called a Vgo.
We demoed several programmable devices—a fan, a blender, and two strings of colored lights—and asked Tom for feedback. He was amazingly insightful and refreshingly forthright on a number of issues. Unfortunately, many of the juiciest tidbits he shared were prefaced with “Don’t blog this, but…”. Oh, well. But, one excellent comment he made that got us thinking was “How does your project relate to SmartThings?”
Mmmm. Well, I didn’t recognize the name at first, but SmartThings is a project that Vukosi Marivate brought to my attention as a great example of work relevant to end-user programming that was seeking funding through KickStarter. I probably should have followed up right away when he first told me, but I always feel very much teased by KickStarter campaigns. The pleas for funds are very compelling, but so many of the amazing ideas never materialize that it’s often a big letdown.
Briefly, SmartThings is a venture to create a networking infrastructure for programmable physical devices. In the words of their homepage, “SmartThings adds intelligence to everyday things in your world, so that your life can be more awesome.” Huh. Awesome is good. They’ve got over a million dollars in funding through KickStarter and three million in seed funding. They’ve got over 30 people working on programmable devices.
Their vision is to have a platform so that developers can create apps that interface with physical devices. They’ve got a cool hub that all the various devices in your home can talk to.
The hub acts as a relay station for messages between the devices and the SmartThings cloud server. Then, you can create apps that communicate with the cloud to monitor and control the devices. It’s even possible to reconfigure and automate the behavior of the devices. In addition to their own custom devices, they are hard at work making other wifi devices compatible with their system. All the devices I’ve bought for my apartment in the last few months appear in their preliminary list of compatible devices, which is very encouraging!
I think SmartThings is an exciting development, but it’s hard not to feel a little competitive with them. They did a demo of their system January 2013 that features the creation of an app that monitors a switch to turn a light on and off. The audience loved it. But, our upod project demoed precisely that same functionality (and more!) in November 2011. We had a cloud server, a switch, lights, and a programming interface. We didn’t have dozens of people and millions of dollars. We had a handful of undergraduates and a few thousand dollars for parts.
For me, the frustrating part is that nothing like SmartThing existed back in 2010 when we started. If it had, we wouldn’t have put the energy into creating our infrastructure and would have used theirs. But, we couldn’t use theirs because it didn’t exist.
Based on their demo, it appears that they have two programming interfaces for their system. One is very very close to the When-do interface we built for upod (which is, itself, inspired by the if-this-then-that design). In our experience, this interface style is extremely easy to use, but also quite limited in its ability to express anything beyond the most basic programming functionality. Their second programming interface is essentially raw code—lots of keywords and curly braces and colons. It provides much more complete functionality but at the expense that non computer scientists would find it impenetrable.
In the upod project, we experiments with a kind of middle ground, which is a fully functioning programming language that is friendly and easy to use. Specifically, we extended Scratch with blocks for listening to and controlling devices.
Looking ahead, we think there’s a lot more that needs to happen to make device programming friendly for the end user. In particular, real-world devices get their information from real-world sensors. Whereas if-this-then-that has recipes that can be specified with absolute precision like “When a new book is added to Kindle Top 100 Free eBooks, send me an email”, real-world sensors are more vague and messy. Consider a recipe that appears in a screen shot in SmartThings’ advertising video: “when it’s going to rain, check if Barkley is in the yard”.
It’s a perfectly reasonable recipe and exactly what you’d want to be able to say as an end user. But, questions like whether it’s going to rain or if a dog is outside hide a tremendous amount of complexity about how information is gathered from the physical world. I think it’s terribly unlikely that SmartThings has this functionality working in a way an end-user can leverage yet. But, it’s a lovely and important research question. And, it’s what I’m anxious to work on assuming SmartThings really has solved the infrastructure problem. I can’t wait until summer!