MQTT Client Protocol (Message Queue Telemetry Transport)

Supported device types and versions 
About the MQTT Sparkplug protocol
Communication line configuration
Communication line parameters
Communication station configuration
I/O tag configuration
Literature
Document revisions

The protocol is an implementation of the MQTT 3.1.1 standard (October 2014). MQTT protocol is a client/server protocol of a subscribe/publish type. It is simple, has little overhead, and is easy to implement. It is used for M2M communication (Machine to Machine) and in the IoT context (Internet of Things). The MQTT server is also called the MQTT broker.
D2000 KOM implements the client part of the protocol. The protocol is implemented on a TCP/IP line. MQTTS (Secure MQTT, MQTT over TLS) is also supported - either directly in the D2000 KOM process (using TLS settings on TCP/IP-TCP line) or via the tunnel utility.
For the transfer of LoRaWAN data encapsulated within the MQTT protocol, see LoRaWan protocol description.

The Sparkplug 3.0.0 standard (Sparkplug B MQTT Payload) is also partially supported. Support includes:

• reading simple value types

• reading arrays (with support for the Destination column)

• writing simple value types

• reading of template items (UDT)

• reading of dataset items

• browsing - finding a list of metrics

The communication was tested/deployed with:

• www.TheThings.network cloud 

• Loriot.io cloud 

• Slovanet cloud (loralink.slovanet.sk)

• Pixii PowerShaper (energy storage solution)

• liveobjects.orange-business.com cloud

• test.mosquitto.org (Sparkplug B)

Note: communication with the cloud liveobjects.orange-business.com via WebSockets (wss://liveobjects.orange-business.com:443/mqtt) was also tested. The program https://github.com/jimparis/unwebsockify.git was used as a WSS wrapper. This program started with the following parameters:
./unwebsockify.py --port 1883 --listen 172.16.0.1 wss://liveobjects.orange-business.com:443/mqtt
The D2000 KOM process connected to address 172.16.0.1 on port 1883. The WSS wrapper connected to the defined URL and wrapped the MQTT communication data in a WebSocket envelope.

Each PUBLISH message contains a topic (Topic), data (Payload), and level of confirmation (QoS). PUBLISH messages can be sent both by the client and the server. The clients at the beginning of the communication will use the SUBSCRIBE message to indicate what topics (parameter of Topic Filter protocol) they are interested in. 

• QoS_0 - PUBLISH message is not confirmed, it may be lost

• QoS_1 - PUBLISH message is confirmed by the other side's PUBACK, it may be duplicated

• QoS_2 - PUBLISH message is confirmed by the other side's PUBREC which is then confirmed back by the PUBREL message and that one by a final PUBCOMP message.

The level of confirmation of the messages sent by the D2000 KOM process is defined by the protocol parameter Publish QoS. The D2000 KOM process considers the writing of the output tag to be successfully finished depending on the QoS:

• QoS_0 - after the data is successfully sent via the TCP connection

• QoS_1 - after receiving PUBACK

• QoS_2 - after receiving PUBCOMP

The MQTT communication starts with the CONNECT message sent by the client (D2000 KOM). The message contains User Name, Password, and other parameters, from which only Clean Session Flag and Client ID can be modified (parameter Will Flag is not used, as well as Will QoS and Will Retain, parameter Keep Alive is set to 0). The server replies with a CONNACK message with a return code that contains information about the success of the connect operation.

Then the client sends a SUBSCRIBE message with a filter of topics (Topic Filter parameter), specifying which topics it is interested in, and with the required maximum level of confirmation (parameter Subscribe QoS).

The server responds with a return code that contains information about the success and maximum QoS that was assigned to the requested topics.

Then follows a phase of communication, during which both the client and the server send PUBLISH messages (the client with any topic, the server with topics relating to the filter of topics of the received SUBSCRIBE message) and confirm them according to the value of the QoS parameter of the received PUBLISH messages.

If the server does not send a message for longer than Ping Interval seconds, the client sends the PING request message, to which the server must respond with the PING response message (within the time specified by the Reply Timeout parameter).
If parameters change on the line, the connection is closed and re-created.

Sparkplug's MQTT protocol defines 3 groups of applications:

• Edge Node - supports the MQTT protocol and connects to the MQTT server. It sends him data obtained from the Device or its own or aggregated data

• Device/Sensor - represents a physical or logical device connected to an Edge Node and providing data, process data, or metrics

• Host Application - represents a data consumer (SCADA/MES system, Historian, analysis tool) that connects to the MQTT server and receives MQTT data from the Edge Node/Device and, if necessary, commands. D2000 is a Host Application.

Open

MQTT Sparkplug defines the following message types:

• NBIRTH – Birth certificate for Sparkplug Edge Nodes (information about the connection of the Edge Node to the MQTT Server)

• NDEATH – Death certificate for Sparkplug Edge Nodes (information about the loss of the connection between the MQTT Server and the Edge Node)

• DBIRTH – Birth certificate for Devices (information about Device connection to Edge Node)

• DDEATH – Death certificate for Devices (information about the loss of Edge Node connection with Device)

• NDATA – Edge Node data message (data from Edge Node)

• DDATA – Device data message (data from Device)

• NCMD – Edge Node command message (Host Application command for Edge Node)

• DCMD – Device command message (Host Application command for Device)

• STATE – Sparkplug Host Application state message (information from the state of the Host Application for the Edge Node/Device [online/offline]).