ตอนสร้าง automation ใน Home Assistant เรามักลองกดให้ action ทำงานก่อน เพื่อดูว่าเลือกอุปกรณ์ถูกหรือยัง ถ้าหลอดไฟติดตามคำสั่ง ก็พอรู้ว่าเส้นทางสั่งไฟทำงานได้ในจังหวะนั้น แต่เมื่อปล่อยให้ระบบทำเอง กลับไม่มีอะไรเกิดขึ้นตามที่คาด
จุดที่ยังไม่ได้ตรวจอาจอยู่ก่อน action เช่น trigger ไม่เคยเกิด เงื่อนไขไม่ผ่าน หรือข้อมูลที่มีเฉพาะตอน trigger จริงไม่ได้ถูกส่งมาเหมือนตอนลองด้วยมือ การเห็นปลายทางทำงานได้จึงยังไม่ได้ยืนยันว่าทั้งเส้นทางพร้อมแล้ว
วิธีตามที่ช่วยได้คือแยกว่ากำลังทดสอบส่วนไหนครับ แล้วใช้ trace ของรอบที่เกี่ยวข้องดูว่า automation เดินมาถึงขั้นใด ไม่เริ่มจากเปลี่ยนทุกเงื่อนไขให้ผ่านโดยยังไม่รู้ว่าส่วนใดเป็นเหตุให้หยุด
Trigger ใช้บอกจังหวะเริ่ม automation เช่น ประตูเปลี่ยนเป็นเปิด หรือค่าข้าม threshold ส่วน condition ใช้ตรวจว่าตอนนั้นควรอนุญาตให้ทำต่อหรือไม่ เช่น อยู่ในช่วงเวลาที่กำหนดหรือโหมดอัตโนมัติยังเปิดอยู่
ความต่างนี้ทำให้การตั้งเงื่อนไขเป็นจริงค้างไว้ไม่ได้แปลว่าจะมีการเริ่มใหม่ทุกครั้งเอง ตัวอย่างประตูที่เปิดอยู่แล้วตั้งแต่ก่อนเปิด automation อาจยังไม่มีเหตุการณ์เปลี่ยนจากปิดเป็นเปิดให้ trigger ที่ตั้งไว้ใช้เริ่ม ต้องตรวจชนิด trigger กับพฤติกรรมที่ต้องการจริง
ถ้างานต้องประเมินสภาพที่มีอยู่ตอน Home Assistant เริ่มด้วย ก็ควรกำหนดเส้นทางสำหรับเหตุการณ์นั้นตามการออกแบบ ไม่สมมติว่า trigger ทุกแบบจะย้อนประเมินสถานะเดิมเหมือนกัน และต้องคำนึงว่า entity บางตัวยังโหลดไม่พร้อมในช่วงเริ่มระบบด้วย
การมีหลาย trigger ยังควรรู้ว่าอันใดเป็นผู้เริ่มรอบนั้น โดยเฉพาะเมื่อ action เลือกทำต่างกันตาม trigger ID การตามเพียงเวลาใกล้เคียงกับที่กดอุปกรณ์อาจยังไม่พอ ถ้ามีอีก trigger เริ่มงานซ้อนอยู่ด้วย
การใช้ Run actions ตามรูปแบบที่เอกสารอธิบายจะเรียกชุด action โดยไม่ใช้ trigger data และข้าม condition ระดับบนของ automation แต่ condition ที่อยู่ภายในลำดับ action ยังมีผลตามจุดนั้นอยู่ จึงควรแยกสองตำแหน่งนี้เมื่ออ่านผล
ถ้าระบบมีเงื่อนไขว่าทำเฉพาะตอนกลางคืน การกด Run actions แล้วไฟติดในตอนกลางวันจึงยังไม่ใช่หลักฐานว่า condition ทำงานผิด เพราะเราอาจกำลังทดสอบเส้นทางที่ตั้งใจข้ามมันอยู่ ต้องใช้วิธีเรียกที่ตรวจเงื่อนไขด้วยหรือรอ trigger จริงตามกรณี
อีกตัวอย่างคือข้อความที่ใช้ trigger.to_state หรือ action ที่เลือกตาม trigger ID เมื่อไม่มี trigger data ผลอาจไม่เหมือนรอบจริง หาก template ล้มเหลวในกรณีนี้ ต้องตรวจว่ากำลังขอข้อมูลที่วิธีทดสอบไม่ได้ให้มา ไม่รีบแก้ template ด้วยค่าเริ่มต้นจนซ่อนปัญหาของรอบปกติไปด้วย
การลองด้วยมือยังมีประโยชน์สำหรับตรวจอุปกรณ์กับลำดับ action เพียงต้องบอกขอบเขตให้ถูกว่าอะไรผ่านแล้ว ส่วน trigger และเงื่อนไขใดยังต้องตรวจอีก ไม่ใช้คำว่าทดสอบผ่านอันเดียวครอบทั้ง automation
Trace ช่วยดูว่ารอบนั้นเริ่มจากอะไร เงื่อนไขให้ผลอย่างไร และ action ใดถูกทำหรือหยุด จึงควรเริ่มจากเลือกรอบที่ตรงเวลากับอาการก่อน หากเปิดรอบ manual ล่าสุดอยู่แต่กำลังตามรอบอัตโนมัติก่อนหน้า เราอาจกำลังอ่านหลักฐานคนละเหตุการณ์
ถ้าไม่มีรอบใหม่เลย ให้ดูว่า automation เปิดใช้อยู่หรือไม่ มีเหตุการณ์ที่ตรง trigger เกิดจริงหรือยัง และ entity ที่เลือกเป็นตัวที่เปลี่ยนจริงหรือเปล่า การที่ action สั่งอุปกรณ์ได้ยังไม่ได้พิสูจน์ว่า trigger กำลังฟัง entity ถูกตัว
ถ้ามีรอบแต่หยุดที่ condition ให้ดูค่าจริงที่ใช้ตรวจในขณะนั้น รวมถึงหน่วย เวลา และสถานะ unknown หรือ unavailable ไม่ดูแค่ค่าที่หน้าจอแสดงภายหลัง เพราะสภาพบ้านอาจเปลี่ยนไปแล้วเมื่อเราเปิดมาตรวจ
ส่วนรอบที่เดินถึง action แล้วต้องดูผลจากบริการหรือ integration ที่รับคำสั่งต่อด้วย การมีบรรทัดเรียก action ใน trace เป็นหลักฐานว่าระบบพยายามทำขั้นนั้น แต่การยืนยันอุปกรณ์เปลี่ยนจริงอาจต้องดู state ที่รายงานกลับหรือผลที่เหมาะกับอุปกรณ์เพิ่ม
Trigger บางแบบมีระยะที่ต้องค้างอยู่ในเงื่อนไขก่อนเริ่ม หากค่าหลุดออกจากช่วงหรือเปลี่ยน state ไปก่อนครบ ก็อาจยังไม่มีการทำงานตามที่คาด ต้องดูประวัติของช่วงนั้น ไม่ตรวจจากค่าสุดท้ายเพียงตัวเดียว
การ reload หรือ restart ก็อาจมีผลกับช่วงรอของ trigger ตามชนิดที่ใช้ จึงควรอ่านข้อกำหนดของ for หรือกลไกรอในเอกสาร แล้วเลือกวิธีที่รักษาความหมายของเวลาตามงาน ไม่ถือว่าระยะที่กำลังนับจะคงอยู่ข้ามทุกเหตุการณ์โดยอัตโนมัติ
หากระบบทำซ้ำมากกว่าที่คาด ต้องดูชนิดการเปลี่ยน state และ attributes ที่ trigger ติดตามด้วย รวมถึงอาจมี automation อีกตัวสั่งอุปกรณ์เดียวกัน การเปลี่ยน threshold ของตัวหนึ่งอาจยังไม่แก้เหตุการณ์จากอีกตัวที่ทำงานอยู่
ส่วนกรณีรอบใหม่มาระหว่างรอบเดิมยังทำอยู่ ต้องตรวจ mode ของ automation ตามงาน เช่น ยอมให้ซ้อน รอคิว หรือแทนรอบเก่า การที่ trigger เกิดไม่ได้แปลว่าระบบจะเริ่ม action ชุดใหม่แบบเดียวกันในทุก mode
เริ่มจากอุปกรณ์หรือ entity ทดสอบที่แยกจากการใช้งานในบ้านจริง แล้วแบ่งการตรวจเป็นส่วนที่ตรวจ action ส่วนที่ตรวจ condition และส่วนที่ใช้เหตุการณ์ trigger ที่ตรงเงื่อนไข โดยบันทึกว่ารอบใดใช้วิธีเรียกแบบไหน
ควรมีกรณีที่ condition ต้องไม่ผ่านด้วย เพื่อให้รู้ว่าไฟไม่ถูกสั่งเมื่ออยู่นอกขอบเขตที่ตั้งใจ เช่น ปิดโหมดอัตโนมัติหรือข้อมูลเซนเซอร์ไม่พร้อม การที่ทุกกรณีเปิดไฟสำเร็จไม่ได้แปลว่ากฎควบคุมทำงานถูกต้องเสมอไป
ถ้าใช้เครื่องมือจำลอง trigger ต้องตรวจว่าความสามารถนั้นมีในรุ่นที่ใช้อยู่และข้อมูลที่ป้อนเหมือนรูปแบบจริง ส่วนการเปลี่ยน state เพื่อทดสอบต้องรู้ด้วยว่าเป็นเพียงสถานะในระบบหรือส่งผลถึงอุปกรณ์ภายนอก ไม่กดทดสอบกับสิ่งที่มีผลกระทบโดยไม่ได้จัดขอบเขตก่อน
หลักฐานควรมี configuration ที่ใช้จริง เวลา รหัสรอบ และผลของแต่ละจุด โดยไม่คัดลอกข้อมูลส่วนตัวของบ้านเกินที่ต้องใช้ เมื่อตามสาเหตุได้แล้ว เปลี่ยนเพียงส่วนที่เกี่ยวข้องและตรวจกรณีเดิมซ้ำ จะรู้ว่าการแก้นั้นตอบอาการที่พบจริง
การกด Run actions ช่วยตรวจชุดคำสั่ง แต่ยังต้องแยก trigger เงื่อนไข และข้อมูลของรอบจริงออกมาตรวจด้วย เมื่อใช้ trace ตามเหตุการณ์ที่ถูกต้องและทดสอบทั้งทางที่ควรทำกับทางที่ควรหยุด เราจะรู้ว่า automation ทำงานเองได้ตามกติกาใด และแก้ปัญหาได้จากจุดที่เส้นทางหยุดจริง