MQTT

Overview

MQTT (MQ Telemetry Transport or Message Queue Telemetry Transport) is an ISO standard, publish-subscribe-based messaging protocol.

Publishing means that data is uploaded to a well-defined place (called topic) on a central server (called message-broker). Subscribing means that data is downloaded from a topic of the message broker, once it was published there. MQTT hence is an event-driven communication protocol, notifying a subscriber once a data message has arrived on its topic.

MQTT is becoming the de-facto standard protocol for accessing IoT data from the internet.

Important

One of the Connectware’s tasks is to map all the factory-local machine data (shop-floor data) into the MQTT protocol. This is challenging as shop-floor data is provided using various different industrial protocols (such as Profinet, Modbus BACnet, OPC/UA, etc.). Mapping all this protocols to MQTT and their naming schemes for data- endpoints into clean and standardized MQTT topics is exactly what the device-mapper does and what is configurable in the device-commissioning file. Within the commissioning file the industrial protocols are referred to as source whereas the MQTT protocol is termed target.

The MQTT message-broker always runs as a component of the Connectware itself and is started automatically. Data access to remote users (i.e. “to the internet”) can be granted by locally allowing specific users to read or write on a specific topic (user/grantee-management).

Commissioning File Specifics

As mentioned above, the MQTT protocol typically appears as target protocol within a commissioning file. However, it may also be used as source protocol expressing a re-mapping of topic names.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# ----------------------------------------------------------------------------#
# Example Commissioning File (not valid because of <placeholders>)
# ----------------------------------------------------------------------------#
source:
  driver: <any industrial protocol>
  connection:
    <connection information regarding the industrial protocol>
  defaults:
    operation: subscribe
# ----------------------------------------------------------------------------#
# Target Interface Definition - MQTT (Cybus Connectware Broker)
# ----------------------------------------------------------------------------#
target:
  driver: mqtt
  defaults:
    operation: write
    topicPrefix: io/cybus/hbm
# ----------------------------------------------------------------------------#
# Mappings: Here the industry protocol data endpoint names are mapped into
#           MQTT topic names.
# ----------------------------------------------------------------------------#
mappings:
- source:
    <endpoint address following the source protocol conventions>
  target:
    topic: temperature1
- source:
    <another endpoint address following the source protocol conventions>
  target:
    topic: temperature2

Available keys under target

In the example commissioning file you can find the target section starting in line 13. Keys allowed here are:

driver
Required, must be mqtt in case of MQTT
protocol
Optional, either mqtt, mqtts, ws or wss (default: mqtt)
host
Optional, defaults to internal message broker
port
Optional, defaults to 1883
defaults
Optional, allows to specify defaults for the target key in the mapping section. All possible keys are optional and can be any of those allowed within the mapping section (see Available keys under each target within mappings)

Available keys under each target within mappings

In the example commissioning file you can find the mapping section starting in line 22. Lines 25 and 29 are examples of the target sub-section within the mapping section. Keys allowed here are:

operation
Either write or subscribe
topicPrefix
Any valid topic name, that will be used as a prefix for the topic specified under key topic
topic
Any valid topic name addressing a single data-point
qos
Quality of service for mqtt messages, either 0, 1 or 2 (default: 0)
retain
Wether the last message should be retained (last-value-cached) on the broker (default: false)
burstInterval

Interval in ms during which incoming data-point values are aggregated. The broker sends at most one message per interval-time containing all data-point values aggregated within this time span. (default: 0 = no aggregation)

Note

Protocols providing data in form of JSON (like BACnet, S7, Hbmdaq, OPC-UA) the aggregated data will simply be an array of those objects. For protocols providing data in raw buffer form (Modbus) the buffer will be base64 encoded, timestamped, packed to JSON and accumulated as array.