MQTT

MQTT Data Connector

The MQTT Data Connector enables Edge connectivity to equipment and systems that communicate using the MQTT protocol. Designed to run at the Edge, this connector supports both publishing and subscribing to MQTT topics, bridging your OT (Operational Technology) devices to your unified IIoT data model - regardless of local protocol differences.

The MQTT Data Connector empowers Tricloud Nexus to integrate with a Unified Namespace (UNS) architecture based on MQTT - regardless of whether the UNS operates locally on-site or at the enterprise level in the cloud. This approach enables consistent, real-time data exchange across your entire organization, breaking down silos and supporting a scalable, future-proof IIoT infrastructure.

What is a Unified Namespace? A Unified Namespace is a central, structured, and real-time information model that brings together all operational and business data in one place - often implemented using MQTT for flexible, scalable connectivity. Learn more about Unified Namespace concepts.

Key Features

  • Edge-Based Operation: The MQTT connector runs locally on your Edge device, ensuring secure, real-time connectivity to equipment - even if your site loses internet connectivity.

  • Flexible Topic Management: Subscribe to (read) or publish (write) data on one or more MQTT topics.

  • Payload Handling: Supports JSON-formatted messages for rich, structured data exchange.

  • Security: Optional support for TLS and client authentication for secure data transfer.

  • Automatic Data Normalization: Converts incoming MQTT data to the Tricloud Nexus measurement format for unified storage and analytics.

  • Offline Buffering: Collect and buffer data locally during connectivity loss; forward all data once the connection is restored.

  • Protocol Version Support: Configure the connector for MQTT v3.1, v3.1.1, or v5.0.

Configuring an MQTT Data Connector

1. Add a New Connector

  1. Select an Area node in your asset hierarchy.

  2. Go to the Data Connectors tab.

  3. Click + New data connector and choose Mqtt Broker and provide a name for the connector.

Add a new Data Connector

2. Configure Connection Settings

Configuration of MQTT Connector

Fill out the connection details:

  • Name: Friendly name for this connector (e.g., LocalUNS).

  • Broker Address: IP or hostname of your MQTT broker (e.g., 123.10.10.142).

  • Broker Port: Port number for the broker (usually 1883 for non-TLS, 8883 for TLS).

  • Protocol Version: Select the MQTT protocol version (v5.0 recommended for new deployments).

3. Authentication & Security

  • Username / Password: (Optional) Enter if your broker requires authentication.

  • TLS Enabled: Toggle on to enable secure (encrypted) communication.

  • TLS Protocol: Choose supported TLS version (e.g., TLS 1.2).

  • Validate Certificate: Toggle on for strict server certificate validation. You must upload a certificate file in CER or CRT format, that can be used for validation.

4. Advanced: Send Connect Message

Enable Send Connect Message to send custom parameters when establishing the MQTT connection. The connect message is the first MQTT packet/message sent by the client after the network connection between the client and the broker is established. You can specify the following values:

  • clientId The clientId (for example, 'client-1') identifies each MQTT client connecting to an MQTT broker. If the clientId value is blank, an MQTT broker will still generate a unique parameter for this client to identify it.

  • cleanSession This parameter specifies whether a client wants to establish a persistent session with a broker or not. It can have the following values:

    • 'True' means a client doesn’t want to establish a persistent session (a broker will not save unsent messages if the connection is interrupted). In addition, all previous persistent sessions will get dismissed.

    • 'False' means a client wants to establish a persistent session

  • sessionExpiryInterval Defines how long a session can be retained on the server after a network disconnection. If the specified time elapses without reconnection, the server discards the session state. The values it can take are:

    • If unspecified or set to 0, the session ends immediately upon network disconnection.

    • If set to a value greater than 0, it specifies the number of seconds the session will be retained after disconnection.

    • If set to 0xFFFFFFFF, the session will never expire.

  • keepAlive The MQTT keepAlive parameter identifies the maximum interval in seconds (eg. 120) that the broker should keep the connection alive, when a client maintains the MQTT connection but does not transmit any data.

  • lastWillMessage The lastWillMessage parameter is a message (this can be a string, e.g., 'hello' or even a JSON formatted message) a broker sends when the MQTT connection abruptly terminates without closing the connection properly.

  • lastWillTopic The lastWillTopic parameter states the topic (or several of them) to which the lastWillMessage should be published. In other words, all subscribers of this particular topic will get the lastWillMessage once the client goes offline.

  • lastWillQos The lastWillQoS parameter provides information about the Quality of Service (QoS) level to use when publishing the lastWillMessage. It can have the following values:

    • '0' simply forwards the message once (there is no guarantee that the message was received by the receiver)

    • '1' ensures the delivery of the message at least once (the message can be sent more than once)

    • '2' provides the delivery of the message exactly once (the message can be sent once only)

  • lastWillRetain The lastWillRetain parameter specifies whether the lastWillMessage should be retained or not. If the value is 'false' an MQTT broker publishes the lastWillMessage as a non-retained one. If the value is 'true' the lastWillMessage is published as a retained one.

All message properties are case-sensitive

Tip: These parameters help you control session behavior, error handling, and device lifecycle notifications.

5. Topics

Topics define what data you read or write via MQTT:

Add/Edit Mqtt Topic Dialog

  • Click + Add to create a topic.

  • Name: Logical name for this topic (e.g., State).

  • Payload Format: Select Json (recommended).

  • Topic Filter: Specify the MQTT topic to subscribe or publish to (e.g., acme/dallas/inctmold/p103/stamp01/status). Note: Wildcards like + and # are currently not supported.

  • Pub/Sub: Choose Subscribe (Read) to collect data, or Publish (Write) to send data. Publishing data means that you will send Measurements from a Tag into the topic, and therefore no example payload can be added, because the format is allready predetermined by the Measurement format.

  • Quality of Service (QoS): Select the QoS level for the topic (e.g., 0 - at most once).

  • For Subscribe (Read) topics, you can preview an example JSON payload for reference.

  • For Publish (Write) topics, toggle Retain latest published message on broker as needed.

  • Example Payload You can optionally paste an example of a payload expected on the MQTT topic into the text area. Doing so will simplify the process of designing your Tags that utilize this Topic later on. JsonAta can be used to filter and process the payload when configuring Tags that uses MQTT Topics, and can even convert datetime values to UTC format. Below is an example of a MQTT payload in Json format:

{
  "name": "Stamper01",
  "state": "idle",
  "time": "2024-03-26T11:23:12",
  "errorCode": 50,
  "errorMessage": "servomotor position 2 disconnected"
}

Best Practices

  • Use descriptive connector and topic names for clarity.

  • Leverage JSON payloads for rich data and easier parsing.

  • Secure your connection using TLS and strong credentials whenever possible.

  • Always test topic subscriptions/publishing with representative payloads before deploying it into a production environment.

PreviousData ConnectorsNextOPC-UA

Last updated

Was this helpful?