Particle IoT Platform Update

Part 1

In this two-part series, Brian is going to take a fresh look at the latest IoT products offered by Particle. Particle’s offerings are noteworthy due to the integration of their hardware modules (Wi-Fi and cellular) with the cloud portal they operate.

As a writer, I jump from project to project, and hadn’t kept up with the changes and advances that had occurred with the Particle platform since then. But recently, I decided to take a fresh look at the current Particle offerings. The structure of its cloud service and the monthly cost of the cellular connection were the first things I investigated. I was pleasantly surprised to find that:

• Particle has introduced a free “sandbox” account for developers, which is fully functional but limited to a small number of connected boards. The cost of the cloud service, beyond that limit, reflects the number of IoT connections and their traffic volume.
• The monthly cost of a cellular connection is now free (with limits). Here too, the cost increases when more units are connected and traffic volume increases.
• When I plugged in my spare Electron board, it connected to the cell phone tower easily. I had stopped paying the $4 monthly cellular charge some time back, so I did have to go to the Particle website and reactivate the SIM account. But once I did this, the Electron connected to the Particle cloud exactly as it had four years ago—except the cell service was now free.

With the IoT environment changing as quickly as it has over the last few years, I was quite surprised that my four-year Electron board was still interacting with Particle’s cloud server, apart from an integration with a third party cloud service which I’ll get into later.

Current Particle Products

The Particle Electron board (cellular) and the Photon board (Wi-Fi) that I had used in my older Circuit Cellar articles have been replaced by the Boron and Argon boards, respectively. Where the older boards used an STMicroelectronics microcontroller (MCU) plus a cellular or Wi-Fi modem module, the newer boards are now powered by a Nordic Semiconductor nRF52840 system-on-chip (SoC). The Argon uses the ubiquitous ESP32 MCU as a Wi-Fi coprocessor, and the Boron uses a u-blox SARA R510 LTE modem (in North America) as its cell modem. Particle also sells complete tracker modules, which are cellular-based and designed specifically for tracking purposes.

What triggered my re-examination of the Particle boards and platform was the fact that both the Argon and Boron boards have Bluetooth 5 capability (a built-in function on the nRF52840 SoC). This wasn’t available on the earlier Photon/Electron modules. I had in mind a basic gateway project in which ESP32s are hooked up to various sensors around the home, all of which use the BLE protocol to communicate with a gateway that could be implemented using either a Particle Argon or Boron module. This would give me free access to Particle’s cloud infrastructure (at my usage level). Part of my interest in BLE stems from the fact that I had just finished working with the GUI-O Android app (“GUI-O: A ‘Virtual’ Front Panel: For ESP32 Projects,” Circuit Cellar 389, December 2022), which communicates with MCU boards via Bluetooth and provides an excellent custom-designed “front panel” for an MCU project [3].

A nice feature of the Argon/Boron modules is that they both share a common physical footprint and pinout. Particle chose to adopt Adafruit’s Feather module standard for its modules. Figure 1 shows a Boron Module.

Choosing the Feather footprint was wise, considering that Adafruit is well-respected in the maker community. It has an admirable policy of developing software libraries for all of its MCU and peripheral boards (including both the Arduino IDE and its own CircuitPython software platform). As a result, there are many developers using Adafruit’s Feather MCU boards, and many peripheral boards have been developed using the Feather pinout specification. For example, Adafruit makes an Ethernet FeatherWing. Feather “wings” are analogous to Arduino “shields” and Raspberry Pi “hats.” Figure 2 shows an Adafruit Feather Tripler—basically a bus board that allows up to three Feather boards to be plugged in. Figure 3 shows the Argon pinout and the general Feather physical layout. This pinout is also applicable to the Boron board.

