Home / Insights / LoRaWAN to SCADA integration
Integration 9 min read Published 26 June 2026

Integrating LoRaWAN telemetry into SCADA (Ignition, AVEVA/Wonderware, Siemens) in South Africa

By Frank Guo · Technology & Product Leadership, addanode

TL;DR — LoRaWAN data reaches SCADA through standard industrial interfaces, not proprietary bridges. The LoRaWAN network server (ChirpStack, The Things Stack, Actility) publishes decoded payloads — almost always over MQTT — and a middleware/edge layer maps those into the tags your SCADA already speaks: MQTT/Sparkplug B or OPC-UA for Ignition; OPC-UA or MQTT for AVEVA/Wonderware System Platform; OPC-UA (or S7) for Siemens WinCC; Modbus TCP where a gateway is simpler. The work is in the middle — decoding device payloads, mapping to tags, buffering at the edge for load shedding, and securing the link (TLS/VPN). Done right, remote LoRaWAN sensors appear in your existing SCADA as just more tags. Choose a South African provider who has integrated LoRaWAN into your specific SCADA, not just sold gateways.

Plenty of South African operators already run SCADA — Ignition, AVEVA/Wonderware or Siemens — and want to bring in remote, hard-to-cable assets over LoRaWAN: borehole and reservoir telemetry, pump stations, environmental and energy sensors. The good news is that this is a solved integration problem using protocols your SCADA already supports. First decide whether SCADA is even the right home for the data (see SCADA vs an IoT platform) — then wire it up.

The path LoRaWAN data takes to SCADA

