จากโจทย์จริงสู่แบบ: canvas schema และการออกแบบตอนพัง

หลักสูตร

AIoT in Action: จากหน้าจอสัมผัสสู่แพลตฟอร์ม IoT (MicroPython) · Capstone: AIoT Mini-Product

ระดับ

L2 ทำตามแนวทาง

เวลาโดยประมาณ

60 นาที (แนวคิด 25 · แล็บ 30 · เช็กความเข้าใจ 5)

อุปกรณ์

BENTO Emulator (ไม่ต้องมีบอร์ด) · Eva Kit · Dev Kit

ทักษะที่ฝึก

• พื้นฐานระบบ IoT ถึง L2
• การตัดสินใจเชิงผลิตภัณฑ์ด้าน AIoT ถึง L2
• การแก้ปัญหาและการคิดเชิงวิพากษ์ ถึง L2

ควรเรียนก่อน

• ลงมือทำ: ส่งค่าจริงผ่านช่องทางเข้ารหัส

สถานะ

ทดลองใช้ (alpha)

• เปิดสไลด์
• เปิด BENTO IDE
• ไฟล์ของบทเรียนบน GitHub

วิดีโอประกอบ

ดูบน YouTube (เปิดในแท็บใหม่)

• Software Development Process - EP01 : Overall Software Development Process สมาคมสมองกลฝังตัวไทย (TESA)
• Software Development Process - EP02 : User Needs สมาคมสมองกลฝังตัวไทย (TESA)
• Software Development Process - EP03 : System Requirements สมาคมสมองกลฝังตัวไทย (TESA)

วิดีโอโดย สมาคมสมองกลฝังตัวไทย (TESA) · ดูทั้งชุดใน playlist AIoT Foundation

โมดูล 5 — Capstone: AIoT Mini-Product · สไลด์: slides.md · ภาพรวมโมดูล · หน้าหลักสูตร

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

เป้าหมาย

เมื่อจบบทเรียนนี้ คุณจะ:

1. เขียนโจทย์ของทีมจากสามคำถาม (ใครเสียอะไรอยู่ทุกวัน · ตอนนี้เขารู้ได้อย่างไรว่ามีปัญหา · ถ้ารู้เร็วขึ้นสามสิบนาทีจะเปลี่ยนอะไรได้) แล้วกรอก canvas ห้าช่อง Sense → Decide → Show → Send → Act ให้ครบ โดยช่อง Act ระบุว่าใครทำอะไรภายในกี่นาที
2. ออกแบบ payload JSON ของทีมที่เล็ก คงที่ มีหน่วยและ device id ไม่เกิน 1000 ไบต์ อธิบายเหตุผลของทุกฟิลด์ได้ และตั้งชื่อฟิลด์ของค่าตัวแทน (proxy) ให้ประกาศตัวว่าเป็นตัวแทน
3. คำนวณจำนวนข้อความต่อวันของการส่งทุกค่าเทียบกับการส่งเหตุการณ์บวก heartbeat และอธิบายได้ว่าทำไมยังต้องมี heartbeat
4. กำหนดพฤติกรรมของระบบในห้าสถานการณ์ตอนพัง (WiFi หลุด · broker ไม่ตอบ · เน็ตกลับมา · ค่ากระโดดวูบเดียว · เตือนแล้วไม่มีใครอยู่หน้าจอ) และตัดสินว่าจะทิ้งหรือเก็บข้อมูลตอนออฟไลน์ พร้อมเหตุผลที่ผูกกับโจทย์ของทีม

ก่อนเริ่ม

บทเรียนนี้ยังไม่เขียนโค้ด เปิด บันทึกการเรียน หน้าใหม่ไว้สำหรับงานจบ canvas ห้าช่อง ตาราง schema และตารางพฤติกรรมตอนพังของทีมจะอยู่ในนั้นทั้งหมด และจะถูกใช้ต่อในบทเรียน 5.2 กับ 5.3 ทบทวนสองงานที่ทีมมีอยู่แล้ว คือ dashboard จากบทเรียน 3.7–3.9 และ telemetry ที่ส่งขึ้น broker ในบทเรียน 4.4–4.6 กับ 4.7–4.9 ชุดบทเรียนนี้ไม่มี API ใหม่สักตัว ใช้เฉพาะของที่ทีมเคยรันเองแล้ว