Another nice feature of the Argon/Boron modules is that, in addition to their built-in Bluetooth chip antennas, they each contain a(n) U.FL connector(s) for external antennas, as well. Argon boards need an external Wi-Fi antenna, and Boron boards need an external cellular antenna to operate. These are included if you are ordering the boards in small quantities (that is, not in a tray). I routinely use Hammond extruded aluminum enclosures for my projects, and to get optimum RF range, it’s best to have the option of using either an external whip antenna or at least being able to attach a “stick-on” antenna to the plastic end-plates that can be used with these extruded aluminum enclosures.

Even though the Particle boards have evolved from using an STMicroelectronics MCU to a Nordic nRF52840 SoC, the programming language for firmware development has remained basically the same. Particle uses the Arduino “sketch” concept (in other words, C++), so anyone who has used the Arduino IDE won’t have trouble writing firmware for the Particle boards. Of particular note is that Particle provides about 3000 libraries. These are, for the most part, ported from pre-existing Arduino libraries to support various peripheral devices, as well as communications protocols and so forth. I’ve run into a few cases where these ported libraries won’t compile without errors, so don’t expect perfection here. I find that an abundance of good libraries is often what tips the scales when I’m deciding what family of MCUs to use.

As I write this article, the Particle product line is being updated. The older modules that I featured in my earlier article series are basically discontinued, but some stock is still available. The older 2G/3G (cellular) Boron modules are available from distributors, but 2G/3G cellular service is being phased out by the carriers. The newer Boron LTE modules are available directly from the Particle e-store (in small quantities), as well as DigiKey and other distributors. The Argon board has been replaced by the Photon2 board (which I discuss later). At the time of writing, the Argon board is still available from distributors, and directly from Particle’s online store at a significant discount.

The Particle Cloud Service

I’d best be described as a “maker”—I design projects but don’t put them into production at any scale. When it comes to considering cloud services, I never need any complex capabilities, nor do I generate any large amount of data traffic. With that in mind, I prefer cloud services that:

• Are free—no monthly charges for modest needs/traffic.
• Preferably do not require a credit card to sign up. Even “free” (small-scale) services sometimes require this (such as AWS).
• Have some indication that the provider has a reasonable business plan that will allow them to provide the service into the future.
• Have a platform that can be easily integrated with other cloud providers that perform specialty functions.
• Have security of data and credit card information (if used).

In my opinion, Particle covers all of the above bases very well. The security issue is generally not critical to me. The household parameters that I would be transmitting to the cloud are not going to be of any interest to anyone else. However, all cloud platforms must implement some security functions, and that generally means that remote IoT devices must be able to handle sophisticated authentication routines in order to connect to the cloud server. Minimally, this dictates that even modest MCUs that can act as IoT devices must also be able to handle complex encryption algorithms. So, the developer usually must be familiar enough with this topic to incorporate them into his own firmware.

For the most part, the developer doesn’t have to worry about the coding needed to implement security with Particle devices. Each module comes with a serial number marked on its label, as well as a QR code. For those wanting to activate small numbers of devices, you need to install the Particle app on your phone or tablet (iOS or Android). When you open this app, you’ll see a “+” symbol at the top right (plus a list of any currently registered modules). Click on the “+” to pick the type of board that you have. Next, you’re prompted to scan the barcode on the Particle module’s label. The app will then pair the module to your phone via Bluetooth. In the case of the Argon/Photon2 boards, a scan will be performed of nearby Wi-Fi access points, after which you choose your access point. You must provide the SSID/password for your access point—both are now securely stored in the module’s Flash memory. You are also prompted for a name for the device, which is solely for your own convenience in recognizing it.

At the completion of this process, if you launch the Particle Console from your web browser and log in to your Particle account, you should see a listing for your newly registered device. This list will contain an ID (24 hex characters, generated by the Particle cloud server). It will also list the board type and the time/date of the last handshake, which in this case would be the current time. If you click on the entry for this board, a more detailed screen will be displayed that contains, among many other things, the serial number marked on the module’s label. There are a few additional windows that display the following information:

