Lost very early in most current discussions of IoT “platforms” is the need to enroll a boatload of devices — get them activated and configured so they are recognized by and can work hand in hand with a server in the cloud. One very clean solution — Electric Imp — has been out since 2012 but still seems fairly unknown among enterprise product development teams looking to get working test products into the field.
Further, Electric Imp recently announced an appliance designed to make the imp platform more useful in commercial and factory floor settings. The appliance, called impFactory, makes device activation and configuration more scalable to production processes.
Whether one’s target is consumer or industrial, the basic need the imp tackles is getting a headless IoT device connected to a wireless network and hooked up to the cloud application that will be providing the heavy lifting when it comes to computation.
Think about your mobile phone for a second — it may arrive at your house (if ordered online) with a SIM installed and your name and billing information already entered in the data center at your provider’s HQ, but the phone wasn’t manufactured with your personal information already burned in. Somebody programmed the SIM. Somebody put your information into the billing system and associated your IMEI (device number) with you and your account.
It’s exactly the same situation if a company designs and starts selling a smart device that needs to send data back to the mother ship in the cloud. That device needs to register. Even if it’s nothing more exotic than a color-changing lightbulb, somehow the company needs to know that the control app you just loaded on your iPhone is going to be controlling that particular bulb. You probably don’t want to have to connect a keyboard and monitor to the lightbulb in order to accomplish this.
Of course, this isn’t even remotely an insoluble conundrum. But it is a problem that you’ve got to solve if you’re going to offer a product at scale. If you’re dealing with all the issues of making and programming the thing and its controlling apps in the first place, it may be the part of the process that makes you break down and cry.
A few weeks ago, Electric Imp sent me its developer kit and, frankly, I wasn’t too excited. The form factor, to be sure, is pretty cool — it looks exactly like an SD card. Doing it that way means it’s cheap to make a board that connects things to it because you can use an SD slot to make the physical electrical connections. (It isn’t, however, an actual SD card. It won’t do anything at all if you stick it into your digital camera.) The breakout board that enables you to power up the imp and hook sensors and the like to it has, for whatever reason, been dubbed an “April” board. April is designed with a header strip positioned sideways at the end of the PCB and there are currently two “tails” that can be interchangeably (but not simultaneously) hooked up to April. One has blinky lights; the other has a handful of environmental sensors.
That’s all cool, but basically it’s another inventor board, vaguely in the same category of things as the Arduino or the Raspberry Pi. Still, no sooner had I powered it up than it hit me: this thing has a secret weapon.
There may be other things like it (let me know), but I haven’t seen them. The approach here is really clever. I’ll walk through it, but first let’s think about what we’d have to do in order to accomplish the same thing with a Raspberry Pi.
First, we’d have to get the Pi hooked up to a Wi-Fi add-on board (a “shield,” in Pi parlance) and logged into our local wireless network. You’d need to tell the Pi which network to use and give it the password. Though it’s possible to attach a monitor to a Pi, remember that we’re dealing with what is more likely to be a headless device and there’s not going to be any obvious way to get the Wi-Fi SSID and password entered into the thing. If you’re thinking about this from a user experience point of view, you need something like a smartphone app where you can be shown the available networks and then type in the password for the one they choose, which is then transmitted to configure the device. Of course, the device isn’t on the network yet.
You can add a shield with Bluetooth support to your Raspberry Pi, which gets you configured on the Wi-Fi network, but not connected to your back-end application in the cloud. And you’re going to have to work out the mechanics of passing data back and forth from device to server and back. Your Pi development efforts may very well use a development interface designed for Pi (and it’s friendly, to be sure); your server will use something else — lots of bouncing back and forth while sorting out the bugs. And none of this enrollment and connectivity stuff has anything to do with the functionality and benefits your product is supposed to deliver.
The imp, on the other hand, has an imp-generic app that you install on your phone. You type in the Wi-Fi network stuff in the app and then you hold the phone over a photoelectric eye on the imp. The app — and now it’s suddenly clear why it’s called “BlinkUp” — sends the info in light pulses over to the device.
And here’s the magic part: you can now go to a URL where you’ll find a web-based developer interface that puts the server side of your application in a window on the left and the on-device part of the code on the right. At this point, you can see the output of the system log running within the device reflected to the console running in a web server on your notebook computer. It’s so seamless that you almost don’t appreciate how much work you’ve just been spared.
The programming you do both on the server (or “agent”) side and on the device, by the way, is being done in the Squirrel programming language. Squirrel is pretty much the same thing as the C programming language, at least at first glance. Functions written in one pane of the developer environment talk to applications running on the other.
Here’s some minimal code that does the “Hello, World” thing and makes the five LED’s on the blinky tail flash on and immediately back off:
#require "WS2812.class.nut:2.0.1" hardware.spi257.configure(MSB_FIRST, 7500); local leds = WS2812(hardware.spi257, 5); server.log("Hello from the Dev Kit"); // Five LEDS, set the first red, the second green, the rest blue leds.set(0, [255,0,0]).set(1, [0,255,0]).fill([0,0,255], 2, 4).draw(); leds.set(0, [0,0,0]).set(1, [0,0,0]).fill([0,0,0], 2, 4).draw();
The thing to focus on here is that the “Hello, World” bit is transferred to the web and stored on a console log on the server. As if by magic.
That’s the beauty and the potential curse of this arrangement. Your input device has a universally unique device ID and it knows how to talk to Electric Imp’s development environment. That may not ultimately be what you want — the upshot of this is that Electric Imp’s cloud is in the middle of your product.
Still, it’s a really clean take on a series of hurdles that nearly every commercial IoT product has to cross if it’s going to connect wirelessly to the wider world. The developer’s edition lends itself to prototyping, but Electric Imp is ready to help you push into production with lower-cost versions of the imp specifically designed to embed in production systems. At present, the developer kit can be had through various DIY outfits like Adafruit and Sparkfun, or you can buy a bundle of an imp, April board and two “tails” for $30 on Amazon.