The Value of MQTT in the Built Environment

MQTT can be utilized to quickly and securely transmit your building data.  It is natively available in most BMS but at the same time many building operators are unfamiliar with it.  This often times creates an obstacle with IT as they need to understand it before approving it’s use.  So, what is MQTT, what are the benefits, and why should it be the protocol of choice for transmitting building data?

What is MQTT and how can it be applied in Smart Buildings?

MQTT stands for Message Queuing Telemetry Transport.

Telemetry refers to the recording and transmission of data from remote sources to a centralized receiving station for monitoring and analysis. In the smart building space, your BMS is constantly receiving telemetry data from sources such as lighting, fire suppression, and mechanical HVAC.

The key design principle of MQTT is it is intended to be lightweight, referring to the size of the data transmitted. MQTT was created in 1999 by engineers from IBM and Arcom.

It’s lightweight design was intended to allow for efficient messaging in constrained environments such as in SCADA systems where bandwidth and processing resources are limited.  As IoT began to take shape, MQTT became the ideal solution for tiny sensors with limited battery capacity, low processing power, and often low connectivity with variable latency and bandwidth.

MQTT data transmission consists of a client publishing data to a broker. It uses a publish/subscribe communication model, which decouples the producers of data (publishers) from the consumers of data (subscribers). This allows for more scalable and flexible communication.

Central to the MQTT protocol is the broker, which acts as an intermediary between publishers and subscribers. Publishers send their messages to the broker, which then forwards the messages to all subscribers who have expressed interest in, and have access to, that particular topic.

In MQTT, messages are published to topics. Topics are hierarchical strings (e.g., "sensors/temperature/livingroom") that allow subscribers to receive only the messages they are interested in and allowed to access. Subscribers express their interest by subscribing to specific topics.

MQTT vs BacNet

While MQTT has become the dominant protocol for Industrial use cases it is not the primary protocol within buildings.  This title goes to BacNet. 

BacNet is a standard widely accepted in the building automation industry for transmitting data from your equipment to your BMS. It is best suited for comprehensive building automation systems, offering robust interoperability and rich functionality specific to building management needs.

BacNet is the clear favorite for connecting your equipment and transmitting data to your BMS and inversely allowing your BMS to control your equipment.  It offers capabilities in this area that MQTT simply cannot.  As a result, BacNet is widely known and utilized across the industry while MQTT sits in the shadows.

However, now that your systems are connected and controlled, you want to leverage that data for things such as advanced analytics to optimize those controls, reduce energy consumption, and improve indoor air quality. 

With a fair amount of work, some of this can be done within the BMS but in most cases you need to transmit this data to third party systems.

Now, BacNet no longer makes sense as you are not connecting the devices to a third party system but instead a BMS to a third party. So, you need an alternative solution.

MQTT vs REST APIs

IT is often tasked with securely transmitting company data. The protocols IT is most used to seeing are SFTP, HTTPS, and even secure email. When it comes to telemetry data, the one that makes most sense of this group is HTTPS and specifically REST APIs or RESTful APIs.

REST APIs use web URLs to make digital resources available between systems and is the most common API used on the web today. If you were to tell your IT group that your are looking to transmit your building data via REST APIs they would instantly understand, and likely be comfortable with, what you are looking to do. 

So, why not just use REST APIs?

The answer to this question is speed and bandwidth. Both protocols utilize TLS for secure connectivity but MQTT does so without taking up precious network resources.

MQTT is generally considered faster than REST API for several reasons, primarily due to its design and communication model. Here are the key factors that contribute to MQTT's speed advantage:

	MQTT	REST API
