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

ดูของจริงก่อน — ผลงานของทีมเราเอง

เปิดสองอย่างขึ้นมาพร้อมกัน: dashboard ที่ทีมสร้างในบทเรียน 3.7–3.9 กับ telemetry ที่ทีมส่งขึ้น broker ในบทเรียน 4.4–4.6 และ 4.7–4.9

ทั้งสองอย่างทำงานได้ทั้งคู่ และทั้งสองอย่างยังไม่ใช่ผลิตภัณฑ์

ลองอย่างนี้: ระหว่างที่มันรันอยู่ ให้เพื่อนถอด WiFi ออกเงียบ ๆ แล้วดูว่าเกิดอะไรขึ้นบนจอ

ชุดบทเรียนนี้เราจะเปลี่ยนงานสองชิ้นนั้นให้เป็นชิ้นเดียวที่ส่งมอบได้

demo กับ product ต่างกันตรงไหน

ช่องขวาทั้งห้าข้อ ไม่มีข้อไหนต้องใช้ API ใหม่ที่เรายังไม่เคยเรียนเลยสักตัว

ระยะทางจาก demo ถึง product สั้นกว่าที่คิด แต่ต้องตั้งใจเดิน ไม่ใช่บังเอิญไปถึง

demo กับ product ต่างกันตรงไหน (ต่อ) — ชิ้นส่วนเดียวกับบทเรียน 2.7–2.9

ทำไม · คืออะไร · ทำยังไง — แผนที่ของชุดบทเรียนนี้

ปลายทางที่จับต้องได้ — ของหนึ่งชิ้นที่วางบนโต๊ะแล้วเดินครบวงเอง ตั้งแต่วัด ตัดสิน แสดง ถึงรายงานขึ้น broker และทีมอธิบายได้ว่ามันแก้ปัญหาอะไรให้ใคร รวมทั้งบอกได้ว่ามันยังทำอะไรไม่ได้

บทเรียน 4.7–4.9 เราทำให้ส่งอย่างปลอดภัยได้ · ชุดบทเรียนนี้เราตอบคำถามที่มาก่อนหน้านั้น — จะส่งอะไร ให้ใคร และเขาจะเอาไปทำอะไรต่อ

เป้าหมายของชุดบทเรียนนี้

1. เลือกโจทย์จาก ความเจ็บปวดจริงในงาน ไม่ใช่จากรายการเซนเซอร์ที่บอร์ดมี
2. ออกแบบระบบด้วย canvas ห้าช่อง: Sense → Decide → Show → Send → Act
3. ออกแบบ schema ข้อมูลที่เล็ก คงที่ มีหน่วย และมีตัวตนอุปกรณ์
4. ออกแบบพฤติกรรมตอนพัง — เน็ตหลุด broker ไม่ตอบ ค่าเซนเซอร์แปลก
5. ต่อโครง s12_capstone_starter.py จนรัน end-to-end แล้ว นำเสนอ 10 นาที

ปลายทางของวันนี้: บอร์ดวางอยู่บนโต๊ะ จอบอกสถานะ ข้อความไหลขึ้น broker และทีมอธิบายได้ว่ามันแก้ปัญหาอะไรให้ใคร

วันนี้เราไม่ได้เรียน API ใหม่ เราเรียน วิธีตัดสินใจ ว่าจะเอา API ที่มีอยู่ไปทำอะไร

ปลายทางของชุดบทเรียนนี้ — โครงตั้งต้นที่ทีมจะต่อยอด

โครงของหน้าจอ แบ่งเป็นสามการ์ด

• ซ้ายบน ค่าที่วัดได้ตัวใหญ่ พร้อม ui.Bar วางทับ ui.Scale — ค่ากับพิสัยอยู่ด้วยกัน และมีป้ายบอกคุณภาพของค่าเองว่าสดหรือค้าง
• ซ้ายล่าง ไฟสถานะสามดวง (ปกติ · เฝ้าระวัง · ผิดปกติ) ติดทีละดวง กับปุ่มรับทราบ
• ขวา ของจริงที่สั่งได้ — ไฟเตือนหน้างาน มีปุ่มเปิดกับปุ่มปิดแยกกันคนละปุ่ม และปุ่มปิดต้องผ่านกล่องยืนยันที่บอกว่าจะเกิดอะไร

