Connector MQTT API Reference

This guide shows how to enable MQTT communication support for a Connectivity Connector. The example code provided shows how a simulated device connects and activates with the Connectivity MQTT endpoint.

Important

Connectivity Platform supports MQTT v3.1.1 and v5 communication.
Please ensure that your hardware and library are fully compatible with these protocols.
Additionally, your hardware and library must comply with the Connectivity TLS Specifications. Make sure to review the documentation thoroughly before proceeding.

Overview

Connectivity MQTT offering supports bi-directional device communication. Devices can provision with a Connector, publish data to its resources, and receive updates about changes made to its resources.

Connectivity MQTT communication support translates MQTT communication into native Connectivity commands, allowing MQTT clients to connect and communicate with the Connector. While the translation layer provides most features of MQTT there are some special considerations to make for Connectivity integration.

Message and Limitations

There is no specific bandwidth or message size limitation, however each individual resource size MUST respect the maximum size of 1048576 bytes.

Connector supports standard MQTT messaging, with a few specific exceptions outlined below. All other MQTT messages and features not listed are considered fully compliant with the MQTT specification.

Note

The Platform Connector's implementation of message constraints is largely consistent between MQTT v3.1.1 and v5. Any differences specific to MQTT v5 are detailed in the sections below.
Features not explicitly mentioned for MQTT v5 can be assumed to behave the same as in MQTT v3.1.1.

MQTT v3.1.1 - CONNECT

CONNECT message "Will Flag", "Will QoS" and "Will Retain" bits in the Variable Header:

Not supported and Ignored. The primary purpose of communication from devices to Connector is the live reporting of (typically) sensory data. A last Will type of pre-stored message does not make much sense for such applications.
CONNECT message "Clean Session" or "Clean Start" flag in the Variable Header:

Ignored, acting as if set to 0. By definition, Connector will sync any resource value that had been updated while the device was offline, back to the device when it connects. This behavior essentially mimics that of when Clean Session is set to 0. Also, since subscriptions are also hardcoded by definition, the device will not have to resubscribe when it reconnects which is also inline with "Clean Session 0" behavior.
CONNECT message "Will Properties", "Will Topic", "Will Message" in the Payload:

Ignored. These fields are ignored by the server, as "Will" functionality is not supported in server implementation.

MQTT v5 - CONNECT

CONNECT message "Properties" in the Variable Header:

Ignored. The Properties field is a feature introduced in MQTT v5. In platform MQTT broker implementation, the server ignores the Properties field when a client sends a CONNECT packet formatted for MQTT v5. This design ensures seamless compatibility: clients can send CONNECT packets using either MQTT v3.1.1 or v5, without encountering any functional differences.

MQTT v3.1.1 - CONNACK

CONNACK message "Session Present" flag in the Variable Header:

Acting as if set to 0. This flag is always set to 0, as the server does not maintain a full session state. Instead, it retains a partial session state, including: Client subscriptions, and Device resource states, so that devices do not need to resubscribe upon reconnection.

MQTT v5 - CONNACK

CONNACK message "Properties" in the Variable Header:
In the event of a successful connection, the following properties are returned along with a ReasonCode of 0:
- AssignedClientIdentifier: This is the ClientIdentifier specified in the CONNECT packet. If it is not supplied, the deviceId is returned instead.
- MaximumQoS: Always set to 1.
- RetainAvailable: Always set to 1.
- WildcardSubscriptionAvailable: Always set to 1.
- SubscriptionIdentifierAvailable: Always set to 0.
- SharedSubscriptionAvailable: Always set to 0.
In the event of connection failures, the following property are returned with a non-zero ReasonCode:
- A string-based reason is returned by the server.

MQTT v3.1.1 - PUBLISH

PUBLISH message "Retain" flag

