On Avoiding Rabbit Holes
Or, how to choose an IoT cloud platform for your new Internet thing.
A critical step building any new product (IoT or otherwise) is to quickly make your innovation tangible, then iterate and refine. This is often referred to as building a Minimum Viable Product; but, I think that’s belittling. This step of the process is crucial because it changes what only existed in your mind or on paper into a vibrant, living process. It requires focus and flow, which can be hard to maintain.
It follows that when choosing your prototyping platform, you don’t want anything that breaks your focus and flow: endless dependencies; laborious build processes; sudden, steep learning curves; having to build non-innovative pieces from scratch; and, too many distracting options.
Some things you do want: a minimal setup cost; useful, pre-existing building blocks; helpful constraints; and, tools you can depend on.
The IoT Cloud Platform Landscape
Truly innovative ideas are beyond the paradigm of component-or-widget-based, drag-and-drop IoT builders. You’ll need — and want — to write your own firmware, and that puts you square in the land of embedded systems programming and/or Arduino.
Even after ruling out those that are too simplistic, there are countless IoT platforms to choose from. Focussing in on those that support both observation and control, excluding those that focus solely on data collection, reduces the available platforms to a manageable number.
By hardware-agnostic, I mean they provide an SDK that works with a variety of processors. For whichever chipset you choose, you’ll also need to learn a build chain and set up your development environment, which includes building with the platform’s SDK, before you get started.
And that leads to questions about how you program, flash, update, and connect your devices. While there are some great choices, this particular rabbit hole runs deep, and a lot of time can slip by before you even get started.
Talking to Your Thing
At the heart of these platforms’ understanding of things are properties like “on” or “off” or “68°” or “up,” and interactions with your thing change those properties or react to changes in them.
If you want turn a light switch thing on, you request the power property be set to “on.” To set a thermostat, you request the targetTemperature property be set to “68°.” The associated cloud platform will (hopefully) keep track of the status of your request and whether the thing’s properties matches what’s reported on the device, so you can find out if your request was successful. In AWS, this is referred to as a “Thing Shadow,” while Azure has a “Device twin.” Hey, nobody said these things were all settled and tidy, these are early days.
Some platforms understand the idea of sending a thing a command, while other only allow you to send generic messages to the device.
This is a pretty good—perhaps great—way to approach prototyping your thing. But this open-ended, property driven approach can get you bogged down in data modeling and premature refactoring, when you should be coding and building. Another deep rabbit hole, and no sign of focus or flow.
A Middle Way
Fortunately, there is a platform that avoids both of these rabbit holes: Particle.
With one of their processors, your thing can be connected to a fully-featured IoT Cloud within minutes over wifi (Photon) or cellular (Electron). You can start programming it right away using their online IDE, or after a simple download with their Atom-based desktop IDE. No multi-part toolchains, build configurations, temperamental cloud authentication processes. Focus!
Even better, both of these IDEs support compiling online and updating your firmware over the air (OTA), so your device can remain operating in situ while you iterate and debug. Flow!
Second, the Cloud API is quick and easy to understand. You can define up to 20 variables (properties) which can be altered by the device, and 15 cloud functions (commands) that can alter those variables or perform other tasks.
Particle’s simplified cloud model clears a path to building the essential functions and activities of your internet thing. Particle still provides access to the more complex features of a message-driven model with what they call Events; but, you can get quite far with just variables and functions.
As a bonus, the Particle chips are Arduino-compatible processors, so you have access to plenty of already-ported libraries that interact with sensors, LEDs, servos, network requests, and much more. Even if a library hasn’t been ported, it’s likely relatively simple to do so yourself, alongside plenty of tutorials and guides to get you going programming with Arduino.
Bonus 2: There’s a mature and extensive community on Hackster, with 628 projects and counting you can use as templates for your own, or just as a self-study program.
Finally, Particle is opening up connectivity to their cloud to other hardware platforms. So, if you need BLE, you can flash your code to a RedBear Duo or bluz. Or, if you need the backing of a complete computer, you can flash to a Raspberry Pi.
As You Grow
With an easy start, plenty of building blocks and examples, and useful constraints, Particle hits a sweet spot for capturing and iterating your innovation.
As you continue development, you’ll want to explore other platform and IoT development models. You may find that the way the structure their cloud interactions and data better achieves your goals. But, in my mind, there really is currently no better place to get started than with Particle.
I learned everything here by going through it myself. I also found things that I thought could be easier for others, so I built something to do just that.
If you’re starting out on the Particle Cloud I invite you to check out Porter. It’s a customizable, cloud-based interface for any Particle device, saving you the need to code a UI, message storage, notifications, device sharing, and more.