• Last Vitals: This includes the prevailing strength of the Wi-Fi signal received by the Particle module, the round-trip time to the Particle cloud server, and the amount of RAM used by the OS and any program currently loaded.
• Events: This is a chronological list of data interactions between your module and the cloud server. Such events include data sent back and forth during publish and subscribe events, as well as the status reports that are generated during OS updates (which are initiated automatically by the Particle cloud server). You also see status reports here when you are flashing new firmware over the air (OTA).
• Firmware: This window will indicate if OTA updates are enabled and contains a switch to allow you to force updates by overriding the device’s firmware setting.
• Functions and Variables: If your firmware contains cloud-connected functions and/or variables, they will be listed here. In the case of variables, you can click on a button to display the current value of the module’s variable with that name. Similarly, you can call functions (running on a Particle module) by loading any necessary argument and clicking the appropriate button.
• There is a group of buttons that allow you to ascertain whether your module is online at the moment. The Signal button will cause the module’s RGB LED to flash a rapidly changing color pattern. The Ping button does what its name implies—it sends a ping message over the internet to the module and waits for a response back.

At this point, your module is authenticated on Particle’s cloud. I won’t get into details of programming the module’s firmware now, but note that Particle devices contain OS firmware that handles all of the low-level details involved in securely connecting to the Particle cloud and transferring data back and forth in an encrypted manner. All necessary access keys and such are stored in non-volatile flash memory—these were generated automatically when the above-outlined registration process was performed.

It’s important to note that the Particle cloud service is designed as a secure way for Particle modules to connect to a cloud platform. It was not designed to be a permanent database where Particle modules could download large amounts of data. If you are used to using MQTT cloud services, they act as a broker, or “middleman,” and store data originating from remote IoT modules or a PC, for example. They allow both the remote IoT device and an associated computer to asynchronously exchange data—in other words, there is no need for both parties in the transaction to be available (online) at any given time. Of course, such MQTT services can also enforce limitations on how much data can be stored, and for how long.

The Particle Cloud server itself does not store events originated by Particle IoT modules, nor the data that may either be published or subscribed to by Particle IoT modules. You can quickly confirm this for yourself by refreshing the Particle Console web page while it is currently showing events that have occurred since you first opened it. All such events will disappear after the webpage refresh, and only new events will be displayed as they occur.

From the above, you can see that the Particle cloud will not act as the traditional MQTT server that you may be accustomed to. As a developer, Particle’s Sandbox account is completely free—but you’re not going to be able to stream data to it from Particle devices and expect it to be waiting for you, in a database array, when you log in with your PC. For cloud functions that either store data or send out alerts based upon conditions monitored on the individual Particle modules, you will have to use what Particle calls “Integrations.” I’ll discuss those integrations later in the series.

Programming Particle Firmware

As mentioned earlier in the article, the firmware running on a Particle board consists of two main parts:

• The Particle OS: This firmware is generated by Particle and tailored to the specific MCU and modem combination on your target module. A version of it is present when you first receive the module—that’s what allows it to be initially registered with the Particle cloud. This OS may get updated OTA automatically by the Particle cloud server, from time to time.
• The customer’s application: This is C++ code, written in the style of an Arduino sketch. The developer writes the code and compiles it, and it can then be flashed to the module’s flash storage either by an OTA method or via a USB connection between the PC computer and the module itself.

As a developer, you don’t have to be particularly knowledgeable about the underlying code in the OS itself. One thing to note is that if you are working with some pre-existing application code (or a code example provided by Particle), the OS version must match the version used when the application was originally written. Generally, the OS is backward-compatible: newer OS versions will usually work with applications written under an earlier version of the OS. However, new application programs may not work when combined with earlier versions of the OS.

There are two distinct methods of developing application code for Particle devices—each one uses a different toolchain:

• Web-based IDE: Using this method, everything—your application code, the editor, compiler, linker, and device flashing utility—is performed on the Particle cloud using a web-based user interface.
• Host PC-based toolchain called Particle Workbench: With this method your program code resides on your own local disk drive. The editor is implemented using Microsoft Visual Studio Code, and the compiler/linker toolchain is installed on your PC and runs under the Visual Code IDE. From this IDE, called the Particle Workbench, you can download the application’s binary code to the Particle module, using either the PC’s USB port, or the OTA method.

