30105-2012

อินเทอร์เน็ตของสรรพสิ่ง – Internet of Things

1) Internet of Things (IoT)

  • ความหมาย: เครือข่ายของอุปกรณ์จริง (Things) ที่มีความสามารถในการรับรู้ (เซ็นเซอร์), ประมวลผล/ตัดสินใจระดับหนึ่ง, สื่อสารผ่านเครือข่าย และทำกิจกรรมตอบสนอง (แอกชูเอเตอร์) โดยข้อมูลถูกนำไปแสดงผล/วิเคราะห์บนระบบกลางหรือคลาวด์
  • เหตุผลที่สำคัญในงานอาชีพ: ลดต้นทุนแรงงาน, เพิ่มความแม่นยำ, เฝ้าติดตามระยะไกล, เก็บข้อมูลระยะยาวเพื่อวิเคราะห์แนวโน้มและซ่อมบำรุงเชิงคาดการณ์
  • ตัวอย่างใกล้ตัว
    • Smart Home: ตรวจจับการเคลื่อนไหว เปิดไฟอัตโนมัติ รายงานพลังงานรายชั่วโมง
    • Smart Farm: วัดความชื้นดิน/อุณหภูมิอากาศ ควบคุมปั๊มน้ำตามเกณฑ์
    • Smart Energy: วัดกระแส/แรงดัน วิเคราะห์การใช้พลังงาน แจ้งเตือนโหลดเกิน

2) ส่วนประกอบหลักของระบบ IoT

  1. Edge/Node (อุปกรณ์ปลายทาง): บอร์ดไมโครคอนโทรลเลอร์/ไมโครโปรเซสเซอร์ เช่น ESP32, STM32 พร้อมเซ็นเซอร์/แอกชูเอเตอร์
    • หน้าที่: เก็บข้อมูล, แปลงเป็นรูปแบบส่งต่อได้ (เช่น JSON), ควบคุมเอาต์พุตขั้นพื้นฐาน
  2. เครือข่ายสื่อสาร: Wi-Fi, Ethernet, LTE/5G, LoRa/LoRaWAN, BLE ฯลฯ
    • เลือกจากระยะทาง, อัตราข้อมูล, พลังงาน, ต้นทุน
  3. Gateway/Router: อุปกรณ์ที่เชื่อมอุปกรณ์จำนวนมากเข้าสู่เครือข่ายกว้าง (Internet) และอาจทำงานรวมข้อมูล/แปลงโปรโตคอล
  4. Cloud/Server/Database: ที่เก็บข้อมูล, ประมวลผล, กำหนดกฎ (Rule/Automation), ให้บริการแดชบอร์ด/ API
  5. Client/Visualization: Web/Mobile Dashboard, SCADA, Grafana, Node-RED Dashboard ฯลฯ

เส้นทางข้อมูลสั้น ๆ:
Edge (วัดค่า) → ส่งผ่านเครือข่าย → Gateway/Router → Cloud/DB → แดชบอร์ด/กฎควบคุม → คำสั่งย้อนกลับมายัง Edge (ถ้าต้องควบคุม)

3) โปรโตคอลสื่อสารที่ใช้บ่อย

3.1 HTTP/REST

  • ลักษณะ: Request–Response (ไคลเอนต์ร้องขอ เซิร์ฟเวอร์ตอบกลับ)
  • จุดเด่น: เข้าใจง่าย, ใช้งานร่วมกับ Web/App ได้ดี, เหมาะกับ การเรียกใช้ API รายครั้ง หรือดึง/อัปเดตข้อมูลเป็นช่วง ๆ
  • หมายเหตุ: โอเวอร์เฮดส่วนหัวมากกว่าบางโปรโตคอล, ไม่เหมาะกับการส่งข้อความขนาดเล็กถี่ ๆ จำนวนมาก

