MQTT Downlink Not Reaching LoRaWAN End Device – WisGate Edge Prime V2 / WisGate OS 2.3.1

LPWAN Industrial Gateways / Concentrators RAK7240
1

Issue: MQTT downlink not reaching LoRaWAN end device – WisGate OS 2.3.1

Setup: Gateway: RAK WisGate Edge Prime V2 (RAK7240CV2)
Firmware: WisGate OS 2.3.1
Network Server: Built-in LoRaWAN Network Server
End Device: Heltec WiFi LoRa 32 V3 (ESP32-S3 + SX1262)
Region: IN865 (intended configuration)
Activation: OTAA
Class: Class A
MAC Version: 1.0.3
MQTT Broker: EMQX Cloud
MQTT Client: MQTT Box
MQTT Protocol: MQTT 3.1.1 over TLS 1.2, port 8883

LoRa® Server: Built-in LoRa® Server

Details: Hello,

I am experiencing an issue with MQTT-originated downlinks using the built-in LoRaWAN Network Server on my RAK WisGate Edge Prime V2 running WisGate OS 2.3.1.

My end device successfully joins via OTAA and continuously sends uplinks. The gateway successfully forwards uplink messages to my external EMQX MQTT broker, and I can receive these messages through MQTT Box.

The gateway’s Generic MQTT integration is enabled.

Uplink MQTT topic:
application/lorawan_test_1/device/70b3d57ed00653c8/rx

Downlink MQTT topic used:
application/lorawan_test_1/device/70b3d57ed00653c8/tx

Example downlink JSON published using MQTT Box:

{
“confirmed”: false,
“fPort”: 3,
“data”: “MTEx”
}

The payload is Base64 encoded and corresponds to ASCII “111”.

However, publishing this message does not result in a confirmed downlink reception on the end device.

Important observations:

  1. Manual downlink scheduling through the WisGate OS device Downlink page works correctly.
  2. The Heltec device receives manual downlinks successfully through RX1.
  3. The firmware downlink callback is working correctly.
  4. MQTT uplink forwarding to EMQX works correctly.
  5. MQTT Box successfully connects to EMQX.

Therefore, the radio downlink path and end-device firmware have already been verified.

My question is:

How should MQTT-originated downlinks be correctly configured and submitted to the built-in LoRaWAN Network Server in WisGate OS 2.3.1?

Does Generic MQTT integration automatically subscribe to the external broker’s /tx topic, or is another configuration or subscription mechanism required?

Is the MQTT downlink topic and JSON format used above correct for this firmware version?

I would appreciate assistance identifying why MQTT-originated downlinks are not being scheduled or delivered.

Thank you.

2

The key difference is that a manual downlink from the Downlink page is queued by the gateway’s own LNS, while a published MQTT message must be parsed and queued by the Generic MQTT integration. Two things to check: whether the tx topic actually matches what the integration subscribes to (the device EUI and application name must be exact), and whether the integration is bound to the same application/device in the built-in LoRa Server. Since your uplinks reach EMQX, uplink forwarding works, but that does not confirm downlink subscriptions. Also verify the JSON field names match what WisGate OS expects for the built-in LNS, since a silently rejected payload would never reach the queue.

3

Thanks for Reaching Out…
The issue was resolved as there was conflict with the MQTT downlink topic names which was causing the issue .As of Now the Issue is Resolved .