เซนเซอร์ส่งข้อมูลขึ้นเว็บ จำเป็นต้องใช้ MQTT ไหม

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

ถ้ามองแค่ว่าอยากเห็นตัวเลขบนหน้าเว็บ HTTP ก็พาไปได้ อุปกรณ์ส่งค่าเมื่อมีคนเรียก หรือส่งเป็นครั้งๆ ไปยัง endpoint ที่เตรียมไว้ วิธีนี้เข้าใจง่ายและไล่ปัญหาได้ตรงไปตรงมา เปิดหน้าแล้วเห็นว่าเรียกสำเร็จหรือไม่ ดูสถานะตอบกลับได้ทันที

แต่พอมีผู้รับหลายตัว หรืออยากให้ระบบอื่นรับค่าชุดเดียวกันโดยไม่ต้องไปยุ่งกับอุปกรณ์ซ้ำอีกครั้ง การผูกทุกอย่างไว้กับ HTTP ตรงๆ เริ่มทำให้ฝั่งอุปกรณ์ต้องรู้ว่ามีใครรออยู่บ้าง ถ้าเพิ่มระบบแจ้งเตือนทีหลัง อาจต้องกลับไปแก้เฟิร์มแวร์ให้รู้จัก endpoint ใหม่ หรือให้มีตัวกลางมารับแล้วกระจายต่อ ซึ่งตอนนั้นเองที่รูปแบบการสื่อสารเริ่มสำคัญกว่าชื่อเครื่องมือที่คุ้น

งานส่งค่ากับงานขอค่าไม่ใช่เรื่องเดียวกัน

งานบางอย่างเป็นลักษณะขอเป็นครั้งๆ เช่น เปิดหน้าแล้วอยากได้ค่าล่าสุด หรือกดสั่งรีเลย์แล้วอยากรู้ผลตอนนั้น การใช้ HTTP ตรงกับความต้องการแบบนี้ดี เพราะเริ่มต้นและจบในรอบเดียว ฝั่งเรียกรู้ว่าสำเร็จหรือล้มเหลวจากคำตอบรอบนั้น และไม่จำเป็นต้องมีกระบวนการค้างรอข้อความตลอดเวลา

ส่วนงานที่เซนเซอร์อ่านค่าแล้วอยากให้ระบบอื่นรับต่อเมื่อมีค่าใหม่ มักเป็นอีกแบบ อุปกรณ์อยากส่งออกไปได้โดยไม่ต้องจำว่ามีใคร subscribe อยู่กี่ตัว และฝั่งรับก็อยากเลือกเองว่าจะรับ topic ไหน MQTT เข้ากับงานลักษณะนี้ เพราะมี broker คั่นกลาง ฝั่งส่งกับฝั่งรับแยกกันได้ บอร์ดทำหน้าที่ publish ตามจังหวะของมัน ส่วน dashboard หรือสคริปต์ค่อยมาเชื่อมเมื่อพร้อม

ความต่างตรงนี้สำคัญ เพราะถ้าเอา HTTP ไปใช้กับงานที่จริงๆ แล้วเป็นการกระจายสถานะ อุปกรณ์อาจต้องวนยิงไปหลายที่ หรือมีบริการกลางมารับแล้วค่อยส่งต่อ ซึ่งก็เริ่มใกล้แนวคิด broker อยู่ดี เพียงแต่จัดการเองทั้งหมด ส่วนถ้าเอา MQTT ไปบังคับกับงานที่แค่กดสั่งครั้งเดียวแล้วจบ ก็อาจได้ระบบที่ตั้งค่ายาวเกินความจำเป็นของคำถามนั้น

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

ก่อนเลือก ลองดูว่าข้อมูลเดินทางอย่างไร

ก่อนลงชื่อเครื่องมือ ลองไล่ดูว่าค่าหนึ่งค่าต้องไปถึงใคร และต้องไปถึงทันทีแค่ไหน ถ้ามีผู้รับเดียวและเรียกเมื่อต้องการ HTTP ก็อาจพอ ถ้ามีหลายระบบที่อยากได้ค่าชุดเดียวกันโดยไม่ต้องแก้ firmware ทุกครั้งที่มีผู้รับใหม่ การแยกผ่าน broker ช่วยลดการผูกฝั่งอุปกรณ์เข้ากับรายชื่อผู้รับ

