ในงานระบบอาคารอัจฉริยะ อุปกรณ์อย่างสวิตช์ไฟ เซนเซอร์อุณหภูมิ หรือเซนเซอร์ประตูส่วนใหญ่ไม่ได้ต่อ Wi-Fi โดยตรง แต่สื่อสารกันด้วยโปรโตคอล Zigbee ซึ่งกินไฟต่ำและกระจายสัญญาณต่อกันเป็นตาข่าย (Mesh) ได้ คำถามที่ตามมาเสมอสำหรับคนทำระบบคือ แล้วเราจะดึงข้อมูลและสั่งงานอุปกรณ์เหล่านี้จากระบบของเราเองได้อย่างไร คำตอบอยู่ที่อุปกรณ์ตัวกลางที่ชื่อว่า Zigbee Gateway

Zigbee Gateway ทำหน้าที่อะไร

Gateway คืออุปกรณ์ที่ “พูดได้สองภาษา” ด้านหนึ่งคุยกับอุปกรณ์ลูกด้วยคลื่นวิทยุ Zigbee อีกด้านหนึ่งเชื่อมต่อเข้าเครือข่าย Wi-Fi หรือ LAN ของอาคารเพื่อออกอินเทอร์เน็ต อุปกรณ์รุ่นใหม่หลายตัวเป็นแบบ Multi-Mode คือรองรับทั้ง Zigbee และ Bluetooth ในกล่องเดียว หน้าที่หลักของมันมีอยู่สามอย่าง

• รวมศูนย์อุปกรณ์ — สวิตช์และเซนเซอร์หลายสิบชิ้นถูกจับคู่เข้ามาอยู่ใต้ Gateway ตัวเดียว ทำให้จัดการจากจุดเดียวได้
• แปลงโปรโตคอล — ข้อมูลดิบจากคลื่น Zigbee ถูกแปลงเป็นข้อความที่คลาวด์และแอปพลิเคชันเข้าใจได้
• ดูแลเครือข่าย Mesh — จัดการการเข้า-ออกของอุปกรณ์ลูก และเส้นทางการส่งข้อมูลภายในตาข่าย Zigbee

ข้อดีที่เห็นชัดในงานติดตั้งจริงคืออุปกรณ์ปลายทางไม่ต้องแบกภาระเรื่อง Wi-Fi เลย จึงใช้แบตเตอรี่ก้อนเล็กอยู่ได้เป็นปี และไม่ไปเบียดช่องสัญญาณของ Access Point ในอาคารที่มักจะหนาแน่นอยู่แล้ว

ภาพรวมสถาปัตยกรรม: จากสวิตช์ถึงไมโครคอนโทรลเลอร์

ถ้าจะต่อยอดจากการ “เปิด-ปิดผ่านแอปมือถือ” ไปสู่ระบบที่เขียนโปรแกรมควบคุมเองได้ โครงสร้างที่เราใช้จริงในงานฝึกอบรมและงานติดตั้งจะแบ่งเป็น 5 ชั้น ดังนี้

1. อุปกรณ์ปลายทาง Zigbee — สวิตช์ไฟแบบ 1/2/3 ช่อง เซนเซอร์อุณหภูมิ เซนเซอร์ประตู ฯลฯ
2. Zigbee Gateway — รับสัญญาณจากอุปกรณ์ทั้งหมดแล้วส่งต่อขึ้นอินเทอร์เน็ต
3. คลาวด์ของผู้ผลิต — เก็บสถานะอุปกรณ์และเปิด Cloud API ให้เรียกใช้งานได้
4. Local Bridge บน Raspberry Pi — โปรแกรมที่รันค้างไว้ คอยดึงสถานะจากคลาวด์มาเผยแพร่ผ่าน MQTT Broker ภายในเครือข่าย และรับคำสั่งจาก MQTT ส่งกลับขึ้นคลาวด์
5. ไมโครคอนโทรลเลอร์ปลายทาง — เช่น ESP32-S3 ที่คุยกับ MQTT Broker ภายในบ้านหรือห้องแล็บเท่านั้น

ทำไมต้องมี Bridge คั่นกลาง ไม่ให้ ESP32 ยิงคลาวด์ตรง ๆ

หลายคนสงสัยว่าทำไมไม่ให้ ESP32 เรียก Cloud API เองเลยจะได้ประหยัดอุปกรณ์ไปหนึ่งชิ้น เหตุผลที่เราเลือกวางสถาปัตยกรรมแบบมี Bridge คั่นมีหลายข้อ