3.2 MQTT

  • ลักษณะ: Publish–Subscribe ผ่าน Broker (ตัวกลาง)
  • โครงสร้างข้อมูล: แยกเป็น Topic และ Payload
  • จุดเด่น: เบา, เหมาะกับการส่งข้อมูลถี่ ๆ, ใช้พลังงานน้อยกว่าเมื่อเทียบกับ HTTP ในหลายกรณี
  • ความสามารถ: QoS (0/1/2), Retain Message, Last Will & Testament (LWT)

สรุปเลือกใช้งาน

  • ต้องเรียกใช้ API เฉพาะครั้ง/ดึงข้อมูลตามคำสั่ง → HTTP/REST
  • ต้องสตรีม/เผยแพร่ข้อมูลวัดค่าถี่ ๆ ไปยังหลายผู้รับ → MQTT

4) โครงสร้างหัวข้อ (Topic) และเพย์โหลด (Payload) แบบมาตรฐาน

4.1 โครงสร้าง Topic (ตัวอย่างสำหรับโรงเรียน/แผนก/อุปกรณ์)

lic/electronics/<project>/<device_id>/<sensor_or_cmd>

เช่น

  • lic/electronics/smartfarm/node-01/soil_moisture
  • lic/electronics/smartfarm/node-01/cmd/pump

หลักคิดในการตั้งชื่อ Topic

  • ไล่จากกว้าง → แคบ (สถาบัน/แผนก → โปรเจกต์ → อุปกรณ์ → ประเภทข้อมูล)
  • ใช้ตัวพิมพ์เล็กและขีดกลาง/ขีดล่างให้สม่ำเสมอ
  • แยกช่องทางคำสั่ง (cmd) ออกจากข้อมูลวัดค่า (data)

4.2 เพย์โหลด JSON ที่ควรมีเสมอ

  • device_id รหัสอุปกรณ์
  • ts เวลามาตรฐาน ISO-8601 (UTC) เช่น "2025-10-20T03:05:00Z"
  • metric ชื่อค่าวัดหรือเอาต์พุต
  • value ค่าเชิงตัวเลข/สตริง
  • unit หน่วย (°C, %, lux, A, V ฯลฯ)
  • qos, status หรือ battery (ถ้ามีความจำเป็น)

ตัวอย่าง Payload

{
  "device_id": "node-01",
  "ts": "2025-10-20T03:05:00Z",
  "metric": "temperature",
  "value": 29.7,
  "unit": "°C",
  "status": "ok"
}

ตัวอย่างคำสั่ง (Downlink)

{
  "device_id": "node-01",
  "ts": "2025-10-20T03:06:30Z",
  "cmd": "pump",
  "action": "on",
  "duration_s": 30
}

5) เวลา (Time) และการซิงค์นาฬิกา

  • ใช้ NTP เพื่อซิงค์เวลา → ลดปัญหาข้อมูลสลับลำดับ/เทียบกราฟไม่ได้
  • เก็บเวลาเป็น UTC (Z) ในอุปกรณ์/ฐานข้อมูล แล้วแปลงเป็นเขตเวลาเมื่อแสดงผล
  • ระบุ หน่วยเวลาที่วัดสะสม เช่น ค่าเฉลี่ย 1 นาที/5 นาที เพื่อความถูกต้องในการวิเคราะห์

6) คุณภาพข้อมูล (Data Quality) เบื้องต้น

  • หน่วย/สเกล ต้องชัดเจน (เช่น °C, %, dBm)
  • การกรองสัญญาณ: ค่าเซ็นเซอร์อาจมีสัญญาณรบกวน → ใช้ค่าเฉลี่ยเคลื่อนที่ (Moving Average) อย่างง่ายใน Edge ก่อนส่ง
  • การตรวจจับค่าผิดปกติ: ตั้งช่วงที่ยอมรับได้ (validation) เช่น อุณหภูมิห้อง 10–45°C

