Third-Party MQTT Forwarding

The current platform forwards ThinkLink messages to a third-party MQTT broker through Broker + Forwarder.

There is no per-device third-party forwarding switch, and there is no Server Configuration entry for a third-party platform. Those legacy settings are retired. Configure the Broker records and enable the corresponding Forwarder rule; messages matching its subscription topic are then forwarded automatically.

The typical data flow is:

ThinkLink internal Broker (AS or ThinkLink)
        ↓ Source Broker / Subscription Topic
Forwarder rule (optional JavaScript transformation)
        ↓ Target Broker
Third-party MQTT Broker (Customize)

1. Create Broker Connections

Go to Advanced Features → Broker. A forwarding rule normally uses one source connection and one target connection.

Source Broker

Select one of the internal types as required:

• AS: MQTT messages from the ThinkLink Application Server.
• ThinkLink: messages processed by the ThinkLink platform.

The platform fills the internal broker address and tenant credentials automatically. You do not retrieve or maintain them under Server Configuration.

Third-Party Target Broker

Create a Customize Broker and enter the connection information supplied by the third-party provider:

• Name and Enabled status.
• MQTT URL, such as mqtt://host:1883 or mqtts://host:8883.
• Username and password when required.
• CA and client certificates when TLS or mutual TLS is required.

After saving and enabling it, check the Broker list. A successful connection reports RUNNING. If it reports ERROR, inspect ErrMsg and verify the URL, port, credentials, certificates, and network path.

2. Create and Enable the Forwarder

Go to Advanced Features → Forwarder → Add and configure:

Field	Description
Name	Forwarding rule name
Enabled	The rule subscribes and forwards only when enabled
Source Broker	Broker to subscribe to
Target Broker	Broker to publish to
Subscription Topic	Topic pattern on the source; supports MQTT + and # wildcards
Custom Script	Optional transformation of the topic, payload, or retain option
Notes / commit message	Optional explanation and version-history note

Once the Forwarder is saved and enabled, every message matching Subscription Topic is sent to Target Broker. No device-side change is required.

Source Broker and Target Broker cannot both be internal AS/ThinkLink types, which prevents an unnecessary internal loop. The common third-party forwarding pair is:

Source Broker = AS or ThinkLink
Target Broker = Customize

Subscription Topics and Protocols

Set Subscription Topic according to the Source Broker type:

Source Broker	Data type	Subscription Topic	Protocol reference
ThinkLink	Thing-model parsed telemetry	/v32/{tenant}/tkl/up/telemetry/#	ThinkLink Protocol
AS	LoRaWAN-decrypted raw uplink data	/v32/{tenant}/as/up/data/#	AS Protocol
AS	Complete uplink messages after multi-gateway collection	/v32/{tenant}/as/up/dataAll/#	AS Protocol

Replace {tenant} with your organization account, available in the personal center. Do not keep the placeholder literally. # covers all devices in that organization; replace it with a device DevEUI to forward only that device. For example, organization mtfac uses /v32/mtfac/tkl/up/telemetry/# for telemetry and /v32/mtfac/as/up/data/# for raw AS uplinks.

3. Optional Transformation Script

Without a script, the Forwarder preserves the original topic and message. Use this entry point when the third-party system requires another payload format:

function forwardScript({ topic, msg, org_params }) {
  if (!msg?.telemetry_data) return null

  return {
    topic: `${org_params.target_topic_prefix}/${msg.device_id}`,
    option: {
      retain: false
    },
    msg: {
      temperature: msg.telemetry_data.T,
      humidity: msg.telemetry_data.H
    }
  }
}

Inputs:

Parameter	Type	Description
topic	string	Original MQTT topic received by the Forwarder
msg	Object	Parsed message payload
org_params	Object	Read-only organization parameters maintained under System Management → Server Configuration → Org Params; this is shared script data, not a third-party forwarding switch or Broker configuration

The returned object supports:

Field	Type	Description
topic	string	Topic published to the target Broker
msg	Object	Message payload to publish
option	Object	Optional MQTT publish settings, such as { retain: true }

Return null, or return nothing, to discard the message.

4. Version History and Public Forwarders

Each saved Forwarder script creates a version snapshot. The editor can show details or restore an earlier snapshot. Restoring creates a new version record and does not delete existing history.

System Platform can maintain public Forwarders. They are visible but read-only on the tenant side. A rule assigned to a specific organization can use that organization's Brokers and org_params. Subscription Topic becomes required after a Source Broker is selected.

5. Troubleshooting Order

1. Confirm that both Brokers are enabled and the target Broker reports RUNNING.
2. Check ErrMsg, host, port, credentials, and TLS certificates.
3. Confirm that the Forwarder rule itself is enabled.
4. Confirm that Subscription Topic matches the actual message topic.
5. Temporarily disable the custom script to test transparent forwarding, then inspect the script return value.

6. Startup and Subscription Recovery (2.00.070)

Forwarding brokers in the same organization load in parallel, so a slow connection does not serialize other brokers. Enabling a rule records its subscription demand even while the source is offline; subscriptions are sent after connection recovery. Local registration is not confirmation: only a successful SUBACK confirms a subscription. Failed subscriptions retry every 3 seconds while connected; retries resume after reconnection when offline.

At startup, each rule waits for its own enabled target broker within the existing connection timeout before registering the source subscription. Unrelated rules continue independently. A target timeout still permits source registration. An unavailable target retains the existing skip-forwarding behavior; no message buffer or offline replay guarantee is added.

• A restored persistent session (clean: false and sessionPresent: true) needs only unconfirmed or newly registered topics. A lost session or clean session rebuilds all still-needed subscriptions.
• When scripts share a topic, removing one script leaves the others subscribed. Unsubscription occurs after the last callback is removed.
• Reconnection does not add duplicate message listeners. One received message invokes a given callback once even if it matches multiple filters. Late acknowledgments from an old connection cannot overwrite the new connection state.
• Deleting or replacing a rule while it waits for a connection or acknowledgment prevents old asynchronous tasks from restoring it.

These changes reduce missing subscriptions and duplicate local dispatch. They do not guarantee business-level exactly-once delivery. MQTT redelivery or sender retries can still produce duplicates; use message identifiers for business deduplication.

Check source and target connections, subscription confirmation, and actual message flow. An enabled rule or connected broker alone does not prove successful forwarding.

Device Status Topic (2.00.084)

A ThinkLink source rule can subscribe to /v32/{tenant}/tkl/device/status/{eui}, or /v32/{tenant}/tkl/device/status/+ within the authorized tenant. The forwarder needs no device-side third-party forwarding switch, but producing status events requires device notify_offline="TRUE", disabled by default. These messages have no telemetry_data; the example script above drops them. Forward unchanged or handle the status format explicitly. See Status Notifications for payloads, reconnect queries, and distinct status definitions.