• ความปลอดภัยของกุญแจ — Access Secret ของโปรเจกต์คลาวด์ถูกเก็บไว้ที่ Raspberry Pi เครื่องเดียว ไม่ต้องฝังลงเฟิร์มแวร์ของบอร์ดทุกตัวที่กระจายอยู่ทั่วอาคาร
• ภาระงานของบอร์ด — การเซ็นลายเซ็นดิจิทัลและจัดการ Access Token ที่หมดอายุเป็นงานที่กินทรัพยากร ปล่อยให้ Raspberry Pi ทำแล้วส่งผลลัพธ์เป็นข้อความ MQTT สั้น ๆ ให้บอร์ดอ่านจะเบากว่ามาก
• ระบบยังทำงานต่อได้เมื่อเน็ตล่ม — การสื่อสารภายในเครือข่ายยังเดินได้ แม้ลิงก์ออกอินเทอร์เน็ตจะมีปัญหาชั่วคราว
• เปลี่ยนแบรนด์ได้โดยไม่ต้องแก้เฟิร์มแวร์ — ถ้าวันหนึ่งเปลี่ยนไปใช้ Gateway ยี่ห้ออื่น แก้เฉพาะโค้ดฝั่ง Bridge ส่วนโครงสร้าง MQTT Topic ที่บอร์ดใช้อยู่ยังเหมือนเดิม

ตัวโปรแกรม Bridge เองทำงานไม่ซับซ้อน คือคอยอ่านสถานะอุปกรณ์เป็นรอบ ๆ (เช่นทุก 10 วินาที) เทียบกับค่าเดิมที่จำไว้ ถ้าเปลี่ยนจึงค่อยประกาศออก MQTT และอีกทางหนึ่งก็เฝ้าฟัง Topic คำสั่งไว้ เมื่อมีคำสั่งเข้ามาก็ส่งต่อขึ้นคลาวด์แล้วตอบผลกลับ ทั้งหมดนี้ควรตั้งให้รันเป็นบริการถาวรด้วย systemd เพื่อให้กลับมาทำงานเองอัตโนมัติหลังไฟดับหรือรีสตาร์ทเครื่อง

สี่เรื่องที่ควรรู้ก่อนลงมือตั้งค่า

• บัญชีมีสองระบบที่แยกจากกัน — บัญชีในแอปมือถือที่ใช้จับคู่อุปกรณ์ กับบัญชีนักพัฒนาบนแพลตฟอร์มคลาวด์ เป็นคนละบัญชีกัน ต้องสร้างทั้งคู่แล้วเชื่อมเข้าหากันด้วยขั้นตอน Link App Account
• ภูมิภาคของศูนย์ข้อมูลต้องตรงกัน — Data Center ที่เลือกตอนสร้างโปรเจกต์คลาวด์ ต้องตรงกับภูมิภาคที่บัญชีแอปมือถือถูกสร้างไว้จริง ไม่เช่นนั้นจะเชื่อมบัญชีไม่ผ่าน
• ต้องเปิดใช้งานบริการ API ให้ครบ — โปรเจกต์ที่เพิ่งสร้างจะยังเรียก API ไม่ได้จนกว่าจะ Subscribe ชุดบริการที่เกี่ยวข้องให้ครบ ทั้งชุดควบคุมอุปกรณ์ การจัดการโทเคน และการแจ้งเตือนสถานะแบบเรียลไทม์
• อุปกรณ์ต่างรุ่นมีช่องข้อมูลไม่เหมือนกัน — ก่อนเขียนโค้ดควรเปิดเครื่องมือ Device Debugging บนหน้าเว็บคอนโซลเพื่อดูรายการ Data Point ของอุปกรณ์ชิ้นนั้นจริง ๆ ก่อนเสมอ อย่าเดาชื่อช่องข้อมูลเอง

อีกจุดที่มือใหม่มักสะดุดคือการยืนยันตัวตนตอนเรียก API ทุกคำขอต้องแนบลายเซ็นดิจิทัลที่คำนวณด้วย HMAC-SHA256 จากข้อมูลของคำขอนั้น ๆ ประกอบกับกุญแจลับของโปรเจกต์ ถ้าลายเซ็นไม่ตรงแม้แต่ตัวอักษรเดียว คลาวด์จะปฏิเสธคำขอทันที

บทเรียนจากการติดตั้งจริง