7) ความปลอดภัยและความเป็นส่วนตัว (สำหรับงานแลบและโปรเจกต์)

  • ไฟฟ้าและฮาร์ดแวร์: ปิดไฟ/ถอดสายก่อนต่อวงจร, ใช้สาย USB ที่มีมอดูลป้องกัน, หลีกเลี่ยงลัดวงจร, ป้องกัน ESD
  • เครือข่ายและซอฟต์แวร์:
    • แยกเครือข่ายทดสอบสำหรับอุปกรณ์ IoT
    • ไม่ฝังรหัสผ่าน/โทเคนแบบชัดเจนในโค้ดที่จะเผยแพร่ (ใช้ไฟล์คอนฟิก/ตัวแปรแยก)
    • ใช้รหัสผ่านที่รัดกุม, หมุนเวียนคีย์สม่ำเสมอ
    • เปิดใช้การเข้ารหัส (MQTT over TLS/HTTPS) เมื่อทรัพยากรเอื้อ
  • จริยธรรมข้อมูล: ไม่เก็บข้อมูลส่วนบุคคลโดยไม่จำเป็น, ทำข้อมูลให้เป็นนิรนามก่อนแชร์

8) กรณีศึกษา “Mini Smart Farm”

วัตถุประสงค์: รดน้ำอัตโนมัติเมื่อดินแห้งและบันทึกข้อมูลขึ้นแดชบอร์ด

  • Edge: ESP32 + เซ็นเซอร์ความชื้นดิน + รีเลย์ปั๊มน้ำ
  • Topic ตัวอย่าง:
    • ขึ้นข้อมูล: lic/electronics/smartfarm/node-01/soil
    • รับคำสั่ง: lic/electronics/smartfarm/node-01/cmd/pump
  • Payload ข้อมูลวัดค่า:
{ "device_id":"node-01", "ts":"2025-10-20T03:10:00Z", "metric":"soil", "value": 38.2, "unit":"%" }
  • เกณฑ์ควบคุม: ถ้า soil < 35% → ส่งคำสั่งเปิดปั๊ม 30 วินาที
  • บันทึก/แสดงผล: เก็บลง DB, ทำกราฟเส้นความชื้นดินรายนาที, สรุปค่าเฉลี่ยรายชั่วโมง

9) คำศัพท์สำคัญ (Glossary)

  • Edge/Node: อุปกรณ์ปลายทางที่วัด/ควบคุม
  • Gateway/Router: ตัวเชื่อมต่ออุปกรณ์เข้าระบบกว้าง/อินเทอร์เน็ต
  • Broker: เซิร์ฟเวอร์ตัวกลางของ MQTT
  • Topic: ช่องทางสื่อสารใน MQTT แยกตามชื่อ
  • Payload: เนื้อหาข้อความ/ข้อมูลที่ส่งจริง
  • QoS: ระดับความเชื่อถือในการส่งของ MQTT (0/1/2)
  • Retain: เก็บข้อความล่าสุดไว้ที่ Broker ให้ผู้มาทีหลังรับได้ทันที
  • LWT (Last Will & Testament): ข้อความที่แจ้งเมื่ออุปกรณ์ตาย/หลุดการเชื่อมต่อ
  • RSSI (dBm): ค่าความแรงสัญญาณวิทยุ เป็นค่าลบ ยิ่งใกล้ 0 ยิ่งแรง

10) สรุปย่อ (Key Takeaways)

  • IoT = อุปกรณ์จริง + ข้อมูล + เครือข่าย + การตัดสินใจ + การมองเห็นผล
  • โครงสร้าง Edge → Gateway → Cloud ทำให้ขยายระบบได้และบำรุงรักษาง่าย
  • เลือกโปรโตคอลให้เหมาะงาน: HTTP สำหรับ API รายครั้ง, MQTT สำหรับสตรีมข้อมูลถี่ ๆ
  • ออกแบบ Topic & JSON ให้เป็นมาตรฐานตั้งแต่ต้น: device_id, ts, metric, value, unit
  • ความปลอดภัย/จริยธรรมข้อมูล เป็นส่วนหนึ่งของงานวิชาชีพเสมอ