MQTT คืออะไร: Publish/Subscribe, Broker และ QoS สำหรับงาน IoT

MQTT (Message Queuing Telemetry Transport) เป็นโปรโตคอลส่งข้อความแบบเบาที่นิยมใน IoT เพราะแยกผู้ส่งข้อมูลออกจากผู้รับผ่าน Broker และใช้รูปแบบ Publish/Subscribe แทนการให้ทุกอุปกรณ์เชื่อมต่อหากันโดยตรง

MQTT เหมาะมากกับงานประเภท sensor, telemetry, Home Automation และ monitoring แต่คำว่า “เบา” ไม่ได้แปลว่าออกแบบระบบอย่างไรก็ได้ เรื่อง QoS, session, retained message, authentication และ TLS ยังต้องกำหนดให้ตรงกับความสำคัญของข้อมูล

สำหรับข้อมูลที่เอาไปตัดสินใจ ต้องมี state freshness contract เพิ่มจาก QoS:

Value
+ source timestamp
+ receive timestamp
+ online/offline state
+ retained policy
+ expiry / stale threshold

QoS ช่วยเรื่อง delivery semantics แต่ไม่ได้พิสูจน์ว่าค่าที่ได้รับยังสดหรือสะท้อน physical state ปัจจุบัน ดังนั้น retained message เก่าหรือ client ที่หลุด network ต้องถูกแยกจาก live measurement

แหล่งหลัก:

MQTT ทำงานอย่างไร

องค์ประกอบหลักมี 3 ส่วน:

Publisher — client ที่ส่งข้อความ
Broker — รับข้อความและ route ตาม Topic
Subscriber — client ที่สมัครรับ Topic ที่สนใจ

ตัวอย่างระบบวัดพลังงาน:

Energy Meter
   │ publish
   ▼
site/main-meter/power_kw
   │
 MQTT Broker
   │
   ├── Dashboard
   ├── Home Assistant
   └── Alert service

Meter ไม่จำเป็นต้องรู้ว่ามี Dashboard หรือระบบแจ้งเตือนกี่ตัว เพียง publish ไปยัง Topic ตาม contract ที่กำหนด

Topic คือ contract ของระบบ

Topic เป็นชื่อเส้นทางเชิงตรรกะ เช่น:

factory/line-1/meter/power_kw
factory/line-1/meter/energy_kwh
solar/inverter-01/status
home/ev-charger/power_kw

สิ่งสำคัญไม่ใช่แค่ตั้งชื่อให้อ่านง่าย แต่ต้องกำหนดด้วยว่า:

payload มี schema อะไร
unit คืออะไร
timestamp อยู่ตรงไหน
retained หรือไม่
ใช้ QoS เท่าไร
ใคร publish/subcribe ได้บ้าง

ถ้าไม่มี contract เหล่านี้ ระบบ MQTT ขนาดใหญ่จะกลายเป็น Topic จำนวนมากที่ไม่มีใครแน่ใจว่าค่าแต่ละตัวหมายถึงอะไร

QoS 0, 1 และ 2 ต่างกันอย่างไร

MQTT มี Quality of Service 3 ระดับสำหรับการส่ง Application Message ระหว่าง sender กับ receiver ในแต่ละช่วงของการสื่อสาร

QoS	ความหมาย	เหมาะกับ
0	At most once	telemetry ที่ส่งถี่และยอมเสียบาง sample ได้
1	At least once	event/telemetry ที่ไม่อยากพลาด แต่ต้องรับมือ duplicate
2	Exactly once ใน protocol exchange นั้น	flow ที่ต้นทุน handshake เพิ่มแต่ต้องการลด duplicate delivery

จุดที่มักเข้าใจผิดคือ QoS ไม่ใช่คำรับประกัน end-to-end ของ business process ทั้งระบบ

ถ้า publisher ส่ง QoS 1 เข้า Broker และ Broker ส่งต่อ subscriber ด้วย QoS อื่น ผลลัพธ์ของแต่ละ hop สามารถต่างกันได้ และ application ยังต้องออกแบบเรื่อง idempotency, duplicate handling และ persistence เอง

Retained Message ไม่ใช่ History Database

Retained Message ทำให้ Broker เก็บข้อความล่าสุดของ Topic แล้วส่งให้ subscriber ใหม่ที่ subscribe เข้ามา

เหมาะกับค่าอย่าง:

current mode
online status
setpoint ล่าสุด
configuration state

แต่ retained message ไม่ได้แทน time-series database เพราะเก็บ “ค่าล่าสุด” ไม่ใช่ประวัติทุก sample

ถ้าต้องการกราฟย้อนหลัง ควรมี consumer ที่บันทึกข้อมูลลงฐานข้อมูลหรือระบบ time series แยกต่างหาก

Session ช่วยเรื่องการ reconnect

MQTT 5.0 มีแนวคิด Session State และ Session Expiry Interval เพื่อให้ client/server รักษาสถานะบางส่วนข้ามการ disconnect ได้ตาม configuration

จึงไม่ควรใช้คำว่า “MQTT reconnect แล้วข้อมูลไม่หาย” แบบเหมารวม เพราะผลลัพธ์ขึ้นกับ:

QoS
Session Expiry
broker persistence
subscription state
queue limits
client implementation

