Giao Thức MQTT: Kết Nối Thiết Bị IoT Thực Tế

MQTT là giao thức publish/subscribe trên TCP/IP, dùng broker làm trung gian giữa publisher (thiết bị) và subscriber (server/app). Thay vì thiết bị gửi trực tiếp đến server, thiết bị publish lên topic; server subscribe vào topic để nhận.

Thiết bị IoT (Publisher)
        │
        │  publish("sensors/temp", 25.3)
        ▼
    MQTT Broker
        │
        │  subscribe("sensors/temp")
        ▼
   Server / App (Subscriber)

Đặc điểm chính:

• Nhẹ: header nhỏ (2 byte minimum), phù hợp MCU tài nguyên giới hạn.
• Publish/Subscribe: thiết bị và server không cần biết địa chỉ nhau — chỉ cần cùng topic.
• Broker: trung gian quản lý kết nối, routing message, QoS.
• Persistent session: broker giữ subscription và queue message khi thiết bị offline (tùy QoS).
• Keep-alive: cơ chế phát hiện kết nối bị drop.

MQTT không phải HTTP. Không có request/response; thiết bị publish và server subscribe — không đồng bộ.

—

MQTT không phải lúc nào cũng tốt hơn HTTP. Với số thiết bị ít, tần suất gửi thấp hoặc không cần subscribe → HTTP/REST đơn giản hơn. Với nhiều thiết bị, gửi dữ liệu đều đặn và cần push từ server → MQTT phù hợp hơn.

—

┌───────────────────────────────────┐
│     THIẾT BỊ IoT (MQTT Client)    │
│  MCU + Firmware + MQTT Client lib │
└──────────────┬────────────────────┘
               │  MQTT over TCP/TLS
               ▼
┌───────────────────────────────────┐
│          MQTT BROKER              │
│  Mosquitto / EMQX / HiveMQ / AWS  │
│  IoT Core / Azure IoT Hub         │
└──────────────┬────────────────────┘
               │  Subscribe / publish
        ┌──────┴──────┐
        ▼             ▼
┌──────────┐   ┌──────────────────┐
│ Backend  │   │ Other Subscriber │
│ Server   │   │ (App, Dashboard) │
└──────────┘   └──────────────────┘

—

Topic là địa chỉ routing message trong MQTT. Topic có dạng chuỗi phân cấp bằng dấu /.

Ví dụ topic hierarchy

devices/{device_id}/sensors/{sensor_type}
devices/{device_id}/status
devices/{device_id}/commands
factory/{factory_id}/line/{line_id}/machine/{machine_id}/data

Wildcard

• + : single-level wildcard — devices/+/status nhận tất cả device status.
• # : multi-level wildcard — devices/# nhận tất cả topic dưới devices/.

Nguyên tắc thiết kế topic

• Không để thiết bị subscribe wildcard # — tốn tài nguyên và bảo mật kém.
• Tách topic data và topic command — tránh nhầm lẫn chiều giao tiếp.
• Nhất quán trong toàn hệ thống — định nghĩa topic convention từ đầu.
• Không nhúng sensitive data vào topic — topic thường không mã hóa.

—

QoS quyết định mức độ đảm bảo message được giao. Chọn sai QoS dẫn đến mất message hoặc broker quá tải.

Không phải mọi message đều cần QoS 2. QoS cao hơn = overhead lớn hơn. Chọn QoS phù hợp với từng loại dữ liệu.

—

Retain Message

Broker lưu message cuối cùng của topic. Subscriber mới kết nối ngay lập tức nhận được giá trị mới nhất mà không cần chờ thiết bị publish lần tiếp theo.

Phù hợp với: trạng thái thiết bị, cấu hình, giá trị baseline.

Last Will Testament (LWT)

Khi thiết bị kết nối đến broker, nó đăng ký một “chúc thư” — message được broker tự động publish nếu thiết bị mất kết nối đột ngột (không gửi DISCONNECT đúng cách).

Thiết bị kết nối:
  → đăng ký LWT: topic="devices/001/status", payload="offline"

