ถ้าแค่ส่งค่าระหว่างบอร์ด จะใช้ ESP-NOW ดีไหม

ถ้าแค่ส่งค่าระหว่างบอร์ด จะใช้ ESP-NOW ดีไหม - Image 1
24/07/2025•Admin Team•
ESP32IoTTutorial

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

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

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

แยกเส้นทางระหว่างบอร์ดออกจากทางขึ้นอินเทอร์เน็ต

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

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

ตัวอย่างเซนเซอร์ ESP-NOW ส่งผ่าน gateway ก่อนเชื่อมต่อบริการบนเว็บ

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

ก่อนส่งข้อมูล ต้องรู้จัก peer และช่องสัญญาณ

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

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

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

Payload ควรเล็กและมีรูปแบบที่ตกลงกัน

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

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

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

ส่งสำเร็จ กับแอปนำไปใช้แล้ว เป็นคนละจุด

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

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

ตัวอย่างส่งข้อมูลพร้อมลำดับและรอการยืนยันจากแอปปลายทาง

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

ความปลอดภัยและระยะใช้งานต้องตรวจจากชุดจริง

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

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

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

ให้ gateway บอกด้วยว่ารับถึงขั้นไหนแล้ว

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

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

สรุป

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

Command Eng Logo
CMD yourNgineers
เลขประจำตัวผู้เสียภาษี0805564000814
บทความ
ติดต่อบริษัท คอมมานด์ เอ็นจ์ จำกัด
81/36 เพอร์เฟค พาร์คบางนาตำบลบางเสาธง อำเภอบางเสาธงจังหวัดสมุทรปราการ 10570
team@commandeng.in.th+66 89 393 5191
Facebook Page | Command EngLine | Command Eng Official
© Copyright 2022-2026 Command Eng Co., Ltd.v1.0.4 · 0d556ab · 2026-11-03 15:23