Mass Provisioning Devices and Easy TTN Import

For most platforms, a web-based dashboard is ideal for getting started. On Helium’s Console, you can create credentials for a LoRaWAN IoT device and integrate it with an MQTT, HTTP, or AWS IoT backend with just a few clicks.

When it comes time to deploy more than just a few devices, though, doing “just a few clicks” a dozen times is enough to drive any IoT developer insane. And when it comes to shipping a few thousand, it’s just not an option.

This is why we’ve developed a Command-Line Interface (CLI) for Helium’s Console. Not only does it help you programmatically provision, configure, and manage your fleet of devices, but it also helps you import existing device deployments from providers like The Things Network and (soon) others. To dive in, head right to the full CLI documentation.

CLI Basic Usage

This quick GIF demonstrates how easy the CLI makes it to work with your devices.

Manage your devices and labels — No Clicks

The foundation of the CLI is built around uploading device data and assigning labels. The idea is to help you provision thousands of devices at a time or to automate device upload on a production line. Here’s everything you can do in this first release:

create and delete devices records

list all device records

create and delete labels

add or remove label to or from device

Import Devices from TTN — With No Downtime

Automating device import from a few different providers was one of the primary motivators for this CLI. We’re doing a lot of these engagements and wanted to make this seamless for our customers and users. When migrating from The Things Network (TTN) specifically, there are two elements of your deployment we need to account for with extra care:

TTN’s application construct;

construct; Your sensor’s sub-band joining logic.

Use Helium Labels to Replicate your TTN Application logic

TTN has a hierarchical setup for devices where an application has many Child Devices. And Child Devices are owned by a single application. The Application has a unique AppEui and you setup your Integrations by Application/AppEui .

Helium Console has a much more flexible configuration where Devices are just independent records with some unique set of AppEui , DevEui , and AppKey . Regardless of AppEui , none, one, or many labels may be attributed to a Device. And none, one, or many Integrations may be connected to a Label.

Despite the very different primitives, we thought it would make import easier if you could automatically create a Helium Label for each TTN AppId , which means after the automated import you’re just a few clicks a way from routing all your device data to the appropriate Integration.

Here’s a two minute video summarizing the automated import workflow:

Band, bands, bands… all types of bands

Once you’ve imported your device’s credentials, you can likely join the Helium Network without doing anything to your device. In fact, any already deployed LoRaWAN-compliant device that supports OTAA can create a session with the Helium network with no in-the-field updates.

The necessary LoRaWAN feature is the following (per the 1.0.2 spec)

The join-request message can be transmitted using any data rate and following a random frequency hopping sequence across the specified join channels¹.

In the US, there are no “Join-Request sub-bands”², so hopefully your LoRaWAN stack has interpreted this as “try all 64 US channels”. If that is so, then it will find the Helium sub-band 7 (channels 48–55) and a session can be created. After the Join-Accept message has been transmitted down and received by the device, the session keys may be derived and normal data frames ensue.

Following its first DataUp frame on the appropriate sub-band (some stacks will continue hopping randomly but others may guess that they should do their first random transmit attempt on sub-band 7), the device can expect a DataDown frame from the Helium Network Server.

This DataDown frame contains an ADR command which provides the channel mask for the Helium sub-band. (For those anticipating our Europe roll-out, we do look forward to using CFList in the Join-Response !). The command, when processed by the LoRaWAN stack, should update the channel mask and then send the ADR request confirmation back up, and henceforth, will stay on the Helium sub-band.

Ready to Deploy?

We’re very excited about the CLI, and it’s already getting some great use from the Helium developer and customer community.