• อุปกรณ์: บอร์ด Eva Kit หรือ TESAIoT Dev Kit ที่ลงเฟิร์มแวร์ MicroPython ของ BENTO แล้ว หรือ BENTO Emulator ใน BENTO IDE
• เรียนมาก่อน: บทเรียน 4.9 — ลงมือทำ: ส่งค่าจริงผ่านช่องทางเข้ารหัส

ดูของจริงก่อน

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

แนวคิด

demo กับ product ต่างกันที่การตัดสินใจ ไม่ใช่ที่ API product ต้องตอบได้ว่าทำไมต้องมีของชิ้นนี้ (มีคนเสียเงินหรือเสียเวลากับปัญหานี้อยู่) ค่าบนจอคือปริมาณที่มีหน่วยและมีคนตัดสินใจจากมันได้ ส่งขึ้นไปเฉพาะสิ่งที่ปลายทางใช้จริง เน็ตหลุดแล้วจอทำงานต่อ และมี device id ให้ตรวจ ทั้งห้าข้อไม่ต้องใช้ API ที่เรายังไม่เคยเรียน ของที่มีในมือคือเก้าโมดูล (lcd gpio ui sensors dsp mic wifi mqtt tesaiot) เช็กตั้งแต่วันนี้ว่าโจทย์ของทีมต้องการชื่อที่ไม่มีในบัญชีนี้หรือเปล่า

เริ่มจากปัญหา ไม่ใช่จากรายการเซนเซอร์ ถามตามลำดับ: ใครเสียอะไรอยู่ทุกวัน · ตอนนี้เขารู้ได้อย่างไรว่ามีปัญหา · ถ้ารู้เร็วขึ้นสามสิบนาทีจะเปลี่ยนอะไรได้ (ตอบข้อสามไม่ได้ แปลว่าโจทย์ยังไม่คุ้มที่จะทำ) แล้วจึงถามว่าบอร์ดวัดอะไร ที่บอกเรื่องนั้นได้ ถ้าบอร์ดวัดสิ่งที่อยากรู้ไม่ได้ ให้ใช้ proxy และประกาศให้ชัดว่าเป็นตัวแทน ทั้งบนสไลด์และในชื่อฟิลด์ เช่น Eva Kit ไม่มีเซนเซอร์อุณหภูมิห้อง โจทย์ห้องเย็นจึงวัดว่าประตูเปิดค้างแทน และตั้งชื่อ door_open_s ไม่ใช่ temp_c (Dev Kit อ่านอุณหภูมิห้องได้ตรงจาก sensors.sht40 แต่ทั้งสองบอร์ดไม่มีเซนเซอร์ก๊าซหรือกระแสไฟ)

canvas ห้าช่องกรอกให้ครบก่อนแตะคีย์บอร์ด Sense (วัดอะไร ถี่แค่ไหน กรองอย่างไร) · Decide (เกณฑ์อะไร ยืนยันกี่รอบ ตัดสินบนบอร์ด) · Show (เห็นอะไรบนจอ รู้ในสองวินาทีไหม มีสถานะเน็ตและปุ่มรับทราบ) · Send (ส่งอะไร ไปไหน schema อะไร) · Act (ใครทำอะไรต่อ ภายในกี่นาที) เติมจากขวาไปซ้ายโดยเริ่มที่ Act ก็ได้ และมักได้ระบบที่เล็กลงและตรงกว่า ถ้าช่อง Act ไม่มีใครทำอะไร ข้อมูลนั้นไม่ต้องส่งตั้งแต่แรก ตัวอย่างในสไลด์คือนั่งร้านชั้นสามที่เอียงแล้วไม่มีใครรู้จนเช้า ซึ่งเป็นโจทย์ที่เฉลยของบทเรียน 5.3 ทำจนจบ

