อุปกรณ์ IoT ต้องตอบเรื่องเวลาอยู่หลายแบบ ทั้งอ่านเซนเซอร์เมื่อไร รอคำตอบมานานแค่ไหน และเหตุการณ์นี้ควรแสดงบน dashboard เป็นวันใด แม้ทั้งหมดเรียกว่าเวลา แต่ไม่ได้ใช้ฐานเดียวกันได้เหมาะกับทุกคำถาม
หากเอาเวลาปฏิทินมาลบเพื่อทำ timeout พอระบบ sync นาฬิกา ค่าระยะที่คำนวณก็อาจเปลี่ยนตามการแก้เวลา ส่วนตัวนับตั้งแต่เปิดเครื่องแม้เหมาะกับการวัดช่วงหนึ่ง ก็ไม่ได้บอกวันจริงหรือเทียบข้ามการเปิดเครื่องได้เอง
ควรเริ่มจากแยกเวลาที่ใช้เรียงเหตุการณ์กับเวลาที่ใช้วัดระยะครับ แล้วค่อยกำหนดว่าจะบันทึกอะไรไว้เมื่ออุปกรณ์หลับหรือเริ่มใหม่
System time ที่อ่านผ่านฟังก์ชันอย่าง gettimeofday ใน ESP-IDF ใช้กับการบอกเวลาปัจจุบันตามฐานที่ระบบตั้งไว้ เมื่อมีการซิงก์จากแหล่งเวลาหรือมีการตั้งค่าใหม่ ค่านี้สามารถถูกปรับให้ตรงขึ้นได้
การปรับอาจเป็นแบบเปลี่ยนทันทีหรือค่อยๆ ชดเชยตามโหมดและเงื่อนไขของ SNTP ที่ใช้ จึงไม่ควรถือว่าเลือก smooth แล้วค่าจะไม่มีทางกระโดดในทุกสถานการณ์ ต้องอ่านพฤติกรรมของรุ่นที่ใช้และความต่างเวลาที่เกิดขึ้นด้วย
ช่วงเพิ่งเปิดเครื่องและยังไม่มีเวลาที่เชื่อถือได้ ควรมีสถานะบอกคุณภาพเวลาประกอบข้อมูล ไม่ส่งวันที่เริ่มต้นที่ดูเหมือนเวลาจริงไปปะปนกับข้อมูลที่ sync แล้วโดยไม่แยก หากไม่มีเวลาเหตุการณ์ที่ยืนยันได้ อาจเก็บลำดับหรือเวลาสัมพัทธ์ไว้รอจับคู่ตามสัญญา
Timezone มีบทบาทต่อการแสดงหรือแปลงเวลาให้คนอ่าน แต่ไม่ได้สร้างความแม่นยำให้นาฬิกา การตั้งให้แสดงชั่วโมงตรงประเทศจึงยังไม่รับรองว่าค่าพื้นฐานตรงกับแหล่งเวลาจริงแล้ว
งานรอคำตอบจากอุปกรณ์หรือเครือข่ายมักถามว่าผ่านไปนานเท่าไร ไม่ได้ถามว่าปฏิทินตอนนี้แสดงกี่โมง ฐานที่ใช้วัดระยะโดยไม่ถูกการตั้งวันที่เปลี่ยนตามจึงเหมาะให้พิจารณาตามวงจรชีวิตของมัน
ESP-IDF มี esp_timer_get_time ซึ่งคืนเวลาหน่วยไมโครวินาทีตั้งแต่การเริ่ม ESP Timer ก่อน app_main และไม่มีการตั้ง timezone หรือ daylight saving มาปรับค่าชุดนั้น เราจึงแยกมันออกจาก system time ที่ใช้บอกวันได้
ตัวอย่างเชิงแนวคิดคือเก็บค่าจุดเริ่มกับค่าปัจจุบันจากฐานเดียวกัน แล้วเทียบระยะกับ timeout ที่กำหนด ไม่เก็บจุดเริ่มจาก system time แต่เอาจุดจบจาก uptime เพราะแม้หน่วยดูเหมือนวินาทีเหมือนกัน จุดอ้างอิงก็ยังต่างกัน
ชนิดข้อมูลกับหน่วยต้องอยู่ในสัญญาให้ชัดด้วย ค่าหน่วยไมโครวินาทีไม่ควรถูกส่งไปหักกับค่ามิลลิวินาทีโดยไม่มีการแปลง และไม่ลดขนาดตัวแปรจนขอบเขตที่เก็บได้สั้นกว่าระยะทำงานจริงโดยไม่รู้ตัว
เมื่อ ESP32 ตื่นจาก deep sleep แอปเริ่มใหม่และ ESP Timer เริ่มนับจากศูนย์ตามพฤติกรรมของระบบ จึงเอาค่า esp_timer_get_time ก่อนหลับที่เก็บไว้ มาลบกับค่าหลังตื่นราวกับเป็นนาฬิกาต่อเนื่องชุดเดิมไม่ได้
ถ้าต้องกู้ deadline ข้ามรอบเริ่ม ต้องกำหนดแหล่งเวลาที่ใช้ต่อได้และข้อมูลอายุของงาน เช่น งานนี้ยังมีผลหรือถูกยกเลิกแล้ว ไม่บันทึกเพียงค่าตัวนับหนึ่งค่าโดยไม่รู้ว่ามันเป็นของ boot ใด
การมี boot identity หรือลำดับรอบช่วยให้ข้อมูลเวลาสัมพัทธ์ไม่ถูกตีความปะปนกัน แต่ไม่ได้บอกเวลาที่ดับอยู่เอง หากต้องรู้ช่วงขาดระหว่างรอบ ต้องมีหลักฐานจากแหล่งที่ยังรักษาเวลาได้ตามฮาร์ดแวร์และการตั้งค่าที่เลือก
ส่วน light sleep มีพฤติกรรมต่างจาก deep sleep ใน ESP Timer โดยระบบชดเชยตัวนับด้วยช่วงที่หลับตามกลไก RTC แล้วกลับมาทำงาน การเลือกฐานจึงต้องดู sleep mode จริง ไม่สรุปว่าใช้คำว่า sleep เหมือนกันแล้วนาฬิกาจะต่อหรือเริ่มใหม่เหมือนกันหมด
สมมติอุปกรณ์ต้องทำงานหลังเวลาหนึ่ง หากเก็บเป็นเวลาปฏิทิน ต้องรู้ว่านาฬิกาพร้อมหรือยังและเมื่อปรับเวลาจะจัดการกำหนดที่ผ่านไปแล้วอย่างไร ส่วนถ้าเก็บเป็นระยะที่เหลือ ต้องรู้ว่าช่วงที่ปิดเครื่องควรถูกนับรวมตามข้อกำหนดหรือไม่
สองแบบนี้ตอบคนละความต้องการ งานที่ต้องหยุดหลังทำงานครบระยะหนึ่งต่างจากงานที่ต้องเริ่มตามเวลานัดของวัน การเปลี่ยนรูปเก็บโดยไม่ถามความหมายอาจทำให้ระบบทำสิ่งที่ถูกตามเลขแต่ผิดตามหน้าที่
ควรบันทึกตัวตนงานและสถานะที่จำเป็นต่อการตรวจซ้ำด้วย เพื่อไม่ให้การฟื้นหลังเริ่มใหม่เรียกงานที่ผู้ใช้ยกเลิกไปแล้ว หรือเรียกผลเดิมซ้ำเพียงเพราะ deadline เก่าถูกอ่านขึ้นมาอีกรอบ
สำหรับงานที่เวลายังไม่พร้อม ควรกำหนดว่าจะรอแหล่งเวลา ใช้พฤติกรรมสำรองที่กำหนดไว้ หรือรายงานว่ายังตัดสินไม่ได้ ไม่เปลี่ยนข้อมูลที่ไม่รู้ให้กลายเป็นวันจริงเพื่อให้เงื่อนไขเดินต่อได้ง่ายขึ้น
API ที่คืนหน่วยละเอียดช่วยให้แทนค่าช่วงสั้นได้ แต่ไม่ได้รับรองว่าแหล่ง clock ไม่มีความคลาดเคลื่อน หรือทุกจังหวะอ่านค่าจะอยู่ตรงเหตุการณ์ทางกายภาพที่สนใจ ความถี่ต้นทางและสภาพการทำงานยังมีผลที่ต้องตรวจจริง
หากใช้ timestamp กับการวัดเซนเซอร์ ต้องระบุว่าเก็บตอนเริ่มอ่าน ตอน conversion จบ หรือตอนรับข้อความที่ task ถัดไปด้วย การใช้ฐานเวลาถูกแต่เลือกจุดเก็บช้าก็ยังตอบผิดว่าอุปกรณ์วัดเมื่อไร
ชุดทดสอบควรครอบคลุมการ sync ไปข้างหน้าและถอยหลัง การเริ่มโดยยังไม่มีเวลา การเข้า light sleep และ deep sleep โดยใช้ข้อมูลทดลองที่ตามลำดับได้ แล้วดูว่าทั้ง timeout กับเวลาที่ส่งออกยังมีความหมายตามงานหรือไม่ ไม่อ้างผลจากการเปิดบอร์ดไว้ช่วงเดียวแทนทุกวงจรชีวิต
ระบุผลที่คาดแยกกันก่อนทดสอบ เช่น การปรับวันไม่ควรทำให้การรอใน boot เดียวสั้นลงเอง ส่วนการกลับจาก deep sleep ต้องเริ่มนโยบายฟื้นงานตามที่กำหนด ไม่เปรียบเทียบตัวนับจากคนละรอบ วิธีนี้ทำให้เห็นว่าเงื่อนไขผิดที่ฐานเวลาหรือผิดที่การกู้สถานะ
เวลาปฏิทินใช้บอกว่าเหตุการณ์อยู่ตรงไหนในโลกภายนอก ส่วนเวลาสัมพัทธ์ช่วยวัดระยะตามขอบเขตที่ตัวนับยังมีผล เมื่อแยกสองหน้าที่พร้อมระบุหน่วย boot และ sleep mode เราจะทำ timeout กับการกู้กำหนดเวลาได้ตรงความหมาย และไม่ให้นาฬิกาที่ถูกปรับพาข้อมูลหรือเงื่อนไขงานเปลี่ยนไปโดยไม่รู้ตัว