นี่คือ starter ไม่ใช่เฉลย — สิ่งที่ให้มาคือ มาตรฐานของหน้าจอ ที่ทีมต้องรักษาไว้ ส่วนเนื้อในเปลี่ยนเป็นโจทย์ของทีมได้ทั้งหมด

สิบเอ็ดชุดบทเรียนที่ผ่านมา เราสะสมอะไรไว้บ้าง

ไม่มีอะไรในตารางนี้ที่ทีมยังไม่เคยรันเอง วันนี้แค่เอามาต่อกัน

ทั้งคอร์สเปิดไปเก้าโมดูล — บัญชีรวมก่อนลงมือทำงานจบ

อย่านับซ้ำ — "ตระกูล IMU สิบสี่ชื่อ" ของบทเรียน 3.1–3.3 ไม่ใช่โมดูลที่สิบ มันคือ sensors.bmi270 ห้า + sensors.bmm350 ห้า + dsp อีกสี่ ที่ซ้อนอยู่ในตารางแล้ว

ของที่คอร์สนี้ไม่เคยมีให้ — ไม่มี machine.PWM .ADC .SPI .Timer · dsp มี fft_mag (ตั้งแต่ 2026-08-20) แต่ไม่มี ulab · Eva Kit ไม่มี DPS368 SHT40 เรดาร์ ส่วน Dev Kit มีทั้งสาม (sensors.sht40 อุณหภูมิ/ความชื้น · sensors.dps368 ความกดอากาศ · sensors.radar()) แต่คอร์สไม่ได้เปิดสอน — ทีมบน Dev Kit ใช้ได้ถ้าอ่านซอร์สเอง และต้องมีแผนสำรองบน Eva เสมอ · optiga เป็นการสาธิตท้ายบทเรียน 4.7–4.9 ไม่อยู่ในเกณฑ์ อย่าวางแผนงานจบทับมัน

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

เริ่มจากปัญหา ไม่ใช่จากรายการเซนเซอร์

วิธีที่คนส่วนใหญ่เริ่ม แล้วจบไม่สวย: "บอร์ดมี IMU กับเข็มทิศ เราจะทำอะไรกับมันดี"

วิธีที่ได้ของที่มีคนใช้: เริ่มจากสามคำถามนี้ตามลำดับ

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

พอตอบครบสามข้อ ค่อยถามว่า "บอร์ดของเราวัดอะไรที่พอจะบอกเรื่องนั้นได้บ้าง"

ทีมที่เดินลำดับนี้จะได้โจทย์ที่เล่าให้คนนอกฟังได้ใน 30 วินาที ทีมที่เดินย้อนกลับมักจบด้วยของสวยที่ไม่มีใครอยากได้

โจทย์ที่ดีเล่าจบก่อนที่คนฟังจะทันถามว่า "แล้วไง"

เริ่มจากปัญหา ไม่ใช่จากรายการเซนเซอร์ (ต่อ) — โจทย์ของจริงสองแบบ

AIoT design canvas — ห้าช่องที่ต้องเติมให้ครบก่อนเขียนโค้ด

canvas นี้อยู่ในบันทึกการเรียน กรอกให้ครบก่อนแตะคีย์บอร์ด

canvas ที่กรอกแล้วหน้าตาเป็นแบบนี้

โจทย์ตัวอย่าง: นั่งร้านชั้นสามของไซต์ก่อสร้าง เอียงผิดปกติแล้วไม่มีใครรู้จนเช้า

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

ตัวอย่างนี้คือโจทย์ที่เฉลย s12_capstone_starter.py ทำจนจบ

หกโจทย์จากหน้างานจริง — เลือกไปใช้ได้เลย

เลือกโจทย์ที่ทีมมีคนเคยเจอปัญหานั้นจริง จะเถียงกันเรื่องเกณฑ์ได้สนุกกว่ามาก

หกโจทย์ (ต่อ) — ตัวแทนของโจทย์ที่ 2 และโจทย์ที่ต้องฟังเสียง

