Wi-Fi หลุดแล้ว อย่าให้ทั้งบอร์ดรอเชื่อมต่ออย่างเดียว

ตอนทดลองบนโต๊ะ เราอาจเขียนให้บอร์ดรอเชื่อม Wi-Fi จนสำเร็จก่อนค่อยเริ่มอ่านเซนเซอร์ เพราะถ้าเปิด router อยู่แล้วก็รอไม่นาน และช่วยให้โค้ดช่วงแรกดูตรงไปตรงมา

แต่เมื่อเอาไปใช้นานขึ้น การเชื่อมต่อไม่ได้อยู่ในสภาพเดิมตลอดครับ อาจมีช่วงปิด access point ย้ายชื่อเครือข่าย หรือเชื่อม Wi-Fi ได้แต่ไปถึงบริการปลายทางไม่ได้ ถ้าโปรแกรมกลับเข้าไปรอขั้นเดียวตลอด งานอื่นในบอร์ดก็อาจหยุดตามทั้งที่ยังทำได้

การ reconnect จึงควรถูกมองเป็นส่วนหนึ่งของการทำงานปกติ มากกว่าข้อยกเว้นที่ปล่อยให้ทั้งระบบรอ แอดอยากชวนแยกสถานะเครือข่ายออกมาก่อน แล้วค่อยกำหนดว่าจะลองใหม่เมื่อไรและให้ส่วนอื่นเดินต่ออย่างไร

ต่อกับ access point ได้ ยังไม่เท่ากับส่งข้อมูลได้

การเชื่อมต่อมีหลายขั้น ตั้งแต่พบเครือข่ายและยืนยันตัวตน ไปจนถึงได้ IP แล้วจึงใช้ DNS และช่องทางไปยังบริการที่ต้องการ หากระบบใช้ข้อความเดียวว่าออนไลน์กับทุกช่วง เราก็จะตามปัญหายากเวลาบางขั้นผ่านแต่บางขั้นยังไม่พร้อม

เช่น ถ้าบอร์ดเชื่อมกับ access point และได้ IP แล้ว แต่ broker ไม่ตอบ การตัด Wi-Fi แล้วเชื่อมใหม่ซ้ำทั้งหมดอาจไม่ได้แก้ต้นเหตุ จึงควรแยกสถานะเครือข่ายกับสถานะบริการ เพื่อให้ส่วนที่เกี่ยวข้องลองใหม่ตามขอบเขตของมัน

ใน ESP-IDF มี event ที่บอกการหลุดและการได้ IP ให้ใช้ตาม lifecycle ที่กำหนด งานใน callback ควรสั้นและส่งต่อสถานะให้งานที่รับผิดชอบ ไม่เริ่มวนรอเชื่อมต่อยาวๆ ภายใน callback จนการจัดการ event อื่นติดตามไปด้วย

การตรวจว่าพร้อมส่งข้อมูลควรอิงขั้นที่แอปต้องใช้จริง ส่วนหน้าจออาจแสดงได้ละเอียดขึ้นว่าเครือข่ายพร้อมแต่บริการยังติดต่อไม่ได้ คนดูแลจะได้ไม่ต้องเริ่มจากเปลี่ยนรหัส Wi-Fi ทุกครั้งที่เห็นข้อมูลไม่ขึ้นเว็บ

ให้ส่วนหลักรู้ว่าจะทำอะไรเมื่อเน็ตหาย

งานอ่านเซนเซอร์หรือปุ่มภายในอุปกรณ์อาจยังทำได้ระหว่างเครือข่ายขาด จึงควรจัดให้มีสถานะ offline ที่ชัด ไม่ให้ความล้มเหลวในการส่งแต่ละครั้งกลายเป็นคำสั่งหยุดทุกส่วนโดยปริยาย

สิ่งที่ต้องตัดสินใจคือข้อมูลที่อ่านต่อจะไปอยู่ที่ไหน หากต้องเก็บประวัติ อาจใช้ buffer ที่จำกัดขนาดและมีนโยบายเต็มไว้แล้ว แต่ถ้างานใช้เพียงค่าล่าสุดก็อาจเก็บทับตามความหมายของมัน การ reconnect จึงต้องทำงานร่วมกับการจัดข้อมูล ไม่ใช่มีลูปลองใหม่อย่างเดียว

ส่วนงานควบคุมต้องกำหนดด้วยว่าคำสั่งใดทำได้ในเครื่อง และคำสั่งใดต้องรอการยืนยันจากส่วนอื่น การกลับมาออนไลน์ไม่ควรทำให้คำสั่งเก่าทุกอันถูกนำมาทำโดยไม่มีการตรวจอายุและสถานะของระบบ

ถอยระยะการลองใหม่ให้มีขอบเขต

หากเชื่อมไม่สำเร็จแล้วลองใหม่ทันทีทุกครั้ง อุปกรณ์ก็อาจใช้เวลาและพลังงานไปกับความพยายามที่ยังไม่มีโอกาสเปลี่ยนผล แนวทาง backoff จึงช่วยเว้นระยะตามจำนวนครั้งที่ล้มเหลว โดยกำหนดเพดานไว้ให้ไม่รอนานเกินโจทย์

เมื่อมีหลายเครื่องที่กลับมาเริ่มพร้อมกัน การใส่ jitter ทำให้รอบลองใหม่ไม่ตรงกันทั้งหมด เป็นการกระจายความพยายามแทนการนัดทุกเครื่องให้เข้าพร้อมกันตามเวลาเดียว โดยช่วงสุ่มและเพดานต้องเลือกให้เหมาะกับการใช้ไฟและเวลาที่ระบบยอมรอ

