MQTT Forwarding Setup for Dragino LoRaWAN Gateways

2 days ago

8 min read

A Dragino LoRa or LoRaWAN gateway can do more than receive wireless sensor packets. With MQTT forwarding enabled, it can publish uplink data from the LoRa network to an MQTT broker, and it can also subscribe to MQTT topics for downlink traffic back toward devices.

That makes MQTT a useful bridge between field sensors and the software that consumes their data. A temperature node, water meter, door sensor, or custom LoRa device can send data to the gateway. The gateway then forwards that payload to an MQTT server where applications, dashboards, databases, and automation tools can read it.

This guide walks through the basic setup flow, using a simple local MQTT server and an MQTT client tool to confirm that the broker works before connecting the Dragino gateway.

Eye-level view of a compact LoRaWAN gateway with an antenna connected on a workbench — A simple bench setup is enough for testing MQTT forwarding before moving to the field.

Supported Dragino devices

This MQTT forwarding instruction applies to the following Dragino gateway models:

Device family	Notes
`LG01N`, `OLG01N`	Use this instruction for these models.
`LG02`, `OLG02`	Supported by the same MQTT forwarding flow.
`MS14` series	Supported if installed with the same firmware. MQTT forwarding works, but LoRa support does not apply in that case.
`LG308N`, `DLOS8N`, `LPS8N`	Supported Dragino LoRaWAN gateway models.
`LPS8V2`	Supported by this MQTT forwarding setup.

Do not use this guide for `LG01-P` or `LG01-S`. Those models use a different MQTT instruction set.

The MQTT client utilities used in Dragino firmware are commonly based on:

`mosquitto_pub`
`mosquitto_sub`

These are command-line tools from the Mosquitto MQTT project. If you need advanced options, such as authentication, TLS settings, keepalive values, retained messages, or custom client IDs, refer to the Mosquitto manual page for `mosquitto_pub`:

https://mosquitto.org/man/mosquitto_pub-1.html

How MQTT forwarding works

MQTT uses a broker-based model. Clients do not normally send messages directly to each other. Instead, they publish messages to topics on a broker, and other clients subscribe to those topics.

In a Dragino gateway setup, the parts usually look like this:

Part	Role
LoRa or LoRaWAN sensor	Sends uplink payloads over radio.
Dragino gateway	Receives LoRa data and forwards it to MQTT.
MQTT broker	Receives published messages and distributes them to subscribers.
MQTT client or application	Reads sensor data, sends commands, or stores payloads.

For uplink traffic, the flow is:

A sensor sends a packet over LoRa or LoRaWAN.
The Dragino gateway receives it.
The gateway publishes the payload to an MQTT topic.
An MQTT client subscribes to that topic and receives the data.

For downlink traffic, the flow works in the other direction:

An application publishes a command to an MQTT topic.
The Dragino gateway subscribes to that topic.
The gateway receives the command.
The gateway sends the payload toward the LoRa or LoRaWAN device, based on the configured behavior.

The exact topic names and payload format depend on the gateway model, firmware, and configuration. The key idea stays the same: the gateway acts as the bridge between radio traffic and MQTT messages.

Prepare a simple local MQTT server

For a first test, use a local MQTT broker on a PC. This keeps the setup simple because the broker, test client, and network tools are all in one place.

You can use Mosquitto as the MQTT broker. On a local test machine, the gateway and test client only need to reach the broker over the network.

A simple test layout looks like this:

Component	Example value
MQTT broker address from the same PC	`localhost`
MQTT broker address from another device	The PC’s LAN IP address
Default MQTT port	`1883`
Test subscriber topic	`test/topic`
Test payload	`hello from mqtt`

If the MQTT client runs on the same PC as the broker, use:

```text

localhost

```

If the Dragino gateway connects to the broker from the network, do not use `localhost` in the gateway settings. From the gateway’s point of view, `localhost` means the gateway itself. Use the PC’s local network IP address instead, such as a private LAN address assigned by the router.

Before configuring the gateway, confirm three things:

The PC running the broker is powered on and connected to the same network.
The broker is listening on the expected port, usually `1883`.
A firewall is not blocking inbound MQTT traffic.

Close-up view of an Ethernet cable plugged into a small gateway beside a powered network switch — Network reachability matters before any MQTT setting can work.

Simulate the MQTT connection with MQTT.fx

MQTT.fx is an MQTT client tool that can publish and subscribe to topics. It is useful because it lets you test the broker before adding the Dragino gateway to the setup.

In this basic test, assume the MQTT broker and MQTT.fx are installed on the same PC. In that case, configure the MQTT server address in MQTT.fx as:

```text

localhost

```

Use the default port unless your broker uses a different one:

```text

1883

```

Then connect MQTT.fx to the broker.

Once connected, test both subscribe and publish actions.

Subscribe to a test topic

In MQTT.fx, subscribe to a simple topic such as:

```text

test/topic

```

Keep the subscription page or message view open. This lets you see incoming messages.

Publish a test message

Publish a message to the same topic:

```text

test/topic

```

Use a simple payload:

```text

hello from mqtt

```

If everything is working, MQTT.fx should display the message almost immediately in the subscription view.

This proves that:

The broker is running.
The client can connect.
Topic publish and subscribe behavior works.
The local MQTT test path is ready.

You can run the same kind of test from the command line with Mosquitto tools.

Open one terminal and subscribe:

```bash

mosquitto_sub -h localhost -p 1883 -t test/topic

```

Open a second terminal and publish:

```bash

mosquitto_pub -h localhost -p 1883 -t test/topic -m "hello from mqtt"

```

The first terminal should print:

```text

hello from mqtt

```

If this local test fails, fix the broker or PC setup before configuring the gateway. The Dragino gateway cannot forward data to a broker that is not accepting connections.

