

ตอนทำอุปกรณ์ตัวแรก โค้ดตัวอย่างมักตั้งชื่อ client ไว้ให้พร้อมเชื่อมต่อ MQTT เราแก้ชื่อ Wi-Fi กับที่อยู่ broker แล้วก็เริ่มส่งค่าได้ แต่เมื่อคัดลอกโปรเจกต์ไปอีกบอร์ด ค่าที่ติดไปด้วยอาจไม่ได้มีแค่การตั้งค่าเครือข่าย ชื่อ client เดิมก็อาจถูกใช้ซ้ำโดยไม่ทันสังเกต
อาการที่เห็นอาจเป็นบอร์ดหนึ่งต่อได้แล้วอีกบอร์ดหลุด พออีกตัว reconnect กลับมาก็เหมือนสลับกันหลุดอีกครั้ง หากดูแค่ log ว่า connection หาย ก็ชวนให้คิดถึงสัญญาณ Wi-Fi หรือกำลังไฟ ทั้งที่ปัญหาอาจเกิดหลังทั้งสองตัวเข้าถึง broker ได้ตามปกติแล้ว
จึงควรตรวจ Client ID ควบคู่กับเหตุผลที่ broker ปิดการเชื่อมต่อครับ เพราะรหัสนี้มีหน้าที่ระบุ client ในการจัดการ session และไม่ควรถูกคัดลอกเป็นค่าเดียวกันให้หลายอุปกรณ์ที่ต้องเชื่อมพร้อมกัน
ใน MQTT 5 เมื่อ server รับการเชื่อมต่อที่ผ่านการตรวจแล้ว และ Client ID นั้นเป็นของ client ที่กำลังต่ออยู่ server ต้องปิดการเชื่อมต่อเดิมตามกระบวนการที่มาตรฐานกำหนด โดยมีเหตุผล Session taken over สำหรับการแจ้ง client เดิม
ดังนั้นสองบอร์ดที่ใช้รหัสเดียวกันไม่ได้กลายเป็นอุปกรณ์อิสระสองตัวเพียงเพราะส่งจากคนละ IP หากทั้งคู่มีโค้ด reconnect อัตโนมัติ ก็สามารถแย่งกันใช้ตัวตนเดิมไปมาได้ การลดเวลารอก่อน reconnect จึงอาจเพิ่มจังหวะการสลับแทนที่จะแก้ปัญหา

อย่างไรก็ดี connection หายไม่ได้ยืนยันว่ารหัสชนทุกครั้ง ต้องดูเหตุผลจาก broker หรือ packet ที่ระบบบันทึกได้ตามสิทธิ์ด้วย ไลบรารีที่รองรับ MQTT คนละรุ่นอาจรายงานรายละเอียดต่างกัน หากเห็นเพียงข้อความทั่วไปก็ควรตรวจ log ฝั่ง broker ในช่วงเวลาเดียวกันประกอบ
สิ่งที่น่าสังเกตคืออาการเริ่มเมื่อเปิดบอร์ดตัวที่สองหรือไม่ และ Client ID ที่โปรแกรมส่งจริงเป็นค่าใด ไม่ดูเพียงชื่อที่พิมพ์บนกล่อง เพราะค่าที่อยู่ใน firmware หรือไลบรารีสร้างให้เองอาจต่างจากชื่อที่ใช้เรียกกันตอนติดตั้ง
อุปกรณ์หนึ่งตัวอาจมีรหัสประจำเครื่องที่คงอยู่ ชื่อห้องที่ย้ายเปลี่ยนได้ และ Client ID สำหรับเชื่อม broker ซึ่งแต่ละค่าไม่จำเป็นต้องเป็นข้อความเดียวกันทั้งหมด การแยกหน้าที่ไว้ช่วยไม่ให้การย้ายห้องไปเปลี่ยน session หรือทำให้ข้อมูลเก่าอ้างไม่ตรงเครื่องโดยไม่ตั้งใจ
ตัวอย่างเช่น ตั้ง device ID ที่ออกให้เฉพาะเครื่องไว้ในระบบจัดเตรียมอุปกรณ์ แล้วสร้าง Client ID ภายใต้ข้อตกลงเดียวกัน ส่วนชื่อที่ผู้ใช้เห็นเป็นข้อความซึ่งแก้ได้ตามตำแหน่งติดตั้ง วิธีนี้เป็นแนวทางออกแบบ ไม่ได้หมายความว่าต้องนำหมายเลขฮาร์ดแวร์ออกไปเปิดเผยในทุก topic
หากใช้ค่าจาก MAC address หรือหมายเลขชิปเป็นส่วนของรหัส ต้องตรวจว่าค่าที่อ่านมามีความคงที่และเหมาะกับความต้องการแค่ไหน รวมถึงเงื่อนไขข้อมูลที่เผยแพร่ออกไป ไม่ถือว่าชื่อที่ดูมีเลขยาวจะช่วยเรื่องความลับหรือสิทธิ์ได้โดยอัตโนมัติ
ควรมีวิธีตรวจความซ้ำตั้งแต่ขั้นจัดเตรียมและเก็บความสัมพันธ์กับ firmware หรืออุปกรณ์ที่ส่งมอบด้วย เพราะต่อให้วิธีสร้างรหัสดี แต่กระบวนการแฟลช image ที่มีข้อมูลเฉพาะเครื่องติดอยู่ไปทุกตัว ก็ยังทำให้ตัวตนถูกคัดลอกตามไปได้
การสร้าง Client ID ใหม่ทุกครั้งที่บูตอาจช่วยให้ไม่ชนค่าคงที่ของอีกบอร์ด แต่ก็ต้องคิดเรื่อง session ที่ต้องกลับมาต่อด้วย เพราะ broker ใช้รหัสนี้ร่วมกับเงื่อนไข session ของ protocol หากเปลี่ยนชื่อทุกครั้ง เราอาจไม่ได้กลับมาหาสถานะเดิมที่ตั้งใจให้เก็บไว้
ใน MQTT 5 มีทั้ง Clean Start กับ Session Expiry Interval สำหรับกำหนดการเริ่มและอายุ session จึงต้องดูการตั้งค่าร่วมกัน ไม่คิดว่าใช้ Client ID เดิมแล้ว subscription และข้อความค้างจะคงอยู่เสมอ โดยไม่สนใจอายุและพฤติกรรมที่ตกลงกับ broker
เมื่อเชื่อมกลับมา client ควรดูผลที่ broker ตอบว่ามี session เดิมหรือไม่ แล้วทำตามพฤติกรรมของไลบรารีและแอปที่ออกแบบไว้ เช่น ต้อง subscribe ใหม่เมื่อไม่มีสถานะเดิม การ reconnect ผ่านเพียงอย่างเดียวยังไม่ได้บอกว่าอุปกรณ์พร้อมรับงานแบบเดิมครบแล้ว

