เวลากดสวิตช์บน dashboard เราคาดหวังว่าจะรู้ว่าอุปกรณ์เปิดหรือปิดอยู่ แต่สำหรับระบบที่ส่งคำสั่งผ่าน MQTT สิ่งที่หน้าจอรู้ในแต่ละช่วงอาจต่างกัน บางครั้งรู้เพียงว่าเพิ่งขอให้เปิด บางครั้งได้รับข้อความว่าอุปกรณ์เปลี่ยนแล้ว และบางระบบอาจมีข้อมูลวัดผลจริงเพิ่มมาอีกชั้น
ถ้าทั้งหมดถูกแสดงด้วยคำว่าเปิดเหมือนกัน เราอาจแยกไม่ได้ว่าหน้าจอกำลังคาดตามคำสั่งหรือกำลังแสดงผลตอบกลับ โดยเฉพาะเมื่ออุปกรณ์หลุด ข้อความมาช้า หรือคนกดปุ่มที่ตัวอุปกรณ์เองนอกเส้นทางของ dashboard
ก่อนเลือกวิธีแสดงผลจึงควรระบุว่าแต่ละสถานะยืนยันถึงขั้นไหนครับ แล้วจัดเส้นทาง command, state และ availability ให้มีความหมายแยกกัน
ใน MQTT Switch ของ Home Assistant command_topic เป็นทางส่งคำขอเปลี่ยนสถานะไปยังอุปกรณ์ ส่วน state_topic ใช้รับข้อความสถานะกลับมา การแยกนี้ช่วยให้หน้าจอไม่จำเป็นต้องถือว่าคำสั่งที่ส่งออกกลายเป็นผลเรียบร้อยแล้วทันที
แต่ต้องดูว่า firmware ตีความคำสั่งอย่างไร เช่น ค่าตั้งให้เป็นเปิดกับคำสั่ง toggle มีความหมายต่างกันเมื่อส่งซ้ำ และ payload ที่ใช้กับ switch ก็ต้องตรงกับกติกาของทั้งสองฝั่ง ไม่เดาความหมายจากชื่อ topic เพียงอย่างเดียว
ถ้าคำขอส่งไม่ผ่านหรือยังไม่รู้ผล ควรเก็บสถานะตามขั้นที่ยืนยันได้ ไม่เปลี่ยนข้อมูลวัดของอุปกรณ์ให้ตรงกับความต้องการของหน้าจอเพื่อทำให้ดูสำเร็จ เพราะจะทำให้ทางตรวจปัญหาขาดข้อมูลตั้งแต่จุดต้นทาง
เมื่อไม่มี state_topic เอกสาร Home Assistant ระบุว่า switch ใช้ optimistic mode ซึ่งเปลี่ยนสถานะตามคำสั่งทันที และยังสามารถกำหนดให้ใช้โหมดนี้แม้มี state_topic ได้ตามตัวเลือกที่รองรับ
พฤติกรรมนี้อาจเหมาะกับอุปกรณ์ที่ไม่มีทางรายงานสถานะ แต่คนดูต้องเข้าใจว่าข้อมูลกำลังอิงสิ่งที่ระบบสั่ง ไม่ใช่หลักฐานล่าสุดจากอุปกรณ์ การที่การ์ดเปลี่ยนสีเร็วขึ้นจึงไม่ควรถูกใช้วัดว่าอุปกรณ์ตอบสนองเสร็จเร็วเท่ากัน
หากมี state_topic และไม่ได้บังคับ optimistic ฝั่ง switch จะรอข้อความยืนยันตามที่ integration ใช้ แต่ก็ยังต้องรู้ความหมายของข้อความนั้นต่อ ไม่หยุดตรวจเพียงเพราะเปลี่ยนจากโหมดคาดตามคำสั่งไปเป็นโหมดรับ feedback แล้ว
Firmware อาจรายงานค่า output ที่มันตั้งไว้ หรืออาจอ่านสถานะจากส่วนอื่นก่อนรายงานก็ได้ สองแบบนี้มีหลักฐานต่างกัน ควรนิยามว่า ON ใน payload หมายถึงตั้งค่าขาควบคุมแล้ว หรือมีข้อมูลยืนยันผลตามที่งานต้องใช้
อย่างการสั่งเปิดไฟ ค่าในโปรแกรมกับการที่แสงเกิดขึ้นจริงไม่ใช่หลักฐานชนิดเดียวกัน หากงานต้องรู้ผลทางกายภาพ ก็ต้องมีแหล่งข้อมูลที่ตรวจผลนั้นได้ตามการออกแบบ ไม่ใช้ข้อความที่ส่งจากตัวแปรคำสั่งมาสวมว่าเป็นค่าจากเซนเซอร์ตรวจผล
MQTT เป็นทางนำส่งข้อความ และกลไกยืนยันการรับในระดับโปรโตคอลก็มีขอบเขตของมัน การได้ acknowledgement ของการนำส่งจึงไม่ใช่คำรับรองของทุกการทำงานหลังรับ payload ต้องแยกหลักฐานระดับข้อความออกจากระดับอุปกรณ์และผลจริง
Availability topic ใช้รายงานสภาพพร้อมหรือไม่พร้อมตามกติกาของ integration ซึ่งเป็นอีกคำถามหนึ่งจากอุปกรณ์กำลังเปิดหรือปิดอยู่ อุปกรณ์อาจ online พร้อมรับคำสั่งแต่ตอนนี้ปิดอยู่ หรือเคยรายงานเปิดก่อนการเชื่อมต่อขาดก็ได้
การเห็น online ยังต้องอ่านภายใต้เงื่อนไขที่เลือกว่าตรวจความพร้อมถึงชั้นไหน ไม่ควรให้ความพร้อมเชื่อมต่อไปยืนยันแทนความสดของค่าทุกชนิดที่แสดงบนหน้าจอ หรือใช้ค่าปิดแทน unknown เมื่อยังไม่มีข้อมูลหลังเริ่มระบบ
หากมีหลายแหล่งกำหนด availability ต้องตรวจวิธีรวมผลตามตัวเลือกจริงด้วย ไม่ถือว่าข้อความจากแหล่งหนึ่งทำให้ทุกส่วนพร้อมเหมือนกัน การแสดงเหตุที่ไม่พร้อมช่วยให้ตามได้ว่าควรตรวจอุปกรณ์ การเชื่อมต่อหรือการรับสถานะ
เมื่อสถานะถูกส่งแบบ retained ผู้สมัครรับใหม่อาจได้ค่าที่ broker เก็บไว้ทันที ซึ่งช่วยเติมค่าตั้งต้นหลังเชื่อมต่อ แต่ค่าที่เก็บไม่ได้กลายเป็นการวัดใหม่เพียงเพราะเพิ่งได้รับบน connection ใหม่นั้น
หากงานต้องใช้ความสด ควรมีข้อมูลเวลาหรือวิธีร้องขอสถานะใหม่ที่ทั้งสองฝั่งรองรับ พร้อมกติกาว่าอายุเท่าไรยังใช้ตัดสินได้ ไม่เขียนเวลาวัดเป็นเวลาที่ dashboard เพิ่งรับ retained message ทั้งที่ค่ามาจากก่อนอุปกรณ์หลุด
คำสั่งแบบ retained เป็นอีกการตัดสินใจต่างจากสถานะ retained เพราะข้อความคำสั่งเก่าอาจกลับมาถึงผู้รับเมื่อเชื่อมใหม่ ต้องกำหนดว่าเป็นเป้าหมายคงค้างที่ตั้งใจให้ใช้หรือเป็นเหตุการณ์ที่ไม่ควรเล่นซ้ำ ไม่เปิดตัวเลือกเดียวกันให้ทุก topic เพียงเพื่อให้จำค่าได้
ถ้าคนกดปุ่มบนตัวอุปกรณ์หรือมีระบบอื่นสั่งเปลี่ยน สถานะที่รายงานกลับควรสะท้อนตามขอบเขตเดียวกับที่หน้าจอตั้งใจแสดง ไม่รายงานเฉพาะเมื่อได้รับคำสั่งจาก Home Assistant แล้วปล่อยให้การเปลี่ยนทางอื่นมองไม่เห็น
สำหรับการตามคำสั่งรายครั้ง อาจต้องมีรหัสคำขอกับผลตอบตามกติกาที่ออกแบบเพิ่ม แต่รหัสดังกล่าวไม่ใช่สิ่งที่ทุก MQTT switch รองรับเองโดยอัตโนมัติ และยังต้องมีทางอ่านสถานะปัจจุบันเมื่อคำตอบของคำสั่งหนึ่งขาดไป
ชุดตรวจควรแยกทั้งการกดปกติ อุปกรณ์ไม่พร้อม state มาช้า การเปลี่ยนที่ตัวอุปกรณ์และการกลับมาได้รับ retained state แล้วดูว่าหน้าจอใช้ถ้อยคำตรงกับหลักฐานที่มีหรือไม่ ไม่ให้สถานะคาดตามคำสั่งถูกนับเป็นผลยืนยันของการทดลอง
การส่งคำสั่ง การรายงานสถานะ ความพร้อมและผลทางกายภาพเป็นหลักฐานคนละชั้น เมื่อกำหนดความหมายของ payload กับความสดให้ชัด แล้วเลือก optimistic หรือ feedback ตามสิ่งที่อุปกรณ์ทำได้ เราจะอ่านสวิตช์บน dashboard ได้ตรงขึ้น พร้อมรู้ว่าส่วนใดยังรอการยืนยันแทนการถือว่าทุกอย่างเสร็จจากการส่ง MQTT ผ่านเพียงครั้งเดียว