หมายเหตุเรื่องเสียง: ไมโครโฟนใช้จาก Python ได้แล้ว โมดูล mic ฝังมากับเฟิร์มแวร์ทั้งสองบอร์ด (boards/KIT_PSE84_EVAL_EPC2/manifest.py และ boards/KIT_PSE84_AI/manifest.py freeze ไฟล์เดียวกัน) และในอีมูเลเตอร์ — mic.start() แล้ว mic.level() คืนความดัง 0-100 ส่วน mic.rms() กับ mic.peak() คืนค่าดิบ 0-32768 · วัดจริงบน Eva Kit 14 ส.ค. 2026 (ตัวเลขบน Dev Kit ยังไม่ได้วัด) ห้องเงียบได้ rms 30 (ระดับ 7) เปิดโทนใส่ไมค์ได้ 19335 (ระดับ 92) ต่างกัน 645 เท่า ซึ่งห่างพอจะตั้งเกณฑ์ตัดสินได้จริง · level() นับเป็นอ็อกเทฟแบบที่หูได้ยิน ไม่ใช่สัดส่วนตรงของสเกลเต็ม จึงขยับตั้งแต่เสียงพูดปกติ

โจทย์ที่ต้องฟังเสียงเริ่มได้เลยวันนี้ — เกณฑ์พลังงานจาก peak() พอสำหรับโจทย์ระดับชุดบทเรียนนี้แล้ว แล้วครอบด้วยกฎ confirm-N เหมือนค่าจากเซนเซอร์ตัวอื่นทุกประการ

ตัวแทนที่ตอบได้ 1 บิต ก็ยังต้องผ่านกฎ confirm-N — สัญญาณเด้งของหน้าสัมผัสคือ "ค่าสั่นวูบเดียว" ในอีกหน้าตาหนึ่ง

เข้าใจฮาร์ดแวร์ · เมื่อบอร์ดวัดสิ่งที่เราอยากรู้ไม่ได้

Eva Kit มี IMU เข็มทิศ ปุ่มสัมผัส ลูกบิด และจอ — ไม่มีเซนเซอร์อุณหภูมิห้อง ความชื้น ก๊าซ หรือกระแสไฟ · TESAIoT Dev Kit มีชุดเดียวกัน และเพิ่ม SHT40 (อุณหภูมิ/ความชื้น) DPS368 (ความกดอากาศ) กับเรดาร์ — แต่ก็ยังไม่มีก๊าซ ไม่มีกระแสไฟ เรื่อง proxy จึงเป็นเรื่องของทั้งสองบอร์ด ต่างกันแค่ว่าอะไรบ้างที่ต้องใช้ตัวแทน

sensors.bmi270.temperature() มีชื่ออยู่ในโมดูลก็จริง แต่บน Eva Kit มัน โยน OSError ทุกครั้ง เพราะค่านี้ไม่ได้อยู่ใน snapshot ของคอร์จอ และถึงอ่านได้ (บน Dev Kit อ่านได้) มันคืออุณหภูมิของชิป IMU ซึ่งอุ่นตามการทำงานของบอร์ด ไม่ใช่ของห้อง — อุณหภูมิห้องบน Dev Kit ต้องมาจาก sensors.sht40

ทางออกที่วิศวกรใช้จริงคือ proxy — วัดสิ่งที่วัดได้ ซึ่งสัมพันธ์กับสิ่งที่อยากรู้: ห้องเย็นอุ่นขึ้นไหม → ประตูเปิดค้างหรือเปล่า · เครื่องทำงานอยู่ไหม → ความสั่นของโครง · มีคนอยู่ในห้องไหม → การเคลื่อนไหวกับการแตะปุ่ม

กติกาข้อเดียวของการใช้ proxy: บอกให้ชัดว่ามันคือตัวแทน ทั้งบนสไลด์นำเสนอและในชื่อฟิลด์ของ schema — ตั้งชื่อ door_open_s ไม่ใช่ temp_c

proxy ที่ประกาศตัวว่าเป็น proxy คืองานวิศวกรรม · proxy ที่แอบอ้างเป็นของจริงคือการหลอกลูกค้า

ส่งอะไรขึ้นไป — schema ที่อยู่ได้นาน

payload ของเราในโครงเริ่มต้นหน้าตาแบบนี้

{"id": "team01", "v": 17.4, "unit": "deg", "state": "ALERT", "kind": "event", "t": 812340}

หกฟิลด์ และทุกฟิลด์มีเหตุผล

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

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

