SmartThings Support for Current and Evolving Standards

Jeff Hagins Updates 2 Comments »

We’ve been getting lots of questions about support for additional standards here at SmartThings, including standards like WiFi, UPnP, Bonjour, and MQTT, so I wanted to take a minute and give everyone some perspective on these things.

There are a variety of initiates across the industry to create ad-hoc standards in support of the Internet of Things. These include MQTT and AllJoyn, but also existing de-facto standards such as UPnP, Bonjour, and others.

MQTT is somewhat different from the others in that it is focused on solving the problem of getting events (message), from the devices that generate them, delivered to the systems/services that want to make use of them. While there are standards for local connectivity of devices (Zigbee, Z-Wave, AllJoyn) and service discovery (SSDP, Bonjour, AllJoyn), there really are no standards for guaranteed message delivery of events across an intranet or the Internet for connected devices. MQTT aims to solve for this by providing a protocol and framework that allows devices to publish message, and for consumer systems to subscribe to those events and receive them, without needing to understand where they are coming from.

MQTT is a publisher subscriber protocol that, if successful, will enable platform interoperability among many different IoT solutions. SmartThings plans to make use of MQTT as a protocol in the future, allowing MQTT compatible devices to be able to work with the SmartThings Cloud.

In fact, all of these efforts at standardization are things that can be adopted by SmartThings in order to broaden our compatibility with devices and other system. For example, we are already working on UPnP support for local WiFi connected devices.

New Resources Added

Ben Edwards Updates 2 Comments »

We’ve made several updates the the Build Site. Most notably the addition of projects functionality. In addition to the ability for members of this community to create and mange their own project blogs we have also just published an overview of the cloud service portion of SmartThings and why we think it is important, as well as a preliminary List of SmartThings compatible devices.

These updates were posted in the (growing) Resources section and so I wanted to highlight them here as well.

Tech From Around The Web

Andrew Urman Things, Updates 2 Comments »

Integration is important. Being able to easily add and configure devices other than our own is something SmartThings fully encourages. That’s why we like to keep our eyes open for emerging products, Kickstarter innovations, and all around cool stuff from around the web.

LIFX / Hue / Spark  / iLumi

One of the most common goals of home automation is the ability to remotely control home lighting. Thankfully, a few products are making it possible. Two Kickstarter projects, LIFX and Spark, have proposed two different means of control. Spark’s method is to place their device between the bulb socket and the bulb. This device connects to your Wi-Fi b/g/n network and to their cloud system. With a dimmable bulb, the Spark system can be controlled manually or programmed to react to different web events. Example functionalities include turning your lights on with your alarm clock and flashing the lights when you receive a new email. Spark’s RESTful API will soon be openly available. LIFX is another Kickstarter lighting system, but different from Spark because users will just replace the lightbulb rather than installing an additional device. LIFX will use LED bulbs which will allow you to control on/off and the bulb’s color. The connection method is a master/slave mesh network that uses the IEEE 802.15.4 protocol. There is a master bulb that connects via Wi-Fi and all other bulbs connect to the main bulb. The Phillips Hue system uses the same basic idea. A user replaces their current bulbs with special wireless bulbs that connect to a base station using the 802.15.4 mesh networking protocol. The base station connects to the Internet using Ethernet. Hue uses the open ZigBee firmware similar to SmartThings, specifically the ZigBee Light Link profile. SmartThings uses the more generalized HA (Home Automation) protocol but we are hoping integration down the road is possible. Both Phillips and LIFX have SDKs planned for the near future. Indigogo may not be as well know as Kickstarter but it may be the next big thing in crowdfunding. Hopping on board that train is, iLumi – yet another LED lightbulb “solution”. Claiming their “patent-pending HyperLux LED technology” is brighter than others and bringing Bluetooth to the table are two of the ways iLumi is hoping to distinguish itself. It is a great looing bulb but like all of the aforementioned, still very pricey.

Twine

