When and why to use MQTT protocol?

why and when to use MQTT:

1. When you have a server capable to run MQTT Broker/server (obviously). You can install on raspberry pi or compile Erlang MQTT broker on any other SBC with ARM linux.
2. When you are going to make use of the topic wildchars. Explained in Goufalite answer.
3. When you are going to make use of the persistent feature. For example publish with persistent on /device/board_1/should_be_active in day 1 and nothing published to that topic ever again. When a new device subscribed to that topic on day 2 or any other day, he will receive the data that was published on day 1. Even when the broker restarted, that persistent data on that topic will not be lost and will be informed again to the subscribers.

When you don't want to use MQTT

1. You don't really need those above features

2. You don't need encryption. For example in a car, not all data is encrypted, especially their data send through CAN.

3. You don't want to spend resource on making an MQTT broker. if you can use microcontroller only why should you.

   You can use other server like CoAP (explained by Pepe Bellin). NodeMCU firmware support CoAP server, means you don't need expensive linux powered server.

   You can use raw socket UDP or TCP-IP and encrypt the data yourself. This way you don't need to use HTTPS.

Years ago i always use MQTT when working on communication between devices. But nowadays in order to be more efficient on resources I always prefer raw socket, even when communicating with Android devices.

Regarding to your quote MQTT is the "protocol of Internet of Things":

Yes, there is a great amount of developers using this protocol (see IoT Developer Survey 2018) but CoAP (it's HTTP adjusted for IoT, based on UDP) provides an alternative for HTTP in case you want to use a lightweight Request/Response functionality within your application.

MQTT on the other hand provides a built-in Publish/Subscribe logic, which makes it great for scaling (you can use more gateways for a greater amount of devices). There is also an UDP alternative (like CoAP to HTTP) that is called MQTT-SN (MQTT for Sensor Networks). This provides even a smaller overhead than CoAP, but doesn't make use of R/R.

Here I wrote an article which shows and evolution in communications system we had in our project. It about micro-services, but you can consider any sensor to be micro-service with its job to gather and publish any kind of telemetry data.

So most important conclusion is that it is better to use MQTT when you just need to send event somewhere and you know nothing about recipient. And it's much better to use HTTP (usually REST) when you know something about recipient and need some response - e.g. in case of commands of whatever.

From traffic, CPU, memory and energy consumption perspectives MQTT and HTTP are basically the same.

MQ Telemetry Transport Protocol known as MQTT is designed for devices which run on low power and low bandwidth. It is a lightweight publish/subscribe messaging protocol which means any other device can subscribe to a particular topic.

HTTP/HTTPS is designed as a request-response protocol for client-server computing which never bother about power usage and has lot of data overhead.

Use MQTT if:

• The device you are using is running on battery cell and you don't want to replace that every x number days (MQTT is optimized for battery usage while HTTP/S is not)
• Need faster response
• Need to have pub/sub mechanism ( If you want to push messages to many clients)
• Need to send data reliably with different levels of QoS

Do MQTT offer as much security as HTTPS?

MQTT relies on TCP as transport protocol, which means by default the connection does not use an encrypted communication. To encrypt the whole MQTT communication, most many MQTT brokers – like HiveMQ – allow to use TLS instead of plain TCP.

Ref: HiveMQ

MQTT (Message Queue Telemetry Transport) seems to be well suited for the proposed application.

It is lightweight both with respect to bandwidth (smallest packet size with a header of just 2 bytes) and client code footprint (enabling it to run on thin clients like the ESP8266, typical IoT client). Reduced transmitted data is beneficial to longer battery life for off-grid battery powered clients like sensors.

MQTT also offers simple methods (verbs) that suit IoT tasks well, like durable subscriptions that recover connections after unexpected client disconnections. Compared to HTTP/HTTPS it is also simpler to extract data from the package (no parser needed).