Thiết bị mất kết nối đột ngột:
  → Broker tự publish: devices/001/status = "offline"

LWT giúp server biết thiết bị offline dù thiết bị không thể gửi thông báo — hữu ích cho monitoring và cảnh báo.

—

Các MQTT client library phổ biến cho thiết bị nhúng:

Flow firmware MQTT cơ bản

01. Khởi tạo network (Wi-Fi / Ethernet / LTE)
        ↓
02. Kết nối broker (TCP/TLS)
        ↓
03. Đăng ký LWT
        ↓
04. Subscribe topic command (nếu cần)
        ↓
05. Loop:
    - Đọc sensor
    - Publish data
    - Poll incoming message (commands)
    - Keep-alive (PINGREQ)
    - Xử lý reconnect nếu mất kết nối

Xử lý reconnect: không bỏ qua

Thiết bị IoT thực tế mất kết nối do Wi-Fi yếu, mạng không ổn định, broker restart. Firmware cần:

• Phát hiện mất kết nối (keep-alive timeout, error callback).
• Retry với exponential backoff — tránh storm reconnect khi nhiều thiết bị cùng mất kết nối.
• Restore subscription sau khi reconnect (nếu không dùng persistent session).
• Buffer hoặc log data locally khi offline (tùy QoS).

—

Transport security (TLS)

MQTT plaintext (port 1883) không mã hóa. Dữ liệu và credentials truyền dưới dạng text rõ. Dùng MQTT over TLS (port 8883) cho production.

Authentication

• Username/password: đơn giản nhưng cần TLS để tránh lộ credentials.
• Client certificate (mTLS): mỗi thiết bị có certificate riêng — bảo mật cao hơn, phức tạp hơn.
• Token: JWT hoặc token-based auth — phổ biến với cloud IoT (AWS IoT Core, Azure IoT Hub).

Authorization

Broker cần kiểm soát ai được publish/subscribe vào topic nào. Thiết bị không nên có quyền subscribe topic của thiết bị khác.

Certificate management

Với nhiều thiết bị, quản lý certificate là bài toán: provisioning (cấp certificate khi sản xuất), rotation (cập nhật certificate khi hết hạn), revocation (thu hồi certificate khi thiết bị bị xâm phạm).

—

Tự host broker phù hợp khi có yêu cầu on-premise, data không ra ngoài, hoặc đã có infrastructure. Cloud managed phù hợp khi muốn giảm ops burden và cần scale.

—

Cảm biến / Thiết bị
        │  Modbus RTU
        ▼
IoT Gateway / Edge Device
        │  MQTT over TLS
        ▼
MQTT Broker (cloud / on-premise)
        │
        ├── Backend Server (subscribe + xử lý)
        │
        └── Dashboard / SCADA (subscribe + hiển thị)

MQTT thường là giao thức giữa gateway và cloud — không nhất thiết giữa sensor và gateway (sensor thường dùng Modbus, analog, RS485).

Xem thêm: Gateway Modbus RS485 · lập trình firmware theo yêu cầu.

—

DeviceLab tích hợp MQTT trong phát triển firmware cho thiết bị IoT — từ thiết kế topic hierarchy, firmware MQTT client, xử lý reconnect và offline đến bảo mật TLS và tích hợp với backend.

Phạm vi thường gặp:

• Firmware MQTT client trên MCU/SoC (ESP32, STM32, custom SoC)
• TLS/mTLS với certificate management
• Topic design và message schema
• Xử lý offline, buffer, reconnect
• Tích hợp với MQTT broker (cloud hoặc self-hosted)
• Bridge MQTT ↔ SCADA/REST/database

Xem thêm: phát triển firmware · các dự án DeviceLab.

Chuẩn bị trước khi gửi yêu cầu

1. MCU/SoC và kết nối của thiết bị là gì?
2. Broker đã chọn chưa (AWS IoT Core, Mosquitto, EMQX…)?
3. Dữ liệu gửi lên tần suất bao nhiêu — mỗi giây, phút hay sự kiện?
4. Yêu cầu bảo mật: TLS, mTLS hay token?
5. Server/backend nhận dữ liệu từ MQTT sẽ làm gì với data?