ส่งเหตุการณ์ ไม่ใช่สตรีมดิบ

บทเรียน 1.1–1.3 เราพูดไว้ว่าหัวใจของ AIoT คือ ตัดสินใจใกล้จุดเกิดเหตุ แล้วส่งขึ้นไปเฉพาะสิ่งที่มีความหมาย วันนี้ถึงเวลาทำจริง

ลองคิดเลขให้เห็นภาพ อ่านค่าทุก 200 ms แล้วส่งทุกค่า

• 5 ครั้งต่อวินาที × 86,400 วินาที = 432,000 ข้อความต่อวัน ต่อหนึ่งบอร์ด
• ข้อความละ ~90 ไบต์ = ราว 39 MB ต่อวัน ต่อบอร์ด · มี 100 บอร์ดคือ 3.9 GB ต่อวัน
• ในจำนวนนั้น เหตุการณ์ที่มีคนต้องทำอะไรจริง ๆ อาจมีวันละ 3 ครั้ง

แบบส่งเหตุการณ์: ส่งตอนสถานะเปลี่ยน + heartbeat ทุก 30 วินาที = 2,883 ข้อความต่อวัน ลดลงร้อยกว่าเท่า และปลายทางอ่านง่ายกว่าเดิม

ทำไมยังต้องมี heartbeat: ถ้าเงียบอย่างเดียว ปลายทางแยกไม่ออกระหว่าง "ทุกอย่างปกติ" กับ "บอร์ดตายไปแล้วเมื่อวาน"

ดูเพิ่ม (6 นาที): MQTT Essentials Part 6 — MQTT Topic Best Practices — HiveMQ — 5:50 — การออกแบบลำดับชั้น topic และ wildcard + # ที่ฝั่งรับใช้ query

ความเงียบไม่ใช่ข่าวดี จนกว่าเราจะออกแบบให้ความเงียบมีความหมาย

เกร็ด: MQTT เกิดมาเพื่อสัญญาณที่แย่

ดูเพิ่ม (5 นาที): MQTT Essentials Part 10 — Last Will and Testament — HiveMQ — 5:27 — broker ประกาศแทนเราเมื่อเราหายไปแบบไม่บอกกล่าว ซึ่งคือกลไกที่ตอบคำถาม "บอร์ดเงียบไป แปลว่าปกติหรือตาย"

MQTT ถูกออกแบบตั้งแต่ปี 1999 โดยวิศวกรสองคน (Andy Stanford-Clark จาก IBM และ Arlen Nipper) สำหรับงานที่ฟังดูไม่น่าเกี่ยวกับเราเลย: ตรวจวัดท่อส่งน้ำมันกลางทะเลทราย ที่เชื่อมโลกด้วยสัญญาณดาวเทียมซึ่งทั้งช้า ทั้งแพง ทั้งหลุดบ่อย

ข้อจำกัดนั้นเองที่ทำให้โพรโทคอลนี้หน้าตาแบบที่เป็น — ส่วนหัวเล็กมาก มีระดับการรับประกันการส่งให้เลือก และมีแนวคิด "last will" คือข้อความที่ broker จะประกาศแทนเราเมื่อเราหายไปแบบไม่บอกกล่าว

เชื่อมกับวันนี้: ทีมที่ออกแบบ payload ให้เล็กและส่งเป็นเหตุการณ์ กำลังใช้โพรโทคอลตรงตามเจตนาของคนออกแบบเมื่อยี่สิบกว่าปีก่อน ส่วนทีมที่ยิงค่าดิบทุก 200 ms กำลังใช้มันผิดวิธี และจะเจอปัญหาเดียวกับที่ท่อน้ำมันเจอ

ออกแบบตอนพัง — สิ่งที่แยก product ออกจาก demo

เน็ตหลุดกลางงานไม่ใช่กรณีพิเศษ มันคือสภาพปกติของอุปกรณ์ที่ติดตั้งจริง

การตัดสินใจที่ต้องเลือกให้ชัดตั้งแต่วันนี้: ตอนออฟไลน์ ทีมจะ ทิ้ง ข้อมูลหรือ เก็บไว้ส่งทีหลัง

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

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

ออกแบบตอนพัง (ต่อ) — เครื่องยังมีชีวิตไหม คนเดินผ่านรู้ได้จากอะไร