Field Log

การออกแบบระบบควบคุมแบบ Hybrid (Online/Offline) ของ Smart Timer

การออกแบบ Smart Timer ที่ดี ไม่ใช่แค่การเขียน Code ให้ทำงานได้ แต่คือการออกแบบโครงสร้างให้ระบบ ฉลาดและเชื่อถือได้ ในทุกสภาวะการณ์

5 MIN READ
06/04/2026
การออกแบบระบบควบคุมแบบ Hybrid (Online/Offline) ของ Smart Timer

Architecture of Smart Timer: การออกแบบระบบควบคุมแบบ Hybrid (Online/Offline)

ในการพัฒนาระบบ IoT สิ่งที่แยกแยะระหว่าง "สคริปต์เปิด-ปิดไฟทั่วไป" กับ "ระบบควบคุมระดับอุตสาหกรรม (System Architecture)" คือ ความทนทาน (Reliability) และ ความต่อเนื่องของการทำงาน (Availability) บทความนี้จะเจาะลึกการออกแบบ Smart Timer ที่ใช้โครงสร้างแบบ Hybrid เพื่อให้ระบบทำงานได้แม่นยำแม้ในสภาวะที่การเชื่อมต่ออินเทอร์เน็ตไม่เสถียร


1. System Design & Data Flow

สถาปัตยกรรมนี้ถูกออกแบบโดยแบ่งหน้าที่การทำงาน (Separation of Concerns) อย่างชัดเจน เพื่อให้เกิดประสิทธิภาพสูงสุดในการรับส่งข้อมูลและการแสดงผล

  • ESP32 (The Edge Controller): ทำหน้าที่เป็นหัวใจหลักในการประมวลผล Logic และควบคุม Hardware โดยตรง
  • MQTT Broker (The Communication Hub): เป็นตัวกลางในการรับ-ส่ง Message แบบ Pub/Sub ซึ่งช่วยลดภาระการเชื่อมต่อแบบ Point-to-Point
  • Next.js Dashboard (The Control Plane): ส่วนติดต่อผู้ใช้ที่จัดการ Data Visualization และการส่งค่า Configuration กลับไปยังอุปกรณ์

Data Flow:

  1. State Reporting: ESP32 ส่งสถานะปัจจุบัน (Relay Status, Uptime, Signal Strength) ไปยัง MQTT Topic ทุกๆ 30 วินาที
  2. Command Flow: เมื่อผู้ใช้ปรับตั้งค่าการทำงานของ Smart Timer บน Next.js ข้อมูลจะถูกส่งผ่าน Webhook หรือ API ไปยัง MQTT Broker
  3. Syncing: ESP32 รับค่า (Subscribe) และอัปเดตตารางเวลาใน Local Memory ทันที

2. Protocol: ทำไมต้อง MQTT และ JSON Payload?

การเลือกใช้ MQTT (Message Queuing Telemetry Transport) ไม่ใช่เพียงเพราะเป็นที่นิยม แต่เพราะคุณสมบัติ Lightweight ที่เหมาะสมกับ Resource ของ Microcontroller

  • Low Overhead: MQTT มี Header ขนาดเล็กมาก (2 Bytes) ทำให้ประหยัด Bandwidth และพลังงาน เหมาะสำหรับระบบที่ต้องเปิดทำงาน 24/7
  • Bi-directional Communication: รองรับการสื่อสารสองทางที่รวดเร็ว (Low Latency) ทำให้การกดสั่งงานจาก Dashboard เห็นผลในระดับมิลลิวินาที

การจัดการ JSON Payload สำหรับ Schedule Setting: เราเลือกส่งข้อมูลในรูปแบบ JSON เพื่อความยืดหยุ่นในการขยายระบบ (Scalability) ตัวอย่างโครงสร้างข้อมูล:

{ "device_id": "ST-001", "config": { "mode": "auto", "schedules": [ {"on": "06:00", "off": "08:00", "days": [1,2,3,4,5]}, {"on": "17:00", "off": "20:00", "days": [1,2,3,4,5]} ] } }

การใช้ JSON ช่วยให้ ESP32 สามารถ Parse ข้อมูลชุดใหญ่ที่มีหลายเงื่อนไขได้ในการรับส่งเพียงครั้งเดียว และง่ายต่อการ Debug ผ่านระบบ Cloud


3. Offline First: โครงสร้าง Layer ระหว่าง Local และ Remote

หัวใจสำคัญของบทความนี้คือ "Offline First" ซึ่งเป็นการออกแบบให้ Logic การตัดสินใจ (Decision Making) อยู่ที่ปลายทาง (Edge) ไม่ใช่บน Cloud

Layer 1: Local Control (Critical Path)

  • Internal RTC (Real-Time Clock): ESP32 จะซิงค์เวลาจาก NTP Server เฉพาะตอนที่มีเน็ต แต่หากเน็ตหลุด ระบบจะใช้ internal timer หรือ RTC Module ภายนอกในการนับเวลาต่อ
  • Local Logic: ตารางเวลา (Schedules) จะถูกเก็บไว้ใน Non-Volatile Storage (NVS) หรือ EEPROM ของชิป ทำให้เมื่อไฟดับและไฟมาใหม่ ระบบสามารถทำงานต่อได้ทันทีโดยไม่ต้องรอโหลดค่าจากเซิร์ฟเวอร์

Layer 2: Remote Monitoring (Status Path)

  • หน้าที่ของส่วนนี้คือการ "สะท้อน" (Mirror) สิ่งที่เกิดขึ้นที่หน้างาน และรับคำสั่งปรับเปลี่ยนเชิงนโยบายเท่านั้น หาก Layer นี้ขาดการเชื่อมต่อ "ระบบต้องไม่หยุดทำงาน"

จาก Script สู่ System Architecture

การออกแบบในลักษณะนี้ยกระดับโปรเจกต์จากงานอดิเรกสู่ Professional Solution ด้วยเหตุผล 3 ประการ:

  1. Fault Tolerance: ระบบมีความทนทานต่อความล้มเหลวของ Network

  2. Data Integrity: การใช้ JSON และ MQTT ช่วยให้มั่นใจว่าข้อมูลตั้งค่าจะถูกส่งถึงอุปกรณ์ครบถ้วน (QoS Level 1)

  3. Scalability: โครงสร้างนี้รองรับการเพิ่มอุปกรณ์จำนวนมาก (Nodes) โดยที่ Dashboard ยังคงจัดการข้อมูลได้อย่างเป็นระเบียบ

การออกแบบ Smart Timer ที่ดี จึงไม่ใช่แค่การเขียน Code ให้ทำงานได้ แต่คือการออกแบบโครงสร้างให้ระบบ "ฉลาดและเชื่อถือได้" ในทุกสภาวะการณ์


Share this log to social network