Ignored, acting as if set to 0. Device initiated PUBLISH messages are processed by Connector real time by applying the published value to the correspond device resource state. This will initiate an internal message to application Lua scripts running at the time for processing. Should new application scripts be launched later, the message will not be sent to them regardless of whether the device specified 0 or 1 for the "Retain" flag, essentially acting as if the device had set it to 0.
PUBLISH message "QoS" flags

Fully supports QoS-0 and QoS-1 but ignores QoS-2. If it is set to indicate QoS-2, Connector will act as if QoS-0 was specified.
PUBLISH message "DUP" flag

Ignored. Since it only has meaning for QoS-2 which Connector currently does not support, this flag is ignored by Connector. However, Connector will disconnect a device if it misuses the flag by setting it to 1 while specifying QoS-0.

MQTT v5 - PUBLISH

PUBLISH message "Properties" in the Variable Header:

The Properties field in the Variable Header of the PUBLISH packet is a feature introduced in MQTT v5. In connectivity platform MQTT broker implementation, the server ignores this field when a client sends a PUBLISH packet formatted for MQTT v5. This behavior ensures seamless compatibility, allowing clients to send PUBLISH packets using either MQTT v3.1.1 or v5, without experiencing any operational differences.

MQTT v3.1.1 - PUBACK

PUBACK, PUBREC, PUBREL and PUBCOMP messages

Not supported. These messages are not supported because QoS-1 or QoS-2 are not supported. QoS-1 is supported device-to-Connector but not from Connector-to-device, hence PUBACK is supported Connector-to-device. If a device sends a one of these messages to Connector, it will disconnect the device immediately.

MQTT v5 - PUBACK

PUBACK message "Properties" and "Reason Code" in the Variable Header:

In connectivity platform MQTT broker implementation, when a client publishes a message with QoS 1, the server responds with a PUBACK message that includes:
- A Reason Code indicating the outcome of the publish operation
- A Reason String provided as a User Property, offering additional context about the result
This mechanism allows clients to receive detailed feedback on the status of their PUBLISH requests.

SUBSCRIBE message

Limited support. By definition, Connector will sync resource state changes back to devices. This does not require explicit subscription from the device. Connector will send the device a PUBLISH message with QoS-0 whenever there is a state change to one of its resources.

If a device sends a SUBSCRIBE message with a topic filter that it is entitled to, Connector will ack it by returning a SUBACK message with QoS-0, even if the device specifies a higher QoS level. The following are valid topics to subscribe to: "#", "$content", "$provision/{device id}", "$resource/#", "$resource/+" and "$resource/{alias}".

If a device sends a SUBSCRIBE message with a topic filter that does not exist or the device is not entitled to receive messages for, Connector will return a SUBACK with the return code 'failure'.

The implementation is identical to MQTT v3.1.1.

MQTT v3.1.1 - UNSUBSCRIBE

UNSUBSCRIBE message

Ignored. By definition, Connector will sync resource state changes back to devices using PUBLISH messages. Devices may not opt out of receiving these messages by unsubscribing. Hence, the UNSUBSCRIBE message is accepted, responded to by UNSUBACK but functionally ignored by Connector. That is, after an unsubscription message exchange, the device will continue to receive state updates from Connector.

MQTT v5 - UNSUBSCRIBE

The implementation is identical to MQTT v3.1.1.

Topics Support and Isolation

The Connector MQTT implementation is not a full MQTT broker. Instead, it provides a protocol-level implementation with support for topic-based messaging and auto-subscribe functionality. Device connectivity and data exchange with Connector are handled using standard MQTT messaging, restricted to a predefined set of topics:

$content
$provision
$provision/{device id}
$resource
$resource/{alias}
$resource.batch

Devices are strictly limited to publishing only to these topics. Publishing to any other topic will result in immediate disconnection.

Note

The following descriptions of PUBACK behavior apply specifically to MQTT v5. In MQTT v3.1.1, a PUBACK message is returned only when the published message is successfully processed, without any additional metadata.

`$content`

The $content topic is shared among devices that belong to the same Connector. If multiple devices under the same Connector publish to $content, they will receive the same list of available contents to download. However, if devices from different Connectors publish to $content, each will receive a Connector-specific list, even though the topic name is identical.