schema ที่อยู่ได้นาน และการส่งเหตุการณ์ payload ของโครงตั้งต้นมีหกฟิลด์ {"id": "team01", "v": 17.4, "unit": "deg", "state": "ALERT", "kind": "event", "t": 812340} คือตัวตนของบอร์ด ค่าที่ตัดสินแล้ว หน่วย คำตัดสินของบอร์ด ชนิดของข้อความ และเวลาบนบอร์ดสำหรับเรียงลำดับ กติกาคือชื่อฟิลด์คงที่ตลอดโครงการ เพิ่มฟิลด์ได้แต่ห้ามเปลี่ยนความหมายของฟิลด์เดิม และ payload ต่ำกว่า 1000 ไบต์เสมอ ถ้าอ่านทุก 200 ms แล้วส่งทุกค่า จะได้ 432,000 ข้อความต่อวันต่อบอร์ด (ราว 39 MB) แต่ถ้าส่งตอนสถานะเปลี่ยน บวก heartbeat ทุก 30 วินาที จะเหลือราว 2,883 ข้อความ heartbeat ยังจำเป็นเพราะถ้าเงียบอย่างเดียว ปลายทางแยกไม่ออกว่า “ทุกอย่างปกติ” หรือ “บอร์ดตายไปแล้วเมื่อวาน” MQTT เองก็เกิดมาเพื่อสัญญาณที่แย่แบบนี้ (ออกแบบเมื่อปี 1999 สำหรับท่อส่งน้ำมันที่เชื่อมด้วยดาวเทียม)

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

ตัวอย่างสมบูรณ์

สไลด์ของบทเรียนนี้อ้างถึงไฟล์ที่อยู่ในบทเรียนอื่นด้วย:

• m05-capstone/l03-build-and-present/practice/s12_capstone_starter.py — โครงเริ่มต้นของ mini-product: Sense -> Decide -> Show -> Send
• m05-capstone/l03-build-and-present/solution/s12_capstone_starter.py — ตัวอย่างที่ทำเสร็จแล้วหนึ่งชิ้น: Tilt Alarm สำหรับนั่งร้าน/ชั้นวาง

เช็กความเข้าใจ

คำถามชุดเดียวกันอยู่ใน quiz.yaml สำหรับระบบที่ตรวจอัตโนมัติ

1. ในโจทย์นั่งร้านเอียงของสไลด์ ข้อใดเขียนช่อง Act ของ canvas ได้ถูกแบบ (เลือกหนึ่งข้อ · เป้าหมายข้อ 1)

   • ก) ส่งค่าความเอียงขึ้นคลาวด์ทุก 200 ms
   • ข) หัวหน้าไซต์ได้แจ้งเตือน แล้วเดินไปดูภายใน 15 นาที
   • ค) แสดงคำว่า ALERT ตัวใหญ่บนจอ
   • ง) เก็บข้อมูลไว้ทำกราฟย้อนหลัง
   เฉลย

   ข — ช่อง Act เขียนเป็น “คนทำอะไร ภายในกี่นาที” ไม่ใช่ “ส่งขึ้นคลาวด์” ถ้าปลายทางไม่มีใครทำอะไร ข้อมูลนั้นไม่ต้องส่งตั้งแต่แรก ส่วนคำว่า ALERT บนจอเป็นงานของช่อง Show

2. ทีมที่ใช้ Eva Kit ทำโจทย์ห้องเย็น แต่ Eva ไม่มีเซนเซอร์อุณหภูมิห้อง จึงวัดว่าประตูถูกเปิดค้างนานกี่วินาทีแทน ควรตั้งชื่อฟิลด์นี้ใน schema อย่างไร (เลือกหนึ่งข้อ · เป้าหมายข้อ 2)

   • ก) temp_c เพราะโจทย์จริงคืออุณหภูมิ
   • ข) door_open_s
   • ค) imu_temp_c โดยอ่านจาก sensors.bmi270.temperature() แทน
   • ง) cold_room
   เฉลย

   ข — proxy ต้องประกาศตัวว่าเป็นตัวแทนทั้งบนสไลด์นำเสนอและในชื่อฟิลด์ ตั้งชื่อ door_open_s ไม่ใช่ temp_c ส่วน sensors.bmi270.temperature() บน Eva โยน OSError ทุกครั้ง และถึงอ่านได้ก็เป็นอุณหภูมิของชิป IMU ไม่ใช่ของห้อง

