41 lines
1.5 KiB
Markdown
41 lines
1.5 KiB
Markdown
---
|
|
tags:
|
|
- micro-controllers
|
|
---
|
|
|
|
# MQTT
|
|
|
|
_Message Queuing Telemetry Transport_
|
|
|
|
Messaging protocol that runs on top of TCP/IP like HTTP. Particularly well
|
|
suited for IoT devices.
|
|
|
|
Has publisher/subscriber architecture. Devices publish data to a broker which
|
|
manages topics. Other devices subscribe to those topics. Broker would typically
|
|
run on a server as the central messaging hub.
|
|
|
|
MQTT handles connection drops gracefully - if an ESP32 temporarily loses Wi-Fi,
|
|
it can queue messages and send them when reconnected. The protocol uses minimal
|
|
bandwidth (just a few bytes of overhead vs HTTP's much larger headers), which
|
|
means lower power consumption on your ESP32s. MQTT also maintains persistent
|
|
connections rather than creating new ones for each data point, reducing network
|
|
overhead and latency.
|
|
|
|
The main Linux client for setting up an MQTT is `mosquitto`.
|
|
|
|
There are different **Quality of Service** levels you can use to manage how
|
|
messages are sent and what to do in event of failure:
|
|
|
|
- _fire and forget_
|
|
- _acknowledged delivery_
|
|
- _acknowledged only once delivery_
|
|
- _retained message_ (broker remembers last message)
|
|
- _last will and testament_ (automatica notification if device disconnects
|
|
unexpectedly)
|
|
|
|
## Example use case
|
|
|
|
As an example, my usecase would be to have several ESP32 micro-controllers in
|
|
different rooms publish humidity data to a small computer that acts as broker.
|
|
This computer will also subcribe to the topics belonging to each room e.g
|
|
`bathroom_sensor`, `bedroom_sensor` and store this data in a database.
|