MQTT vs HTTP/API ต่างกันอย่างไร? เลือกอะไรสำหรับ IoT, ESP32 และ Automation.

MQTT และ HTTP/API ใช้ส่งข้อมูลระหว่างระบบได้เหมือนกัน แต่ architecture ต่างกันชัด

ภาพง่าย ๆ คือ:

MQTT
Publisher → Broker → Subscriber(s)

HTTP/API
Client → Request → Server
       ← Response ←

จึงไม่ควรถามว่า “อะไรดีกว่า” แบบรวม ๆ แต่ควรถามว่า ระบบกำลังส่ง telemetry, ขอข้อมูล, สั่งงาน หรือ integrate service แบบไหน

MQTT เหมาะกับ Publish/Subscribe

MQTT แยก producer ออกจาก consumer ผ่าน Broker

ตัวอย่าง:

ESP32 meter node
   ↓ publish
home/main/power_kw
   ↓
MQTT Broker
   ├─ Home Assistant
   ├─ Database
   └─ Alert service

ESP32 ไม่จำเป็นต้องรู้ว่ามี consumer กี่ตัว

เหมาะกับ:

• sensor telemetry
• event distribution
• device state
• local automation bus
• gateway → central systems
• one-to-many distribution

อ่านพื้นฐาน protocol ที่ MQTT คืออะไร

HTTP/API เหมาะกับ Request/Response

HTTP เหมาะเมื่อ client ต้องการ resource/action ที่ชัด:

GET /api/energy/today
POST /api/device/command

แล้วรอ response

เหมาะกับ:

• web/mobile application
• CRUD/data service
• configuration
• query historical data
• webhook
• external integration ที่มี REST/API contract

Telemetry ส่งด้วยอะไรดี

ถ้า Sensor ส่งค่าต่อเนื่องและมีหลาย consumer MQTT มักตรง architecture มากกว่า

Temperature node
   ↓ ทุก 30 s
MQTT Broker
   ├─ Dashboard
   ├─ Historian
   └─ Automation

ถ้าใช้ HTTP แบบให้ Sensor POST ไปหลาย service เอง:

Sensor
 ├→ Dashboard API
 ├→ Database API
 └→ Alert API

จะเพิ่ม coupling ที่ edge device

แต่ถ้ามี ingestion API กลางเพียงจุดเดียว HTTP ก็สามารถเหมาะสมได้

Request ข้อมูลเฉพาะครั้ง HTTP ตรงกว่า

ตัวอย่าง App ต้องการรายงานเดือนนี้:

GET /api/energy/monthly-summary

ไม่จำเป็นต้องสร้าง MQTT topic เพื่อ query ทุกอย่าง

ดังนั้นระบบจริงมักใช้:

Realtime telemetry → MQTT
Historical/query/config → HTTP API

ได้พร้อมกัน

Command ใช้ MQTT ได้ไหม

ได้ เช่น:

home/pump/cmd
home/pump/state

แต่ต้องแยก Commanded State กับ Actual State

ห้ามออกแบบว่า publish ON แล้ว Dashboard เปลี่ยนเป็น ON โดยถือว่า Pump ทำงานจริงทันที

Architecture ที่ดีกว่า:

Command topic
   ↓
Controller validates command
   ↓
Actuator command
   ↓
Feedback
   ↓
State topic

สำหรับ load จริงยังต้องมี timeout/protection/local interlock ตามระบบ

HTTP Command ก็มีข้อจำกัดเหมือนกัน

HTTP 200 OK อาจหมายถึง server รับคำสั่งแล้ว ไม่ได้แปลว่า physical actuator ทำงานสำเร็จเสมอ

ควรกำหนด contract เช่น:

• accepted
• executing
• completed
• failed
• timeout

โดยเฉพาะ operation ที่ใช้เวลานาน

Offline / Reconnect ต่างกันอย่างไร

MQTT ecosystem มีแนวคิดอย่าง session, QoS, retained message และ broker-side queue ตาม configuration

HTTP request ทั่วไปเป็น transaction ต่อ request ถ้า network ล่ม client ต้องกำหนด retry/backoff/idempotency เอง

แต่ MQTT ก็ไม่ได้ทำ offline correctness ให้โดยอัตโนมัติ เพราะยังต้องดู:

• QoS
• persistence
• session expiry
• queue limits
• duplicate handling
• stale retained state

Retained Message ระวังเรื่อง Command

Retained state มีประโยชน์กับสถานะล่าสุด แต่ retained command อาจมี risk ถ้า device reconnect แล้วได้รับคำสั่งเก่าที่ไม่ควรถูก execute อีก

จึงควรแยก message class ให้ชัด:

State
Event
Command
Configuration

และกำหนด retained/QoS/expiry ตาม semantics ของแต่ละแบบ

HTTP Retry ต้องคิด Idempotency

ถ้า client ส่ง:

POST /start-irrigation

แล้ว timeout ก่อนเห็น response จากนั้น retry อาจเกิดคำสั่งซ้ำถ้า server ไม่ออกแบบให้ idempotent

แนวทางอาจใช้:

• request ID
• idempotency key
• desired-state model
• command sequence/version

หลักเดียวกันใช้กับ MQTT QoS 1 ที่ duplicate message เป็นไปได้

Security ต่างกันอย่างไร

ทั้ง MQTT และ HTTP สามารถใช้ TLS ได้ตาม stack และ deployment

สิ่งที่ต้องออกแบบจริงคือ:

• authentication
• authorization
• credential lifecycle
• certificate validation
• network segmentation
• exposed ports
• per-device/per-topic/API permission

อย่าถือว่า:

HTTPS = ระบบปลอดภัยอัตโนมัติ
MQTTS = ระบบปลอดภัยอัตโนมัติ

เพราะ authorization และ application logic ยังมีผล

MQTT Broker เป็น Dependency กลาง

ข้อดีของ broker คือ decouple producer/consumer

แต่ถ้า broker ล่ม ระบบที่พึ่ง broker ทั้งหมดก็อาจเสีย function

ดังนั้น control สำคัญควรถามว่า:

Broker unavailable
→ local controller ยังทำงานได้ไหม

Smart Home/Smart Farm ที่ดีอาจให้ cloud/broker เป็น supervision มากกว่าการเป็น safety/control layer เดียว

HTTP API เป็น Dependency กลางเช่นกัน

ถ้าทุก device ต้อง call cloud API ก่อนทำงาน ก็มี dependency ต่อ Internet/DNS/cloud availability

ระบบ local-first อาจใช้:

Local control
+
MQTT/API สำหรับ monitoring / remote management

ESP32 ควรเลือกอะไร

เลือก MQTT เมื่อ

• publish telemetry ต่อเนื่อง
• มีหลาย subscriber
• ต้องการ broker-based decoupling
• Home Assistant/MQTT ecosystem เป็นแกน

เลือก HTTP/API เมื่อ

• เรียก service เป็นครั้ง ๆ
• query/configuration ชัด
• integrate กับ web backend
• endpoint เป็น canonical source ของ resource

ใช้ทั้งคู่เมื่อ

• telemetry realtime ไป MQTT
• configuration/history/report ไป API

ตัวอย่าง Energy Monitoring

Meter → Gateway
          ↓ MQTT
     Realtime power
          ↓
Home Assistant / EMS

Web App
  ↓ HTTP API
Historical billing/report

ตัวอย่าง Smart Farm

Field Controller
   ├─ local pump/valve policy
   ├─ MQTT telemetry/state
   └─ HTTP API for configuration/reporting

เมื่อ Internet หรือ central service ล่ม local policy ที่จำเป็นยังไม่ควรหายไป

MQTT vs HTTP/API สรุป

ประเด็น	MQTT	HTTP/API
Model	Publish/Subscribe	Request/Response
ตัวกลาง	Broker	Server/API
One-to-many	เหมาะมาก	ต้องออกแบบเพิ่ม
Query resource	ไม่ใช่จุดเด่นหลัก	เหมาะ
Realtime telemetry	เหมาะ	ทำได้
Web ecosystem	ต้องมี bridge/client	Native มาก
Offline semantics	มี session/QoS tools แต่ต้อง config	client/app ต้องออกแบบ retry

ระบบที่ดีไม่ต้องเลือกผู้ชนะหนึ่งตัว

ให้เลือก protocol ตาม message semantics และ failure behavior แล้วกำหนดว่าอะไรคือ state, event, command และ source of truth ให้ชัด