—

MQTT là gì?

MQTT là giao thức publish/subscribe nhẹ trên TCP/IP, dùng cho IoT. Thiết bị publish dữ liệu lên topic qua broker; server/app subscribe vào topic để nhận. Phù hợp với thiết bị tài nguyên giới hạn và kết nối không ổn định.

MQTT khác HTTP ở điểm gì?

MQTT dùng mô hình publish/subscribe async, có broker, persistent connection và overhead nhỏ. HTTP dùng request/response sync, không cần broker, overhead lớn hơn. MQTT phù hợp IoT nhiều thiết bị; HTTP phù hợp API web thông thường.

MQTT QoS 0, 1, 2 khác nhau thế nào?

QoS 0: gửi một lần, không đảm bảo. QoS 1: giao ít nhất một lần (có thể trùng). QoS 2: đúng một lần. QoS cao hơn = đảm bảo hơn nhưng overhead lớn hơn. Chọn QoS phù hợp với từng loại dữ liệu.

MQTT có an toàn không?

MQTT plaintext không an toàn. MQTT over TLS (port 8883) mã hóa kết nối. Kết hợp với authentication (certificate hoặc token) và authorization (ACL) tạo bảo mật đủ cho production.

LWT (Last Will Testament) trong MQTT là gì?

LWT là message broker tự publish khi thiết bị mất kết nối đột ngột — thường dùng để cập nhật trạng thái “offline” mà không cần thiết bị tự gửi. Hữu ích cho monitoring trạng thái thiết bị.

Retain message trong MQTT là gì?

Retain message là message broker giữ lại. Subscriber mới kết nối vào topic ngay lập tức nhận được giá trị cuối cùng, không cần chờ publisher gửi lại. Phù hợp với trạng thái, cấu hình, giá trị hiện tại.

MQTT Broker nên dùng loại nào?

Phụ thuộc yêu cầu: Mosquitto đơn giản, nhẹ, phù hợp small scale. EMQX cho scale lớn, nhiều tính năng. AWS IoT Core / Azure IoT Hub cho cloud managed, tích hợp cloud services. Không có broker “tốt nhất cho mọi trường hợp”.

Firmware cần làm gì khi mất kết nối MQTT?

Phát hiện mất kết nối (error callback hoặc keep-alive timeout), retry với exponential backoff, buffer hoặc log data locally khi offline, restore subscription sau khi reconnect thành công.

MQTT dùng thế nào trong thiết bị IoT công nghiệp?

Thường làm giao thức giữa IoT Gateway và cloud/backend — không phải giữa sensor và gateway (sensor thường dùng Modbus, RS485, analog). Gateway thu thập dữ liệu từ thiết bị hiện trường, chuyển đổi và publish lên MQTT broker.

Chi phí phát triển MQTT firmware phụ thuộc gì?

MCU/SoC, library chọn, yêu cầu bảo mật (TLS/mTLS/certificate management), xử lý offline/buffer, tích hợp với broker và backend, và số lượng topic/message type cần hỗ trợ.

—

MQTT là giao thức IoT tốt khi được triển khai đúng cách. Publish dữ liệu lên topic chỉ là bước đầu — firmware sản phẩm cần xử lý reconnect, offline, QoS đúng, bảo mật TLS và tích hợp mượt với backend.

Thiết kế topic hierarchy và message schema từ đầu quan trọng hơn chọn broker — vì thay đổi topic sau khi đã triển khai nhiều thiết bị rất tốn kém.

Bắt đầu từ: xác định dữ liệu cần gửi, tần suất, QoS và broker trước khi viết firmware client.

—

Gửi mô tả MCU/SoC, kết nối mạng của thiết bị, broker định dùng, yêu cầu bảo mật và cách backend sẽ xử lý dữ liệu. DeviceLab sẽ giúp thiết kế kiến trúc MQTT phù hợp và triển khai trong firmware.

Gửi yêu cầu →