If you are just starting out with Particle modules, I would strongly recommend that you choose the Web-based IDE method, for the following reasons:

• While I have referred to the programming toolchain as a single entity, it isn’t really. It will vary depending upon what Particle module you are using: STM, Nordic, and, recently, Realtek MCUs have all been used. Also, the OS version present on the target module will have to be addressed by the toolchain. All this complexity is transparent to the developer/programmer when using the web-based toolchain.
• At some point, I read that 3000+ libraries are hosted on the Particle cloud. Using the web-based IDE, these are easily included in your program code by merely browsing the libraries and clicking the button labeled “Include in Project.” Your target program must be currently loaded in the editor window when doing this. Also, you are compiling using library code stored on the Particle server, so you can’t make any changes to those libraries if you were to need to do so.
• Your program code is automatically stored on the Particle server, so you don’t have to worry about backing up those source files on your local PC’s hard disk.
• Flashing your code to the target module is just a matter of clicking on the “thunderbolt” icon. Assuming that the target module is online, it will be flashed OTA.
• Compilation/linking is quite fast since it’s performed on a powerful computer running the Particle cloud.

Figure 4 shows the Particle web-based IDE. The command icons on the left are generally easy to decipher, but are also described if you hover over them. Along the bottom of the screen is a status bar. You can see the currently-selected Particle module and the blue dot beside it will be “breathing” if it is online. Compiler progress and flashing progress also appear on this status line. Your program text is color-highlighted to show keywords and language syntax.

As you gain more experience, and programs become more complex, the Particle Workbench might be more useful for the following reasons:

• The Visual Code IDE contains the IntelliSense feature. That is, it will auto-complete keywords as you type them in. If you pause while entering a line containing a call to a class function, it will display all of the class methods and the type of arguments expected.
• The Explorer window contains a hierarchical view of your source code as well as the library dependency files. You can navigate to any of the library .h or .cpp files and click on them to open that code in a new tab in the Editor window. This makes it easier to troubleshoot problems you might be having with library functionality. And, unlike the Web IDE, you can edit library code if the need arises.
• The color highlighting of the various statement elements is better than that present in the web-based IDE.
• Compilation/linking can either be done on the cloud or locally by selecting the desired option in the Command Palette (CTRL-SHIFT-P, or the F1 key shortcut, or View -> Palette).
• Flashing can be done OTA or via the USB port.

Figure 5 shows the Particle Workbench in action. Note that when opening the Command Palette, you may only see a few Particle commands at the top of the list—but those are not all that are available. After you type in “particle” you will be presented with a list of all applicable Particle commands (and other commands, not applicable to Particle, will be filtered out). See Figure 6. Incidentally, there is a small icon strip near the top right of the Workbench screen. These icons mimic those used by Particle’s web-based IDE and can be used instead of invoking the Command Palette (Figure 7).

If you have started developing a program using Particle’s web-based IDE, and decide to export that program to the Particle Workbench for more advanced development, you can do so via Particle’s site. A link to the program export page is available on Circuit Cellar’s Article Materials and Resources webpage [4].

This procedure produces a ZIP file called “export.zip” in your browser’s downloads folder. Move that zip file to the target folder on your PC and extract it there. Alternatively, you can hit CTRL-SHIFT-P while running the Particle Workbench and select: Particle Import Project.

I personally use Microsoft Visual Studio with the Visual Micro add-in in place of the Arduino IDE for all of the MCUs that I use which are supported by the Arduino IDE. I am familiar with many useful features in that environment, but I haven’t become that familiar with the Particle Workbench yet. I’m sure there are many more Visual Code features than I have listed above.

Integrations

While the Particle cloud service handles all of the interconnection functionality between a Particle device and the Particle cloud, the cloud doesn’t do anything with any events or data that it receives unless you forward these events/data to another cloud service. This is called an Integration and can take on many forms, most of which are much more sophisticated than what I need for my projects. To define an Integration, you click on