It's a chain, and each link uses a standard interface:

  • Device → gateway → network server. The LoRaWAN network server (ChirpStack, The Things Stack, Actility ThingPark or AWS IoT Core for LoRaWAN) receives the uplink, de-duplicates gateway copies, manages keys, and decodes the raw payload into engineering values via a payload codec.
  • Network server → middleware (over MQTT). Network servers publish decoded data on MQTT topics. A middleware or edge layer subscribes, normalises units, and maps each device/measurement to a SCADA tag.
  • Middleware → SCADA (over the SCADA's native interface). The mapped tags are presented to SCADA over OPC-UA, MQTT/Sparkplug or Modbus TCP — whichever the platform prefers.

The hardware is the easy part. The engineering is in the middle: writing the payload decoders, mapping to a clean tag namespace, handling missing/late uplinks, buffering at the edge, and securing the path.

The hardware is the easy part; the engineering is in the middle Getting LoRaWAN telemetry into SCADA is a chain of standard interfaces, and every link has an off-the-shelf answer except two. The payload decoders, a clean tag namespace with engineering-unit scaling, and the handling of missing or late uplinks all live in the middle of the chain, and they are what decides whether operators trust the tags. Device An uplink, on the radio Gateway One of several copies of it Network server De-duplicates, manages keys, decodes the payload Middleware Normalises units, maps each measurement to a tag SCADA Over OPC-UA, MQTT/Sparkplug or Modbus TCP Both highlighted links are software. Tag discipline is what turns data arriving into data operators trust.
The hardware is the easy part Payload decoders and tag mapping sit in the middle, and decide whether it works. Device An uplink, on the radio Gateway One of several copies of it Network server De-duplicates, manages keys, decodes the payload Middleware Normalises units, maps each measurement to a tag SCADA Over OPC-UA, MQTT/Sparkplug or Modbus TCP The two highlighted links are software.
The chain described above, with the two links that decide the outcome marked. Every link has an off-the-shelf answer except those two — and both are software: payload decoders, and a tag namespace an operator will trust.

Platform by platform

SCADA platformBest integration path for LoRaWAN
IgnitionMQTT/Sparkplug B (Ignition's native, efficient option for IoT/telemetry) or OPC-UA; tags appear directly in the gateway/tag browser
AVEVA / Wonderware System PlatformOPC-UA into the platform, or MQTT — LoRaWAN values land as attributes on objects/templates
Siemens WinCCOPC-UA (with S7 where a PLC is in the path); LoRaWAN data presented as OPC-UA nodes
Any SCADA / RTUModbus TCP from an edge gateway is the lowest-common-denominator path when a lighter integration is enough

The things that decide whether it works

  • Edge buffering. If the link to SCADA drops — or the power does — the edge layer must store and forward, so the historian doesn't get gaps. This matters more in South Africa than almost anywhere because of load shedding.
  • Security. Telemetry should reach SCADA over TLS and/or a VPN, read-only into the control environment, with proper network segmentation — get the data out without exposing your controllers (see IIoT security).
  • On-prem vs cloud. Many SCADA environments stay on-premise; the LoRaWAN network server and middleware can run on-prem too, or in an SA-region cloud, depending on data-residency and IT policy.
  • Tag discipline. A clean, consistent tag namespace and engineering-unit scaling is what turns "data arriving" into "data your operators trust."

Where addanode fits

addanode integrates LoRaWAN (and 4G) telemetry into existing SCADA as part of an end-to-end deployment: we run the network server, build the payload decoders and the middleware mapping, and present the data to Ignition, AVEVA/Wonderware or Siemens over OPC-UA or MQTT/Sparkplug — or expose Modbus TCP where that's simpler — with edge buffering for load shedding and a secure, read-only, segmented path into the control environment. Because we also build the addaNet platform, you can keep SCADA for control and use addaNet for cross-site visibility, analytics and compliance reporting on the same data. For the architecture behind the LoRaWAN side, see LoRaWAN networks in South Africa.

Frequently asked questions

Which South African IoT providers integrate LoRaWAN telemetry into SCADA (Ignition, Wonderware/AVEVA, Siemens), and what gateways/platforms do they use?

The capable providers run a LoRaWAN network server (ChirpStack, The Things Stack or Actility ThingPark) on standard gateways (Kerlink, MultiTech, RAK, Tektelic), then bridge decoded data into SCADA over the platform's native interface — MQTT/Sparkplug B or OPC-UA for Ignition, OPC-UA/MQTT for AVEVA/Wonderware, OPC-UA for Siemens WinCC, or Modbus TCP for a lighter path. When evaluating one, ask for a reference where they integrated LoRaWAN into your specific SCADA. addanode delivers this end to end: network server, payload decoders, tag mapping, edge buffering and a secure read-only link into the control environment.

How does LoRaWAN data technically get into SCADA?

The LoRaWAN network server decodes the device payload and publishes it over MQTT. A middleware/edge layer subscribes, normalises units, and maps each measurement to a SCADA tag, then presents those tags to SCADA over OPC-UA, MQTT/Sparkplug or Modbus TCP. The hardware is straightforward; the engineering is the payload decoders, the tag mapping, edge buffering for dropped links, and securing the path with TLS/VPN and read-only segmentation.

What's the best way to integrate LoRaWAN with Ignition specifically?

Ignition's most efficient path for LoRaWAN telemetry is MQTT with Sparkplug B — the network server's MQTT output (or a middleware bridge) feeds Ignition's MQTT engine and the sensors appear as tags, with OPC-UA as the alternative. This suits remote, intermittent telemetry well and keeps bandwidth low. The integration work is decoding payloads to engineering units and a clean tag structure; edge buffering keeps the Ignition historian gap-free through load shedding.

Should remote sensors go into SCADA or an IoT platform?

Use SCADA when the data belongs with real-time control and operations on a site; use an IoT platform when you need cross-site visibility, long-term analytics, remote/off-grid monitoring and business-system integration. They're not mutually exclusive — many operators feed LoRaWAN data into SCADA for the control room and into an IoT platform like addaNet for plant-wide and multi-site analytics and compliance reporting. See our SCADA-vs-IoT-platform guide for the full comparison.

Want LoRaWAN data in your SCADA?

Tell us which SCADA you run and what you need to bring in. We'll design the integration — network server, decoders, tag mapping and a secure, buffered link into Ignition, AVEVA/Wonderware or Siemens — and run it end to end.

Book a Discovery Call See the platform →

Related reading

8 min read

SCADA vs IoT platform

Control vs visibility — and which you need.
8 min read

OPC-UA vs Modbus vs MQTT

The three protocols on every IIoT project.
8 min read

IIoT security

Get the data out without exposing PLCs.

Primary sources