MQTT - Everything you need to know in 5 simple sentences
- MQTT transports data between publishers and subscribers via a broker who manages the subscriptions and stores incoming data which is then published to remote subscribers.
- It does not understand the data and it doesn’t care. In theory, you could transport video using MQTT.
- It does not care how the data is used.
- Data is addressed by means of ‘Topics’. A fancy name for addresses of hierarchically structured data. Topics can include wild cards.
- A subscriber cannot interpret published data unless both parties understand the topics being used.
MQTT - Everything you need to know in 5 simple Diagrams
Before the diagrams, let's list some of MQTT Topic Structure and Rules:
- Topics serve as an organizational framework for data, resembling the hierarchy of folders and subfolders on a computer.
- Topic names are structured hierarchically.
- Consider MQTT topic and topic roles with a minimum of one chart (UTF-*).
- Spaces are allowed but should be minimized.
- Topics are case-sensitive.
- Topics never commence with a forward slash (/).
- The use of "$" is reserved for MQTT status information topics.
- Prioritize human-readable formats; avoid non-human-readable structures.
- Incorporate unique identifiers for enhanced clarity.
- Avoid subscribing to "#" as wildcards are not allowed during publishing.
MQTT Subscriber, Broker and Publisher
An MQTT Publisher is a component responsible for sending messages, referred to as "publishing," to the MQTT broker. Puclish means to encapsulate the data in a format that the Broker understands - MQTT. In essence it allocates a Topic, (an addressing system) and sends it to a Broker.
An MQTT Broker functions as a central hub in the MQTT (Message Queuing Telemetry Transport) protocol, facilitating communication between publishers and subscribers. It carries on the following tasks:
- Manages Subscriptions
- Publishes data that has been subscribed to
- Manages the data it receives from Publisher(s) in an addressing system known as a "Topic"
The write functionality allows the BACnet application to send commands to the REST API to change a setpoint or to activate/deactivate a relay. These are mapped to Analog-Outputs and Binary-Outputs. When the BACnet application receives a WriteProperty, it attempts to send the write request to the web server and if successful, sets the value in the memory database.
The response to the write request contains the result of the write operation. If the operation failed, then the json response contains the error message of the reason for the failure that is then translated into a BACnet error.
An MQTT subscriber is a component in the MQTT (Message Queuing Telemetry Transport) protocol responsible for receiving and consuming messages published to specific topics on the MQTT broker. It performs the following functions:
- Subscribes to data by topic (an addressing system)
- Receives data from the Broker who in turn might have received the data from one or more Publishers
See the diagram below for a detailed Overview.
MQTT and the FieldServer Protocol Gateways
MQTT has been added to the FieldServer gateways library moving to the next stage of industrial automation and IoT (Internet of Things). MQTT, known for its lightweight and efficient messaging protocol, among other things, enables communication between devices in a distributed network and Cloud Platforms. When coupled with FieldServer gateways, which act as protocol converters, allowing data from any devices to be retrieved, the integration becomes more significant. FieldServer gateways play an important role in translating data between various industrial protocols, ensuring interoperability. Together, MQTT and FieldServer gateways provide a robust solution for connecting, managing, and exchanging data across heterogeneous systems.
See the below diagrams for a simplified overview of how MQTT Can be used.
