Home Assistant เจออุปกรณ์ผ่าน MQTT ได้ยังไง

ตอนเพิ่มเซนเซอร์ตัวแรกใน Home Assistant การสร้างรายการด้วยมือยังไม่ยุ่งมากนัก แต่พอมีหลายค่าในหลายห้อง เราก็เริ่มต้องกรอกข้อมูลลักษณะเดิมซ้ำ ทั้งชื่อ หน่วย และ topic ที่ใช้รับสถานะ

MQTT discovery ช่วยให้อุปกรณ์ประกาศข้อมูลที่ระบบใช้สร้างรายการได้ครับ แต่การประกาศนี้ไม่ได้มีเพียงข้อความบอกว่ามีเซนเซอร์อยู่หนึ่งตัว ยังต้องมีตัวตนที่คงที่กับเส้นทางข้อมูลที่สอดคล้องกัน เพื่อไม่ให้การเปลี่ยนชื่อหรือ firmware กลายเป็นอุปกรณ์ใหม่ทุกครั้ง

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

discovery บอกวิธีรู้จัก ส่วน state บอกข้อมูลที่อ่านได้

ข้อความ discovery อธิบาย configuration ตามรูปแบบที่ Home Assistant รองรับ เช่น component ชื่อเฉพาะ หน่วย และ topic สำหรับอ่านสถานะ ส่วนข้อความค่าที่เกิดระหว่างใช้งานส่งไปตามเส้นทาง state ที่ประกาศไว้ ไม่จำเป็นต้องสร้างรายการใหม่ทุกครั้งที่อุณหภูมิเปลี่ยน

สองส่วนนี้จึงควรถูกตรวจแยกกัน หากเห็นชื่อเซนเซอร์แต่ไม่มีค่า อาจเป็นเรื่อง state topic, payload หรือการตีความข้อมูล ขณะที่ถ้าส่ง state ไปแล้วระบบยังไม่รู้จักรายการ ก็ต้องดู discovery กับการตั้ง integration ตามขอบเขตที่ใช้

ชื่อ prefix กับรูปแบบ discovery topic ต้องตรงกับการตั้งค่า ไม่สมมติว่า topic ที่อ่านง่ายสำหรับคนจะถูก Home Assistant ตีความเป็น configuration เองทั้งหมด ควรเริ่มจากรูปแบบในเอกสารของ component ที่ต้องการแล้วตรวจด้วยข้อมูลหนึ่งค่าให้ครบเส้นทางก่อน

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

ตัวตนที่คงที่ช่วยให้เปลี่ยนชื่อได้โดยไม่สร้างซ้ำ

ชื่อที่คนเห็นกับรหัสที่ใช้ระบุรายการมีหน้าที่ต่างกัน ชื่ออาจเปลี่ยนจากห้องทำงานเป็นห้องประชุมได้ แต่ถ้าเปลี่ยนรหัสทุกครั้งที่แก้คำแสดงผล ระบบก็อาจมองเป็นรายการใหม่ตามความหมายของ configuration นั้น

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

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

ส่วน entity ID ที่คนใช้ใน automation ก็ไม่ควรถูกถือว่าเท่ากับ unique ID ทุกกรณี ต้องดูวิธีที่ระบบจัดเก็บและให้แก้ชื่อจริง หากกำลังย้าย configuration ควรตรวจผลต่อสิ่งที่อ้างรายการเดิม ไม่ใช้การเห็นชื่อบนหน้าเป็นหลักฐานเพียงอย่างเดียวว่าสัญญาทั้งหมดคงเดิม

เริ่มระบบใหม่แล้วต้องได้ configuration กลับอย่างไร

Home Assistant หรือ broker อาจเริ่มใหม่ระหว่างที่อุปกรณ์ยังทำงานอยู่ เราจึงต้องเลือกวิธีให้ข้อมูล discovery กลับมาถึงตามกลไกที่ใช้ เช่น retained configuration หรือการตอบสนองต่อข้อความเริ่มต้นของระบบตามเอกสาร ไม่สมมติว่าส่งครั้งเดียวตอนไฟเข้าบอร์ดแล้วทุกฝ่ายจะจำตลอดไป

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

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

availability กับค่าล่าสุดบอกคนละอย่าง

อุปกรณ์อาจมี retained state จากก่อนหลุดอยู่ แม้ตอนนี้ไม่ได้ติดต่อแล้ว หากหน้าจอแสดงเพียงตัวเลขล่าสุด คนดูอาจเข้าใจว่าเซนเซอร์ยังรายงานสด จึงควรจัด availability กับอายุข้อมูลตามหน้าที่ที่ต้องการ

กลไก birth, will และ availability ต้องตั้งให้ตรงกับวงจรชีวิตจริง ไม่ให้โหมดหลับที่ออกแบบไว้ถูกมองเป็นปัญหาเสมอไป หรือให้ข้อความออนไลน์ค้างเป็นหลักฐานว่าหัววัดอ่านสำเร็จทุกครั้ง ควรแยกสถานะการเชื่อมต่อกับสถานะการวัดให้ชัดตามข้อมูลที่มี

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

ย้ายหรือถอดรายการต้องทำตาม lifecycle

หากเปลี่ยน firmware แล้วรูปแบบการประกาศเปลี่ยน ควรวางช่วงย้ายและวิธีล้าง discovery เดิมตามรูปแบบที่รองรับ ไม่เริ่มสร้างรหัสใหม่เพื่อหลบปัญหาโดยปล่อยรายการเดิมไว้ เพราะ automation กับประวัติอาจยังอ้างสิ่งเหล่านั้นอยู่

เมื่อเลิกใช้ entity ให้จัดการ payload configuration และ retained ที่เกี่ยวข้องตามขั้นตอน พร้อมตรวจว่ารายการและการอ้างอิงในระบบเปลี่ยนอย่างที่ตั้งใจ การล้าง state topic อย่างเดียวอาจไม่เท่ากับลบ configuration ที่สร้าง entity

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

ลองเก็บรายการก่อนและหลัง reboot หรืออัปเดตในชุดทดสอบด้วย ว่าจำนวน entity, unique ID และการจับกลุ่ม device ยังตรงเดิมหรือไม่ หากมีรายการเพิ่มโดยไม่ตั้งใจ เราจะมี payload สองช่วงให้เทียบ แทนการแก้ด้วยการลบทุกอย่างจากหน้าใช้งานแล้วเริ่มใหม่โดยไม่รู้เหตุ

สรุป

MQTT discovery ช่วยลดงานสร้างรายการ แต่ต้องออกแบบ configuration, state และตัวตนให้ทำงานด้วยกัน เมื่อเลือก ID ที่คงที่ จัด availability และมีวิธีย้ายหรือล้างข้อความเดิม เราจะเพิ่มอุปกรณ์ได้โดยไม่สร้างรายการซ้ำตามการบูตหรือเปลี่ยน firmware และยังตามความสัมพันธ์ของข้อมูลเดิมได้ครับ