MQTT Bridge

The Message Queuing Telemetry Transport (MQTT) protocol was originally developed by IBM and has today become the de-facto standard for Internet of Things (IoT) communication. There is a large ecosystem of software and infrastructure that supports MQTT, including cloud-hosted IoT infrastructure by from Google Cloud, Microsoft Azure and Amazon AWS.

MQTT follows a Publish-Subscribe pattern; clients (devices) publish information on topics, and other clients can subscribe to these topics in order to receive updates. Likewise, each client can also subscribe to a set of topic that other clients publish (write) to, thus receiving commands from the other clients.

Communication is conducted through a central server, called the broker. There are several options available for MQTT brokers, included hosted servers, but also self-hosted free options like Mosquitto.

BTConnect supports the most frequently used MQTT protocol version 3.1. Each device connection has a built-in MQTT Bridge that publishes all input parameter changes to the MQTT broker, and receives output parameter values through a set of subscribed topics.

The concept of the parameter tree and the naming of its nodes was carefully chosen so that it naturally matches the guidelines for MQTT topics.

Note that using the MQTT Bridge is fully optional. It can be turned on or off individually for each connection. Internal communication between the connections of a single BTConnect instance uses an internal message bus and does not rely on the MQTT Bridge. The best practive is to enable MQTT Bridge only for those connections which you are going to integrate with the “outside IoT world”.

Note: In addition to the built-in MQTT Bridge for each connection type, there is also the “MQTT Client” connection type, which offers another way to connect to a (possibly different) MQTT broker. See the chapter on connection types for more information.

Receiving Parameter Updates

All (input) parameter updates are published to the topic <global prefix>/<connection prefix>/val/<parameter ID>, where the global prefix is an optional string set in the global configuration, and the connection prefix defaults to the connection ID (but can be adjusted in the connection settings where required).

For example, consider our example from above, the Logic 87 from our DHD core of Studio 1, with the following configuration settings:

• Global prefix = btconnect
• Connection prefix = connection ID = dhd-studio1
• Parameter ID = logic/87

Then the changes of the logic will be published to the MQTT topic btconnect/dhd-studio1/val/logic/87.

Sending Parameter Updates

You can also send updates to writable (output) parameters via MQTT by publishing to the respective MQTT topic. The topic name is the same as the one for reading, with val replaced by set. So in the above example, you would publish to btconnect/dhd-studio1/set/logic/87 in order to set the Logic 87 of the DHD core of Studio 1.