ลองนึกภาพห้องที่มีเซนเซอร์อุณหภูมิหนึ่งตัว ค่าชุดเดียวกันอาจถูกเอาไปแสดงบนหน้าเว็บ ถูกเอาไปเทียบเกณฑ์แจ้งเตือน และถูกเอาไปบันทึกแนวโน้มระยะยาว ถ้าให้บอร์ดยิงตรงไปทุกปลายทาง ทุกครั้งที่มีปลายทางใหม่ก็ต้องไปแตะเฟิร์มแวร์อีก แต่ถ้าบอร์ดส่งเข้า topic หนึ่งไว้ ระบบอื่นที่สนใจค่อยมา subscribe เอง การเพิ่มผู้รับจึงไม่ต้องเริ่มจากอุปกรณ์ทุกครั้ง

เรื่องที่มักทำให้สับสนคือ retained message กับค่าล่าสุด คนเปิดหน้าเว็บหลังเซนเซอร์ส่งไปแล้วอาจไม่เห็นอะไรเลยถ้าไม่มีใครเก็บค่าล่าสุดไว้ให้ ส่วน MQTT ที่มี retained ช่วยให้ผู้รับใหม่ได้ข้อความล่าสุดของ topic นั้นได้ แต่ก็ยังควรมีเวลาวัดกำกับไว้ด้วย เพื่อรู้ว่าค่านั้นเก่าแค่ไหน ไม่ใช่เห็นตัวเลขแล้วคิดว่าเพิ่งอ่านมาตอนนี้

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

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

เช่น แยกคำสั่งออกจากสถานะไว้คนละกลุ่ม topic จะช่วยให้ระบบที่อยากได้แค่ค่าปัจจุบันไม่ไปรับคำสั่งปน และระบบที่ส่งคำสั่งก็ไม่ไปรบกวนผู้ที่สนใจเฉพาะการอ่านค่า รายละเอียดแบบนี้ดูเล็กตอนมีบอร์ดเดียว แต่พอระบบเริ่มโต การจัดชื่อตั้งแต่แรกมักถูกกว่าการมาเปลี่ยนชื่อทีหลังทั้งชุด

สิ่งที่ยังไม่ต้องตัดสินใจตั้งแต่วันแรก

ยังไม่จำเป็นต้องลงรายละเอียด QoS ทุกระดับ หรือออกแบบคลัสเตอร์ broker ให้ใหญ่โตตั้งแต่วันที่มีเซนเซอร์สองสามตัว สิ่งที่ควรวางก่อนคือรูปแบบการเดินทางของข้อมูล ผู้รับมีใครบ้าง และค่าล่าสุดจะถูกเก็บอย่างไรให้คนเปิดหน้าไม่สับสน

พอเส้นทางข้อมูลชัดแล้ว ค่อยไล่เรื่องความทนทาน การยืนยันการส่ง และการแยก environment ตามที่งานต้องการ โดยไม่ต้องเริ่มจากรายการฟีเจอร์ของโปรโตคอลแล้วค่อยหาเหตุผลมารองรับ

เมื่อเริ่มมีทั้งหน้าเว็บและระบบอื่นพร้อมกัน

พอมีแค่หน้าเว็บหน้าเดียว การยิง HTTP จากบอร์ดไปยัง endpoint หนึ่งจุดยังไล่ปัญหาได้ตรง แต่เมื่อมีระบบแจ้งเตือนเข้ามาด้วย และอาจมีสคริปต์เก็บประวัติแยกอีกทาง คำถามจะเปลี่ยนจาก “ส่งถึงเว็บได้อย่างไร” เป็น “ค่าชุดเดียวกันควรแยกทางเดินอย่างไร”

ถ้าให้บอร์ดเป็นคนรู้จักทุกปลายทาง ทุกครั้งที่ระบบปลายทางเปลี่ยนชื่อหรือเพิ่มตัวใหม่ ฝั่งอุปกรณ์จะถูกดึงเข้าไปเกี่ยวข้องด้วย การมีจุดรวมอย่าง broker จึงไม่ใช่เพราะอยากได้ชื่อโปรโตคอลใหม่ แต่เพราะอยากให้การเพิ่มผู้รับไม่ต้องเริ่มที่เฟิร์มแวร์ทุกครั้ง

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

สรุป

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