จากประสบการณ์ติดตั้งระบบและแก้ปัญหาหน้างาน ข้อผิดพลาดที่เจอบ่อยมักไม่ใช่เรื่องโค้ด แต่เป็นการตั้งค่าเล็ก ๆ ที่มองข้าม

• เชื่อมบัญชีแอปไม่ผ่าน มักมาจากภูมิภาคของศูนย์ข้อมูลไม่ตรงกับบัญชีแอป ให้เปิดดูภูมิภาคจริงในแอปมือถือแล้วกลับไปแก้ที่หน้าโปรเจกต์
• เรียก API แล้วถูกปฏิเสธเพราะ IP เคยเจอกรณีที่ตัวเลือกจำกัด IP ถูกเปิดไว้โดยไม่ตั้งใจแต่ยังไม่ได้ใส่ IP ใดเลย ผลคือทุก IP ถูกบล็อกหมดรวมถึงเครื่องของเราเอง
• ลายเซ็นไม่ผ่าน สาเหตุยอดฮิตคือหยิบกุญแจมาจากคนละโปรเจกต์ หรือมีช่องว่างติดมาตอนคัดลอกค่า ตรวจความยาวและค่าที่แท้จริงของตัวแปรก่อนไล่แก้โค้ด

ด้านความปลอดภัย ขอเน้นสามข้อ: อย่าเขียนกุญแจลับลงในไฟล์โค้ดที่จะขึ้น Git ให้เก็บไว้ในตัวแปรสภาพแวดล้อมแทน, เปิดการยืนยันตัวตนด้วยชื่อผู้ใช้และรหัสผ่านบน MQTT Broker เสมอ อย่าปล่อยให้เชื่อมต่อแบบไม่ระบุตัวตน และงานส่วนที่เกี่ยวกับไฟฟ้าแรงดัน 220 โวลต์ ต้องให้ผู้มีความรู้ด้านไฟฟ้าเป็นผู้ดำเนินการเท่านั้น

Zigbee กับ LoRa ต่างกันอย่างไร

ทั้งสองเทคโนโลยีถูกออกแบบมาเพื่องานพลังงานต่ำเหมือนกัน แต่จุดที่ใช้งานต่างกันชัดเจน Zigbee เหมาะกับอุปกรณ์จำนวนมากในระยะใกล้ระดับภายในอาคาร ส่งข้อมูลถี่ ตอบสนองเร็ว และอาศัยการกระโดดต่อกันเป็นตาข่ายเพื่อขยายพื้นที่ ส่วน LoRa ออกแบบมาเพื่อระยะไกลระดับกิโลเมตรกลางแจ้ง แลกมาด้วยแบนด์วิดท์ที่ต่ำกว่ามากและการส่งข้อมูลที่ห่างกว่า จึงเหมาะกับงานเกษตร งานตรวจวัดสิ่งแวดล้อม หรือมิเตอร์ที่กระจายอยู่นอกอาคาร

พูดง่าย ๆ คือถ้างานอยู่ในตึก ให้เริ่มมองที่ Zigbee ก่อน แต่ถ้าจุดวัดอยู่ห่างเป็นกิโลเมตรและส่งข้อมูลไม่บ่อย LoRa จะคุ้มกว่า อ่านรายละเอียดของ LoRa เพิ่มเติมได้ในบทความ LoRa คืออะไร เทคโนโลยีไร้สายระยะไกลสำหรับ IoT

ดาวน์โหลดคู่มือฉบับเต็ม

บทความนี้เป็นภาพรวมเชิงแนวคิด ผู้ที่ต้องการลงมือทำตามทีละขั้นตอน ทั้งการจับคู่อุปกรณ์ การตั้งค่าโปรเจกต์บนคลาวด์ ตัวอย่างโค้ด Python สำหรับเรียก API และการเชื่อมต่อ MQTT บน Raspberry Pi สามารถดาวน์โหลดคู่มือฉบับสมบูรณ์ที่ทีมงานเท็นเนอยี่ อินโนเวชั่น จัดทำขึ้นเพื่อการเรียนการสอนได้ที่ลิงก์ด้านล่าง

หากองค์กรของท่านกำลังวางระบบ Smart Building หรือต้องการที่ปรึกษาด้านการเชื่อมอุปกรณ์เข้าสู่ระบบ IoT ของตนเอง ทีมงานของเรายินดีให้คำแนะนำ ติดต่อสอบถามได้ผ่านหน้าติดต่อของเว็บไซต์