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.

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).