ตั้งค่า MQTT Gateway บน USR-N5X0 PUSR ทีละขั้น: Broker, SSL/TLS สองทาง, Will Message และการทดสอบด้วย MQTT.fx

วันที่ 20 สิงหาคม 2569 | บทความเทคนิค | VR Automation

ทำไม MQTT ถึงเหมาะกับงานอุตสาหกรรม

คู่มือ USR-N5X0 อธิบายเหตุผลไว้ตรงประเด็น แม้โปรโตคอล MQTT จะมีอายุเกือบสามทศวรรษแล้ว แต่การออกแบบทำให้เหมาะกับงาน IIoT อย่างยิ่ง โดยเฉพาะงานที่เน้น active notification ซึ่งอุปกรณ์ส่งข้อมูลเฉพาะเมื่อจำเป็น ต่างจาก passive notification ที่ต้องโพลลิงอุปกรณ์เป็นระยะสม่ำเสมอ

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

ขั้นที่ 1 — ตั้งค่า Broker

คู่มือระบุว่าเมื่อเข้าหน้าตั้งค่า Broker ค่า Client ID, Host และ Port จะถูกกรอกไว้ให้ล่วงหน้าอยู่แล้ว ผู้ใช้แก้ไขเองได้ตามข้อมูล Broker จริงที่จะใช้ ในเอกสารตัวอย่าง ผู้ผลิตใช้ Free Public MQTT Server ของ EMQX Cloud เป็นที่อยู่เซิร์ฟเวอร์สำหรับทดสอบอย่างรวดเร็ว

หาก broker ของคุณเปิดการยืนยันตัวตนผู้ใช้ ให้กรอกข้อมูล Username และ Password ในรายการคอนฟิกเพิ่มเติม

ขั้นที่ 2 — เปิด SSL/TLS และเลือกรูปแบบการยืนยันตัวตน

ส่วนนี้สำคัญที่สุดสำหรับงานที่ข้อมูลวิ่งผ่านอินเทอร์เน็ตสาธารณะ คู่มือระบุว่ามีให้เลือกสองเวอร์ชันคือ TLS 1.0 และ TLS 1.2 เมื่อเลือกใช้ SSL/TLS แล้วจึงตั้งค่าใบรับรองต่อได้

รูปแบบการยืนยันตัวตนแบ่งเป็นสองแบบ

คู่มืออธิบายบทบาทของแต่ละไฟล์ไว้ด้วย โดย ไฟล์ CA มาจาก Certificate Authority ซึ่งเป็นหน่วยงานที่ออกใบรับรองดิจิทัลเพื่อรับรองความเป็นเจ้าของกุญแจสาธารณะ ไฟล์ Client Certificate เป็นใบรับรองที่ระบบไคลเอนต์ใช้ทำคำขอที่ผ่านการยืนยันตัวตนไปยังเซิร์ฟเวอร์ระยะไกล และ ไฟล์ Private Key คือกุญแจส่วนตัวของไคลเอนต์

ขั้นที่ 3 — คอนฟิกขั้นสูงและ Will Message

คู่มือระบุว่าในส่วนคอนฟิกขั้นสูง ผู้ใช้ตั้งค่า Keep Alive, Clean Session, Auto Reconnect และเวอร์ชัน MQTT ได้ ส่วน Will Message มีค่าเริ่มต้นของ Last-Will-QoS เป็น 0 และ Last-Will-Retain เป็น False เมื่อกรอกค่า Last-Will-Topic และ Last-Will-Payload ครบก็ถือว่าตั้งค่า Will Message เสร็จสมบูรณ์

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

ขั้นที่ 4 — บันทึกค่าและตรวจสอบสถานะ

คู่มือย้ำขั้นตอนที่คนมักลืมไว้ชัดเจน หลังตั้งค่าพื้นฐานเสร็จ ให้เลื่อนลงไปด้านล่างสุดของหน้าแล้วกดปุ่ม Save & Apply เพื่อบันทึกการเปลี่ยนแปลงทั้งหมด และ คอนฟิกทั้งหมดจะมีผลหลังจากรีบูตระบบเท่านั้น