ตัวตั้งเวลาควรปล่อยให้งานอื่นเดินต่อได้ ไม่เอา backoff ไปทำเป็นการหน่วงทั้งโปรแกรม และควรระวังไม่ให้มีหลายเส้นทางต่างคนต่างสร้างรอบ retry เช่น ทั้ง event handler และงานส่งข้อมูลตั้ง timer ของตัวเองจนกลายเป็นความพยายามซ้อนกัน

เมื่อเชื่อมกลับมาแล้ว ควรมีเงื่อนไขคืนตัวนับที่เหมาะสมด้วย หากสัญญาณขึ้นลงเร็ว การล้างประวัติทันทีที่เชื่อมได้ชั่วครู่ก็อาจทำให้กลับไปลองถี่อีกตลอด ควรดูเสถียรภาพและหน้าที่ของระบบก่อนตัดสินว่ารอบเชื่อมต่อใหม่สมบูรณ์แล้ว

ความผิดพลาดบางแบบต้องการการตั้งค่าใหม่

ถ้า access point ยังไม่พร้อม การรอแล้วลองใหม่อาจเหมาะ แต่ถ้ารหัสผิดหรือเครือข่ายที่ตั้งไว้ไม่อยู่แล้ว การทำแบบเดิมไปเรื่อยๆ อาจไม่ช่วย ผู้ใช้จึงควรมีทางตรวจสถานะและเข้าสู่ขั้นตั้งค่าใหม่ตามที่อุปกรณ์รองรับ

เหตุที่ระบบรายงานควรถูกแปลอย่างระมัดระวังตามเอกสาร ไม่เอารหัสผิดพลาดหนึ่งตัวไปอธิบายเกินสิ่งที่มันยืนยันได้ และไม่แสดงรหัสผ่านหรือข้อมูลลับใน log เพื่อให้แก้ง่ายขึ้น เพราะข้อมูลที่จำเป็นต่อการไล่ปัญหามักไม่ต้องรวมความลับทั้งหมด

หากมีโหมดตั้งค่าเครือข่าย ก็ต้องกำหนดว่าเปิดเมื่อไร ใครเข้าถึงได้ และออกจากโหมดนั้นอย่างไร ไม่เปิดช่องตั้งค่าค้างทุกครั้งที่เน็ตสะดุดช่วงสั้นโดยไม่ได้คิดผลต่อการใช้งานส่วนอื่น

กลับมาแล้วต้องต่อระบบในชั้นถัดไปให้ครบ

หลังได้เครือข่าย แอปยังอาจต้องต่อ broker ใหม่ สมัครรับ topic และส่งสถานะปัจจุบันตามลำดับที่ออกแบบไว้ แต่ควรระวังการลงทะเบียน callback หรือสร้างงานซ้ำทุกครั้งที่ reconnect จนจำนวนตัวจัดการเพิ่มขึ้นโดยไม่รู้ตัว

หากมีคิวค้าง ควรระบายด้วยอัตราที่ไม่ทำให้งานปัจจุบันรอ และใช้รหัสข้อมูลเดิมเมื่อส่งซ้ำตามความต้องการของระบบ ส่วนหน้าจอก็ควรแยกเวลาที่อุปกรณ์เชื่อมกลับจากเวลาที่ข้อมูลแต่ละตัวอย่างถูกวัดจริง

ในการทดสอบ ลองแยกกรณีปิด access point บริการปลายทางไม่ตอบ และคืนการเชื่อมต่อกลับมา แล้วดูว่าปุ่ม เซนเซอร์ และสถานะคิวเป็นไปตามที่กำหนดหรือไม่ การผ่านกรณีเน็ตพร้อมอย่างเดียวจึงจะไม่เป็นผลทดสอบทั้งหมดของการ reconnect

ให้คนดูแลแยกสถานะปัจจุบันกับข้อมูลครั้งล่าสุดได้

หากเว็บเห็นเพียงเวลารับข้อมูลล่าสุด ก็ยังไม่รู้แน่ว่าบอร์ดดับหรือแค่การเชื่อมต่อขาด อุปกรณ์อาจเก็บเหตุผลการหลุด จำนวนรอบลองใหม่ และเวลาที่กลับมาติดต่อได้ไว้ส่งภายหลัง ส่วนหน้าจอควรแสดงขอบเขตว่าเป็นข้อมูลที่รายงานล่าสุด ไม่ทำให้ดูเหมือนกำลังมองสถานะสดระหว่างติดต่อไม่ได้

เมื่อมีข้อมูลนี้ เราจะตรวจได้ว่ากำลังเจอการหลุดถี่หรือเป็นช่วงเดียวที่ยาว และค่อยตัดสินใจว่าต้องแก้สัญญาณ การตั้งค่า หรือบริการปลายทาง โดยยังไม่สรุปต้นเหตุจากคำว่า offline คำเดียว

สรุป

การ reconnect ที่ดูแลได้ควรแยกสถานะ Wi-Fi, IP และบริการ พร้อมให้ส่วนที่ยังทำงานได้เดินต่อ กำหนด backoff กับ jitter อย่างมีขอบเขต และมีทางตั้งค่าใหม่เมื่อการรอไม่ช่วย เมื่อทดสอบทั้งตอนหลุดและตอนกลับครบเส้นทาง อุปกรณ์ก็จะไม่ต้องหยุดทั้งตัวเพียงเพราะการเชื่อมต่อส่วนหนึ่งกำลังมีปัญหาครับ