The folks at Supermechanical have developed a neat device called Twine. As they put it, “Twine is the simplest way to get the objects in your life texting, tweeting or emailing.” The goal of their approach is simplicity. The rubberized square device connects to your Wi-Fi network and has a very simple interface reminiscent of “If This Then That.” Starting at $99, the basic Twine can sense temperature and orientation. For a bit more money, you can add moisture and/or magnetic sensors with vibration detection (forthcoming). Twine also has a great open hardware/software solution with the option to use a breakout board and various methods of connecting with other services. In fact, Twine and Spark have worked together to turn the lights on in Minnesota when a door opens in Texas!

Digispark

If you’re standing in the SmartThings maker lab, no matter where you look, you’ll see at least one Arduino open source microcontroller. Arduinos come in various shapes, sizes, and flavors, but one of their main benefits is the ability to use shields. Shields are devices you can plug into an Arduino to give it added functionalities, like a motor shield for a robot or an Ethernet shield for connecting to the Internet. Shields are made by multiple companies for a myriad of applications. Here at SmartThings, we use one to connect to our hub. One of the drawbacks of shields is that they mostly fit a certain size of Arduino. For many projects it wouldn’t matter, but what if you needed a smaller microcontroller that was inexpensive enough to leave in a project? That’s where Digispark comes in. Digispark has developed a very small and very inexpensive open source microcontroller that is Arduino-compatible, allowing you to use the Arduino programming platform at a smaller size and cost. The best part? They offer plenty of shields that work with their system, including motor shields, RGB LED shields, and infrared shields. They’re even planning a SmartThings shield!

Designing the Internet of Things

James Stolp Presentations, Updates No Comments »
ignite2

This week has been an exciting one so far for the SmartThings team at Le Web. It’s my first time in Paris, and I’m here with co-founders Ben Edwards and Jeff Hagins. We’ve seen some great speakers and have met many people with big ideas for the Internet of Things, which is the theme of the conference. On opening day, Jeff shared the SmartThings vision of an open physical graph with the world from the main stage, and announced the Maker & Developer Contest Series.

Jeff and I were also invited to present 5-minute “Ignite” talks this morning. 5 minutes. 20 slides that start and move automatically while you speak. What a challenge! My talk topic was “Designing the Internet of Things”. Even with solid prep and rehearsal, my talk went off the rails early on. I feel like I recovered some in the middle and towards the end. The format really is tough! All in all it was a great experience. You have to start an illustrious career in public speaking somewhere, right?

While the live presentation was a little rough, I couldn’t be more passionate about design’s role in the evolution of the Internet of Things. I believe that we will only succeed working together as a community, sharing our ideas. So, let’s start the conversation.

Design + technology. It’s not one or the other.

As a designer that loves technology, these really are super exciting times. Thanks to recent efforts from designers, developers and brands that have focused on creating products that are beautiful and easy to use, design has permanently become part of our internal dialog that guides our decisions about what new things and services we add to our lives.

Design can drive global adoption of very complex things.

Careful design, iterated over time and working hand-in-hand with advances in technology, plays a critical role across the three graphs in the evolution of the Internet. It’s true for the knowledge graph. It’s true for the social graph. And it’s only just beginning to impact the emerging Internet of Things, or physical graph.

Consider the knowledge graph: everything we know made digital. It’s something we take for granted now, but it never ceases to amaze me when I stop to think about it. All of the world’s knowledge, data and experience. Indexed. Easily searched using simple and elegant interactions. Available at the tips of our fingers, within seconds (or less!), anywhere in the world.

And what about the social graph? Our relationships are now digital. Not that long ago, it would have been difficult to imagine that we would be connecting with so many others – friends, family, coworkers – online and sharing so many details of our lives on a regular basis.

These graphs are infinitely complex (and the physical graph promises to be just as far-reaching), yet they have been adopted by and now influence a large portion of the global population. In no small way, iteration of the design of the user interface and interaction model has allowed this kind of mainstream adoption to happen.

Design can integrate new technology seamlessly into daily life.

Think about a common scene. Perhaps a group of friends at dinner. The knowledge and social graphs have likely played a role in just about every aspect of that moment in time. The friendships, the time to meet, the restaurant, the food ordered, the clothes worn, the discussion… everything. We often don’t notice just how seamlessly these amazing technologies have been integrated into our habits, thinking and way of life. When the product or technology “gets out of the way” and people are just living better lives because of the physical graph, we will have succeeded.

This hasn’t happened yet for the physical graph.