3. ข้อใดเป็นกติกาที่ทำให้ schema อยู่ได้นาน เลือกทุกข้อที่ถูก (เลือกได้หลายข้อ · เป้าหมายข้อ 2)

   • ก) ชื่อฟิลด์คงที่ตลอดโครงการ
   • ข) เพิ่มฟิลด์ใหม่ได้ แต่ห้ามเปลี่ยนความหมายของฟิลด์เดิม
   • ค) payload ขาออกต่ำกว่า 1000 ไบต์เสมอ
   • ง) ส่งค่าดิบทุกแกนไปด้วย เผื่อปลายทางอยากคำนวณเอง
   • จ) เปลี่ยนชื่อฟิลด์ให้สื่อความหมายขึ้นเมื่อทีมเข้าใจโจทย์มากขึ้น
   เฉลย

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

4. บอร์ดอ่านค่าทุก 200 ms ถ้าส่งทุกค่าจะได้ 432,000 ข้อความต่อวัน ถ้าเปลี่ยนเป็นส่งตอนสถานะเปลี่ยนบวก heartbeat ทุก 30 วินาที จะเหลือราว 2,883 ข้อความ ทำไมยังต้องมี heartbeat (เลือกหนึ่งข้อ · เป้าหมายข้อ 3)

   • ก) เพื่อให้ปลายทางแยกได้ว่า “ทุกอย่างปกติ” กับ “บอร์ดตายไปแล้ว”
   • ข) เพื่อให้กราฟฝั่งปลายทางลื่นเหมือนตอนส่งทุกค่า
   • ค) เพื่อส่งค่าดิบที่ถูกกรองทิ้งไปให้ครบ
   • ง) เพื่อให้จำนวนข้อความต่อวันเท่าเดิม
   เฉลย

   ก — ถ้าเงียบอย่างเดียว ปลายทางแยกไม่ออกระหว่าง “ทุกอย่างปกติ” กับ “บอร์ดตายไปแล้วเมื่อวาน” heartbeat ทุก 30 วินาทีคือ 2,880 ข้อความต่อวัน บวกเหตุการณ์จริงอีกไม่กี่ครั้ง ยังน้อยกว่าการส่งทุกค่าร้อยกว่าเท่า

5. ทีมหนึ่งทำเครื่องนับจำนวนชิ้นงานที่ผลิตได้ ตอนเน็ตหลุด ทางไหนสมเหตุผลที่สุด (เลือกหนึ่งข้อ · เป้าหมายข้อ 4)

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

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

แล็บ

ออกแบบงานจบบนกระดาษ (ราว 30 นาที ทำเป็นทีม) จดทุกข้อลงบันทึกการเรียน

• ตอบสามคำถามของโจทย์ แล้วเล่าโจทย์ให้เพื่อนอีกทีมฟังให้จบใน 30 วินาที ถ้าเขาถามว่า “แล้วไง” ให้กลับไปแก้คำถามข้อสาม
• เลือกโจทย์ของทีมเอง หรือหนึ่งในหกโจทย์จากหน้างานในสไลด์ แล้วเทียบกับบัญชีเก้าโมดูลว่าทุกชื่อที่ต้องใช้มีอยู่จริงบนบอร์ดของทีม
• ถ้าต้องใช้ proxy ให้เขียนไว้ว่ามันบอกอะไรได้และบอกอะไรไม่ได้ และตั้งชื่อฟิลด์ให้ประกาศตัวว่าเป็นตัวแทน
• กรอก canvas ห้าช่องให้ครบ ช่อง Act เขียนเป็น “ใครทำอะไร ภายในกี่นาที”
• เขียนตาราง schema สองคอลัมน์ (ฟิลด์ · ทำไมต้องมี) ทุกฟิลด์มีเหตุผล มีหน่วยและ device id
• คิดจำนวนข้อความต่อวันของทีมสองแบบ คือส่งทุกค่ากับส่งเหตุการณ์บวก heartbeat
• เขียนตารางตอนพังห้าแถว (WiFi หลุด · broker ไม่ตอบ · เน็ตกลับมา · ค่ากระโดดวูบเดียว · เตือนแล้วไม่มีใครอยู่หน้าจอ) และตัดสินเรื่อง “ทิ้ง หรือ เก็บไว้ส่งทีหลัง” พร้อมเหตุผลหนึ่งประโยค
• ตอบให้ได้ว่า ถ้าเครื่องของทีมค้าง คนที่เดินผ่านจะรู้ได้จากอะไร

