LoRaWAN

LoRaWAN (Long Range Wide Area Network) is a low-power, wide-area networking protocol designed to connect wireless battery-powered devices to the internet across regional, national, or even global deployments. It is optimized for low energy consumption while providing secure bi-directional communication, localization capabilities, and support for mobility.

As one of the most widely adopted technologies in the IoT market, LoRaWAN provides several advantages:

  • Long Range: Coverage of several kilometers in rural environments and a few kilometers in dense urban areas.

  • Low Power Consumption: Devices can operate for years using standard batteries.

  • High Capacity: A single gateway can manage thousands of devices simultaneously.

  • Cost Efficiency: Reduced infrastructure and operational costs compared to cellular alternatives.

  • Secure Communication: End-to-end encryption ensures data confidentiality and integrity.

Device integration is usually achieved through a LoRaWAN Network Server (LNS), which manages communication between gateways and applications.

Compatible LNS

Thinger.io maximizes interoperability with LoRaWAN by offering plugins that integrate with the most widely used LNS providers in the market

Cover

The Things Stack

The world’s largest community-driven LoRaWAN network, freely accessible and widely adopted for collaborative and educational projects. It enables quick onboarding and extensive global coverage.

Cover

LORIOT LNS

A professional-grade solution offering advanced enterprise services, including scalability, high availability, and SLA-backed support. It is commonly chosen for commercial and industrial deployments.

Cover

ChirpStack

An open-source LNS that must be self-hosted and maintained. It provides maximum control and customization for developers, but requires infrastructure management and operational expertise.

Note: Some LoRaWAN gateways include built-in LNS functionality. Support for this type of integration is currently being explored.

Thinger.io does not endorse one LNS provider over another. Multiple integrations are provided to reach the broadest possible range of user communities. It remains the responsibility of the user to evaluate and decide which service best suits the requirements of a specific project and deployment scenario.

Integrating LoRaWAN Devices

The Challenge

When you build a LoRaWAN IoT product, your devices send data (uplinks) and receive commands (downlinks) through a LoRaWAN Network Server (LNS). Each LNS provider uses its own JSON schema for device uplinks and downlinks, which makes it impossible to create a generic product configuration. That is why each LNS plugin parses each LNS request into a Thinger.io standardized format.

Consider a temperature monitoring product initially configured with LORIOT. The product reads device properties, configures dashboard widgets, and defines data processing rules based on LORIOT's specific JSON structure. Six months later, you decide to switch to The Things Stack. Without standardization, you would need to:

  • Rewrite data processing rules to match the new schema

  • Update device property mappings

  • Modify automation workflows and API integrations

The Solution

Thinger.io's LoRaWAN plugins implement a protocol adaptation layer that normalizes data from any LNS provider into a unified schema. Each plugin acts as a bidirectional parser, translating between the LNS-specific format and Thinger.io's standard format.

Every uplink message processed by a Thinger.io LoRaWAN plugin conforms to a canonical JSON schema, regardless of the originating LNS:

{
  "deviceEui": "1234567890ABCDEF",
  "deviceId": "sensor-room-101",
  "source": "loriot",
  "appId": "building-monitoring",
  "fPort": 1,
  "fCnt": 42,
  "payload": "01A5CB1288A",
  "decodedPayload": null,
  "metadata": {
    "ack": false,
    "battery": 254,
    "offline": false,
    "seqNo": 12345
  }
}
Field
Type
Definition

deviceEui

string

Device Extended Unique Identifier

deviceId

string

Human-readable device identifier. This is usually used to autoprovision the device.

source

string

LNS provider identifier (lowercase: "loriot", "chirpstack", "ttn")

appId

string

Application identifier within the LNS

fPort

integer

LoRaWAN application port

fCnt

integer

Uplink frame counter

payload

string (hex) | null

Hex-encoded raw payload bytes (when LNS doesn't decode)

decodedPayload

object | nulll

Decoded uplink data (when LNS provides decoding)

metadata

object

Optional LNS-specific metadata

Exactly one of payload or decodedPayload must be present

For the same reason as Uplinks, Downlink data format must properly formatted and forwarded to Thinger.io LNS plugin. As an example;

{
  "data": "FF0164",
  "port": 85,
  "priority": 3,
  "confirmed": false,
  "uplink": {
    "deviceEui": "1234567890ABCDEF",
    "fCnt": 42,
    ...
  }
}
Field
Type
Definition

data

string (hex)

Hex-encoded payload bytes

port

integer

LoRaWAN FPort

priority

integer (0, 1 ... 5, 6)

Queue priority (0=lowest, 6=highest)

confirmed

boolean

Request MAC-layer acknowledgment

uplink

object

Last Recieved Uplink

Product Configuration Profile

The LoRaWAN Product Template in the Marketplace has been specifically designed to be used as a generic template for any LoRa-driven device working through any LNS supported in Thinger.io. To start building a LoRaWAN device, this integration would be as simple as installing this generic template, clone it to change the device_id and start working!

This generic template provides a product with the following basic configuration

This Uplink Property stores the last uplink received from the device. It is used to recall essential information needed to send downlinks to the device or to visualize specific device metadata in dashboards.

Uplink Property

Generic Data Bucket

A pre-configured data bucket is also created within this product template to provide a generic "end-of-pipeline" storage solution for the data. This bucket automatically stores time-series data from device uplinks.

Generic Data Bucket

It is recommended (though not required) to perform data decoding at the bucket stage rather than at the API resource level. This approach ensures that the raw uplink message stored in the product property remains unaltered, preserving the exact payload format originally received from the LNS plugin.

API Resource

Pre-configured uplink and downlink endpoints have been created within the product profile configuration, defining a unified data communication bridge with the LNS Thinger.io Plugin. These channels communicate directly with the LNS plugin, so all data incoming to and outgoing from these endpoints is expected to be correctly formatted according to the standardized schema.

API resources

These API endpoints use the standardized format described in the plugin documentation. Do not modify the endpoint structure unless you understand the implications for cross-LNS compatibility.

Auto Provision

The Device autoprovisioning will need to be configured in the application that has been created in the LNS Thinger Plugin. This device ID comes in two parts:

  • The prefix needs to be specified in both the product autoprovision schema and in the LNS application plugin configuration. This ensures consistent device identification across both systems.

Autoprovision Configured in Product Profile
Device ID Prefix configured in LNS Plugin (in this case, The Things Stack)
  • The device ID sufix: This id sufix is the device EUI wich will be appended in the LNS Thinger Plugin.

Last updated

Was this helpful?