Well, my usual tool of choice is Force.com, but this kind of high-frequency, low-difference data doesn’t work well when fully imported to that environment. This got me thinking about two relatively new and completely exciting things: Lightning Connect and Heroku Connect External Objects.
Lightning Connect (earlier blog, cool tutorial) is a product that includes external data in Salesforce by reference — the data is accessed via the OData protocol and is never copied into your org. Hence it does not count against storage limits. Heroku Connect (Pat’s awesome blog) is all about easy data synchronization between Salesforce and a Heroku PostgreSQL database. But Heroku Connect also includes an External Objects (@vzmind‘s awesome blog) option that publishes any Heroku PostgreSQL table you request in OData format.
Heroku Connect demo edition is free, which is great, but you’ll need to file a ticket to have External Objects activated. Once that is done it’s super simple. Note: External Objects are activated per app, not per user. If you create a new app, you’ll need to request them again.
Start by creating a connection:
Next initialize your username and password. These will come to your email.
You’ll now see your OData URL as well as a list of tables you might want to share. Note that the listing of available tables appears to be an asynchronous process — it takes a minute for them to show up. Grab a cup of coffee. Then check the ones you want to share.
External Data Source configuration is super easy (with many examples), the only difference here being that the Identity Type is Named Principal and the Authentication Protocol is Password Authentication. Settings example below based on my setup.
And now we have the Heroku Readings object in Salesforce!
Which is super cool. But we can make it cooler by connecting this IoT data with something meaningful in Salesforce. For example, a Device record. As long as I have an External ID field on the Device, I can create an Indirect Lookup between that Device and the Heroku Readings by modifying the Reading’s “Device Name” field type.
]
And now we have live IoT data meaningfully connected to Salesforce data without importing it and using up storage.
Which, I gotta say, feels pretty much like a HOLY SHIT moment to me.
TL;DR – Look ma — CODE that stores DATA which becomes usable in SALESFORCE via OData.
For the last couple of days, I’ve been talking about some hardware I’ve put together (here and here). These efforts all come from a pretty simple problem I have:
My house is old, drafty and hard to heat. And I live in Chicago.
This problem is particularly noticeable in January and February, but July and August can be just as bad in the other direction so I need to address it somehow. Ugh.
Well, that which can be measured can be improved, right? So that’s where I’m going to start. Measurement is actually the easy part. Simple Data Recorder handles that. Where I’ve struggled is figuring out where to put that data which I measure, how to put it there and then what to do with it. This post covers the first two.
Most of the time, I work on the Force.com side of the Salesforce1 platform. I’m extremely comfortable in it, but the free Developer Edition will run out of storage very quickly if you start throwing a new record at it every minute or so. Enter the other side of Salesforce1: Heroku.
Naive IoT Host, deployed to Heroku, solves my storage problem. I’m using the free tier of everything so far, and should be able to for ~20 days at my current rate of data production. You can see a live dataclip of conditions in my house right now should you be interested. If you’ve even glanced at the code, you know it won’t scale to 100,000 devices any time soon. But it will do a couple of dozen just fine, and that’s just the scale I need for this experiment.
The high level end to end looks something like this:
Everything starts out on the Arduinos. The Raspberry Pi polls the Arduinos for data, transforms that data into JSON, and then posts that to a Node.js app running on Heroku. The Node.js app augments that data with current weather conditions and then writes it to a PostgreSQL table. I have it set to do this about every 5 minutes.
The basic Node.js app is built using Express, but I haven’t spent any significant time optimizing it.
I’m using ipfilter to ensure that only someone from a whitelisted IP address can make a request on the app. If you aren’t calling from some recognized IP, you get an “unauthorized” response.
Sequelize coordinates the database activities. For some reason I didn’t look at ORM when I wrote that tweet a couple of months ago. Sequelize isn’t perfect, but it’s super fast as a getting started tool, and it’s way better than anything I might write. You start by declaring a model, which it then automatically creates for you in the actual database. It doesn’t do database modifications as far as I can tell — there’s some kind of a separate module for that which I haven’t investigated yet.
Lastly, the Forecast module connects me to Forecast.io to get the current outside weather conditions. I thought this would be useful information to keep in mind as I start to look at the data. Now, I could have chosen to work with current-condition-then data in a number of ways, including querying for it analysis time (whenever that turns out to be), but the incremental cost of including it with each reading was so trivial I decided to do it.
Mess or not, the wiring did teach me two things: I2C works as long as there is conductivity and yes you can power a couple of Arduinos from the RPi. I2C doesn’t require a particular wiring sequence or whole bunch of cables extending from a central point to a single device, so when I decided to beef it up a bit, I started to imagine a way of connecting devices over a small distance. I was hopeful it would be easy and not require 100% custom wiring. The requirements boiled down to something like this:
I decided to look for a solution built around Cat5 cable — it’s cheap, has great connectors and I’ve worked with it a fair amount. I found it at Microcenter. I’m using a couple of el cheapo cable splitters and an RJ45 F-F joiner, for most of the connection, and it works great. I still need to solder 1/2 a Cat5 cable for the Raspberry Pi and another 1/2 for each device, but I can now put the Arduinos (somewhat) arbitrarily far away from the RPi node and add more until my power runs out.
Still not ideal, but like I said it works great. Although relatively inexpensive, each splitter is about $10, and I could do without stripping the Cat5 wires and soldering them to pins. Next up I think I’ll add a couple of RJ45 ports to a proto shield, and connect that directly to each Arduino. I’ll net a little more soldering, but it will be easier soldering so should be faster.
Here’s what the current system actually looks like in my attic. Note that the Arduino and RPi are far enough away that it’s impractical to photograph them together.
Questions I’ve pondered:
Why am I doing this instead of just getting an Arduino with an Ethernet shield? I’m trying to solve two problems, communication and power. if I go with the Ethernet shield, I’m in it for $60 each if I include a power over ethernet (POE) module, which is a lot. It solves the power problem and the connectivity problem, but I still have to wire ethernet.
Why don’t I just go wireless? Well, I could. In fact, I have a bunch of XBees sitting around from Dreamforce 13 that I could harness. However, I’d still have to get power to each one of these devices, so I’ve only solved one problem.
How will I scale this beyond my attic? I’ll probably need to scale this to the other floors of my house to get the data I want. I suspect the easiest way to scale it will be to add a nearly identical system on each floor. Otherwise I’ll have to deal with stringing wires, and I hate stringing wires.
I’ve said before that all Internet of Things (IoT) projects should start with a great use case that matters. In this post I want to discuss the next logical question: how to architect a system capable of handling the use case. I divide these use case centric IoT deployments into five architectural patterns, and I call them Anonymous, Direct, Buffered, Gateway and Cloudy. I’m going to first introduce a simple metaphor for how to think about IoT systems and then describe these core architectures, discuss their capabilities and limitations and review some interesting variations.
Note that I use Salesforce products here to represent key business systems, but each architecture could be adapted for use with other offerings (although you should really have Salesforce in the mix IMHO).
Also note that these architectures are more about generating actionable insights than they are about managing devices deployed in the field. Great Salesforce partners like Devicify and Cycle30 can help with these issues.
The Metaphor & Key Considerations
The easiest metaphor for a robust Internet of Things system is the nervous system. Signals come in from the extremities, they are processed in the brain, and muscles take action. In an IoT style solution, sensors send signals up the chain, those signals are aggregated and analyzed, and new signals are sent to actuators of some kind. Note that these actuators may be devices, other systems or people.
(You might enjoy reading about the nervous system over on Wikipedia, which is also where I found this great image.)
When you’re designing your system, you should consider:
Device Sophistication:What is the minimum viable device I can use to gather the signals I’m interested in?
Reporting Frequency:How often will that device need to report data in order for me to accurately analyze and understand the conditions I’m interested in?
Next Action:Once the information is aggregated and analyzed, what happens next and is it driven by a person or an automated system?
Distance:How many steps are there between understanding the need for action and the ability to take action?
A key difference between a standard animal nervous system and a robust IoT system is that the nervous system has private pathways for signals to flow. Most IoT systems will be running on the public Internet, and so will have significant concerns around signal encryption. That is the subject for a different article.
Anonymous
Anonymous implementations take advantage of APIs originally designed for use with basic websites. In the Salesforce world, these would be the Web2Case and Web2Lead APIs. These are incredibly easy to deploy by design, but, also by design, they lack many of the features considered standard in today’s business and IT climate, including authentication that clearly identifies the individual user or device reporting an issue. Example implementation: Create a case in Salesforce with the Staples Easy Button. Device sophistication: high. Reporting frequency: very low. Next action: human intervention. Distance: Low.
Direct
The first step above Anonymous is Direct, where the device knows how to authenticate and is powerful enough to communicate securely using standard REST APIs. Direct integrations require standard credentials embedded in each device, and so is generally appropriate for higher order systems and higher value add situations. This architecture isn’t well suited to high volumes of data or transactions, but works great for systems that report, for example, once per day. Example implementation: Control Philips Hue from Salesforce. Device sophistication: high. Reporting frequency: low. Next action: human intervention. Distance: low.
Buffered
The Buffered architecture enables systems to communicate at higher transaction volumes without requiring the destination system to be aware of the originating devices in a detailed way. Buffered architectures simplify IoT systems by allowing you to create a custom API and to define your own interaction models. On the Salesforce1 Platform, you can easily create a buffered architecture by combining Heroku services with Force.com services. Heroku would be responsible for device interaction and information aggregation. The system would then sync summarized information to Force.com using Heroku Connect or standard REST APIs. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: medium.
Gateway
Gateway architectures allow you to include much lower power devices in your IoT system. These low power devices communicate with a more sophisticated gateway device that is powerful enough to connect with either a custom API built on Heroku or a standard Force.com API. Although I’ve used Bluetooth to represent the low power device, it is not limited to bluetooth. Gateway architectures open your system to a much greater variety of participating devices since the gateway can serve as a broadly capable adapter class. Device sophistication: low for the device, high for the gateway. Reporting frequency: high. Next action: automatic or human response. Distance: high to medium.
Cloudy
Cloudy architectures are interesting because they essentially roll-up functionality starting with the device end of the typical IoT value stream. The core model is to combine a core piece of hardware with Internet connectivity. The connectivity ends in a cloud service, and the cloud service becomes the end point for talking to business systems. This pattern requires a higher level device in the field along with rich connectivity between that device and cloud system. The integration is then cloud to cloud. This is a great way to get started, but, like any tightly coupled design, your ability to change and modify the system is bound to the strengths and limitations of your supplier’s platform. Device sophistication: high. Reporting frequency: indeterminate. Next action: automatic or human response. Distance: low to medium.
Variation #1: Direct (Augmented)
Sometimes you’ll want to interact with Salesforce APIs directly, but you’ll want to augment that interaction with computing resources located on another system, e.g. an app running on Heroku. This is useful when you need processing not typically handled on the Force.com platform, such as image analysis. In that case, you can easily upload data to Force.com, trigger a Heroku process based on that data, and then complete the interaction by putting the actionable results back in Force.com. Device sophistication: high. Reporting frequency: low. Next action: human response. Distance: medium.
Variation #2: Buffered by Partners
The Salesforce ecosystem has a rich variety of partners, including several focused on building end-to-end solutions for our customers. One way of deploying a system is to use a partner solution as your aggregation layer, looking something like the picture below. Note that the device below could be replaced by a collection of lower powered devices connecting to a more powerful gateway. Example implementation: Get Started with the Internet of Things in 10 Minutes. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: medium.
Variation #3: Double Buffered
It’s also possible to create a double buffered system that puts a partner solution in front of a custom API deployed to Heroku, which then connects to Force.com. This creates a more complicated system, but might be justified by your business case. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: far to medium.
Next Steps
I hope this discussion is useful for you. I’m going to be doing a longer version of this at ThingsExpo in Santa Clara this week (November 6), which also includes some background, use cases and predictions.
If you have comments, I’d love to hear them. If you’re working on an IoT deployment, I’d love to hear about that too.
@MJFreshyFresh put together a scatter plot of patterns AND sketched some ideas about how actuators and sensors might have different pathways. Pretty sweet!
@AliNajefi points out that examples would be helpful, so I’ve added links where I’ve created examples. Great feedback!
This year, I ignored everything but my little portion — the DF14 DevZone Internet of Things area — and it still took me three pretty long posts and almost 3000 words. What a difference a year makes!
Whether we finally see an iWatch tomorrow or not, all of this frenzy around wearables made me curious what the timeline on the architectural approach looks like. So I did a little research and came up with the following table. This is incomplete for sure, but I found a few things that surprised and entertained me, so here it is for your enjoyment. Comments, additions, criticisms all welcome on @ReidCarlberg.
Format: Earliest Date Seen or Announced – Name (Category) – Link for More Information
09/09/2014 – Apple iWatch Maybe (Unknown) – Apple.com
littleBits makes it easy for people to experiment and play with a variety of DIY electrical components. It’s fun and easy, and yesterday they made it even better by introducing the littleBits cloudBit.
The cloudBit is a unique and powerful way anyone can create fun Internet of Things style solutions for whatever is important to them. Today, I’m going to create a fun alert that fires when new Leads are added to Salesforce.
Let’s take a look at the bit itself. It has the same basic architecture as other bits — magnetic connectors on both sides with a direction indicator — and then a USB wifi connector on the front and a 4GB micro SD card on the back containing Linux.
Yes, that’s right, Linux. In fact, as the description notes, “The cloudBit is a single board computer running Linux.” Later they also note, “We’ve left pads on the bottom of the board so that you can connect to the cloudBit’s serial console using 3.3V UART (8-N-1, 115,200 baud) and poke around.” OK, that’s now on my //TODO list.
Front:
Back:
Configuring the WiFi is pretty easy. When you first power on your cloudBit, it creates a new hotspot. You connect to that hotspot, and then configure it to connect to whatever your local setup is. This is a familiar pattern for a lot of new connected devices, so you’ll probably find it easy. Once you’ve configured it, the basic operation is pretty simple, as I demonstrate in the video below.
Ok those are the basics. So, you might be asking, what can you do with it?
Quite a bit as it turns out. I like to create fun things in Salesforce, so I decided to create a real world alert that tells me when a new Lead is added to the system. I did this using a cloudBit, Twilio and LEGO. Check out this video for a demo and an explanation.
There you have it. There’s really no meaningful code required, it’s mostly done with a few clicks. If you’d like to try it yourself, you can get a littleBits cloudBit for $59 and try out the Twilio Salesforce integration for free.
The Internet of Things, the Internet of Everything, the Industrial Internet — whatever you call it, connected devices are a fantastic gift to any business that wants to get closer to their customers. The pattern captures people’s imaginations and many of the predictions feel like magic, but IoT solutions are hard to get right. If you’re trying to decide on your first project, you probably have a lot of questions. Here are six critical things to keep in mind as you move forward.
#1 Pick a Great Use Case
There are a lot of fun IoT use cases around the Internet. Many of them don’t matter. In the interest of keeping good relations with the rest of the world, I’m going to call out something I did as a fantastic example of a trivial exercise: the Coffee Copter, detailed in the video below. As you pour a cup of coffee, a quadcopter takes off. As you empty the cup, the quadcopter lands.
Now, as fun as that was, it was an execise in can you do something, and these days can is the wrong question. You need to be asking yourself should questions. Should I connect a coffee urn and a quadcopter? No.
But there are lot of areas where the answer is yes.
One of my favorite examples in this department is New England BioLabs. NEB sells supplies to medical researchers. As part of their sales process, they stock these supplies in a freezer at their customer’s location. Now, it used to be that they had a hard time knowing the right supplies to stock, validating that supplies were kept at the right temperature, and tracking the researchers that used a specific item. NEB solved this by transforming their freezers into connected devices and now they know the researchers, they know the supplies and they know the temperature history for each item.
I’m sure we can all agree that medical research is a worthy cause. But not everyone is a healthcare researcher, so you have to find a similar problem in your business. You need to start by identifying the target outcomes your customers are looking for, and then come up with ways to help them achieve those outcomes more reliably. When you do this, you deliver additional value and build better relationships.
These outcome oriented use cases are what matter, and you should start with them.
#2 Create a Great User Experience
Once you decide on the right use case, you have to create a user experience that delights your customers.
User experience, UX, determines how people engage with your solution, and there’s no one UX for every product. Your UX goal should be two fold. First, if possible, your new solution should fit into what customers already know how to do. Second, it should reduce the friction of what they have to do to realize the value it delivers. Great UX not only disappears into the environment, it makes the environment better.
The current generation of fitness wearables is interesting example of good UX. Fitbit, for example, has no buttons. All you have to do is put it on and the technology does everything else in the background. Now, on the down side, the user also has to tap the device from time to time. It’s easy to get the hang of, but I wouldn’t call it natural, and it still requires a local gateway rather than being able to magically talk directly to the cloud. There’s no great way around that right now, it’s a constraint that the technology hasn’t eliminated yet. But the first wearable that includes some sort of background connectivity will have a tremendous advantage.
#3 Community & Collaboration
I’m not talking about the network of connected toasters or refrigerators complaining to each other about being out of milk. I’m talking about actual people. People value interacting with other people in context of things they care about. In fact, they value it so much, if you don’t create a destination for the community that pops up around your product, your customers will probably create one on their own.
There are three main types of communities to be thinking about.
The first is a data-centric community. Runkeeper has created an excellent example of a data-centric community. Data-centric communities take the output of the device and interact around it. In Runkeeper’s case, this is a leader board comparing the number of activities between you and your friends (yes, that’s me at the bottom). Most fitness wearables have data-centric communities as a core part of the product.
The second type of community is product-centric. Product-centric communities are more about how to use things, news from the company, tips and tricks, etc. PrintrBot has an excellent product-centric community. Interestingly, it’s not operated by the company itself. Customers created their own informal community. Today the company has an official one as well, but the original continues to thrive.
The third type is transaction-centric. Say you manufacture MRI machines, and you connect those MRI machines to an enterprise backend like salesforce.com. When the MRI machines have actionable data, that data gets posted to Chatter, and all of the people who have a legitimate interest in it can collaborate around that particular post. MRI techs, doctors, hospital staff, biomed technicians, and external contractors can create a short lived, ad hoc community around that transaction. (The screenshot above is from this video, a couple of minutes in.)
#4 Developer Experience
Open Source has shown time and again that remix is often more valuable than the original. And although I won’t presume to say you should open source your core IP behind whatever connected solution you land on, I think its critical you have an easy to understand, well documented and powerful API that developers can harness.
A great example of a good out of the box Developer Experience (DX) is Automatic, the car tracking company. With Automatic, you pair an OBD-II device with your phone and track driving patterns. Automatic launched with an API out of the box, and they exposed their API using a number of standards. For example, it has a REST API and handles authentication via OAuth2. This definitely sets them up for developer success, and people are doing great things. (Note that Automatic’s API is still in beta. That’s fine.)
Like the community, the funny thing is that if you don’t deliver an API out of the box, chances are good someone else will attempt to. Take the example of Kickstarter success LiFX. It took a year for them create and ship bulbs to their backers, and they did so without an official API. However, an unofficial API showed up on Github in days. Now the challenge here is that an unofficial one is OK, but people don’t have a lot of confidence in it. Meanwhile the Philips Hue, their competitor, has had a reasonably good API for quite a while.
This all begs the question of Nest. Nest doesn’t have a public API yet which probably makes you wonder if you really need one. My opinion is that most of the time yes you will need one. Nest has proven to be a successful exception. There may be more exceptions, but I suspect not many.
#5 The Right Amount of Data
In order to succeed, your IoT solution needs to gather enough data to create accurate, actionable insights for your users. Is this Big Data? Yes, but your users don’t want and can’t handle big data. They want the processed results.
How do you handle big data if you don’t already understand it? The right thing to do is partner with a company who already has the expertise, of which there are an increasing number. Companies like Etherios, 2lementry and Axeda, just to name a few. Can you develop it yourself? Sure, but see the above discussion about can versus should.
Processed data is where the action is. A typical IoT value chain has a number of components, all of which are easy to get lost in, but processed data, that someone can act on, will drive the success or failure of your product. User experience plays a critical role here as well, although it’s a different set of users: internal users. If your use case involves helping customers achieve better outcomes from their purchase, and it should, then the processed data needs to sit very close to the customer data so people can take quick action on it.
Learning what data is valuable will take some trial and error, and the data that’s valuable today will be different that the data which matters tomorrow. You need to figure this out for your customers.
#6 Non-Technical Integration
Connected devices open up new and interesting future possibilities, but they have to play well in the current world with all of it’s existing requirements. A good case in point is government regulation.
Brivo Labs is a great example of a company that understands the impact of regulatory requirements on IoT solutions. Brivo Labs is an access management company that’s a spin off of a well established commercial security access control company with a deep understanding of regional building codes. This kind of knowledge is absolutely key to working effectively with existing markets, and they’ve used this to create a number of interesting products, including an iBeacon enabled app that works with Salesforce Identity called Rändivoo.
Nest experienced an interesting result of regulatory requirements when they found a problem with their smoke detectors. They started to fix it and then received a demand for a recall from the Consumer Product Safety Commission – six weeks after their own disclosure and initial action. This kind of interaction can be very distracting for a business, especially when it’s not planned for, but the reality is that even the most leading edge companies are still subject to it.
Source. Note that as of this writing, Nest Protects were not available on the Nest website. This letter from Nest CEO describes the situation.
Now is the Time to Jump In!
I hope this list is helpful. The Internet of Things is an architectural style that will drive really interesting innovation in the coming years. There’s a lot of detail around creating an IoT solution, but you shouldn’t let that stop you from jumping in. Now is a great time. Companies are increasingly turning to connected customer experiences as a way of delivering what all customers really want: better outcomes.
If you’re looking for more ideas and inspiration, you should take a look at the ever growing list of artifacts created by some of the leading thinkers in the space. I recommend the videos from ThingMonk, ThingsCon and SolidCon as a great place to start.
I’d love your feedback on this or any other article.
The Internet of Things — IoT for short — is the new black, but most people still can’t explain what it is or why the average person, developer or CEO should care. Let me break it down in 5 easy to understand steps.
#1 Nobody Wants Your Product
I want to start off by setting the stage with a very simple fact: nobody wants your product. I don’t care if you make smart phones, cars, houses, bathroom scales, pens, pencils or chairs. A priori no one wants your product.
This is confusing. We often conflate the effects of marketing and advertising with inherent desire and generally that inherent desire just isn’t there. Now, if your products are food staples, or maybe art, I’d open that up for discussion but once you get beyond those basics – once you get into the very specific realm of, for example, prepared sandwich cookies, desire isn’t natural, it’s manufactured.
#2 People Want Outcomes
People want outcomes. Smart phones provide connectedness. Cars provide safe transit from point A to B. Houses help us feel safe.
Products and outcomes are different. Sometimes it’s difficult to remember that they’re different while caught up in the day to day world of making things and selling them, but that’s why people buy products.
They want outcomes.
It’s always important to ask, what are people getting out of this product? Why are they buying it. It’s the why that matters.
#3 Technology Enables Better Outcomes
I’ve been in technology most of my career. The reason I like technology is simple: technology enables better outcomes. The has been true for a long time, since long before we called it “technology” (a term that joined us in the 17th century) and long before there was a tech industry (coined in the 20th century).
Think about Gutenberg’s printing press (from the 15th century). Gutenberg’s printing press was the quad-copter drone of it’s day. It made “printing” a thing. Before Gutenberg, creating new books meant copying by hand. For centuries, control of the printing presses conferred a huge amount of power.
Computing power is the same. It started with mainframes, went to PCs, then the Internet and now everyone carries a wildly connected supercomputer in their pocket that fundamentally creates better outcomes for them every day.
Importantly, these better outcomes still require a device, an intermediary, something that separates the user from the computing power.
#4 IoT Breaks Computing Power’s Fourth Wall
The fourth wall is a metaphor describing the relationship between the performers and the audience in a theater. The fourth wall keeps the actors on the stage, safely separated from the audience in their seats. Breaking the fourth wall, a concept that started in the 19th century, is all about engaging observers in the performance.
IoT, as a technical architecture, is fundamentally about eliminating computing power’s fourth wall. IoT embeds computing power among the diverse devices a user might rely on to improve outcomes and reduces the intentionality required for a user to engage it.
IoT is a great marketing term right now as well, which means it’s sometimes used out of context. That’s OK. Marketing terms, even those lacking precision, can be useful organizing principals that help people talk about similar ideas in a similar way.
#5 All Estimates of IoT’s Impact are Too Small
You’ve probably heard 75 billion devices and $14 trillion in revenue opportunities. These are huge numbers — mind boggling — which is great — but kind of insignificant when you switch your default mindset to assume every thing you come into contact with every day will soon have incredibly rich computing and communication capabilities.
Think a decade out, or two decades out, when the standards are agreed on and the technology stack is mature. Suddenly, I Dream of Jeannie is the new normal. But instead of Barbara Eden crossing her arms and nodding her head, it will be you, conducting the technology embedded everywhere around you, without thinking about it.
Sensors, robotics and technology we’re not even talking about yet will turn I Dream of Jeannie into brilliant speculative fiction instead of a quality sitcom.
IoT is the organizing metaphor that will help us get there.
…And We’re Just Getting Started
I hope this paints a clearer picture of IoT. This architectural style is just getting started and people are thinking about it in many different ways. It doesn’t matter that we don’t agree on all of it yet, or that we don’t have all of the technology worked out. That will happen.
Let’s say — hypothetically — your VP of Drone Fleet Operations just asked you to help her handle drone management, route planning, payload optimization and more. What do you do? Well, there’s a few approaches to tackling the problem. Approach #1 is all about controlling drones using the Salesforce1 Mobile app. That’s what I’m going to talk about today. Note that all of this is done with a free Developer Edition and a little code.
Although I won’t cover it here, there’s also a mildly entertaining yet entirely impractical YouTube artifact documenting my adventures at ThingMonk where together with the excellent Darach Ennis we were able to launch a quadcopter using a coffeepot.
Equipment & Architecture
Let’s start by looking at the equipment you’ll need. The first thing is a quadcopter or two. I used the Parrot AR Drone 2.0 available at pretty much every retailer worth their weight in salt. The Parrot is great for a lot of reasons, but first and foremost is that it has a great API. Where you have an API, great things are possible, right? Now, the Parrot is also a toy, so you production minded folks will probably want to upgrade to something more robust.
The way the AR Drone works out of the box is that it creates a WiFi hotspot. You then connect your controlling device to that AR Drone hotspot and operate it. Parrot sets you up with an app that runs on either an iOS or Android device. I’ve controlled them from both platforms and it works great. The default AR Drone configuration requires one controller per drone, and it requires that controller to be on the WiFi network provided by the drone. If you have two drones, they are isolated from each other by their network connections and there’s no interaction.
In order for this to work with Salesforce, and in order to control multiple drones at the same time, we have to somehow unify these devices, which using the out of the box configuration means the controller needs to bridge multiple networks. My goto local interface box is typically the Raspberry Pi, and, fortunately, the Raspberry Pi is capable of supporting multiple network interfaces, which means it can also handle multiple network addresses. There are a few ways you could configure this, but I chose to use a single Raspberry Pi as a bridge between Salesforce and two other Raspberry Pi’s which connect to the AR Drones. It looks a little like this:
Now all you need is an app to handle the interface to the AR Drone. There are a lot of great ways to do this, and for this example I have used CylonJS and their ARDrone driver. (You might remember Cylon JS from the Dreamforce Connected Device Lab. They do tons of great stuff in the robotics world and have cool libraries for JavaScript, Ruby and Go.)
Control via the Streaming API Pattern
My first approach on this project is to use the familiar Streaming API Pattern. (See Controlling Philips Hue from Salesforce1 for another example, or get started with a really simple streaming API example.) The Drone Gateway connects to Salesforce, listens to a Streaming API Push Topic and then forwards those instructions to a device as soon as they’re received.
On the Salesforce side of the house, we have to create a simple way to generate listenable data. This is easier than it sounds. The first thing we want is an sObject to store the data in. I’m re-using an existing object pattern I’ve used for other message driven work, I call it “Drone Message.” The two key pieces of data it stores are the Address and Message. You can see in the screen capture that this one is setting the “land” message to “D2”.
You can of course use the default UI to create the records, but that then requires you to know addresses and message codes. Since code handles those kind of details better than my brain does, I created a simple Apex class to create these records.
public class DroneController{
public void droneOneTakeoff() {
insertMessage('D1','takeoff');
}
public void droneOneLand() {
insertMessage('D1','land');
}
public void droneTwoTakeoff() {
insertMessage('D2', 'takeoff');
}
public void droneTwoLand() {
insertMessage('D2', 'land');
}
public void insertMessage(String address, String message) {
Drone_Message__c m = new Drone_Message__c();
m.Address__c = address;
m.Message__c = message;
insert m;
}
}
And now all I need is a little Visualforce code to extend this out to the UI layer. Note that this Visualforce page is tied to the Apex code above using the controller attribute.
Now that we have a quick and easy way to create listenable messages, let’s take a quick look at the Drone Gateway that’s doing this listening. This is a pattern I’ve re-used a few times, so you might be familiar with it. The gateway authenticates, begins listening to a Streaming API Push Topic, and then handles whatever it receives. I chose to write this in Node.js and the code is pretty simple. The connect to Salesforce is detailed in the Philips Hue article, so I’ll just show you how it handles the message. Note the “address” and “message” arguments.
function handleMessage(address, message) {
console.log("address: " + address);
console.log("message: " + message);
if (address == 'D1') {
if (message == 'takeoff') {
console.log("in d1 takeoff");
handleRequest("http://10.0.0.2:1337/start");
} else if (message == 'land') {
console.log("in d1 land");
handleRequest("http://10.0.0.2:1337/stop");
}
} else if (address == "D2") {
if (message == 'takeoff') {
console.log("in d2 takeoff");
handleRequest("http://10.0.0.3:1337/start");
} else if (message == 'land') {
console.log("in d2 land");
handleRequest("http://10.0.0.3:1337/stop");
}
}
}
Now, you will have no doubt noticed that the above code is doing nothing more than making a call to a webserver. When I was testing, I decided that an http based interface would also be fun, so I created a small server that simply responds to two URLs: start and stop. You can see that these map to the CylonJS commands for “takeoff” and “land”.
http.createServer(function(req,res) {
if (req.url == "/start") {
console.log("ready to start");
copter1.connections['ardrone'].takeoff();
} else if (req.url == "/stop") {
console.log("ready to stop");
copter1.connections['ardrone'].land();
}
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Executed');
}).listen(1337, "10.0.0.2");
And there you have it. The start to finish message flow now looks like this:
User presses takeoff on their mobile device.
Salesforce1 inserts a Drone Message object for takeoff.
Streaming API picks up the new records, forwards to listeners.
The Node.js based Drone Gateway catches the new record, and sends it to the right address.
The Node.js based Drone Server sends the specific command to the AR Drone.
Code notes and links:
Visualforce and Apex is above, everything else is a minor configuration.
My command center for the video shoot looks a bit more complicated, but it follows the diagrams above. Note the three Raspberry Pi’s and two network hubs on the lower left.
Wrap Up
As you can see from the video, it’s pretty easy to get the drones to follow some simple instructions. The primary challenge with this method is the inherent lag between when an instruction is issued and when it gets to the drone. This lag depends on a huge number of factors — Internet connection, gateway device performance, Streaming API performance, etc — but the end result is the same. A drone moving at 5-6 meters per second will be in a completely different place by the time it responds to a delayed command.
An interesting experiment that raises a lot of questions for me. First and foremost, what is the best way to spread device intelligence out among the components of a system? Which is to say, what kind of work should Salesforce play in this kind of complicated interaction? My overall feeling is that this, while interesting, is lower level than truly practical today.
]
The first is a data-centric community. 
Reid Carlberg 