ไปต่อ

บทเรียน 5.2 แกะโครงตั้งต้น s12_capstone_starter.py ทีละท่า ถือ canvas ที่กรอกแล้วไปด้วย เพราะทุกจุด “ทีมเขียนเอง” ในโครงจะถามหาคำตอบจากมัน ถ้ามีเวลา ดูวิดีโอเสริมในสไลด์เรื่องการออกแบบ topic และ Last Will and Testament ของ MQTT

บทเรียนถัดไป: บทเรียน 5.2 — โครงตั้งต้น: Sense Decide Show Send

สะท้อนคิด

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

คำถามทบทวน

ลองตอบเองก่อน แล้วค่อยเปิดดูเฉลย

1. ในโจทย์นั่งร้านเอียงของสไลด์ ข้อใดเขียนช่อง Act ของ canvas ได้ถูกแบบ (เป้าหมายข้อ 1)

   1. ส่งค่าความเอียงขึ้นคลาวด์ทุก 200 ms
   2. หัวหน้าไซต์ได้แจ้งเตือน แล้วเดินไปดูภายใน 15 นาที
   3. แสดงคำว่า ALERT ตัวใหญ่บนจอ
   4. เก็บข้อมูลไว้ทำกราฟย้อนหลัง
   ดูเฉลย

   คำตอบ: B. หัวหน้าไซต์ได้แจ้งเตือน แล้วเดินไปดูภายใน 15 นาที

   ช่อง Act เขียนเป็น "คนทำอะไร ภายในกี่นาที" ไม่ใช่ "ส่งขึ้นคลาวด์" ถ้าปลายทางไม่มีใครทำอะไร ข้อมูลนั้นไม่ต้องส่งตั้งแต่แรก ส่วนคำว่า ALERT บนจอเป็นงานของช่อง Show

2. ทีมที่ใช้ Eva Kit ทำโจทย์ห้องเย็น แต่ Eva ไม่มีเซนเซอร์อุณหภูมิห้อง จึงวัดว่าประตูถูกเปิดค้างนานกี่วินาทีแทน ควรตั้งชื่อฟิลด์นี้ใน schema อย่างไร (เป้าหมายข้อ 2)

   1. temp_c เพราะโจทย์จริงคืออุณหภูมิ
   2. door_open_s
   3. imu_temp_c โดยอ่านจาก sensors.bmi270.temperature() แทน
   4. cold_room
   ดูเฉลย

   คำตอบ: B. door_open_s

   proxy ต้องประกาศตัวว่าเป็นตัวแทนทั้งบนสไลด์นำเสนอและในชื่อฟิลด์ ตั้งชื่อ door_open_s ไม่ใช่ temp_c ส่วน sensors.bmi270.temperature() บน Eva โยน OSError ทุกครั้ง และถึงอ่านได้ก็เป็นอุณหภูมิของชิป IMU ไม่ใช่ของห้อง

3. ข้อใดเป็นกติกาที่ทำให้ schema อยู่ได้นาน เลือกทุกข้อที่ถูก (เป้าหมายข้อ 2)

   1. ชื่อฟิลด์คงที่ตลอดโครงการ
   2. เพิ่มฟิลด์ใหม่ได้ แต่ห้ามเปลี่ยนความหมายของฟิลด์เดิม
   3. payload ขาออกต่ำกว่า 1000 ไบต์เสมอ
   4. ส่งค่าดิบทุกแกนไปด้วย เผื่อปลายทางอยากคำนวณเอง
   5. เปลี่ยนชื่อฟิลด์ให้สื่อความหมายขึ้นเมื่อทีมเข้าใจโจทย์มากขึ้น
   ดูเฉลย

   คำตอบ: A. ชื่อฟิลด์คงที่ตลอดโครงการ · B. เพิ่มฟิลด์ใหม่ได้ แต่ห้ามเปลี่ยนความหมายของฟิลด์เดิม · C. payload ขาออกต่ำกว่า 1000 ไบต์เสมอ

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

