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

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.

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.
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.
The Standarized UpLink Schema
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
}
}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
The Standarized Downlink Schema
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,
...
}
}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
Uplink Property
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.

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.

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.

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.


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?