I believe that one of the biggest reasons (and there are many!) that the vision and promise of the Internet of Things hasn’t been realized yet is that design has not been effectively and thoughtfully applied in the space. This isn’t just the look and feel of the software, or the enclosure of a piece of hardware. Designing the physical graph is about a complete view of the customer experience. Design strategy needs to be planned, and decisions need to made, for so many details across software, hardware, electrical engineering, manufacturing, support, packaging, marketing… and the list goes on. We have a long way to go, so we need to get started now.

We don’t need to start from scratch.

So, it’s time to finally pair design excellence with technological innovation for the physical graph. But where do we start? Fortunately, while there are new challenges to overcome, we’re not starting from scratch. We can look at what’s worked for the knowledge and physical graph as a starting point, and build from there. I think the building blocks that follow are a great starting point for anybody or any business that’s building for the physical graph.

Make it easy.

This is a lot harder than it sounds, for sure. The sources of friction in the user experience of your product will seem endless. I like to think that means boundless opportunity to do better! Pay unrelenting attention to the details of your hardware and software designs and ruthlessly eliminate friction to reduce the time it takes for somebody to start realizing value.

Take the time to map out the complete flow of interaction with your product: pre-purchase, the purchase itself, pre-delivery configuration and setup, delivery, unboxing, installation (hardware and software!), first use, maintenance, getting help when there’s a problem, and more.

Consider every step. Prototype and test as much of it as possible. Ask for others to try things. Listen to what they say. Were they ever confused about what to do next? What takes longer than it should? Was something confusing or physically hard to do? Were instructions easily understood?

Then, step back and look at the big picture. There will be some low-hanging fruit and things you can improve quickly. You’ll also see some of the tougher challenges, and you can begin to design solutions. Develop a plan for making improvements and get started.

Make it intelligent.

Intelligent solutions built for the physical graph will do more than what’s possible only with computing power and information available locally to an individual device. Effectively tapping into the incredible amount of raw processing power, context, history, collective intelligence, personal data and rich world of web services in the cloud will allow the creation of truly intelligent product experiences that learn, adapt, and anticipate in ways that will seem magical.

Software development has been revolutionized by a world of programmable web services, now it’s time for the same to happen for the Internet of Things.

Make it open.

Read this update to find out what we mean when we talk about creating an open physical graph. We believe it’s the right path, and are focused on making it real. From my perspective, one of the most important benefits is the potential to maintain simplicity and elegance of the user experience while also making possible scenarios incorporating a very wide range of devices.

People should have control and flexibility to make their world of connected things react in intelligent ways. As you design, be thoughtful about how your project will interact with other projects, devices and services without creating unnecessary friction in daily use.

Make it mobile.

“Mobile first” has been talked about a lot, so I won’t spend too much time on it here. But it’s important. Smartphones are everywhere and are fast becoming the most important interface to the knowledge graph and social graph because they are with us all the time. As we develop for the physical graph, this is even more true. The physical graph will literally be all around a person, and their smartphone will be with them as they move through it.

Beyond control, alerts, discovery, and configuration in smartphone software, however, the smartphone itself should be considered an integrated part of the physical graph itself, providing sensors and tons of useful context and data that can be used to personalize the user experience and make what we do that much more intelligent.

Make it beautiful.

Deceptively simple. 100% essential. In all of its many forms, beauty in design can create emotional connections between people and their things, which is an important factor for mainstream adoption of new technology. People like to fill their homes and interact with objects that are appealing to look at and fit well into their own decor. Building products for the physical graph has the added complexity of requiring beauty to span software, industrial design, marketing and more. Don’t neglect any opportunity, no matter how small, to make something beautiful.

Make it agile.

As designers, sometimes we need to learn new tricks. With software developers leading the way down the agile path, the designers that work together with them have adapted and adopted agile methodologies and processes into their process of creation. For me, at least, being agile is about increased responsiveness in rapidly evolving markets, and also having greater resolution and control over delivering a product experience that is matched to real-world needs.

Now, designers, developers and engineers building projects for the physical graph have to fit together both software and hardware product development, keeping them perfectly in alignment. It’s still early to say exactly where we’ll end up, but recent innovation in industrial design and manufacturing are now introducing the opportunity to be increasingly agile in hardware development. Design strategies that acknowledge this new reality and effectively embrace it will win.