4. บอร์ดอ่านค่าทุก 200 ms ถ้าส่งทุกค่าจะได้ 432,000 ข้อความต่อวัน ถ้าเปลี่ยนเป็นส่งตอนสถานะเปลี่ยนบวก heartbeat ทุก 30 วินาที จะเหลือราว 2,883 ข้อความ ทำไมยังต้องมี heartbeat (เป้าหมายข้อ 3)

   1. เพื่อให้ปลายทางแยกได้ว่า "ทุกอย่างปกติ" กับ "บอร์ดตายไปแล้ว"
   2. เพื่อให้กราฟฝั่งปลายทางลื่นเหมือนตอนส่งทุกค่า
   3. เพื่อส่งค่าดิบที่ถูกกรองทิ้งไปให้ครบ
   4. เพื่อให้จำนวนข้อความต่อวันเท่าเดิม
   ดูเฉลย

   คำตอบ: A. เพื่อให้ปลายทางแยกได้ว่า "ทุกอย่างปกติ" กับ "บอร์ดตายไปแล้ว"

   ถ้าเงียบอย่างเดียว ปลายทางแยกไม่ออกระหว่าง "ทุกอย่างปกติ" กับ "บอร์ดตายไปแล้วเมื่อวาน" heartbeat ทุก 30 วินาทีคือ 2,880 ข้อความต่อวัน บวกเหตุการณ์จริงอีกไม่กี่ครั้ง ยังน้อยกว่าการส่งทุกค่าร้อยกว่าเท่า

5. ทีมหนึ่งทำเครื่องนับจำนวนชิ้นงานที่ผลิตได้ ตอนเน็ตหลุด ทางไหนสมเหตุผลที่สุด (เป้าหมายข้อ 4)

   1. ทิ้งทุกค่า เพราะโครงตั้งต้นเลือกทิ้ง
   2. เก็บไว้ส่งทีหลัง เพราะความครบสำคัญกว่าความสด แล้วจดการตัดสินใจนี้ไว้ในบันทึกการเรียน
   3. ไม่ต้องตัดสินใจ ปล่อยให้เป็นไปตามที่โปรแกรมทำอยู่
   4. หยุดนับจนกว่าเน็ตจะกลับมา
   ดูเฉลย

   คำตอบ: B. เก็บไว้ส่งทีหลัง เพราะความครบสำคัญกว่าความสด แล้วจดการตัดสินใจนี้ไว้ในบันทึกการเรียน

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

อ้างอิงบทเรียนนี้

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

"จากโจทย์จริงสู่แบบ: canvas schema และการออกแบบตอนพัง" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย (Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program สัญญาอนุญาต CC BY-NC 4.0

ข้อความอ้างอิงภาษาอังกฤษ: "From a real problem to a design: canvas, schema and designing for failure" from TESA Open Knowledge by the Thai Embedded Systems Association (TESA), https://github.com/tesaiot/tesa-qualification-program, licensed under CC BY-NC 4.0

ลิงก์บทเรียน: https://tesaiot.github.io/tesa-qualification-program/courses/aiot-micropython/m05-capstone/l01-problem-to-design/

บทเรียนนี้ดัดแปลงจากต้นฉบับด้านล่าง เมื่ออ้างอิงให้คงเครดิตต้นฉบับไว้ด้วย
https://github.com/Advance-Innovation-Centre-AIC/embedded-systems-for-aiot-developer/blob/a80bbe88a34bcb9bb8d991f42f9252b77cdab079/session-12.html (slides 1–21)

วิธีอ้างอิง TESA ฉบับเต็ม