Communication Model	Uses a publish/subscribe model, which allows for asynchronous communication. Once a message is published to a topic, the broker immediately forwards it to all subscribed clients, minimizing latency	Uses a request/response model, which is synchronous. The client must send a request and wait for a response from the server, introducing latency, especially if the server is busy or the network is slow
Message Overhead	Has a minimal fixed header size of just 2 bytes, which makes it very efficient in terms of bandwidth usage. The protocol is designed to transmit small messages quickly	Uses HTTP, which includes significant overhead due to headers, methods, and status codes. Each HTTP request and response carries additional metadata, which increases the size of the transmitted data and processing time
Persistent Connections	Maintains a persistent connection between clients and the broker using TCP. This means that once a connection is established, messages can be sent and received with minimal delay since the connection setup time is eliminated for each message	Typically uses stateless HTTP, meaning each request/response pair requires a new TCP connection unless HTTP/1.1 keep-alive or HTTP/2 is used. Establishing a new connection for each interaction adds latency
Efficient Data Transmission	Optimized for transmitting small packets of data, making it ideal for IoT applications where messages are often brief. Its protocol design focuses on minimizing the time it takes to transmit a message	Designed for a wide range of web services, often transmitting larger and more complex payloads (e.g., JSON or XML). This can introduce parsing and processing delays on both the client and server sides
Quality of Service (QoS) Levels	Provides three levels of QoS (0, 1, 2), allowing the application to balance between speed and delivery assurance. This flexibility can optimize communication speed based on the application's requirements	Does not have built-in QoS levels. Ensuring reliable delivery typically requires custom implementations, which can add complexity and delay
Protocol Design	Specifically designed for low-bandwidth, high-latency, and unreliable networks. Its lightweight nature and efficient data handling make it faster in such environments	Designed for general web use, emphasizing ease of use and broad compatibility over raw speed. The complexity and versatility of HTTP can introduce delays that are not present in MQTT

Use Case Examples

• IoT Applications: In IoT environments, where devices need to send frequent, small messages with minimal delay, MQTT excels due to its low overhead and fast message delivery.

• Web Services: For traditional web applications that require compatibility with web browsers and standard HTTP clients, REST API is preferred despite its relative inefficiency compared to MQTT.

MQTT Data Security

When dealing with data, processing and transmission speed are extremely important, but even speed takes the back seat to security.  If you can not securely transport your data, the speed at which you transport it is a moot point.

MQTT has several security capabilities to ensure secure communication between clients and brokers including the same level of encryption as HTTPS, SFTP, and secure email. Below are security features of the MQTT protocol.

Transport Layer Security (TLS)	Encryption: MQTT supports TLS/SSL to encrypt data transmitted between clients and brokers, ensuring confidentiality and protection against eavesdropping and man-in-the-middle attacks. Authentication: TLS also enables the use of certificates to authenticate both the client and the broker, ensuring that both parties are who they claim to be.
Username and Password Authentication	Client Authentication: MQTT allows clients to authenticate with the broker using a username and password. The broker can then validate these credentials to allow or deny access. Basic Access Control: This method provides a basic level of access control to ensure that only authorized clients can connect to the broker.
Access Control Lists (ACLs)	Granular Permissions: Brokers can implement ACLs to control which clients can publish to or subscribe to specific topics. This ensures that clients only have access to the topics they are permitted to interact with. Role-Based Access: ACLs can be used to define roles with specific permissions, simplifying the management of large numbers of clients and their access rights.
Token-Based Authentication	OAuth: Some MQTT implementations support OAuth for token-based authentication, providing a more secure and scalable way to handle authentication, especially in large deployments. JWT (JSON Web Tokens): Another method is to use JWTs for authentication, which can include encoded information about the client and its permissions, allowing for stateless and scalable access control.
Audit Logs	Logging: Some MQTT brokers provide logging capabilities to track client connections, disconnections, and message flows. This can be useful for auditing and detecting suspicious activities. Monitoring: Continuous monitoring of MQTT traffic can help detect anomalies and potential security breaches.
Message Integrity	QoS Levels: While not a direct security feature, MQTT's Quality of Service (QoS) levels help ensure message delivery reliability. Combined with other security measures, they help maintain the integrity of message delivery.

Conclusion

MQTT offers a secure and fast means of transmitting building data to third parties. While natively available in many BMS it is often overshadowed by technologies more widely known such as BacNet and REST APIs. 

However, all of them serve a specific purpose.  Leveraging MQTT as the standard protocol of connecting a BMS to third party systems can allow owner/operators to easily leverage the data that they are already tracking and to help make buildings more intelligent and sustainable.

---

To learn more about how leveraging MQTT to transmit data can unlock advanced functionality with AI contact us at info@elipsa.ai