Make it together.

It has been a process, but the best progress that has been made on the Web over the years in beauty, manageability, ease of use, accessibility, and usefulness have come about through an engaged community. Collaboration. Discussion. Disagreement. Competition. But in the end, working together to make the Web a better place. The same is true for the physical graph. Software and hardware. Designers, developers, engineers, enthusiasts, hackers, makers, and businesses. A diverse ecosystem needs to engage as a community in order to ensure that now is finally the time that the physical graph goes mainstream.

Add it all up, and we’re making it livable.

Incredible complexity, intelligence, and an ever expanding world of connected things that responds to my presence. The potential for friction in the user experience surrounding the physical graph is enormous. It will take focus, determination, and attention to every design detail to truly make the physical graph livable, to see it cross over into the global mainstream, and to see it influencing every aspect of our lives as the knowledge and social graphs do today. This is the real promise and potential of the physical graph.

Let’s keep the conversation going!

I hope that these thoughts are useful to you and your own approach to design and development for the open physical graph. I’d love to hear what you think. What you would add to the list? What do easy, intelligent, open, mobile, beautiful, agile, together, and livable mean to you? Let’s design the physical graph together.

// Attribution: the photo of James at Le Web is courtesy of Le Web.

Choose Contest Series Themes

SmartThings Updates 1 Comment »
ContestHero2

Thanks for participating in the SmartThings Developer and Maker Contest. There are so many amazing ideas out there; we’ve had over 2,000 ‘Wouldn’t it be smart if…’ submissions since we launched on Kickstarter. They all deserve to be realities, but in order to focus this round of the contest, we want to narrow the submissions to the top 5 themes that most of the community is ready to see in their lives.

To help us do that, please choose up to 5 themes from the following list in which you would most like to see your life get smarter, more automated, more controllable, and more fun.


View Results

Loading ... Loading ...

You need to be registered to vote. It only takes a second to sign up and be sure to check the box to join the ‘Contest Series’ group.

SmartApp Web IDE

Josh Reed Updates 3 Comments »

A key component of the SmartThings vision are the SmartApps.  SmartApps interact with your SmartThings, as well as online and other services, to make the world around you smarter and your life easier, more convenient and fun. It could be as simple as a SmartApp that turns on the entryway light when you open the front door or as complex as a SmartApp that learns when you wake up and what temperature you like it.  These are just a few of the ideas you came up with already.  We expect that as you get your SmartThings, you’ll have even more ideas for SmartApps.  So we’re obviously going to need great tooling to help you implement all those great ideas.

One of the tools we’ve been working on is a web-based IDE that lets you build and test SmartApps in your browser:

SmartApp IDE
The SmartApp IDE

If you’ve used other IDEs, hopefully you’ll see a lot of similarities.  The SmartApp IDE consists of four main components: the editor, the preferences, the devices, and the console.

Editor

The Editor is a pretty standard affair.  It offers line numbers and code syntax highlighting.  If you have compile errors in your code, they will be highlighted when you save.

Preferences

The Preferences area is where things get more interesting. Any non-trivial SmartApp will declare a set of preferences for the SmartThings and data it operates on. For example, if the SmartApp turns on a light when a door is opened, it would declare a preference for a contact sensor (the door) and a switch (the light). When a user installs the SmartApp on their phone, she would be prompted to choose specific SmartThings to fill the preference slots. The Preference area provides the same function; it allows you to choose the specific virtual or real devices you want to test your SmartApp with in the simulator.

Devices

The Devices area shows the state of the SmartThings that the running SmartApp is configured to use. These can represent real SmartThings that you own, in which case when you open a contact sensor, the state of the device in the IDE would update and any effects from the running SmartApp will be triggered. The devices can also represent ‘virtual’ SmartThings. You can interact with these virtual devices by clicking on them in the IDE. This will update their state and send the appropriate events to the running SmartApp. This allows you to develop and test SmartApps for SmartThings you don’t actually own.

Console

The Console area shows the logging output from the running SmartApp. Any logging statements you put in your event handlers will show up here.

Help & Examples

