สื่อการเรียนรู้ · Internet of Things
เรียนรู้มาตรฐานการเชื่อมต่ออุปกรณ์ IoT แต่ละประเภทผ่านภาพเคลื่อนไหว ดูว่าข้อมูลเดินทางจากเซนเซอร์ตัวเล็ก ๆ ไปจนถึงคลาวด์ได้อย่างไร
ภาพรวม
ทุกระบบ IoT มีโครงสร้างหลักคล้ายกัน 4 ชั้น ลองดูเส้นทางของข้อมูลหนึ่งก้อนเคลื่อนผ่านแต่ละชั้น
คลิกการ์ดเพื่อเปิด Packet Inspector
Packet Inspector · อุปกรณ์ / เซนเซอร์
เปลี่ยนสิ่งที่วัดได้ ให้กลายเป็นตัวเลข
Input
อุณหภูมิจริงในห้อง
Process
Sensor วัดและแปลงสัญญาณ
Output
31.8 °C
ข้อมูลที่ชั้นนี้มองเห็น
temperature = 31.8
จุดแสง = แพ็กเก็ตข้อมูล · เปลี่ยนทิศทางเพื่อดูว่าคำสั่งเดินทางกลับอย่างไร
มาตรฐานการเชื่อมต่อ
แต่ละมาตรฐานออกแบบมาเพื่องานต่างกัน — ระยะใกล้/ไกล เร็ว/ช้า กินไฟมาก/น้อย คลิกที่แต่ละชื่อเพื่อดูภาพเคลื่อนไหวและรายละเอียด
IEEE 802.11
อุปกรณ์ทุกตัวเชื่อมตรงเข้า Access Point (เราเตอร์) แบบดาว ส่งข้อมูลได้เร็วมากแต่กินไฟสูง จึงเหมาะกับอุปกรณ์ที่เสียบปลั๊กไฟ
ระยะทำการ
~50 ม.
ความเร็ว
สูงสุดหลายร้อย Mbps
พลังงาน
สูง
ความถี่
2.4 / 5 GHz
เหมาะกับ
เปรียบเทียบ
ไม่มีมาตรฐานไหน 'ดีที่สุด' มีแต่ 'เหมาะที่สุดกับงาน' กราฟนี้ช่วยให้เห็นภาพการแลกเปลี่ยน (trade-off)
กฎทอง: ยิ่งส่งไกล + ความเร็วสูง มักยิ่งกินพลังงานมาก — เลือกมาตรฐานตามงาน
ลงมือออกแบบ · เลือกเครือข่าย
ลองกำหนดระยะ แหล่งพลังงาน และปริมาณข้อมูล แล้วดูว่า architecture แบบใดเหมาะเป็นจุดเริ่มต้น
เปลี่ยน requirement แล้วดูว่าทางเลือกและภาพเครือข่ายเปลี่ยนอย่างไร
ทางเลือกที่เหมาะกับโจทย์
ส่งไกลหลายกิโลเมตรและให้เซนเซอร์หลับระหว่างรอบส่งได้
โปรโตคอลข้อมูล
การเชื่อมต่อ (เช่น Wi-Fi) เป็นแค่ 'ถนน' ส่วนโปรโตคอลข้อมูลคือ 'ภาษา' ที่อุปกรณ์ใช้สื่อสารกันบนถนนนั้น MQTT เป็นที่นิยมที่สุดใน IoT
MQTT v5.0 เป็นโปรโตคอลแบบ Client-Server Publish/Subscribe ที่ออกแบบให้เบา ใช้งานง่าย และเหมาะกับอุปกรณ์ M2M/IoT ที่ bandwidth หรือทรัพยากรจำกัด
เซนเซอร์ส่งครั้งเดียวไปที่ Broker - ใคร subscribe topic นั้นก็ได้รับข้อมูลตามเงื่อนไข QoS
topic: building/room-01/temperature
retain: false
qos: 1
payload:
{
"deviceId": "room-01",
"temperature": 31.8,
"unit": "celsius",
"ts": "2026-06-16T10:42:08+07:00"
}อุปกรณ์ทุกตัวเป็น Client ที่เชื่อมไปหา Broker ไม่ต้องเปิด port ให้ device คุยกันเองโดยตรง
Publisher ส่งข้อความเข้า topic ส่วน Subscriber เลือกสมัครรับ topic ที่สนใจ ทำให้ระบบแยกส่วนกันได้ดี
topic มักจัดเป็นลำดับชั้น เช่น building/room-01/temperature และใช้ wildcard เพื่อรับข้อมูลหลายจุดพร้อมกัน
MQTT ไม่บังคับรูปแบบ payload จะส่ง JSON, binary หรือ protobuf ก็ได้ ข้อตกลง schema จึงอยู่ที่ระบบของเรา
ยิ่ง QoS สูง ยิ่งมี acknowledgement มากขึ้น แลกกับ traffic และ latency ที่เพิ่มขึ้น
ข้อมูลเซนเซอร์ที่ส่งถี่และยอมเสียบางค่าได้
PUBLISH
event สำคัญที่รับซ้ำได้ เช่น alert หรือสถานะเครื่อง
PUBLISH -> PUBACK
ธุรกรรมที่ซ้ำไม่ได้ เช่น billing หรือคำสั่งสำคัญ
PUBLISH -> PUBREC -> PUBREL -> PUBCOMP
กำหนดได้ว่า Broker จะเก็บ session หลังหลุดนานแค่ไหน เพื่อให้ device reconnect แล้วรับงานค้างต่อได้
Broker เก็บข้อความล่าสุดของ topic ไว้ให้ subscriber ใหม่เห็นสถานะปัจจุบันทันที เช่น online/offline หรือค่าล่าสุด
ข้อความมีอายุได้ ถ้าส่งไม่ทันในเวลาที่กำหนดก็ไม่ควร deliver ต่อ เพราะข้อมูล IoT บางชนิดหมดความหมายเร็ว
packet ตอบกลับบอกผลสำเร็จ/ล้มเหลวได้ชัดขึ้น เช่น QoS ไม่รองรับ, packet ใหญ่เกิน หรือ auth ไม่ผ่าน
ลด overhead โดยแทนชื่อ topic ยาว ๆ ด้วยเลข alias ระหว่าง connection เหมาะกับเครือข่ายที่ bandwidth จำกัด
ใช้รูปแบบ $share/{group}/{filter} เพื่อกระจายงานจาก topic เดียวไปยัง worker หลายตัวแบบ load balancing
Publish / Subscribe
โปรโตคอล Client-Server แบบ publish/subscribe ที่ให้อุปกรณ์ส่งข้อความเข้า Broker ตาม topic และให้ระบบที่สนใจ subscribe รับต่อ โดยไม่ต้องรู้จักกันโดยตรง
Request / Response
คล้าย HTTP แต่ออกแบบมาให้เบาสำหรับอุปกรณ์เล็ก ทำงานบน UDP ใช้รูปแบบ GET/POST/PUT/DELETE เหมือนเว็บ
Request / Response
โปรโตคอลเว็บมาตรฐาน ใช้ได้ทันทีกับทุกระบบ แต่ header ใหญ่และกินทรัพยากร จึงไม่เหมาะกับอุปกรณ์ที่ใช้แบตเตอรี่
ลงมือออกแบบ · End-to-End
ระบบจริงไม่ได้จบที่การเชื่อมต่อ ลองดู topic, payload, database และสิ่งที่ควรเกิดขึ้นเมื่ออินเทอร์เน็ตหลุด
กดส่ง packet ทีละขั้น แล้วลองตัดอินเทอร์เน็ต
ESP32 อ่านอุณหภูมิได้ 31.8°C
{
"deviceId": "room-01",
"temperature": 31.8,
"unit": "celsius",
"timestamp": "10:42:08"
}ระบบจริง · Security
ความปลอดภัยไม่ใช่กล่องใบเดียว แต่เป็นเกราะหลายชั้นตั้งแต่ตัวอุปกรณ์ เครือข่าย ไปจนถึง firmware
เลือกชั้นป้องกัน หรือจำลองการโจมตีเพื่อดูผล
Certificate หรือ key ทำให้ระบบแยกอุปกรณ์จริงออกจากอุปกรณ์ปลอมได้
หลักคิด: ไม่มีเกราะชั้นเดียวที่พอ ระบบจริงต้องใช้หลายชั้นร่วมกัน
กรณีศึกษา · พลังงาน
ก่อนเจาะแต่ละอุปกรณ์ ลองดูภาพรวมก่อน — โซลาร์ แบตเตอรี่ รถ EV และกริด ทั้งหมดแลกเปลี่ยนพลังงานกันบนบัสบาร์เดียว โดยมีสมอง IoT คอยตัดสินใจทุกวินาทีว่าจะเก็บ ใช้ หรือขายไฟ
ทุกหน่วยมาเจอกันที่บัสบาร์ · ระบบ IoT วัดและสั่งทุกวินาทีว่าจะ เก็บ / ใช้ / ขาย พลังงาน
กรณีศึกษา · พลังงาน
อุปกรณ์พลังงานแต่ละชนิดมีมาตรฐานเฉพาะของตัวเอง เลือกอุปกรณ์เพื่อดูว่าพลังงานและข้อมูลไหลอย่างไร และคุยกันด้วยโปรโตคอลอะไร
ผลิตไฟ DC → แปลงเป็น AC → ส่งเข้าบ้าน/กริด
แผงโซลาร์ผลิตไฟกระแสตรง (DC) ส่งให้อินเวอร์เตอร์แปลงเป็นกระแสสลับ (AC) ระบบ IoT อ่านค่าจากอินเวอร์เตอร์ผ่าน Modbus ตามมาตรฐาน SunSpec ที่กำหนดรูปแบบรีจิสเตอร์ให้เหมือนกันทุกยี่ห้อ
ระบบ IoT อ่าน/สั่งอะไรได้บ้าง
ตู้ชาร์จ EV ↔ ระบบหลังบ้าน (CSMS)
มาตรฐานเปิด ทำให้ตู้ชาร์จต่างยี่ห้อใช้ระบบบริหารเดียวกันได้
อินเวอร์เตอร์โซลาร์, แบตเตอรี่
SunSpec กำหนดรูปแบบรีจิสเตอร์ Modbus ให้เป็นมาตรฐานเดียวกัน
สมาร์ตมิเตอร์ไฟฟ้า (AMI)
มาตรฐานสากลสำหรับอ่านค่ามิเตอร์อัตโนมัติของการไฟฟ้า
สถานีไฟฟ้า, สมาร์ตกริด
ใช้ควบคุม/ป้องกันระบบส่งจ่ายไฟระดับสถานี
กรณีศึกษา · โซลาร์
หัวใจของบ้านโซลาร์ยุคใหม่คือสมองที่ตัดสินใจทุกวินาที — เก็บไฟเข้าแบต ใช้เอง หรือขายคืนกริด กดเล่นแล้วดูพลังงานเคลื่อนผ่านทั้งวัน
ระบบ IoT คอยตัดสินใจทุกชั่วโมงว่าจะเก็บไฟ ใช้ไฟ หรือขายคืนกริด — กดเล่นแล้วดูพลังงานไหล
นิ่ง
กรณีศึกษา · สถานีชาร์จ EV
ตั้งแต่ชาร์จช้า ๆ ที่บ้านจนถึงตู้ Ultra-Fast ริมไฮเวย์ มาดูความต่างของกำลังไฟ หัวชาร์จ และเบื้องหลังการคุยกันด้วยโปรโตคอล OCPP
ตู้ AC ส่งไฟสลับให้รถไปแปลงเป็น DC เองในตัว (จำกัดด้วย on-board charger) ส่วนตู้ DC แปลงไฟให้เสร็จแล้วอัดเข้าแบตตรง ๆ จึงเร็วกว่ามาก — เลือกดูทีละแบบ
ความเร็วการเติมในภาพสัมพันธ์กับกำลังไฟจริง
ทุกข้อความที่ตู้ชาร์จกับระบบหลังบ้านคุยกัน ตั้งแต่เปิดเครื่องจนคิดเงิน
ตู้เพิ่งเปิดเครื่อง รายงานรุ่น/เฟิร์มแวร์ให้หลังบ้านรู้จัก
กรณีศึกษา · สมาร์ตกริด
ในระดับอาคารและกริด ระบบ IoT ใช้แบตเตอรี่จ่ายไฟแทนช่วงพีค (peak shaving) เพื่อกดยอดความต้องการไฟฟ้าสูงสุดที่การไฟฟ้านำไปคิดเงิน — ลองเปิด/ปิดระบบดูผล
การไฟฟ้าคิด “ค่าความต้องการพลังไฟฟ้า” (demand charge) จากยอดพีคสูงสุด ระบบ IoT จึงสั่งแบตจ่ายไฟแทนช่วงพีค เพื่อกดยอดลง
ระบบจริง · Reliability & Lifecycle
ดูสถานะ fleet, เลือกระดับการส่งข้อความ และทำความเข้าใจวงจรชีวิตตั้งแต่ลงทะเบียนจนปลดระวาง
สถานะผิดปกติต้องมองเห็นได้ก่อนผู้ใช้พบปัญหา
ส่งอย่างน้อยหนึ่งครั้ง อาจซ้ำ แต่เหมาะกับ telemetry ส่วนใหญ่
ทบทวน
แบบทดสอบสั้น ๆ เพื่อเชื่อมภาพทั้งหมดเข้าด้วยกัน ตั้งแต่การเลือกเครือข่ายจนถึงการรับมือเมื่อระบบมีปัญหา