When a client sends a QoS 1 PUBLISH message to $content to request metadata for all available contents, the server responds with a PUBACK message. This response includes the content metadata in the User Property field, using the key "content" and the value containing the metadata details.

`$provision`

Anonymous clients are limited to publishing only to the $provision topic and subscribing to its corresponding activation reply topic, $provision/{device id}, which is unique to each activation request.

When connecting a device to a Connector for the first time, it must anonymously subscribe to $provision to receive its MQTT password via the subscription reply. This password represents the activation of the client and enables subsequent authenticated connections.

When an anonymous client sends a QoS 1 PUBLISH message to the topic $provision/{device_id} to provision a device associated with a solution configured for token authentication, the server generates a token and responds with a PUBACK message. This response includes a User Property containing two keys:

"identity" – representing the device_id from the topic
"token" – the token generated by the server

`$resource`

The $resource topic is used to report data for multiple resources to the Connectivity Platform. Before publishing data, users must create the corresponding resources on the Connector resource page. To publish data for a specific resource, use the topic $resource/{alias}.

When a client sends a QoS 1 PUBLISH message to the $resource topic to transmit data for multiple resources, the payload must be structured as a JSON object containing multiple key-value pairs. If one or more pairs contain errors, the server responds with a PUBACK message that includes the first detected error, while valid key-value pairs are processed successfully and remain unaffected.

`$resource.batch`

The $resource topic is used to report historical data for multiple resources to the Connectivity Platform.

When a client sends a QoS 1 PUBLISH message to the $resource.batch topic to submit historical data for multiple resources, the payload must be formatted as a list of JSON objects. Each object includes:

"timestamp" – indicating the time of the data point
"values" – a JSON object containing resource aliases as keys and their corresponding data point values

If any key-value pair contains an error, the server responds with a PUBACK message that reports the first detected error, while valid entries are retained and processed successfully.

MQTT APIs

Provision authentication credentials for a device

To provision a device identity to Connector, you have to send a PUBLISH message with the topic:

$provision/<device_id>

Device ID must conform to the identity format specification defined in the Settings tab of the Product UI.

Note: 1. This is only for token and password authentication types. 2. Only password authentication needs to provide the credentials (at least 20 characters) as the request payload. For token authentication, leave the payload empty since the token will be generated by Connector.

Response message with the secret token (When a Product is configured for token authentication):

eY4f3tyrE4Jqe3HsLGnPYf7cACKZlb0uvKVatFxX

Received Data

To retrieve all meta information (name, length, mime, url) for all contents, you have to send a PUBLISH message with the topic:

$content

Leave the request payload empty.

Response message with a list of JSON objects, each one containing the name, length, mime and url keys. For example::

[
  {
    "name": "logo.gif",
    "length": 16214,
    "mime": "image/gif",
    "url": "https://s3.something.something.logo.gif"
  }
]

The values for name, length, mime and url keys are:

name: The name of this content. Example: "name": "logo.gif"
length: The content length for this content in bytes. Example: "length": 16214
mime: The mime type for this content. Example: "mime": "image/gif"
url: The download url for this content. Example: "url": "https://s3.something.something.logo.gif"

Report data

to multiple resources

To report data, you have to send a PUBLISH message with the topic:

$resource/

The request payload should be a JSON object, containing the resource alias as key and value of the data point. For example:

{"state": "on", "temperature": 25}

Connector will assign a timestamp in microseconds.

to specific resource

To report data to a specific resource, you have to send a PUBLISH message with the topic:

$resource/<alias>

The request payload must follow the format specification defined in the Resources Settings. Connector will assign a timestamp in microseconds.

to historical timestamps

To report historical data to multiple resources, you have to send a PUBLISH message with the topic:

$resource.batch

The request payload must be a list of JSON objects, each one containing the timestamp and values keys. For example:

[{"timestamp": 1531111131679000, "values": {"state": "on", "temperature": 25}}, {"timestamp": 1531111131689665, "values": {"temperature": 30}}]

Accepted values for timestamp and values keys are:

timestamp: Timestamp in microseconds. Example: "timestamp": 1531111131679000
values: A JSON object containing the resource alias as key and value of the data point. Example: {"state": "on", "temperature": 25}

Note

The timestamp must fall within a valid range: from up to 10 years in the past to no more than 1 day in the future relative to the current date.
This constraint ensures data integrity and supports effective data maintenance. For optimal performance, publishing real-time data is recommended, as it enables the most efficient and accurate data delivery.

Getting Started

MQTT client libraries are readily available. Connector requires that the library supports TLS and requires that the TLS support is modern enough that it includes Server Name Indication (SNI). Please contact the Connectivity development team if a preferred MQTT client library fails either criteria.

This tutorial will use Python and Eclipse Paho™ MQTT Python Client to connect to Connector.

Hardware Setup

A development computer or laptop.

Software Setup

To complete this guide, download and install the following on the development machine:

Python 3.5 from the Python website.
Install the Eclipse Paho™ MQTT Python Client via the following command:

$ pip install paho-mqtt

You must have a Connectivity Platform account and have created a Connector within it. For more information on how to create an account and a Connector in the account, visit the Get Started article for more information.

Setup A Sandbox

This guide will require files to be created on the development machine. Throughout this guide it will be assumed that all commands and files will be run from the following directory:

$ mkdir ~/mqtt-client
$ cd ~/mqtt-client

Configuration

Create a Resource

Initiate a 'temp' global resource of the 'string' type via the web UI. For a swift start, feel free to maintain default settings for the remaining options.

Activate Your Device

The default Connector settings are such that devices are allowed to register their own identities. In some provisioning models it is required or advantageous to have a list of pre-authorized device identities registered with Connector. This is also known as whitelisting. At this point, make sure that the default setting is applied and saved. Navigate to the SETTINGS tab in your Connector web UI and verify that "Allow devices to register their own identity" is selected.

Save the following code into a file called ~/mqtt-client/activate.py:

from paho.mqtt import client as mqtt
import ssl
import logging

# logging.basicConfig(level=logging.DEBUG)

pid = input("Connector ID? ")
did = input("Device ID? ")
host = pid + ".m2.diagnostic.westpharma.com"
open("IoT_Connector_id.txt", "w").write(pid)

def on_connect(client, userdata, flags, rc):
    provision_str = "$provision/" + did
    client.publish(provision_str, None, qos=0)

def on_message(client, userdata, msg):
    print("Activation succeeded!")
    token = msg.payload.decode()
    print("Token: ", token)
    open('token.txt', "w").write(token)
    client.disconnect()

def on_disconnect(client, userdata, rc):
    if rc != 0:
        print("Disconnected with error", rc)
        exit()

client = mqtt.Client(client_id="")
logger = logging.getLogger(__name__)
client.enable_logger(logger)

# see https://github.com/eclipse/paho.mqtt.python/blob/1.1/README.rst#tls_set
client.tls_set()

client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message

client.connect(host, 443)
client.loop_forever()

Now execute the above script by running the following:

$ python3 activate.py

Provide the Connector ID and a device identity of your choice when the activate.py script prompts you for them.

$ python activate.py
Connector ID? o33ara2ekbo800000
Device ID? 12345

Activation succeeded!
Token: b7b34f55e948b94841820ea50868a2490632d78f

