MQTT (Message Queuing Telemetry Transport) là giao thức truyền tin nhắn theo mô hình publish/subscribe, được thiết kế tối ưu cho thiết bị IoT và mạng không ổn định. Trong bài này, bạn sẽ hiểu vì sao MQTT thường phù hợp hơn HTTP khi cần theo dõi từ xa: nhẹ, realtime tự nhiên, dễ mở rộng nhiều thiết bị, và có các tính năng “đúng bài” như QoS (độ tin cậy), Retained (giữ giá trị mới nhất) và Last Will (tự báo offline khi thiết bị rớt mạng).
1) Vấn đề của người làm dự án IoT: “Thiết bị chạy được, nhưng không theo dõi từ xa”
Nếu bạn là maker/beginner, rất có thể bạn đã từng làm được:
- ESP32 đọc nhiệt độ/độ ẩm và hiển thị trên OLED
- Cảm biến cửa/motion bật đèn/còi tại chỗ
- Relay điều khiển máy bơm/ổ cắm
Nhưng khi bạn muốn xem từ xa (đang ở công ty vẫn biết nhà kính nóng hay không), bạn sẽ gặp 2 rào cản lớn:
- Không biết tự làm hệ thống cloud: server, database, dashboard, bảo mật… khá nhiều thứ.
- Thiết bị IoT mạng chập chờn: Wi‑Fi yếu, 4G lúc có lúc không; gửi dữ liệu kiểu “web app” thường không ổn định.
Đây là lý do MQTT trở thành lựa chọn cực phổ biến trong IoT.
2) MQTT là gì?
MQTT (Message Queuing Telemetry Transport) là giao thức truyền tin nhắn theo mô hình Publish/Subscribe (Pub/Sub).
- Publish (Pub): Thiết bị gửi (publish) dữ liệu lên một kênh gọi là topic.
- Subscribe (Sub): Ứng dụng (dashboard, điện thoại, server) đăng ký (subscribe) topic để nhận dữ liệu.
Điểm quan trọng: Thiết bị và ứng dụng không cần biết nhau là ai, chỉ cần thống nhất topic.
Ví dụ topic rất “IoT”
- iotlabs/<orgId>/devices/<deviceId>/telemetry
- iotlabs/<orgId>/devices/<deviceId>/status
- iotlabs/<orgId>/devices/<deviceId>/event
Thiết bị chỉ cần publish lên các topic này, còn dashboard/server sẽ subscribe để hiển thị.
3) MQTT khác HTTP thế nào?
HTTP: kiểu “thiết bị gọi API”
Thiết bị muốn gửi dữ liệu phải:
- Kết nối → gọi POST https://your-api/telemetry
- Đính kèm token, header…
- Server xử lý, lưu DB
HTTP rất tốt cho web/app, nhưng với IoT thì thường gặp:
- Overhead lớn (header nhiều, handshake, request/response)
- Kém phù hợp mạng chập chờn (thiết bị phải tự retry, quản lý lỗi)
- Khó realtime Pub/Sub (muốn realtime thường phải thêm WebSocket)
MQTT: kiểu “đẩy tin + ai cần thì nghe”
MQTT được thiết kế cho:
- Thiết bị tài nguyên thấp (CPU/RAM yếu)
- Mạng không ổn định
- Gửi dữ liệu nhỏ, liên tục hoặc theo sự kiện
- Mô hình 1 thiết bị → nhiều nơi nhận (dashboard + alert service + lưu DB)
Tóm lại: HTTP giống “gửi đơn hàng đến 1 quầy”, MQTT giống “phát sóng trên kênh — ai cần thì bắt”.
4) 4 khái niệm MQTT bạn cần nắm để theo dõi IoT từ xa
4.1) Pub/Sub: Nâng cấp dự án hiện tại trong 5 phút
Bạn đã có một dự án đọc nhiệt độ trên ESP32.
Trước đây: nhiệt độ chỉ hiện trên OLED.
Sau khi gắn MQTT + IoTLabs Cloud:
- ESP32 publish nhiệt độ lên topic telemetry
- Dashboard subscribe và vẽ biểu đồ
- Bạn xem từ xa bằng điện thoại/laptop
Payload ví dụ (telemetry)
{
"ts": 1768324653317,
"metrics": {
"temperature": 28.6,
"humidity": 66.2
}
}ts là timestamp (ms). metrics chứa các số đo bạn muốn hiển thị.
4.2) QoS: Độ tin cậy khi gửi dữ liệu
QoS (Quality of Service) quyết định tin nhắn có cần “đảm bảo” hay không.
- QoS 0 — At most once: gửi là xong, có thể mất (nhanh nhất)
- QoS 1 — At least once: đảm bảo đến nơi ít nhất 1 lần (có thể bị gửi trùng)
- QoS 2 — Exactly once: đảm bảo đúng 1 lần (nặng nhất)
Vậy nên dùng QoS nào?
- Telemetry liên tục (nhiệt độ mỗi 5s): QoS 0 hoặc QoS 1
- Sự kiện quan trọng (cảnh báo khói/gas): QoS 1
- Gửi dữ liệu/sự kiện rất quan trọng: QoS 2
Mẹo: Với IoT monitoring, QoS 1 là “điểm cân bằng” cho cảnh báo/event.
4.3) Retained message: Vừa mở dashboard đã thấy “giá trị mới nhất”
Nếu bạn từng gặp cảnh:
- Mở dashboard nhưng chưa thấy số liệu vì thiết bị chưa gửi lại -> Thì retained là giải pháp.
Retained message là tin nhắn mà broker “giữ lại” như giá trị mới nhất của topic.
- Khi ai đó subscribe vào topic, broker sẽ gửi ngay retained message.
Dùng retained khi nào?
- Trạng thái thiết bị: status = online/offline
- Giá trị cấu hình hiện tại
- Số đo “gần nhất” (nếu bạn muốn mở dashboard là thấy ngay)
4.4) Last Will and Testament (LWT): Tự động báo offline khi thiết bị rớt mạng
IoT hay gặp:
- Mất điện
- Wi‑Fi rớt
- Thiết bị treo
Bạn muốn dashboard biết ngay thiết bị offline mà không cần “người dùng đoán”.
Last Will (LWT) cho phép thiết bị khai báo trước:
“Nếu tôi rớt kết nối bất thường, hãy publish một tin nhắn thay tôi.”
Ví dụ:
- Will topic: …/status
- Will payload: {“status”:”offline”}
Khi thiết bị disconnect bất ngờ, broker tự publish message offline.
Kết quả: Dashboard theo dõi online/offline cực chuẩn.
5) Vì sao IoT dùng MQTT nhiều hơn HTTP?
Tóm gọn theo đúng nhu cầu maker/beginner:
- Nhẹ và nhanh: phù hợp ESP32/MCU và dữ liệu nhỏ.
- Chịu mạng chập chờn tốt: hỗ trợ session, retry, QoS.
- Realtime tự nhiên: Pub/Sub, nhiều bên nhận cùng lúc.
- Theo dõi trạng thái tốt: LWT giúp biết online/offline.
- Trải nghiệm dashboard tốt: retained giúp mở là thấy dữ liệu mới nhất.
6) Ví dụ “nâng cấp dự án hiện tại”
Kịch bản: Dự án cảm biến nhiệt độ tại nhà
- Bạn có ESP32 + DHT22/DS18B20
- Hiện tại chỉ xem tại chỗ
Nâng cấp với MQTT + IoTLabs Cloud:
- Tạo device trên IoTLabs Cloud
- Copy thông tin kết nối MQTT (host/user/pass/topic)
- ESP32 publish telemetry mỗi 10–30 giây
- Dashboard hiển thị biểu đồ nhiệt độ theo thời gian
- Cài rule cảnh báo nếu nhiệt độ vượt ngưỡng (bài use-case sẽ đi sâu)
Kết quả: Bạn có hệ thống theo dõi từ xa mà không cần tự viết cloud.
7) FAQ – Câu hỏi thường gặp
MQTT có cần gửi dữ liệu liên tục không?
Không. Bạn có thể gửi:
- Theo chu kỳ (mỗi 10–60 giây)
- Theo ngưỡng (chỉ gửi khi thay đổi đáng kể)
- Theo sự kiện (cửa mở, phát hiện khói…)
MQTT có thay thế HTTP hoàn toàn không?
Không. HTTP vẫn rất hữu ích cho:
- Trang quản trị
- API cấu hình
- Tải file/firmware
Nhưng để stream telemetry + realtime status, MQTT thường “đúng bài” hơn.
8) Kết luận
MQTT giúp bạn biến các dự án IoT “chạy local” thành hệ thống theo dõi từ xa nhanh chóng nhờ:
- Pub/Sub đơn giản
- QoS tăng độ tin cậy
- Retained giúp thấy dữ liệu mới nhất ngay
- Last Will giúp biết thiết bị offline tự động