the Integrations Icon on the
Particle Console’s web page.

The main Integration categories that are available are as follows:

• Google Maps
• Azure IoT Hub
• Google Cloud Platform
• Webhooks

The first three options are popular cloud services provided by Alphabet and Microsoft.

Webhooks are different in that they can be associated with many different cloud services, or even your own web server if you have one running. Basically, webhooks work by navigating to a specific URL, made up of the host cloud service’s URL, concatenated with a long user ID string that identifies the specific user. The information sent to that URL (using the POST protocol) generally starts out with a long, unique key string(s) that is used for authentication. After that key, the specific information that has been published to the Particle cloud by a remote unit, for any given event, is sent.

There are three broad categories of cloud interactions that Particle devices might use, which make use of Webhooks:

• Sending an alert in real time to a user, to flag some critical condition that the Particle device has measured.
• Logging sensor data to a cloud service, on a periodic basis. This data can then be examined by the user in raw, table, or graphic form, at some later time.
• Accepting commands from a user at a remote location to perform some local action—like turning on a light, for example.

Let’s look at how each of these three categories can be handled by Particle devices.

Alerts

For this project, I was primarily interested in generating alerts: in other words, generating push notifications to my phone. In the past, I have had some success with cloud services using webhooks, which could send either SMS messages or email messages. However, it’s harder now to find free cloud services that will send SMS messages, and getting an MCU to send email messages using Gmail is getting difficult, due to the ever-increasing security provisions that Google requires. Because of this, I chose to use cell phone push notifications, which are equally well-suited for time-critical alerts.

One of the Integrations that is well-described in a Particle forum post is the Integration with the Pushover cloud service. Note that what used to be called the Particle forum is now called Community. Pushover is the combination of a cloud back-end service and a cellphone app that they sell for $5 USD. When you set up a free account with Pushover, they provide you with a user ID and an API token. These are tied to the phone (or tablet) on which you have installed the Pushover app. When you set up a Particle Integration for Pushover, you configure it for the following:

• The Pushover webhook URL
• Your user ID
• Your API token
• The name of the event that your remote unit will be publishing to the Particle cloud (the webhook “trigger”)
• A value that is associated with that event (for example, battery condition)
• A title for the push notification
• The message that you want to be sent via the push notification (which can include the value above).

Apart from the cost of the app, there is no monthly charge for this push notification service, at least for the modest traffic volume that I would be sending. Versions of the app are available for both iOS and Android, and once you’ve purchased the app, it can be used on more than one of your phones/devices. But, if you have both iOS and Android devices, you will have to purchase both versions of the app.

I won’t cover the details of setting up this Integration beyond the general information above. A good Webhooks Tutorial on how this is accomplished can be found on Community [5].

Originally, I set up my Argon program to just report on an alarm condition and configured a Pushover Integration for that. When I added the battery monitoring, I used a slightly different format for the data published when the battery became low. So, I set up another discrete Pushover Integration to handle battery condition alerts. However, I could see that it would be possible to use only one Pushover Integration to handle both conditions if I had written the Argon gateway program a bit differently.

Data Logging

In general, data logging is probably the main use for IoT devices. For Particle devices, this also requires an Integration with a third-party cloud provider to provide data storage as well as a method for the end-user to access the database containing that logged data. For medium to large-scale projects, this Integration would likely be implemented using Google, Microsoft Azure, or Amazon AWS.

For “makers” and small users such as myself, there are many cloud services that are available free for low-traffic users. There are too many to list here, but I have personally tried Adafruit’s IO cloud service and a few others. For my current project, I didn’t need data logging, but I wanted to investigate how this might be done and give it a try.

ThingSpeak is a popular cloud service that can be used for free, given the low amounts of traffic that I might generate. It is tailored for complex analysis of the data and does this via an integration with the MATLAB program. When you sign up for a ThingSpeak account, you must sign in using a MathWorks account (to allow the use of MATLAB). The ThingSpeak login page says that you can use ThingSpeak for free, so I assume you can set up the MathWorks account needed to access ThingSpeak for free, as well. Although I’m retired, my university MathWorks account is still active, so I didn’t need to set up a free account.

