LoRaWAN integration

LoRaWAN connects battery-powered sensors over kilometres at very low data rates. ALLINLET does not talk to radios directly. It receives decoded or raw uplinks from the network server, which handles device activation, de-duplication across gateways and security keys.

Typical sources

Water meters and level sensors in utilities, soil moisture and weather probes in agriculture, waste bin fill sensors, room temperature and occupancy sensors in buildings, and asset trackers. Devices send small uplinks, often every 10 to 60 minutes, and spend most of their time asleep.

Transport

Network servers such as The Things Stack and ChirpStack expose application data through MQTT integrations or HTTP webhooks. ALLINLET subscribes to the application uplink topic or receives webhook posts over HTTPS. Each message contains the device EUI, frame counter, port, payload, and metadata including received gateways, RSSI, SNR and the spreading factor used.

Prerequisites

  • Access to the network server application with an API key or MQTT credentials limited to that application.
  • The payload decoder or byte format specification from the device manufacturer.
  • A device list linking DevEUI to asset, location and installation details.
  • Expected uplink interval per device to support freshness checks.

Payload meaning

Raw payloads are a few bytes, for example two bytes of temperature in hundredths of a degree and one byte of battery percentage. Decoding may happen in the network server or in the ALLINLET mapping, but must be done in only one place. The measurement time is normally the network server receive time, since many devices do not include their own clock. Radio metadata is kept as diagnostic context, which helps explain gaps caused by coverage rather than sensor faults.

Limitations

  • Duty-cycle and airtime rules restrict how often devices can transmit; LoRaWAN is not for high-rate or real-time data.
  • Downlinks and device configuration are outside the integration scope.
  • Lost uplinks are not retransmitted by most class A devices, so gaps are normal and should be shown as gaps.
  • Decoder errors after firmware updates are a common source of wrong values.
  • Network server versions and device models are validated per project.

Further reading

Catalogue listings describe possible integration paths. Implementation and validation status is confirmed for each source during project scoping; no certification, service level or price is implied by this page.

Plan your data integration

Share your devices, protocols and network constraints, and we will propose a first validated connection.

Related pages