ทางเลือกจึงขึ้นอยู่กับงาน อุปกรณ์ที่ต้องมีตัวตนคงที่และรับข้อความตาม session เดิมอาจเลือกอีกแบบจากเครื่องมือทดสอบที่ใช้ session ชั่วคราว สิ่งที่ต้องรักษาร่วมกันคือไม่ให้สองการเชื่อมต่อที่ตั้งใจเป็นคนละ client ใช้รหัสเดียวกันโดยไม่รู้ตัว
ถึงชื่อจะต้องไม่ชน แต่การรู้ Client ID ไม่ควรเท่ากับมีสิทธิ์เข้ามาแทนอุปกรณ์ได้ ระบบยังต้องมีการยืนยันตัวตนและกำหนดสิทธิ์ publish หรือ subscribe ตามงาน โดยตรวจว่าบัญชีหนึ่งถูกอนุญาตให้ใช้รหัสกับ topic ใดได้บ้างตามความสามารถของ broker
ถ้าใช้บัญชีเดียวร่วมกันทุกบอร์ด และอนุญาตให้เลือก Client ID อะไรก็ได้ การคัดลอกรหัสจากอีกเครื่องอาจกระทบมากกว่าการส่งค่าปะปน จึงควรมองการจัดเตรียม credential กับตัวตนเป็นส่วนเดียวของงานดูแลอุปกรณ์ แต่ยังแยกหน้าที่ของแต่ละค่าให้ชัด
การเปลี่ยน Client ID ให้มีความสุ่มมากขึ้นจึงไม่แทนการตรวจสิทธิ์ และไม่ควรพิมพ์ credential ไปพร้อม log ของการตรวจ collision ข้อมูลที่จำเป็นคือรหัส client รหัสอุปกรณ์ รุ่น firmware เวลา และเหตุผลการเชื่อมต่อ โดยเก็บไว้ในขอบเขตที่เหมาะสม
หากต้องเปลี่ยนรหัสของอุปกรณ์ที่ติดตั้งแล้ว ควรวางแผนด้วยว่าข้อมูลที่ระบบอ้างอุปกรณ์นั้นอยู่จะตามไปอย่างไร รวมถึง session เก่าที่ broker อาจยังเก็บอยู่ ไม่แก้ให้เชื่อมผ่านแล้วปล่อยชื่อซ้ำกับสถานะค้างไว้โดยไม่จัดการตามนโยบาย
ใน broker ทดสอบที่แยกจากงานจริง สามารถใช้ client สองตัวที่ตั้งรหัสเดียวกันเพื่อดูพฤติกรรม takeover ตาม protocol แล้วเปลี่ยนให้เป็นคนละรหัสและตรวจการเชื่อมต่อพร้อมกัน วิธีนี้ช่วยตรวจทั้งความเข้าใจของเราและข้อมูลที่เครื่องมือรายงานได้
จากนั้นค่อยตรวจกรณีบอร์ดเดียว reconnect หลังเครือข่ายหาย เพื่อดูว่า session กลับมาตามที่ตั้งไว้หรือไม่ และกรณีที่ไม่มีสิทธิ์ใช้รหัสของอีกเครื่องต้องถูกปฏิเสธตามนโยบายของระบบ การผ่านกรณีไม่ชนอย่างเดียวไม่ได้ยืนยันเรื่องสิทธิ์แทนอุปกรณ์
หากจะอ้างว่าแก้อาการหลุดของอุปกรณ์จริงแล้ว ต้องมี log กับการตรวจจากชุดนั้นประกอบ บทนี้อธิบายกลไกและแนวตรวจ ไม่ได้ระบุว่าบอร์ดของผู้ใช้กำลังหลุดเพราะรหัสชน เพียงเพราะอาการที่เล่าคล้ายกัน
Client ID เป็นส่วนหนึ่งของการระบุ session จึงต้องไม่ถูกคัดลอกไปให้หลายอุปกรณ์ที่ต้องต่อพร้อมกันโดยไม่ได้ตั้งใจ เมื่อแยกรหัสประจำเครื่อง ชื่อแสดง และ credential ออกจากกัน พร้อมตรวจ session กับเหตุผลการปิด connection ก็จะตามอาการหลุดได้ตรงจุด และเปลี่ยนจำนวนอุปกรณ์ได้โดยไม่ให้แต่ละตัวแย่งตัวตนเดียวกัน