วิธีตรวจสอบว่าเชื่อมต่อสำเร็จ ให้เข้าเมนู Status > Overview ถ้าอุปกรณ์อยู่ในสถานะ CONNECTED แปลว่าเชื่อมต่อกับ IoT Hub สำเร็จ และเริ่มดำเนินการ publish และ subscribe ได้

ขั้นที่ 5 — ทดสอบด้วย MQTT.fx

คู่มือแนะนำ MQTT.fx เป็นเครื่องมือทดสอบ โดยระบุว่าเป็นไคลเอนต์ MQTT บนเดสก์ท็อปที่เป็นที่นิยม รองรับ Windows, macOS และ Linux ใช้ตรวจสอบได้รวดเร็วว่าเชื่อมต่อกับ IoT Hub และ publish หรือ subscribe ข้อความได้หรือไม่ เอกสารอ้างอิงเวอร์ชัน 1.7.1

ขั้นตอนทดสอบตามคู่มือ: คลิกไอคอนตั้งค่าด้านขวาของช่องกรอกที่อยู่การเชื่อมต่อ เลือก Profile Type เป็น MQTT Broker จากนั้นกรอก broker.emqx.io ในช่อง Broker Address และ 1883 ในช่อง Broker Port แล้วกด OK และกด Connect ถ้าไฟแสดงสถานะด้านขวาเปลี่ยนเป็นสีเขียว แสดงว่าการเชื่อมต่อสำเร็จ

สำหรับการทดสอบโหมด transparent transmission คู่มือยกตัวอย่างการเลือก Publish topic1 กรอกชื่อหัวข้อ ผูกกับ Port1 เลือก QoS 0 และไม่ติ๊ก retained message โดยใช้ /PubTopic1 เป็นตัวอย่าง จากนั้นกด Save & Apply แล้วรีบูต

สรุปลำดับงานที่แนะนำ

ให้ทำตามลำดับ: ทดสอบเชื่อม broker สาธารณะด้วย MQTT.fx ก่อนเพื่อยืนยันว่าเส้นทางเครือข่ายและอุปกรณ์ทำงานถูกต้อง จากนั้นย้ายไป broker จริง เปิด TLS 1.2 พร้อมใบรับรอง แล้วจึงตั้ง Will Message และ Keep Alive ให้เหมาะกับความถี่ข้อมูล สุดท้ายกด Save & Apply และรีบูต แล้วตรวจสถานะที่หน้า Status > Overview ทุกครั้ง

สนใจ Serial Device Server ที่รองรับ MQTT และ Modbus ในตัว ดูรุ่นที่จำหน่ายได้ที่ หมวดอุปกรณ์เครือข่ายอุตสาหกรรม ของ VR Automation

คำถามที่พบบ่อย (FAQ)

ตั้งค่า MQTT เสร็จแล้วทำไมยังไม่เชื่อมต่อ

สาเหตุที่พบบ่อยที่สุดคือยังไม่ได้กด Save & Apply หรือยังไม่ได้รีบูต เพราะคู่มือระบุชัดว่าคอนฟิกทั้งหมดจะมีผลหลังรีบูตระบบเท่านั้น ให้ตรวจสถานะที่ Status > Overview ว่าขึ้น CONNECTED หรือไม่

จำเป็นต้องใช้ใบรับรองแบบสองทางไหม

ขึ้นกับนโยบายของ broker หากเป็นการเชื่อมต่อทางเดียวใช้เพียงไฟล์ CA ก็พอ แต่สำหรับระบบที่ต้องการยืนยันว่าอุปกรณ์เป็นตัวจริงด้วย ต้องอัปโหลดทั้ง CA, Client Certificate และ Client Key

Will Message มีประโยชน์อย่างไรในงานโรงงาน

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

แหล่งข้อมูลและมาตรฐานอ้างอิง

1. Catalog: USR-N5X0.pdf (USR-N510/N520/N540/N580 User Manual V1.0.0) — VR Automation (เอกสารเทคนิคจากผู้ผลิต)
2. PUSR — USR-N5X0 User Manual — คู่มือผู้ใช้ฉบับทางการ บทที่ 8 ว่าด้วย MQTT gateway
3. EMQ — MQTT QoS 0, 1, 2 Explained — อธิบายระดับ QoS ที่ใช้ตั้งค่าในหน้า publish/subscribe
4. EMQX — MQTT Core Concepts — อ้างอิงแนวคิด retained message, will message และ clean session