MQTT Brokers
MQTT is the preferred protocol standard for communication between components of an IoT solution. It is an asynchronous messaging protocol that uses servers known as brokers. It follows a publish-subscribe (pub-sub) model and uses what are known as topics as the channel for communication.
An MQTT Broker is the easiest way to exchange data between physical microcrontroller circuits and the IoT app. The message broker is an intermediary program between the sender and the receiver that ensures that messages from a sender are routed to the correct receiver with guaranteed delivery. In addition to its core function of message routing, the message broker may also perform additional tasks, such as message validation (based on rules probably defined in the message broker) and message transformation (if the message format needs to be changed from what is sent by the sending program to what can be processed by the receiving program).
To use MQTT directly, boards must have WiFi capability and be connected to a WiFi network. Alternately the boards need to connect to a platform such as Node-RED which in turn will connect to a WiFi network. Sensors connected to the board will publish their data to a topic on an MQTT broker and the app will subscribe to the topic. Whenever the sensor captures any data it is displayed on the app through this pub-sub approach. In the other direction, the app will publish a control signal to a topic on an MQTT broker and the microcontroller that has subscribed to the topic will receive the signal and change the device state as required.
You can install an MQTT broker locally, but to keep things simple, we will be using a free and public MQTT broker on the cloud. There are multiple options, we will use the one from HiveMQ.
Note that public MQTT brokers do not guarantee persistence or security of data. Do not ever post any confidential data on such brokers. Many of these brokers offer an alternative to set up a private and secure broker, generally at a cost but with some free trial options. Private and secure MQTT brokers that work with a user id and password for authentication are easier to set up and are supported by the mobile app. Brokers that require certificates for authentication are currently not supported by the mobile app.
MQTT Brokers use two main protocols:
- MQTT over TCP (for native apps) and
- MQTT over Websocket (for browser and mobile apps).
When configuring MQTT servers in Node-RED use the TCP protocol (and corresponding port) since the connection is being made through Node.js code which is considered a native app.
Both protocols further support secure (TLS) and unsecure communication. Brokers listen on specific ports for each protocol. While there are some standard ports, brokers may use any port of their choice (which they will specify in their documentation). Private brokers also require authentication credentials, either a user id and password, or certificates.
You can use any of the following following public MQTT brokers to test the app:
| Broker FQDN | Port | Protocol | User Id/Password |
|---|---|---|---|
| test.mosquitto.org | 8080 | Websocket Unsecure | Not required |
| broker.hivemq.com | 8000 | Websocket Unsecure | Not required |
| broker.hivemq.com | 8884 | Websocket TLS | Not required |
| broker.emqx.io | 8084 | Websocket TLS | Not required |
The URLs provided are valid and secure to the best of our knowledge but you must reconfirm their validity and security yourself before you use them.
Sample screenshots for the HiveMQ Broker are shown below:
Websocket
WebSocket is a computer communications protocol that makes it possible to open an interactive communication session between a web browser or a mobile app (a client) and a server. With this protocol, a server can alert the client regarding any change to data without the client needing to make a request. In a traditional request/response protocol, the client has to send a request to the server to get some data. If there is any change in the data on the server, the client will not be aware of the change until it sends the next request. In use cases where data changes infrequently or the user does not need to be updated data changes in real-time, the request-response approach works fine.
With this approach, if all users are required to know of any changes on the server data at the same time, then the client has to run in a loop sending a request as frequently as the user needs to be updated (known as polling). Websocket is a good alternative solution for this. It allows the client to establish a connection with a server and then keep that connection open. Once the connection is established, every time there is a change in the server data, it sends the data to the client. If there is no data, the client can stay idle. This approach is well-suited for IoT applications that need to work in real-time (as soon as a sensor reads some data, the user needs to be made aware immediately).