ตอนเพิ่มอุปกรณ์ใน Home Assistant เรามักดูว่าค่าปัจจุบันขึ้นครบและใช้กับ automation ได้แล้วหรือยัง แต่เมื่อมีหลาย entity ทำงานไปด้วยกัน ประวัติที่เกิดตามการเปลี่ยนสถานะก็เพิ่มขึ้นเรื่อยๆ ทั้งข้อมูลที่อยากเก็บกับรายละเอียดที่แทบไม่ได้ย้อนกลับไปดู
พื้นที่ฐานข้อมูลจึงไม่ได้ขึ้นกับจำนวนอุปกรณ์อย่างเดียว ยังเกี่ยวกับสิ่งที่แต่ละ entity รายงานและขอบเขตที่เลือกบันทึกด้วย หากรอจนพื้นที่เหลือน้อยแล้วค่อยลดข้อมูล อาจมีพื้นที่ไม่พอสำหรับขั้นดูแลฐานข้อมูลที่ต้องทำตามมาอีก
การวางประวัติควรเริ่มจากคำถามที่จะใช้ตอบครับ ว่าต้องดูเหตุการณ์ย้อนหลังระดับไหน ข้อมูลใดจำเป็นต่อกราฟหรือสถิติ และต้องเก็บสำเนาเพื่อกู้ระบบอย่างไร ไม่รวมทุกอย่างเป็นคำว่าประวัติแล้วตั้งระยะเดียวโดยไม่รู้ผล
Recorder เป็นส่วนที่บันทึกประวัติ state และ event ตามขอบเขตที่กำหนด ข้อมูลนี้ถูกใช้โดยส่วนแสดงย้อนหลังและคุณสมบัติอื่นที่เกี่ยวข้อง ส่วนการเห็นค่าปัจจุบันของ entity ยังเป็นอีกหน้าที่หนึ่งของระบบ
ดังนั้นการตัดบาง entity ออกจากการบันทึกต้องคิดถึงสิ่งที่ต้องย้อนดูภายหลัง ไม่ใช่ตรวจเพียงว่ายังเห็นค่าใน dashboard แล้วถือว่าไม่มีอะไรเปลี่ยน อุปกรณ์นั้นอาจยังทำ automation ได้ แต่คนดูแลเสียหลักฐานของเหตุการณ์ก่อนหน้าไป
ในทางกลับกันการบันทึกทุก entity ตลอดก็ไม่ได้ทำให้การตามปัญหาง่ายขึ้นเสมอไป หากข้อมูลที่เกิดถี่มากกลบสิ่งที่ต้องใช้ ควรเลือกชุดที่ตอบคำถามได้ เช่น สถานะสั่งงานกับเซนเซอร์ที่เป็นเงื่อนไข พร้อมระดับรายละเอียดที่พออธิบายเหตุการณ์
ควรแยกกลุ่มด้วยว่าข้อมูลใดเป็นสถานะเปลี่ยนไม่บ่อย ข้อมูลวัดที่เปลี่ยนต่อเนื่อง และ event ที่ต้องรู้ว่าเกิดขึ้นแต่ละครั้งอย่างไร แล้วค่อยตัดสินระยะเก็บจากความหมาย ไม่ดูเพียงชื่อ domain ว่าเป็น sensor เหมือนกันทั้งหมด
Home Assistant มีข้อมูลสถิติสำหรับ sensor ที่เข้าเงื่อนไขตามชนิดและคุณสมบัติของ entity ซึ่งให้มุมมองรวมของการวัดตามการออกแบบ การมีตัวเลขในหน้าสถิติจึงไม่ได้แปลว่าจะย้อนอ่านทุก state change แบบละเอียดได้ตลอดช่วงเดียวกัน
หากต้องตามเหตุการณ์สั้น เช่น ทำไมไฟจึงเปิดในจังหวะหนึ่ง ประวัติสถานะกับข้อมูลรอบ automation อาจตอบได้ตรงกว่าค่าเฉลี่ย ขณะที่ถ้าจะดูภาพรวมระยะยาว ข้อมูลรวมอาจตรงคำถามโดยไม่ต้องเปิดรายละเอียดทุกการเปลี่ยน
ก่อนลด retention หรือเปลี่ยน filter จึงควรดูว่ากราฟและคุณสมบัติที่ใช้พึ่งข้อมูลชุดไหน และ sensor นั้นรองรับสถิติที่ต้องการจริงหรือไม่ ไม่เติม state_class ตามชื่อที่คุ้นเพียงเพื่อให้ระบบยอมเก็บ เพราะความหมายการวัดสะสมกับค่าขณะหนึ่งต่างกัน
ที่สำคัญ ประวัติกับสถิติยังไม่ใช่ backup สำหรับกู้การติดตั้งทั้งหมด การมีกราฟย้อนหลังไม่ได้เก็บ configuration, credential และส่วนประกอบอื่นที่ระบบต้องใช้เมื่อเครื่องเสีย จึงต้องวางสำรองตามขอบเขตการติดตั้งแยกกัน
Recorder มี include กับ exclude สำหรับกำหนดขอบเขตข้อมูลตามรูปแบบที่รองรับ ควรอ่านลำดับการใช้ filter เมื่อกำหนดหลายอย่างร่วมกัน และทบทวนหลังเพิ่มอุปกรณ์ เพื่อไม่ให้ entity ใหม่ถูกเก็บหรือหายจากประวัติโดยที่คนดูแลไม่รู้
การเริ่มจากรายการ entity ที่ต้องใช้จริงช่วยให้ทบทวนเหตุผลได้ แต่ถ้าเลือกแบบแคบมากก็ต้องมีขั้นเพิ่มรายการเมื่อมีอุปกรณ์ใหม่ ส่วนการใช้ pattern กว้างต้องระวังชื่อที่ภายหลังตรงเงื่อนไขโดยไม่ได้ตั้งใจ ทั้งสองทางมีภาระดูแลต่างกัน
การเปลี่ยน filter ยังควรแยกจากการจัดการข้อมูลที่เก็บไปแล้ว ไม่คิดว่าแก้ config แล้วพื้นที่เก่าจะหายทันที ต้องตรวจวิธี purge และการประยุกต์ filter กับข้อมูลเดิมจากเอกสารรุ่นที่ใช้ก่อนเลือกดำเนินการ
หากข้อมูลรายงานถี่เกินความต้องการ อาจดูการตั้งค่าต้นทางหรือรูปแบบที่ integration ให้ปรับร่วมด้วย แต่ต้องไม่ลดจน automation หรือข้อมูลเหตุการณ์ที่จำเป็นหายไป การเลือกเก็บน้อยลงควรมาจากสิ่งที่งานยอมรับได้ ไม่ใช้พื้นที่เป็นเหตุเดียว
การลบข้อมูลเชิงตรรกะกับขนาดไฟล์ที่ระบบปฏิบัติการเห็นเป็นคนละชั้น ฐานข้อมูลอาจต้องมีขั้นจัดพื้นที่ใหม่ตามชนิดและวิธีที่รองรับ จึงไม่ควรสรุปว่า purge ล้มเหลวจากการที่ไฟล์ยังมีขนาดเท่าเดิมเพียงอย่างเดียว
เอกสาร Recorder ระบุความจำเป็นของพื้นที่ชั่วคราวสำหรับงานอย่าง rebuild, repair หรือ repack และการอัปเกรด schema เพราะขั้นตอนอาจต้องสร้างสำเนาข้อมูลบางส่วนระหว่างทาง จึงควรเผื่อพื้นที่ก่อนเข้าสู่จุดที่ต้องดูแล ไม่รอจนเต็มแล้วสั่งงานหนักเพิ่มทันที
ก่อนใช้ action บำรุงรักษาต้องตรวจฐานข้อมูลและรุ่นที่ใช้จริง พร้อมมีสำรองที่กู้ได้ตามขอบเขตงาน ไม่หยิบคำสั่ง SQL หรือวิธีจัดไฟล์ของอีก engine มาใช้ตามเพียงเพราะชื่อการบำรุงรักษาคล้ายกัน
การลบไฟล์ฐานข้อมูลตรงๆ ก็มีผลต่อประวัติและคุณสมบัติที่เกี่ยวข้อง จึงไม่ควรใช้เป็นวิธีทั่วไปเพื่อให้พื้นที่กลับมาโดยไม่อ่านสถานะกับทางสำรองก่อน หากมีอาการ corruption ต้องแยกการกู้ข้อมูลจากการลด retention ให้ชัด
การประเมินควรเก็บขนาดฐานข้อมูล พื้นที่ว่าง และอัตราการเปลี่ยนในช่วงที่เทียบกันได้ พร้อมบันทึกการเพิ่ม entity หรือเปลี่ยน filter หากไม่ได้เก็บบริบทเหล่านี้ การเห็นไฟล์โตเร็วขึ้นก็ยังไม่ชี้ว่าเป็นปัญหาของ Recorder หรือเกิดจากปริมาณข้อมูลที่เพิ่มตามงาน
เมื่อตรวจผลหลังปรับ ควรเปิดประวัติของ entity สำคัญ กราฟที่ใช้จริง และช่วงที่เกิด automation เพื่อยืนยันว่าข้อมูลที่ตั้งใจรักษายังอยู่ รวมทั้งดูว่างานบำรุงรักษาทำได้ตามสถานะที่ระบบรายงาน
ตัวเลขพื้นที่กับระยะเก็บต้องมาจากการติดตั้งนั้นเอง ตัวอย่างระยะวันใน config ของเอกสารใช้บอกวิธีกำหนดค่า แต่ไม่ได้รับรองว่าทุกบ้านจะใช้พื้นที่เท่ากัน และไม่ควรถูกใช้เป็นผลทดสอบแทนการเก็บข้อมูลจริง
หากมีข้อมูลที่บอกพฤติกรรมคนในบ้าน ประวัติก็ควรถูกจำกัดสิทธิ์กับระยะที่จำเป็นด้วย การสำรองออกไปอีกปลายทางเพิ่มทั้งทางกู้และสำเนาที่ต้องดูแล จึงควรกำหนดเจ้าของข้อมูลกับผู้ที่เข้าถึงไว้พร้อมกัน
การดูแล Recorder เริ่มจากแยกค่าปัจจุบัน ประวัติละเอียด สถิติ และ backup แล้วเลือกเก็บให้ตอบคำถามของบ้าน เมื่อกำหนด filter กับ retention พร้อมเผื่อพื้นที่บำรุงรักษาและตรวจผลจากคุณสมบัติที่ใช้จริง เราจะควบคุมการสะสมได้โดยไม่ตัดหลักฐานที่จำเป็นต่อการใช้งานและการตามปัญหาออกไปโดยไม่ตั้งใจ