MQTT มี Encryption ในตัวหรือไม่

ตัว MQTT protocol ไม่ได้บังคับให้ทุก connection ถูกเข้ารหัส

OASIS ระบุว่า implementation สามารถใช้ transport ที่เหมาะสม และ TLS เป็นแนวทางมาตรฐานสำหรับ authentication, integrity และ privacy ของข้อมูลระหว่างทาง

แนวทาง production ทั่วไปจึงควรพิจารณา:

TLS สำหรับ network ที่ไม่ไว้วางใจ
server certificate validation
client authentication ตาม risk
username/password หรือ stronger authentication mechanism
per-topic authorization / ACL
credential rotation

อย่าเขียนว่า “MQTT รองรับ SSL แล้วจึงปลอดภัย” โดยไม่ดูว่า deployment เปิด TLS จริงหรือไม่ และ client ตรวจ certificate ถูกต้องหรือเปล่า

MQTT 3.1.1 กับ MQTT 5.0

MQTT 3.1.1 ยังถูกใช้งานกว้างมาก ส่วน MQTT 5.0 เพิ่มความสามารถ เช่น:

Session Expiry
Reason Codes ที่ละเอียดขึ้น
User Properties
Message Expiry
Request/Response pattern support
Topic Alias

เวลาเลือก version ควรดู ecosystem ของ broker, device firmware และ integration ที่ใช้อยู่ ไม่ใช่อัปเกรดเพียงเพราะเลข version ใหม่กว่า

MQTT เหมาะกับงานอะไร

MQTT เหมาะเมื่อระบบมี producer/consumer หลายตัวและต้องการ decouple กัน เช่น:

sensor telemetry
Solar / Energy Monitoring
Home Assistant integrations
machine status
alarm/event distribution
edge gateway → cloud
local automation bus

แต่ไม่ได้แปลว่าต้องใช้ MQTT ทุกจุด ตัวอย่างเช่น device อุตสาหกรรมจำนวนมากอาจสื่อสารด้วย Modbus ที่หน้างาน แล้ว Gateway เป็นผู้แปลงข้อมูลขึ้น MQTT อีกชั้นหนึ่ง

ถ้ากำลังเลือกระหว่าง Publish/Subscribe กับ Request/Response อ่าน MQTT vs HTTP/API ต่างกันอย่างไร เพื่อแยก message semantics ก่อนเลือก protocol

Meter / Inverter
    │ Modbus RTU/TCP
    ▼
Edge Gateway
    │ MQTT/TLS
    ▼
Broker → Dashboard / Database / Alert

นี่เป็น architecture ที่พบได้บ่อย เพราะแยก field protocol ออกจาก message distribution layer ชัดเจน

เมื่อไรไม่ควรใช้ MQTT

MQTT ไม่ได้เป็นคำตอบอัตโนมัติของทุกระบบ IoT ตัวอย่างที่ protocol อื่นอาจตรงกว่า:

โจทย์	ทางเลือกที่มักตรงกว่า
Client ขอข้อมูลหนึ่งครั้งแล้วรอคำตอบทันที	HTTP/API หรือ request/response ที่ชัดเจน
อุปกรณ์มี consumer เดียวและ integration ตรงอยู่แล้ว	Native/local API อาจลด component กลาง
ต้อง query ข้อมูลย้อนหลังจากฐานข้อมูล	Database/API ไม่ใช่ retained topic
งาน field control ที่มี timing/safety constraint สูง	Local controller/PLC/interlock ไม่ควรพึ่ง broker เป็น safety path
ระบบเล็กมากและไม่มีเหตุผลต้อง decouple producer/consumer	อย่าเพิ่ม Broker เพียงเพื่อให้ architecture ดูเป็น IoT

ถ้ากำลังเลือกระหว่าง MQTT กับ API ให้ดู MQTT vs HTTP/API และถ้าเป็น ESPHome + Home Assistant โดยตรง ให้เทียบ ESPHome Native API vs MQTT ก่อนเพิ่ม Broker

เช็กลิสต์ก่อนใช้ MQTT จริง

ก่อน production ควรตอบให้ได้ว่า:

Topic naming convention คืออะไร
payload schema และ unit ถูก version อย่างไร
QoS ของแต่ละ message class คืออะไร
retained topic ตัวไหนบ้าง
Session Expiry ต้องการหรือไม่
broker เก็บ queued message ได้แค่ไหน
authentication/authorization ใช้อะไร
TLS terminate ที่ไหน
ถ้า Broker ล่ม ระบบ critical ยังทำงาน local ได้หรือไม่
ข้อมูลย้อนหลังถูกเก็บที่ระบบใด

สรุป

MQTT เป็น message protocol ที่เรียบง่ายและทรงพลังสำหรับ IoT เพราะใช้ Broker และ Publish/Subscribe ลด coupling ระหว่างอุปกรณ์ แต่ระบบที่ดีต้องออกแบบมากกว่าแค่ “ต่อ Broker แล้ว publish ได้”

ให้มอง Topic + Payload + QoS + Session + Security เป็น contract เดียวกัน และแยกให้ชัดว่า MQTT ใช้สำหรับส่งข้อความ ส่วน persistence, analytics และ control safety เป็นหน้าที่ของระบบรอบข้าง