A successful result, as shown above, activates the device, prints the credential, and saves it to a file called ~/mqtt-client/token.txt for subsequent sessions. Notice that in the Connector UI the device has been "activated". Save the device ID for later usage (e.g., 12345

NOTE: The client connected anonymously and then provisioned itself using the provided device identity (e.g., 12345) as the MQTT client ID.

Publish Data

Next, use the returned credentials to reconnect and publish data to the new device in the Connector. The data will be published to the temp resource defined a few steps above.

Save the following code into the file ~/mqtt-client/publish.py:

from paho.mqtt import client as mqtt
import ssl
import logging

logging.basicConfig(level=logging.DEBUG)

pid = open("IoT_Connector_id.txt").read()
print("Using Connector ID: ", pid)
host = pid + ".m2.diagnostic.westpharma.com"

def on_connect(client, userdata, flags, rc):
    res = "temp"
    resource = "$resource/" + res
    print("Publishing to Resource: ", res)
    client.publish(resource, input("Value? "), qos=0)
    print("Press \"Ctrl+C\" to exit...")

def on_message(client, userdata, msg):
    print("Value set, previous was: ", msg.payload.decode())

def on_disconnect(client, userdata, rc):
    if rc != 0:
        print("Disconnected with error", rc)
        exit()

client = mqtt.Client(client_id="")
logger = logging.getLogger(__name__)
client.enable_logger(logger)

# see https://github.com/eclipse/paho.mqtt.python/blob/1.1/README.rst#tls_set
client.tls_set()

# read auth token from file
token = open("./token.txt").read()
print("Using Token: ", token)
client.username_pw_set("", token)

client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message

client.connect(host, 443)
client.loop_forever()

Next, execute the script with the following command:

$ python3 publish.py

The script prompts the user for the data to send. The device’s resources are represented as topics "$resource/" (e.g., $resource/temp”).

Below is some example output of the script prompting the user for data and then publishing:

$ python3 publish.py
Using Connector ID: o33ara2ekbo800000
Using Token: XzE3KU2Zhs9ZDl0cSz0Lf8Xp5Ez7rR0cUa1rO4qE
Publishing to Resource: temp
Value? 23
Press "Ctrl+c" to exit...

The device’s temp resource value will reflect the value published by the script.

Inspect the value via the device page on the Connector's web UI.

Receiving data

Copy the following code to a file called ~/mqtt-client/subscribe.py:

from paho.mqtt import client as mqtt
import ssl
import logging

# logging.basicConfig(level=logging.DEBUG)

pid = open("IoT_Connector_id.txt", "r").read()
print("Using Connector ID: ", pid)
host = pid + ".m2.diagnostic.westpharma.com"

def on_message(client, userdata, msg):
    print("Received: ", msg.payload.decode())

def on_connect(client, userdata, flags, rc):
    print("Waiting for messages")

def on_disconnect(client, userdata, rc):
    if rc != 0:
        print("Disconnected with error", rc)
        exit()

client = mqtt.Client(client_id="")
logger = logging.getLogger(__name__)
client.enable_logger(logger)

# see https://github.com/eclipse/paho.mqtt.python/blob/1.1/README.rst#tls_set
client.tls_set()

token = open("token.txt", "r").read()
print("Using Token: ", token)
client.username_pw_set("", token)

client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message

client.connect(host, 443)
client.loop_forever()

Executing the script (command provided below) will subscribe to all changes to the Connector device with the token recieved with the activate.py script. The subscribe.py script will print all messages sent to the device.

$ python3 subscribe.py

Now, adjust the temp resource state using the Connector's web UI

Enable the setting to directly input resource values in the browser by navigating to the resource settings page: Resource Settings -> Enable 'Write data from Connectivity' -> Enable 'Do not synchronize with device'.

After setup, find the pencil icon next to the resource's last value on the device page. Click it, input your desired data, enable 'Write on behalf of the device', and hit the 'SET' button.

After entering the value, above, in a separate terminal, the subscribe.py script should print something like the following:

$ python3 subscribe.py
Using Product ID:  n110e3xbifmfk0000
Using Token:  eY4f3tyrE4Jqe3HsLGnPYf7cACKZlb0uvKVatFxX
Waiting for messages
Received:  32

Client Reconnect

If the client becomes disconnected for any reason, you can modify the following code to enable automatic reconnection to the server:

# the on_disconnect callback
def on_disconnect(client, userdata, rc):
    # if rc != 0:
    #    print("Disconnected with error", rc)
    #    exit()
    client.reconnect()

Authentication Types

FieldAuth Type	Token	Password	Certificate
ClientID	Empty/DeviceID	Empty/DeviceID	Empty
Username	Empty/DeviceID	DeviceID	Empty
Password	Token Credential	Password Credential	Empty

Password Authentication

Update the Provisioning Authentication to Password in the connector settings page.

You can use the previous examples; you need to do minor changes.

Activation

Send the password (at least 20 characters) as the request body when you publish to $provision/DeviceID client.publish("$provision/device001", "12345678901234567890", qos=0)

pid = input("Connector ID? ")
# did = input("Device ID? ")
host = pid + ".m2.diagnostic.westpharma.com"
open("IoT_Connector_id.txt", "w").write(pid)

def on_connect(client, userdata, flags, rc):
    # provision_str = "$provision/" + did
    client.publish("$provision/device001", "12345678901234567890", qos=0)
    client.disconnect()

def on_message(client, userdata, msg):
    print("Activation succeeded!")
    token = msg.payload.decode()
    print("Token: ", token)
    open('token.txt', "w").write(token)
    client.disconnect()

No token will be returned. Use the DeviceID as username and your password as the password for any further communication. client.username_pw_set("device001", "12345678901234567890")
The client ID should be set as empty

Read/publish

Use the DeviceID as username and your password as the password for any further communication.
The client ID does not need to be set

# read auth token from file
# token = open("./token.txt").read()
# print("Using Token: ", token)
client.username_pw_set("device001", "12345678901234567890")

Client Certificate

Update the Provisioning Authentication to TLS Client Certificate in the connector settings page.

Activation

When setting up for TLS Client Certificate authentication, the client cert will be sent to the server during the activate request.
Any further communication needs to use the key/cert you used for the activation
The client ID does not need to be set.
Copy the code below to a file called certificate_activate.py
Create certs/ directory
Put the cert and the corresponding private key to a file called cert.pem and key.pem in the certs directory
Certificate common name will be used as device name by default
ex: self signed for devicea: openssl req -subj '/CN=devicea' -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem -days 1500

from paho.mqtt import client as mqtt
import os
import ssl
import logging

# logging.basicConfig(level=logging.DEBUG)

pid = input("Connector ID? ")
host = pid + ".m2.diagnostic.westpharma.com"
open("IoT_Connector_id.txt", "w").write(pid)

def on_connect(client, userdata, flags, rc):
    print("Activation succeeded!")
    client.disconnect()

def on_disconnect(client, userdata, rc):
    if rc != 0:
        print("Disconnected with error", rc)
        exit()

client = mqtt.Client(client_id="")
logger = logging.getLogger(__name__)
client.enable_logger(logger)

certfile = "./certs/" + "cert.pem"
keyfile  = "./certs/" + "key.pem"
# print("Current dir: " + os.getcwd() + " Certificate: " + certfile + ", Keyfile: " + keyfile)
client.tls_set(
    certfile=certfile,
    keyfile=keyfile,
    cert_reqs=ssl.CERT_REQUIRED
)

client.on_connect = on_connect
client.on_disconnect = on_disconnect

client.connect(host, 443)
client.loop_forever()

Now execute the above script by running the following:

$ python3 certificate_activate.py

Provide the Product ID of your choice when the certificate_activate.py script prompts you for them. The device ID does not need to be set; it will be set to the common name in the certificate automatically

$ python3 certificate_activate.py
Connector ID? x2lmj5npsktbuik9

Activation succeeded!

After the success message nothing need to be done you only need to use the same cert/key for any further communication.

Read/publish

Use the key/cert for any further communication
Copy the following snippet to a file called certificate_publish.py

from paho.mqtt import client as mqtt
import os
import ssl
import logging

# logging.basicConfig(level=logging.DEBUG)

pid = open("IoT_Connector_id.txt").read()
print("Using Connector ID: ", pid)
host = pid + ".m2.diagnostic.westpharma.com"

def on_connect(client, userdata, flags, rc):
    resource = "$resource/" + input("Resource ID? ")
    client.publish(resource, input("Value? "), qos=0)
    client.disconnect()

def on_message(client, userdata, msg):
    print("Value set, previous was: ", msg.payload.decode())

def on_disconnect(client, userdata, rc):
    if rc != 0:
        print("DisConnected with error", rc)
        exit()

client = mqtt.Client(client_id="")
logger = logging.getLogger(__name__)
client.enable_logger(logger)

certfile = "./certs/" + "cert.pem"
keyfile  = "./certs/" + "key.pem"
# print("Current dir: " + os.getcwd() + " Certificate: " + certfile + ", Keyfile: " + keyfile)
client.tls_set(
    certfile=certfile,
    keyfile=keyfile,
    cert_reqs=ssl.CERT_REQUIRED
)

client.on_connect = on_connect
client.on_disconnect = on_disconnect

client.connect(host, 443)
client.loop_forever()

Next, execute the script with the following command:

$ python3 certificate_publish.py

The script prompts the user for the data to send. The device’s resources are represented as topics "$resource/<resourceName>" (e.g., $resource/temp”).

Below is some example output of the script prompting the user for data and then publishing:

$ python3 certificate_publish.py
Using Connector ID: d23kegyeoxb280000
Publishing to Resource: temp
Value? 23
Done. Disconnecting...

The device’s temp resource value will reflect the value published by the script.

Troubleshooting

In the event of a MQTT disconnection, please consult the following table for a better understanding of the likely reasons:

Disconnect Reason	Description
Normal	Indicates a standard disconnection, such as a user-initiated disconnect.
tcp_closed	Denotes a sudden closure of a TCP-based connection.
ssl_closed	Signifies an abrupt termination of an SSL-based connection.
tcp_error	Represents an error within a TCP-based connection.
ssl_error	Indicates an error within an SSL-based connection.
deleted_client	Occurs when the device has been deleted.
locked_client	Happens when the device is locked.
duplicate_connection	Arises when a new connection with the same client_id is established.
{auth_timeout, 5000}	Occurs when authentication status is not obtained within 5 seconds of a connection attempt.
{keep_alive_timeout, <keep_alive_timeout_value>}	Triggers when there's no response after the user-defined keep_alive_timeout (default is 90 seconds).
<other reasons>	If the disconnect reason is not one of the above, it's likely due to an error in the SSL or TCP layer. This generic error may require further research for understanding.

Summary

This guide showed how to configure a Connector to use the MQTT internet protocol to provision and activate a simulated device with a Python script, as well as publishing to device resources and subscribing to changes to device resources.

Connector MQTT API Reference

Overview

Message and Limitations

MQTT v3.1.1 - CONNECT

MQTT v5 - CONNECT

MQTT v3.1.1 - CONNACK

MQTT v5 - CONNACK

MQTT v3.1.1 - PUBLISH

MQTT v5 - PUBLISH

MQTT v3.1.1 - PUBACK

MQTT v5 - PUBACK

MQTT v3.1.1 - SUBSCRIBE

MQTT v5 - SUBSCRIBE

MQTT v3.1.1 - UNSUBSCRIBE

MQTT v5 - UNSUBSCRIBE

Topics Support and Isolation

$content

$provision

$resource

$resource.batch

MQTT APIs

Provision authentication credentials for a device

Received Data

Report data

to multiple resources

to specific resource

to historical timestamps

Getting Started

Hardware Setup

Software Setup

Setup A Sandbox

Configuration

Create a Resource

Activate Your Device

Publish Data

Receiving data

Client Reconnect

Authentication Types

Password Authentication

Activation

Read/publish

Client Certificate

Activation

Read/publish

Troubleshooting

Summary

`$content`

`$provision`

`$resource`

`$resource.batch`