Lab Notes: Exploring the Particle IoT Platform
With the Internet of Things becoming a quickly-growing field in tech and some exploration of the field under our belt already, we’ve continued to test the waters and get a feel for some of the various other platforms available for IoT development. We’ve previously written about the work we did with Amazon’s Dash Button, and now we’ve set our eyes on the Particle Photon.
The Photon is an Arduino-like device made by Particle (formerly Spark) optimized for IoT development. Its optimizations include built in Wi-Fi capability, a tiny form factor, a surprisingly helpful status LED, and considerable feature support provided by the Particle Cloud. The similarity to Arduino, which includes using the same Processing language with a few modifications, makes it easy to quickly get working with sensors and actuators. The Particle Cloud adds another layer of convenience by allowing the user to access devices, create webhooks, and even update the device software remotely.
An interesting potential application of IoT products is to deploy a fleet of devices inside a climate-sensitive facility, like a greenhouse or museum. Such a fleet would allow the conditions at locations throughout the facility to be measured, compared against each other, and tracked over time. Using this hypothetical situation as a starting point, we decided to try it out with Particle.
What We Did
With our goal being to monitor climatic conditions, we ordered a Particle Photon along with a few sensors: the BME280 and DHT22 climate sensors, and the PIR189 motion sensor. The BME280 measures temperature, pressure, altitude, and humidity, while the DHT22 can measure temperature, pressure, humidity, and dew point. The PIR189 is more straightforward, simply allowing the user to know whether or not any motion is presently occurring. On the software side, we had a simple backend consisting of a Postgres database and a Python server that received data from the Photon sent by the Particle webhook, stored it in the database, and then retrieved it for viewing upon request.
It wasn’t too long before we were able to get our system running and collecting data on the climate in one of our offices. Unsurprisingly, monitoring a climate-controlled office doesn’t lead to very exciting data — although it was fun to pinpoint when people actually came into the office! More interesting was the experience with using Particle.
We got well acquainted with the various solutions that comprise Particle’s platform. For development, though users can naturally write code anywhere, code must be sent to the Particle Cloud to be verified and compiled on their servers, which then return the binary that will be run on the Photon. Using the Particle CLI package, you sacrifice the convenience of some of the features offered by the Particle IDEs to gain access to more manual control over the device. This option enables users to receive the compiled binary file and then flash it to the Photon via serial connection, so if the Photon is set to Manual Mode, in which it is disconnected from the Particle Cloud, then using the Particle CLI allows you to interface with the device even if Wi-Fi connection is momentarily spotty or unavailable by skipping the cloud compilation step.
The other options for interfacing with a Particle device are the Particle Dev local IDE and the Particle Build online IDE. Both of these offer considerable convenience at the cost of the manual control available with the Particle CLI, e.g. neither can be used without an internet connection. There are some minor differences. With Particle Build, you have immediate access to the dozens of libraries available for Particle devices, including ports of existing Arduino libraries for devices like the BME280; with Particle Dev, one must manually download libraries from the internet and then add them to the project directory. Mostly though, everything from compiling code to choosing which device to upload to only takes a few clicks. Since all three development options perform the essential steps of compiling and uploading to the Photon, the developer is afforded the luxury of using an option best suited to their tastes, while having two other options to switch to if needed.
Challenges
While working with Particle was a treat, we were reminded quite often that their platform is still somewhat young. Particle offers a great deal of documentation on their website, which is pleasantly designed and laid out, but many important details are not mentioned, leaving puzzled users to ask if there is some kind of centralized guide where such details — like Arduino’s key library Wiring.h being renamed at first to Spark.h and then application.h for Particle — are stated. Looking at their guides, forums, and press releases, we came across statements like “Currently community libraries aren’t supported natively (but we’re working on it).” and “Data storage is not part of the Console yet, although it is on the roadmap for a future addition.”
These growing pains aren’t necessarily a bad thing. In the cited forum posts, users are communicating directly with such higher-ups as the CEO and CTO (also founders) of Particle. Particle is clearly continuing the impressive growth they’ve displayed since starting in 2012, so their platform will only improve with time. Users must be mindful when working with Particle that the reason information can be difficult to find is most likely because they’re rapidly growing.
Next Steps
We will be testing a climate system again, but this time around we’ll use a Raspberry Pi 3 Model B loaded with Windows 10 IoT Core and connected to an Azure backend. With our Particle setup running, we can continue to monitor data and see how the Photon performs over time, but like Particle we’re just going to keep moving forward with evaluating multiple platforms.
Have a vision for an IoT product you want built? Drop us a line.
