เวลาทำ template จากค่าเซนเซอร์ สิ่งที่อยากได้มักเป็นตัวเลขที่นำไปเปรียบเทียบหรือคำนวณต่อได้ แต่ entity ใน Home Assistant ไม่ได้มีค่าตัวเลขพร้อมอยู่ตลอด ตอนอุปกรณ์หลุด integration ยังเริ่มไม่ครบ หรือข้อมูลยังไม่มาถึง เราอาจพบ unknown หรือ unavailable แทน
ทางที่ดูง่ายคือใส่ fallback เป็นศูนย์เพื่อให้คำนวณต่อได้ ทว่าเมื่อผลนั้นถูกนำไปตัดสินใจ ความหมายก็เปลี่ยนจากยังไม่มีข้อมูลเป็นวัดได้ศูนย์ ซึ่งอาจตรงกับเงื่อนไขสั่งงานบางอย่างพอดี ทั้งที่เซนเซอร์ไม่ได้รายงานสภาพนั้นจริง
จึงควรแยกข้อมูลไม่พร้อมออกจากค่าศูนย์ตั้งแต่ก่อนคำนวณครับ แล้วกำหนดว่าหน้าจอ กราฟ และ automation จะรับมือสถานะนี้อย่างไร แทนการแก้ error ของ template ด้วยตัวเลขเดียวแล้วปล่อยให้ทุกส่วนตีความตามไปเอง
unknown บอกว่ายังไม่รู้ค่าของ entity ส่วน unavailable เกี่ยวกับการที่ข้อมูลหรือ entity ไม่พร้อมตามสถานะที่ integration รายงาน และการเรียก entity ที่ไม่มีอยู่ก็มีพฤติกรรมที่ต้องคำนึงถึงด้วย จึงควรใช้ฟังก์ชันอ่านสถานะที่ระบบรองรับและตรวจชื่อ entity ให้ตรง
สิ่งที่มีประโยชน์คือเก็บให้เห็นว่าปัญหามาจากข้อมูลไม่พร้อมหรือค่าที่อ่านได้จริง เช่น กำลังไฟเป็นศูนย์อาจเป็นผลวัดที่ถูกต้องเมื่อตัวเครื่องหยุดใช้ แต่ถ้าตัววัดหลุดแล้วถูกแทนเป็นศูนย์ กราฟจะดูเหมือนตรวจพบว่าหยุดใช้ไปด้วย ทั้งที่ไม่มีหลักฐานการวัดช่วงนั้น
การเก็บสถานะความพร้อมแยกจากค่าช่วยให้คนอ่านเห็นช่องว่าง และช่วยให้ระบบเลือกไม่ตัดสินใจจากช่วงนั้นได้ การทำให้กราฟต่อเนื่องสวยขึ้นด้วยค่าที่แต่งแทนอาจซ่อนปัญหาเครือข่ายหรือทำให้สถิติเปลี่ยนความหมายตามไป
ถ้าจำเป็นต้องประมาณค่าเพื่อการแสดงผลบางอย่าง ก็ควรระบุว่าเป็นค่าประมาณและแยกจากค่าที่ใช้สั่งงาน ไม่ทำให้ผลลัพธ์นั้นย้อนกลับไปดูเหมือนข้อมูลดิบที่เซนเซอร์ส่งมา
ฟังก์ชัน has_value ช่วยตรวจกรณีที่ entity ไม่มีค่าซึ่งใช้ได้ เช่น unknown หรือ unavailable แต่ไม่ได้รับรองว่าค่าที่เหลือทุกอย่างเป็นตัวเลขตามงาน เพราะ sensor บางชนิดตั้งใจเก็บข้อความ และข้อมูลที่ผิดรูปแบบก็ยังต้องมีทางตรวจเพิ่ม
หลังตรวจความพร้อมจึงค่อยแปลงชนิดอย่างมีข้อตกลง และกำหนดผลกรณีแปลงไม่ได้ไว้ ตัวอย่างด้านล่างเป็นข้อความ template สำหรับการแสดงผลสมมติ ไม่ใช่ configuration ของ numeric template sensor ครบชุด และไม่มีตัวเลขวัดจริงอยู่ในตัวอย่าง
{% set raw = states('sensor.room_temperature') %}
{% if has_value('sensor.room_temperature') and is_number(raw) %}
{{ raw | float }}
{% else %}
ข้อมูลไม่พร้อม
{% endif %}
จุดสำคัญคือค่าที่ไม่พร้อมหรือไม่ผ่านการตรวจตัวเลขถูกแยกไปอีกทาง ไม่เปลี่ยนเป็นศูนย์โดยอัตโนมัติ ส่วน entity ที่ประกาศเป็นชนิดตัวเลขต้องใช้รูปแบบ state กับ availability ตามเอกสารของ template integration ไม่ส่งข้อความแจ้งปัญหาเข้า field ที่คาดหวังตัวเลขโดยไม่ตรวจข้อกำหนด
เมื่อเทียบค่าก็ต้องรู้หน่วยและช่วงที่ยอมรับด้วย การแปลงข้อความเป็น float ผ่านไม่ได้ยืนยันว่าค่ามีหน่วยตรงกับ threshold หรืออยู่ในช่วงที่เครื่องวัดรองรับ การตรวจรูปแบบช่วยเริ่มต้น ส่วนความหมายยังเป็นเงื่อนไขของแอป
อีกทางเลือกคือแสดงค่าล่าสุดที่เคยมีแทนช่วงที่ขาด ซึ่งอาจช่วยให้คนเห็นบริบทได้ แต่ควรแสดงอายุหรือสถานะว่าข้อมูลไม่สด ไม่ย้ายเวลาให้ดูเหมือนเพิ่งวัดใหม่ทุกครั้งที่หน้าเว็บอัปเดต
สำหรับ automation ต้องกำหนดว่าจะยอมใช้ค่าเก่านานแค่ไหน หรือพักเมื่อข้อมูลขาดทันทีตามผลของงาน การใช้ค่าที่ค้างโดยไม่รู้ระยะเวลาอาจทำให้สั่งต่อจากสภาพห้องที่เปลี่ยนไปแล้ว แม้ตัวเลขนั้นเคยถูกต้องในอดีตก็ตาม
ข้อมูลที่กลับมาหลังขาดก็ต้องตรวจการเปลี่ยนสถานะกับ trigger ที่ใช้ด้วย โดยเฉพาะเงื่อนไข numeric_state ซึ่งมีความหมายเรื่องการข้าม threshold ไม่ควรสมมติว่าการเปลี่ยนจาก unavailable กลับเป็นตัวเลขจะเหมือนการเคลื่อนผ่านช่วงตัวเลขตามลำดับที่เราจินตนาการไว้ทุกแบบ
หากต้องประเมินใหม่เมื่อข้อมูลกลับมาพร้อม ควรออกแบบเหตุการณ์นั้นและเงื่อนไขให้ชัด พร้อมดูว่ามี action ค้างจากก่อนข้อมูลหายหรือไม่ เพื่อไม่ให้คำสั่งเก่ากลับมาทำภายหลังโดยไม่เทียบสภาพใหม่
หน้าจออาจแสดงข้อมูลไม่พร้อมพร้อมเวลาครั้งล่าสุด ส่วนกราฟอาจเว้นช่วงเพื่อให้เห็นช่องว่าง ขณะที่ automation อาจพักการสั่งบางประเภทและบันทึกเหตุผลไว้ สิ่งที่ควรเหมือนกันคือไม่สร้างผลวัดขึ้นมาเพื่อให้ทุกส่วนทำงานต่อได้เสมอ
การพักไม่ได้แปลว่าต้องปิดอุปกรณ์ทุกครั้ง เพราะบางงานมีผลต่างกันเมื่อหยุดหรือคงสถานะเดิม ต้องกำหนดตามลักษณะอุปกรณ์และความต้องการใช้งานจริง หากมีข้อกำหนดด้านความปลอดภัยเฉพาะ ต้องใช้กลไกที่ออกแบบมาสำหรับงานนั้น ไม่ฝากไว้กับ template กลางเพียงตัวเดียว
ถ้ามีการแจ้งข้อมูลขาด ควรแยกช่วงเริ่มต้นที่คาดไว้จากปัญหาที่นานผิดปกติ และมีวิธีลดข้อความซ้ำโดยยังเห็นว่ายังขาดข้อมูลอยู่ การรายงานความพร้อมจึงควรมีสถานะต่อเนื่อง ไม่สร้างการแจ้งใหม่ทุกครั้งที่ template ถูกประเมิน
สำหรับข้อมูลรวมจากหลาย sensor ต้องเลือกว่าจะคำนวณเฉพาะตัวที่พร้อม แสดงว่าผลไม่ครบ หรือไม่คำนวณเลย การรวมเฉพาะบางส่วนโดยไม่บอกจำนวนที่ขาดอาจทำให้คนอ่านคิดว่าเป็นผลรวมทั้งหมด และนำไปใช้เทียบกับช่วงที่ข้อมูลครบอย่างไม่ตรงความหมาย
เตรียมกรณีตัวเลขปกติ ศูนย์จริง unknown unavailable entity ที่ไม่มี และข้อความที่แปลงเป็นตัวเลขไม่ได้ แล้วดูทั้งผลบนหน้าจอกับเส้นทาง action ที่เกิด ต้องเห็นว่าศูนย์จริงยังถูกรับตามกติกา ไม่ถูกปฏิเสธเพียงเพราะเขียนเงื่อนไขตรวจแบบค่าจริงเท่ากับ true
จากนั้นตรวจช่วงบูต ระบบขาดข้อมูลระหว่างรอ และข้อมูลกลับมาขณะค่าข้าม threshold โดยใช้ entity ทดสอบที่ไม่ไปสั่งอุปกรณ์จริงตรงๆ พร้อมอ่าน trace เพื่อยืนยันว่าหยุดหรือทำต่อด้วยเหตุผลใด
การทดสอบนี้ช่วยตรวจข้อตกลงของข้อมูลกับ automation ไม่ใช่ผลวัดความแม่นยำของเซนเซอร์ หากจะรายงานผลจากการติดตั้งจริง ต้องเก็บเวลา ค่าต้นทาง และสถานะการเชื่อมต่อของชุดนั้นประกอบต่างหาก
ข้อมูลไม่พร้อมต้องมีทางแสดงและทางตัดสินใจของตัวเอง แยกจากค่าศูนย์หรือค่าล่าสุดที่เคยอ่านได้ เมื่อเช็กทั้งความพร้อม ชนิด หน่วย และความสดก่อนส่งต่อ เราจะรักษาความหมายของข้อมูลไว้ได้ และทำให้ automation หยุดหรือกลับมาทำงานจากกติกาที่ตั้งใจ แทนการตัดสินใจจาก fallback ที่ถูกใส่เพื่อให้คำนวณผ่านเท่านั้น