I am developing a device which measures temperature, humidity and mass. Currently it uses HTTPS to upload data to a remote server. Now I know that there is a protocol called MQTT which is claimed to be the "protocol of Internet of Things".

In what case and why should I switch from HTTPS to MQTT?

  • We should close this old opinion-based question. Enough opinions have been added. This can be googled with many possible answers. Commented Jul 5, 2020 at 14:46
  • I agree. Initially this one only survived because it was asked during private beta. Commented Jul 5, 2020 at 19:48

6 Answers 6


MQTT is a "messenger" between devices:

  • your device measures at time T a temperature of X degrees
  • it connects (itself or via the zwave hub) to the MQTT broker
  • it create a message with the topic /domotics/myplace/mydevice/temperature
  • within the message it just puts X (as the "payload")

Elsewhere in your house:

  • your Raspberry Pi is connected to the MQTT broker (it can be the MQTT instance itself)
  • it subscribes to the topic /domotics/+/+/temperature to receive ALL temperature information from all the devices that use this topic format. See the MQTT spec for more information on MQTT topic wildcards (+ and #).
  • it will receive a message with the payload X and do whatever it wants !

Elsewhere in your house:

  • your computer is connected to the MQTT broker and subscribes to the topic /domotics/myplace/mydevice/# to get ALL the information from your device and log it
  • it will receive a message with the payload X and do whatever it wants !

MQTT is very useful to avoid putting web services and sockets all around your servers. Node-RED uses MQTT and Domoticz can be configured to get in and set out signals.

I personally use MQTT at my home to switch off computers: /house/computers/mycomputer payload: 0

  • Good point that I do not have to bother with sockets and other web services. Commented Dec 6, 2016 at 18:54
  • Can you comment on the security aspects? Is traffic plaintext?
    – Mawg
    Commented Dec 7, 2016 at 11:34
  • 2
    Another answer says MQTT supports TLS ; iot.stackexchange.com/a/69/39
    – Goufalite
    Commented Dec 7, 2016 at 12:06

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

  • 1
    Do MQTT offers as much security as HTTPS? Commented Dec 6, 2016 at 18:55
  • 2
    It could use SSL/TLS so it should be as secure as HTTPS.
    – Ghanima
    Commented Dec 6, 2016 at 18:59
  • 1
    Exactly as @Ghanima said, I updated the answer with reference article to check which talks about securing MQTT.
    – bravokeyl
    Commented Dec 6, 2016 at 19:00

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


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.


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.


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.

  • 1
    I tend to agree with last comment. Using UDP is simpler than MQTT or MQTT-SN. Commented Oct 20, 2020 at 3:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.