ข้อมูลจากเซนเซอร์หนึ่งจุดอาจเดินทางผ่านหลายขั้นก่อนขึ้นกราฟ เริ่มจากบอร์ดอ่านค่า เก็บไว้ในคิว ส่งผ่านเครือข่าย แล้วให้บริการหลังบ้านบันทึกลงฐานข้อมูล ถ้าเครือข่ายปกติแต่ละขั้นเกิดตามกันค่อนข้างเร็ว เราอาจยังไม่รู้สึกว่าต้องแยกเวลาของแต่ละช่วง
แต่เมื่อบอร์ดขาดการเชื่อมต่อแล้วค่อยส่งข้อมูลเก่ากลับมา เวลาที่ server รับเข้ากับเวลาที่วัดจริงจะต่างกันมากขึ้น หากนำเวลารับมาเป็นเวลาของทุกตัวอย่าง กราฟอาจดูเหมือนอุณหภูมิเปลี่ยนหลายครั้งตอนเน็ตกลับมา ทั้งที่เป็นสิ่งที่เกิดก่อนหน้านั้น
จึงควรตกลงความหมายของเวลาก่อนเก็บข้อมูลครับ และต้องดูด้วยว่าบอร์ดมีเวลาที่เชื่อถือได้แล้วหรือยัง เพราะ field ที่ชื่อ timestamp อาจดูครบรูปแบบ แต่ยังแทนเวลาจริงไม่ได้ถ้านาฬิกายังไม่พร้อม
เวลาที่วัดหรือ event time ช่วยบอกว่าตัวอย่างนั้นอธิบายสภาพแวดล้อมช่วงไหน ส่วน ingest time บอกว่าข้อมูลเข้าระบบเก็บเมื่อไร ความต่างระหว่างสองค่าเป็นข้อมูลเกี่ยวกับเส้นทางส่ง ไม่ควรถูกซ่อนไว้ด้วยการเลือกเก็บเพียงค่าที่เห็นง่ายกว่า
ลองสมมติบอร์ดวัดค่าระหว่างเครือข่ายหลุดแล้วเก็บไว้หลายรายการ เมื่อส่งสำเร็จภายหลัง server อาจรับข้อมูลทั้งหมดในช่วงใกล้กัน หากยังมีเวลาวัดเดิมที่เชื่อถือได้ ก็สามารถนำข้อมูลไปวางตามเหตุการณ์ได้ และยังเก็บเวลารับเพื่อดูว่ามาช้าเท่าไร
แต่ถ้าบอร์ดไม่มีเวลาจริงขณะวัด การใส่เวลาที่ส่งสำเร็จแทนโดยไม่บอกชนิดเวลาก็ทำให้ข้อมูลดูแน่นอนเกินกว่าหลักฐาน ทางเลือกที่ตรงกว่าคือเก็บลำดับกับเวลานับภายใน และระบุว่าเวลาปฏิทินยังไม่ยืนยัน แทนการสร้างค่าที่ดูเหมือนวัดตรงเวลานั้นจริง
การใช้งานแต่ละแบบอาจยอมรับข้อมูลช้าไม่เท่ากัน กราฟย้อนหลังอาจยังใช้ประโยชน์จากตัวอย่างเก่าได้ ส่วน automation ที่กำลังตัดสินใจจากสภาพปัจจุบันควรตรวจอายุข้อมูลก่อน การมาถึงใหม่จึงไม่ได้ทำให้ข้อมูลเก่ากลายเป็นสภาพล่าสุดของห้องโดยอัตโนมัติ
เวลาปฏิทินต้องอ้างอิงกับแหล่งเวลาที่ระบบเลือก เช่น การ sync ผ่าน SNTP และอาจถูกปรับเมื่อได้รับข้อมูลใหม่ บน ESP-IDF มีทั้งการปรับทันทีและการปรับแบบค่อยๆ ลดความต่างตามเงื่อนไขที่กำหนด จึงไม่ควรสมมติว่าค่า wall clock จะเดินต่อเนื่องแบบไม่มีการเปลี่ยนตลอดการทำงาน
ถ้าต้องวัดว่าการอ่านเซนเซอร์ใช้เวลานานเท่าไร หรือผ่านมานานแค่ไหนหลังเริ่มงาน การใช้ตัวนับช่วงเวลาที่เหมาะสมจะตรงหน้าที่กว่า แล้วค่อยใช้เวลาปฏิทินสำหรับอ้างเหตุการณ์กับโลกภายนอก การเอา wall clock สองค่ามาลบกันโดยไม่คิดถึงการปรับเวลาอาจให้ผลที่อ่านผิดได้
สำหรับ ESP-IDF ฟังก์ชัน esp_timer_get_time ใช้ดูเวลานับตั้งแต่ ESP Timer เริ่มทำงาน และไม่ได้มี timezone แต่ตัวนับนี้เริ่มใหม่หลังตื่นจาก deep sleep ตามพฤติกรรมที่เอกสารระบุ จึงไม่ได้ใช้แทนเวลาต่อเนื่องข้ามทุกรอบตื่นได้โดยไม่เก็บบริบทเพิ่ม
ถ้าแต่ละรอบมี boot ID หรือตัวระบุช่วงเริ่มทำงาน พร้อมลำดับตัวอย่างภายในรอบ จะช่วยแยกค่าตัวนับที่เริ่มจากศูนย์ใหม่ได้ ส่วนการแปลงกลับเป็นเวลาปฏิทินต้องมีจุดอ้างอิงที่เชื่อถือได้และยอมรับข้อจำกัดของความคลาดเคลื่อน ไม่ควรแปลงแล้วลืมว่าต้นทางเป็นเพียงค่าประมาณ
รูปแบบ payload อาจมีเวลาวัด สถานะการ sync และลำดับข้อมูลแยกกัน ตัวอย่างสมมติด้านล่างใช้ null เพื่อแสดงว่ายังไม่มีเวลาปฏิทินที่ยืนยัน ไม่ใช้ค่าเริ่มต้นที่หน้าตาเหมือนวันจริงแทนข้อมูลที่ขาด
{
"device_id": "room-sensor-a",
"boot_id": "boot-example-a",
"sequence": 42,
"sampled_at": null,
"uptime_ms": 12000,
"time_quality": "unsynchronized",
"temperature_c": 25.4
}
ชื่อ field และค่าต่างๆ ในตัวอย่างเป็นข้อตกลงระดับแอป ไม่ใช่ field ที่ MQTT กำหนดให้โดยอัตโนมัติ หน่วยของ uptime ก็ควรระบุชัด เพราะการสลับระหว่างวินาทีกับมิลลิวินาทีสามารถทำให้ข้อมูลผิดช่วงได้มาก แม้ค่าจะเป็นตัวเลขที่อ่านผ่าน parser เหมือนกัน
เมื่อ sync สำเร็จแล้ว ควรระบุเวลาวัดตามรูปแบบที่กำหนด เช่น UTC ที่มีเขตเวลาชัดเจน ส่วนการแสดงผลเป็นเวลาท้องถิ่นค่อยทำตามหน้าจอ ไม่เก็บเวลาโดยไม่มี timezone แล้วหวังว่าทุกระบบจะตีความตรงกัน
สถานะ synced ก็ยังควรมีขอบเขต เช่น sync ล่าสุดนานเท่าไร และอุปกรณ์ผ่านการปิดไฟหรือเปลี่ยนช่วงการทำงานมาหรือยัง การเคย sync สำเร็จครั้งหนึ่งไม่ได้รับรองว่าตัวอย่างทุกชิ้นหลังจากนั้นมีความแม่นเวลาเท่ากันตลอดอายุอุปกรณ์
ฝั่งเก็บข้อมูลอาจรับทุกตัวอย่างที่ตรวจรูปแบบผ่านไว้สำหรับประวัติ แต่ขั้นเลือกสถานะล่าสุดต้องเทียบตามความหมายของเวลาและลำดับด้วย ไม่ใช้ข้อความที่มาถึงทีหลังเขียนทับทุกอย่างเสมอ เพราะอาจเป็นข้อมูลจากคิวเก่าที่เพิ่งส่งถึง
หากข้อมูลจากคนละ boot เปรียบเทียบ sequence ตรงๆ ไม่ได้ ก็ต้องใช้บริบทของช่วงการทำงานร่วมกัน และเมื่อเวลาวัดยังไม่เชื่อถือ ควรมีนโยบายว่าจะแสดงเป็นข้อมูลรอยืนยัน แยกออกจากข้อมูลสด หรือใช้เวลารับพร้อมบอกข้อจำกัดอย่างไร
เรื่องเดียวกันนี้มีผลกับการตรวจข้อมูลซ้ำ รหัสตัวอย่างที่อิง device ID, boot ID และ sequence สามารถช่วยอ้างถึงรายการเดิมได้ แต่ต้องกำหนดไม่ให้รหัสช่วงเริ่มงานชนกันง่าย และไม่ใช้เวลาปฏิทินเพียงอย่างเดียวเป็นตัวรับรองความไม่ซ้ำในช่วงที่นาฬิกาอาจถูกปรับ
สำหรับ automation ควรตรวจทั้งคุณภาพเวลาและเงื่อนไขความสดที่งานต้องใช้ เช่น ระบบยอมสั่งจากค่าที่เก่าขนาดใด และทำอะไรเมื่อข้อมูลล่าสุดไม่พร้อม คำตอบขึ้นอยู่กับผลของการสั่งงาน ไม่ควรเลือกเกณฑ์เดียวให้ทุกอุปกรณ์โดยไม่มีเหตุผลจากงานจริง
เริ่มทดสอบจากการเปิดบอร์ดโดยยังไม่มีเครือข่าย ให้เก็บข้อมูลก่อน sync แล้วค่อยเชื่อมต่อ จากนั้นตรวจว่าข้อมูลช่วงแรกถูกติดป้ายอย่างไร และข้อมูลช่วงหลังมีเวลาที่สัมพันธ์กับลำดับจริงหรือไม่
อีกกรณีคือมีข้อมูลค้างแล้วรีบูต หรือตื่นจาก deep sleep ก่อนส่งหมด ควรดูว่า boot ID กับ sequence ยังตามข้อมูลเดิมได้หรือไม่ และการส่งคิวเก่าทำให้หน้าสถานะล่าสุดย้อนกลับไปใช้ค่าเก่าหรือเปล่า
หากต้องรายงานความแม่นยำของเวลา ต้องมีแหล่งอ้างอิงและวิธีวัดจริงประกอบ แค่การ sync ผ่านไม่ใช่ผลวัดว่าแม่นในระดับใด บทนี้จึงมุ่งที่ความหมายของ field และวิธีตามข้อมูล เพื่อให้พร้อมวัดโดยไม่สรุปความแม่นจากชื่อ API
เวลาของข้อมูลเซนเซอร์ควรบอกได้ทั้งเหตุการณ์เกิดเมื่อไร ข้อมูลมาถึงเมื่อไร และนาฬิกาต้นทางเชื่อถือได้แค่ไหน เมื่อแยกเวลาปฏิทิน ตัวนับช่วงเวลา และลำดับข้ามรอบทำงานไว้ชัด เราก็จะจัดกราฟย้อนหลังกับการใช้ข้อมูลสดได้ตามหน้าที่ โดยไม่เปลี่ยนความล่าช้าของเครือข่ายให้กลายเป็นเหตุการณ์ที่ดูเหมือนเพิ่งเกิดขึ้น