I’m terrible at personal projects. Let’s just get that out of the way. I have a collection of neglected hobbies, half (or less) finished electronics builds, unprocessed astrophotos, and unfinished song ideas leaving a wake behind me. Sometimes a project falls by the wayside due to attention span, but usually what happens is that I run into some obstacle that convinces me the idea will require much more time or effort than anticipated. And in the pile it goes. Yet, as I mentioned on our last episode, there’s no better way to keep learning than by doing, so I keep trying.
So when I received a Photon Kit from Particle.io (formerly Spark.io) last month (thanks and Elecia and Solid Con), I wasn’t sure what to do with it. I really didn’t want to start another build that I wasn’t going to finish. Thankfully, through some magic combination of good documentation, comprehensive libraries, and friendly development tools, that didn’t happen this time.
Photon is an ARM Cortex M3 based Wi-Fi module (based on a chipset from Broadcom) with a healthy clock speed (120MHz), 128KB of RAM, 1MB of onboard flash, and a nice collection of I/O. The device is packaged in a breadboard-friendly DIP that’s been common since the Basic Stamp. So far so good, this sounds like a lot of devices out there. However, it’s the ecosystem Particle.io has built up around the device that makes it interesting.
The out-of-the-box experience is designed to get you up and running nearly immediately. The kit I got includes a small breadboard, photoresistor, and an LED (with a current limiting resistor) to make a simple Internet-connected sensor + blinkenlight. The device is prepackaged with example firmware, and there is a mobile app (for iOS and Android) that provisions the device for Wi-Fi, then lets you control digital outs and read inputs. It’s pretty great to have something up and running with a simple circuit, Wi-Fi, and a mobile app in literally five minutes.
The Photon is programmed using an “Arduino-like” development environment. Arduino source code should run on Photon with minimal changes. It is not, however, hardware compatible with Arduino shields (though a set of Photon specific shields is emerging). For one thing, the Photon is a 3-volt logic part, which can complicate interfacing to Arduino-compatible modules. You may require a level-shifter to connect to Arduino compatible 5V parts.
Developing code for the Photon is done through a web-based IDE (called “Build”) that is reasonably friendly, with easy access to community libraries and documentation. The web-based approach is becoming popular (mbed is another example). I would like to see more editor features (auto-completion, links back to documentation from keywords), but it’s a nice start. Thankfully, there is also a native version of the IDE for Mac and Windows if you want more control.
Deploying code to the device is incredibly simple. It may be the fastest and simplest code deployment scheme I’ve seen for a device of this kind. Once you’ve got a program written in the IDE (and the device provisioned with Wi-Fi), you hit the flash button and the device is reprogrammed over the Internet. Assuming your code works and it can reconnect to the network, the device is back up and running in under a minute. If it doesn’t work, well the tri-color LED on the board should tell you why.
The real feature that makes the Photon shine (hmm) is the cloud connectivity and backend. While Wi-Fi is certainly a prerequisite, unless you only want to access your device on the local network you’ll need more infrastructure. For example, the device needs to get through any firewalls, provide some way of accessing internal functions and structures (internal webserver, data push to a remote server), and hopefully secure the device from unauthorized access. Doing all of those things requires more time and expertise than most of us can muster, especially when the real goal is focusing on the core features of the project or product. Photon comes with all of that work and infrastructure ready to go.
Let’s look at how you expose your program’s details to the Internet. Within any program, you will have variables to store data and the state of things, as well as functions that perform actions based on that data. On the module, using the Photon library (still called Spark), you simply associate tell the API which variables and functions you want to expose:
Spark.variable(“adcvalue”, &adcvalue, INT);
This tells the device to expose a function called ledToggle with the remotely accessible name led and to associate the variable name adcvalue with a remotely accessible variable of the same name. That’s it. Everything about managing the internet connection, device identification and authentication, transferring data to and from the cloud is handled by the Photon base firmware.
Well that’s all well and good, but just how do we access the device from the outside? According to Particle.io, nearly any way you want. Since they’ve chosen to make the Cloud API based on REST (Representationl State Transfer, if you care), the options are many. At the highest level, a REST API means you can make requests using standard HTTP GETs and POSTs. Complex data is packaged in JSON so it’s easy to parse. Theoretically, you could access your device using any code that can talk to the web (even a browser if you just want to try things out).
I would be remiss if I didn’t mention a very similar development platform, the Electric Imp. The Electric Imp has been around a while and has been the core of many IoT products over the last few years. While at a very high level the two platforms are very similar I want to point out a few differences that might make the difference on which you choose for a project.
First, Electric Imp also provides a cloud backend. A major difference is that Imp allows you (requires, actually) to write small pieces of code (called agents) that run on the cloud server to serve as the glue between your device and the global internet. Through the agent, you can customize how you access the device, and even run logic that would normally consume power and resources on your device (which could be a big consideration for complex, data-intensive operations). Effectively, the agent is a tiny webserver that handles requests to and from the device. The Photon doesn’t start with that model, but it seems like similar things would be possible by running your own server.
The device and the agents for Imp are both programmed in a language called Squirrel. It’s another C-like language that should seem reasonably familiar to anyone coming from the world of C, Java, etc. but ultimately it is one more thing to learn. If you have Arduino experience, that might sway you toward Photon, but it’s not a big deal from my (new-to-either-one) perspective.
The Electric Imp has a novel provisioning method called “Blink-up” that allows you to get on the Wi-Fi network with your device using a mobile phone. Photon uses a soft-AP mode which means you configure your computer or mobile phone to connect to a network it creates so that you can program it with your network credentials. Either way amounts to about the same hassle and personally I don’t believe anyone has solved this problem satisfactorily.
There are other differences regarding power consumption, form factor, cloud management, and development environments, too, and the choice depends on the details of your project’s needs. The good news is that the devkits are inexpensive ($19 for Photon and $29.95 + $12.50 for an Imp with breakout board), so it’s possible to try both. Competition is great and will only make both products better.
Whew! I haven’t even gotten to what I built with the Photon! I’ll save that for the next post as I want to describe the whole process of getting the Photon set up, programming for the application, and at least a few words and details about building a mobile app to control it. Just to tease the project, I’ll be describing a connected garage door opener, with open/close sensing and accompanying iPhone and Apple Watch apps.
I’ll just finish by saying that the Photon board made developing an IoT device so easy and fun it felt like cheating and at no point did I want to throw my hands up and walk away from the project.