Since starting from scratch in a new language can often be a daunting task, we also provide links to the SmartApp developer documentation as well as source code for some example SmartApps. You can pull in an existing SmartApp as a starting point and be testing it with virtual devices in a minute or two.

SmartApp IDE Help and Examples
The Help and Examples menu in the SmartApp IDE

We’re really excited about how the SmartApp IDE is progressing. We’re already using this tool, today to create and test SmartApps and we hope to roll it out to everyone very soon.

An update on all those SmartThings

Ben Edwards Updates 13 Comments »
SmartThings_MS_test2

As a group, those of us building SmartThings have worked together for a number of years in an agile fashion. We iterate, tweak, adjust, change, and otherwise break and fix things in rapid succession. Now, we’ve brought that style to the world of hardware, and while we are happy with where we are now, the repercussions of this method in hardware are a bit different than in software. With circuit design, physical testing, firmware development, battery choices, enclosure designs, material selections, and so much more to consider, I am surprised we have come this far, this quickly. Here is a run down of where we are for each Thing (and the hub):

SmartThings Hub

To simplify the FCC certification requirements, speed development, and meet deadlines we made the decision early in our Kickstarter campaign to remove the cellular and Bluetooth radios. This allowed us to do two great things: add a Z-Wave radio to accomodate those devices people may buy “off-the-shelf” and change the power requirement so that we need only a Micro USB power cable that will make it much easier for our international backers and customers to use in their countries.

We’ve replaced the ZigBee radio with a chip that uses our custom ThingModule firmware. It also includes a ZigBee radio. With each of the ZigBee and Z-Wave radios we’ve improved the antennas and we boosted the power of the ZigBee radio so that signal strength won’t be a problem across the average home.

Motion Sensor

We’ve changed the battery clips for the motion sensor after finding that it was sometimes easy to knock one or both of the AA batteries loose. We’ve also added a USB power option in the event that some want to conserve batteries and just leave the sensor plugged into the wall or a computer. We’ve designed the enclosure in a way that allows for it to stand in multiple orientations or be mounted in the corner of a wall or ceiling. Though you maybe cannot tell from the photo of the 3D print above, we’re still not quite happy about the size (too big) and have revised the design and are printing the first copy of the new design at the office today.

Contact Sensor

More power tweaks: In an effort to make sure we hit our goal of measuring battery life by year between replacements, we altered the contact sensor to use 2 AAAA’s (yes that is 4 A’s) instead of the coin cell batteries we were using. We’ve also replaced the magnet we were using but that decision and the enclosure design are still in flux.

SmartTags

Last but not least, here is a run down of the changes we made to the multi-sensor SmartTag: After breaking several battery holders we changed it out for a sturdier way to hold the coin cell battery in place. We also decided that it was worth the delay and changes to the enclosure for the SmartTag to add a speaker. This will add some functionality to perhaps find your keys with a beeping sound. We’re sure there will be a lot more uses for the speaker, and we’re excited to see how it ends up being used in SmartApps.

The SmartTag hardware, in full enclosure, was submitted for comprehensive FCC certification testing. The battery of tests is impressive! Covering duty cycle, bandwidth measurements, radiated measurements for the integrated antenna and peak power output, and spurious emissions within the frequencies we use. It has passed all of its tests and is compliant with all applicable FCC guidelines and regulations. The FCC filing itself is now underway. The team is excited and proud of this milestone.

As you can see we’ve been making changes but we are finally seeing the results of those efforts and we’re excited to share them with you. We’ve got more in store very soon, too. Look for an update for details of a new web-based IDE that you can use to create virtual and real SmartApps.

Welcome

Ben Edwards Announcements, Updates 1 Comment »

We’re excited with the enthuiasm we have seen from ouf first group of makers and developers who backed us throughout our Kickstarter Campaign. Over 750 of you have stepped up as desiring to help bring the SmartThings platform forward in new and as yet unimagined ways. Over the next few weeks we are going to be inviting more and more people to this site to share with us and each other their ideas and thoughts about SmartThings.

We will be posting pertinent information to the blog and creating additional content to help guide the community of hardware hackers and software developers as they embark on this journey with us. For now, please find the pages titled Enabling the Community with SmartThings Technology and SmartApps Developer Overview for more information.