Once in ThingSpeak, you first create a channel that specifies the format of the data that you intend to send to it. As part of creating this channel, you’ll be assigned a channel ID as well as an API write key which is needed to send data to ThingSpeak. These two values, along with ThingSpeak’s URL (https://api.thingspeak.com/update) are needed to set up the Particle webhook Integration. Like the alert notification webhook described earlier, the ThingSpeak webhook will be “triggered” by the publishing of an Event from your remote Particle device. The value of that Event is what ThingSpeak treats as data and then stores.

A clear, step-by-step tutorial on setting up a ThingSpeak channel and defining a Particle webhook Integration can be found on Particle’s site [6].

As far as firmware on a Particle Argon/Boron/Photon2 device is concerned, all that is needed to send data to trigger a ThingSpeak webhook Integration is a line of code looking something like this:

Particle.publish(“temperature”, temp, PRIVATE);

In the above, “temperature” is the name of the event that has been defined as the webhook event name (the “trigger”) and temp is a program variable containing the value that you want to send to ThingSpeak. Note the word PRIVATE in this context. This can be found in older Particle example programs/libraries, but this argument has been deprecated, and will be ignored, if present. Figure 8 shows a ThingSpeak graph that was generated using a bit of random data that I sent it, using an Argon board and the ThingSpeak webhook integration described above. There are a few things to note about the Publish function:

• Currently, a device can publish at a rate of about one event per second, with bursts of up to four allowed in one second. A back-to-back burst of four messages will take four seconds to recover.
• Particle.publish() and Particle.subscribe() handlers share the same buffer. As such, calling Particle.publish() within a Particle.subscribe() handler will overwrite the subscribe buffer, corrupting the data. To prevent this, copy the subscribe buffer’s content to a separate char buffer prior to calling Particle.publish().
• Publishes are not end-to-end confirmed. Even if the Particle.publish function call returns a value of true, that just means it was acknowledged by the Particle cloud server. There is no guarantee that any recipient (another device, webhook, or SSE) will receive it.

In Part 2 of the series, I’ll describe the remaining basic Particle Integration category. I’ll also briefly cover the new line of Particle modules including the Photon2 and the new Boron module. I’ll also cover the hardware and the programming involved in both the Gateway unit as well as one IoT remote unit. 

REFERENCES
[1] Brian Millier, “Picking Up Mixed Signals: Easing into the IoT Cloud (Part 1): Web Connecting MCUs.” Circuit Cellar 340, November 2018.
[2] Brian Millier, “Picking Up Mixed Signals: Easing into the IoT Cloud (Part 2): Modules in Action.” Circuit Cellar 342, January 2019.
[3] Brian Millier, “GUI-O: A ‘Virtual’ Front Panel: For ESP32 Projects.” Circuit Cellar 389, December 2022.
[4] Particle’s Web IDE Exporter: https://docs.particle.io/tools/developer-tools/web-ide-exporter/
[5] Community Tutorial on Pushover Integration: https://community.particle.io/t/webhooks-tutorial-push-notifications-with-pushover/52070
[6] Tutorial on setting up a ThingSpeak channel and defining a Particle webhook Integration: https://docs.particle.io/getting-started/integrations/webhooks/

SOURCES
DF Robot ESP32C3 Beetle module (DFR0868): https://www.digikey.ca/en/products/detail/dfrobot/DFR0868/16678683?s=N4IgTCBcDaICIDEBKAGAHANjSAugXyA
External Bluetooth Antenna: Pulse Electronics W3334B0100, https://www.digikey.ca/en/products/detail/dfrobot/DFR0868/16678683?s=N4IgTCBcDaICIDEBKAGAHANjSAugXyA

RESOURCES
Particle | www.particle.io

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2024 #402 – Get a PDF of the issue

Sponsor this Article