Configure the Dragino gateway for MQTT forwarding

After the broker works, move to the Dragino gateway.

The exact web interface labels can vary by firmware and model, but the setup normally follows the same pattern. Log in to the gateway’s web interface and find the MQTT forwarding, MQTT bridge, IoT server, or LoRaWAN packet forwarding settings.

Set the broker connection details first.

Setting	What to enter
MQTT server	The broker IP address or hostname reachable by the gateway
Port	Usually `1883` for plain MQTT
Username	Enter if the broker requires authentication
Password	Enter if the broker requires authentication
Publish topic	Topic used for gateway-to-server uplink data
Subscribe topic	Topic used for server-to-gateway downlink data
Client ID	Use a unique value if the field is available

For a local PC broker, the MQTT server should be the PC’s LAN IP address, not `localhost`.

For example:

```text

192.168.1.50

```

Use the actual IP address of the PC running the broker.

If the firmware exposes command options for the MQTT client utilities, remember that Dragino uses `mosquitto_pub` and `mosquitto_sub`. That means many Mosquitto options can apply, depending on what the firmware allows.

Examples of options people commonly use in MQTT environments include:

```bash

-h

```

Host

```bash

-p

```

Port

```bash

-t

```

Topic

```bash

-m

```

Message payload

```bash

-u

```

Username

```bash

-P

```

Password

```bash

-i

```

Client ID

Do not add extra options unless you need them. A clean basic test is easier to troubleshoot.

Overhead view of a laptop screen showing MQTT topics beside a LoRa gateway and antenna — Start with plain topic tests, then add gateway data after the broker is confirmed.

Test uplink forwarding from LoRa to MQTT

Once the gateway is connected to the broker, test uplink traffic.

A good test sequence is:

Subscribe to the gateway’s MQTT publish topic from MQTT.fx or `mosquitto_sub`.
Power on or trigger a LoRa or LoRaWAN sensor.
Watch for incoming MQTT messages.
Confirm the payload, device identifier, timestamp, signal information, or other fields shown by your firmware.

A command-line subscriber may look like this:

```bash

mosquitto_sub -h 192.168.1.50 -p 1883 -t "dragino/uplink/#"

```

The `#` wildcard subscribes to all subtopics under `dragino/uplink/`. Use the topic structure configured in your gateway.

If the gateway publishes messages, the forwarding path is working:

```text

Sensor → Dragino gateway → MQTT broker → MQTT subscriber

```

If no messages appear, check the basics in this order:

The sensor is sending data.
The gateway can receive the sensor’s LoRa or LoRaWAN packet.
The MQTT broker address is correct.
The publish topic in the gateway matches the subscribed topic.
The broker allows the gateway to connect.
Any username and password are correct.
The PC firewall allows inbound traffic on the MQTT port.

Do not skip the topic check. MQTT topics are case-sensitive, and small differences matter.

For example, these are different topics:

```text

dragino/uplink

```

```text

Dragino/Uplink

```

```text

dragino/uplink/

```

Test downlink forwarding from MQTT to LoRa

After uplink works, test the reverse path if your device and firmware support it.

The downlink path is:

```text

MQTT publisher → MQTT broker → Dragino gateway → LoRa or LoRaWAN device

```

Subscribe settings on the gateway must match the topic used by your application or test client. If the gateway listens on:

```text

dragino/downlink

```

Then publish the command to that same topic:

```bash

mosquitto_pub -h 192.168.1.50 -p 1883 -t "dragino/downlink" -m "your_payload_here"

```

Use the payload format expected by your gateway and device. Some setups expect plain payload data. Others expect JSON or a firmware-specific structure that includes fields such as device address, port, confirmation mode, or encoded payload.

If the downlink does not work, confirm uplink first. Then check:

The gateway is subscribed to the correct topic.
The broker shows the gateway as connected.
The payload format matches the gateway firmware requirements.
The end device is able to receive downlinks.
LoRaWAN timing and receive windows are suitable for the class of device being used.

For battery-powered LoRaWAN devices, downlink timing can be limited. A device may only listen after it sends an uplink, depending on its class and configuration.

Common problems and quick fixes

MQTT forwarding issues often come from network basics rather than the gateway itself.

Symptom	Likely cause	What to check
Gateway cannot connect to broker	Wrong host address	Use the broker PC’s LAN IP, not `localhost`.
MQTT.fx works, but gateway does not	Broker only accepts local connections	Check broker listener and firewall settings.
Subscriber receives nothing	Topic mismatch	Confirm exact spelling, case, slashes, and wildcards.
Authentication fails	Wrong credentials	Test the same username and password with `mosquitto_pub`.
Uplink works, downlink fails	Wrong downlink topic or payload format	Match the gateway subscription topic and expected payload.
Works on LAN, fails remotely	Router, firewall, or public broker issue	Check routing, ports, DNS, and broker access rules.

For the first setup, keep the broker local and unauthenticated only if you are working in a safe lab network. For any shared, remote, or production system, use proper authentication and network controls.

Wide-angle view of a field sensor node placed near a gateway antenna during a LoRa test — A successful setup ends with real sensor data reaching MQTT subscribers.

What a successful setup looks like

A working MQTT forwarding setup should give you a clear data path in both directions.

For uplink, a sensor packet received by the Dragino gateway should appear on the configured MQTT publish topic. You should be able to see it in MQTT.fx or with `mosquitto_sub`.

For downlink, a message published to the configured MQTT subscribe topic should reach the gateway and then be handled according to the LoRa or LoRaWAN settings for the target device.

Start with the simplest possible test: one broker, one client, one topic, and one payload. Once that works, add authentication, custom topics, real sensor data, and downlink commands. This method keeps each problem small and makes MQTT forwarding much easier to verify.