โครงร่วมของทุกโปรแกรม MicroPython

ก่อนดูไฟล์จริง จับ "โครง" เดิมที่เราเจอมาตั้งแต่ บทเรียน 1.1–1.3 ให้ได้ก่อน — โปรแกรม BENTO เกือบทุกตัวเดินตามสี่จังหวะนี้:

จังหวะ 3 (ลูป) ของชุดบทเรียนนี้คือ "อ่านค่าดิบ → แปลงเป็น derived → ตัดสินด้วยกฎ → วาดคลาส" จำสี่ก้าวในลูปนี้ไว้ เดี๋ยวเราไล่โค้ดทีละก้าว

โครงของไฟล์ s07_rule_classifier.py

ทั้งไฟล์อ่านเป็นประโยคเดียว: "อ่าน temp+humidity → คำนวณ dew/heat → เอาเข้าบันไดกฎ → เอาคลาสที่ชนะขึ้นจอพร้อมสี → เทียบกับกฎสำเร็จรูป"

ตัวเลข "เติม 1..4" ชี้ไปที่ # เติม: ในไฟล์ฝึก จำโครงนี้ไว้ เดี๋ยวไล่ดูทีละช่อง

ไล่โค้ด (1) — อ่านค่าดิบ + คำนวณ derived

ช่องเติมที่ 1 และ 2: ต้นลูป อ่านเซนเซอร์แล้วแปลงเป็นค่าอนุพัทธ์ที่กฎจะใช้:

while True:
    p, t = sensors.dps368.pressure_temperature()   # ความดัน + อุณหภูมิ (ให้ไว้แล้ว)
    h = sensors.sht40.humidity()                    # ความชื้น %RH (ให้ไว้แล้ว)

    # เติม: dp = dsp.dew_point(t, h)      # จุดน้ำค้าง
    dp = 0.0
    pass
    # เติม: hi = dsp.heat_index(t, h)     # "รู้สึกเหมือน" กี่องศา
    hi = t
    pass

• ช่อง 1: แทน pass ด้วย dp = dsp.dew_point(t, h) · ช่อง 2: แทนด้วย hi = dsp.heat_index(t, h)
• ค่าตั้งต้น dp = 0.0 / hi = t กันโปรแกรมพังตอนยังเติมไม่ครบ พอเติมแล้วบรรทัดจริงจะทับค่าตั้งต้น
• dp เอาไปโชว์บนการ์ด · hi เอาไปป้อนบันไดกฎ (คลาส hot/danger ตัดสินจาก hi)

ทำไม humidity() คืนค่าตัวเดียว (float) ไม่ใช่ tuple? เพราะมันคืน %RH อย่างเดียว ส่วนอุณหภูมิเราเอามาจาก DPS368 แล้ว — ลองเรียก sensors.sht40.humidity() ใน REPL ดูได้

ไล่โค้ด (2) — เขียนบันไดกฎ classify()

ช่องเติมที่ 3 (หัวใจของชุดบทเรียน): เติมบันไดกฎในฟังก์ชัน classify():

def classify(t, h, hi):
    # เติม: เขียนบันไดเงื่อนไข ไล่จาก "อันตรายสุด" ลงมา แล้ว return ชื่อคลาส (str)
    #   if hi >= 41: return "danger"
    #   if hi >= 32: return "hot"
    #   if h  >= 70: return "humid"
    #   if t  <  20: return "cold"
    #   if h  <  30: return "dry"
    #   return "comfortable"
    pass

• แทน pass ด้วยบันไดทั้งชุด — ลำดับต้องไล่จากรุนแรง/เฉพาะ (danger) ลงไปกว้าง (comfortable)
• คลาสที่ return ต้องเป็นหนึ่งใน key ของ COLORS ไม่งั้นตอนระบายสีจะได้สีขาว (fallback)
• อยากปรับให้เป็น "กฎของคุณ" ก็เปลี่ยนเลขเส้นแบ่งได้เลย นี่คือ hyperparameter ของกฎ

ถ้าลืมเติมช่องนี้: classify() คืน None → verdict โชว์ว่างเปล่า และ COLORS.get(None) ได้สีขาว นี่คืออาการที่บอกว่าบันไดยังไม่ทำงาน

ไล่โค้ด (3) — เอาคลาสขึ้นจอ + ระบายสี

ช่องเติมที่ 4: เอาคลาสที่ classify คืนมา ขึ้นจอพร้อมสีประจำคลาส:

zone = classify(t, h, hi)
# เติม: verdict.text(zone)
#       verdict.color(COLORS.get(zone, WHITE))
pass

• แทน pass ด้วยสองบรรทัด: verdict.text(zone) แล้ว verdict.color(COLORS.get(zone, WHITE))
• COLORS.get(zone, WHITE) = ถ้าคลาสอยู่ในแผนที่สี ใช้สีนั้น ถ้าไม่ (เช่นเติมบันไดพลาด) ใช้สีขาว
• นี่คือ ชัยชนะที่เห็นได้: ตัวหนังสือคำตัดสินเปลี่ยนคำ+เปลี่ยนสีตามอากาศจริง

pattern "สร้าง widget ครั้งเดียว แล้วในลูปแค่ .text() / .color()" คือของเดิมจาก บทเรียน 1.1–1.3 — เราไม่สร้าง Seg7 ใหม่ทุกรอบ แค่เปลี่ยนข้อความกับสีของอันเดิม จอจะได้ไม่กระพริบ

ไล่โค้ด (4) — เทียบกับกฎสำเร็จรูป

ท่อนสุดท้าย (ให้ไว้แล้ว) เอาคำตัดสินของเราไปเทียบกับ dsp.comfort_zone เพื่อ "ตรวจการบ้านตัวเอง":

lab_builtin.text("dsp.comfort_zone: %s" % dsp.comfort_zone(t, h))

• ค่าอาจ ไม่ตรงกัน เพราะเราตั้งเส้นแบ่งคนละชุด (เราใช้ heat index, มันใช้อุณหภูมิดิบ; เลขเส้นก็ต่าง)
• ไม่ตรงกันไม่ได้แปลว่าผิด — แปลว่า "สองกฎนิยามความสบายต่างกัน" ซึ่งเป็นเรื่องปกติของกฎมือ
• ในฉบับเต็ม (examples/) เราเพิ่มไฟบอก = เมื่อตรงกัน x เมื่อต่างกัน ไว้สังเกตว่ากฎสองชุดเห็นพ้องกันบ่อยแค่ไหน

จุดนี้คือประเด็นที่ควรคิดให้จบ: "เมื่อกฎสองชุดตัดสินต่างกันตรงไหน แล้วชุดไหนถูก?" คำตอบคือ ไม่มีชุดไหน 'ถูก' โดยสมบูรณ์ — กฎขึ้นกับนิยามที่เราเลือก นี่คือข้อจำกัดที่ ML จะเข้ามาช่วยด้วยข้อมูลจริง

ลงมือ (1) — รันบน BENTO Emulator

ไม่มีบอร์ดก็เริ่มได้ (Emulator จำลองค่า temp/humidity ให้):

1. เปิด ide.tesaiot.dev (BENTO Emulator) ในเบราว์เซอร์
2. เปิดไฟล์ s07_rule_classifier.py
3. เติมช่องว่างทั้ง 4 จุดตามคำใบ้ # เติม:
4. กด Run — จะเห็นสามการ์ด (ค่าดิบ / derived / คำตัดสิน) + การ์ดคำตัดสินโชว์คลาสพร้อมสี
5. สังเกตว่าเมื่อค่าจำลองเปลี่ยน คลาสที่ชนะเปลี่ยนคำ+เปลี่ยนสีตาม

Emulator ใช้ค่าจำลองแต่ dsp.dew_point / heat_index / comfort_zone คำนวณด้วยสูตรจริงเหมือนบอร์ด — เหมาะกับซ้อมตรรกะบันไดกฎที่บ้าน

หน้าตา Emulator ที่เราจะใช้

BENTO Edge AI Emulator คือจอ emulator ที่รันได้จริงในเบราว์เซอร์ ไม่ต้องมีบอร์ดก็เขียนโค้ดแล้วเห็นผลบนจอจำลองได้ทันที

• ซ้าย: หน้าต่างเขียนโค้ด MicroPython (เปิด s07_rule_classifier.py ที่นี่)
• ขวา: จอจำลอง BENTO ที่จะโชว์การ์ดค่าดิบ / derived / คำตัดสินพร้อมสี เหมือนบอร์ดจริง
• ค่าจากเซนเซอร์เป็นค่าจำลอง แต่ dsp.* คำนวณด้วยสูตรฟิสิกส์จริง ตรรกะบันไดกฎจึงซ้อมได้เหมือนอยู่หน้าบอร์ด

เปิดที่ ide.tesaiot.dev ได้เลย เครื่องใครก็รันได้ ไม่ต้องลงอะไร — เหมาะมากสำหรับกลับไปซ้อมต่อที่บ้าน

ลงมือ (2) — รันบนบอร์ด BENTO จริง (AI Kit)

บนบอร์ดจริงใช้เซนเซอร์จริง DPS368 + SHT40 บน AI Kit:

1. เสียบบอร์ด AI Kit เข้าคอมด้วยสาย USB (ชุดบทเรียนนี้ต้องเป็น AI Kit เพราะ Eva Kit ไม่มี SHT40/DPS368)
2. เปิด s07_rule_classifier.py ใน BENTO IDE กด Program to Device
3. หายใจรดเซนเซอร์ → ความชื้นพุ่ง ดูคลาสขยับไป humid
4. กำบอร์ดไว้ในมือสักครู่ → อุณหภูมิ+heat index ขึ้น ดูคลาสขยับไป hot
5. เป่าลมเย็น / พาไปที่แอร์ → ดูคลาสกลับมา comfortable หรือ cold

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

ลงมือทำ — เติมช่องว่างทั้ง 4 จุด

เปิด s07_rule_classifier.py มี pass วางไว้ 4 จุด ตรงที่ต้องเติมตรรกะจริง:

ขั้นตอน:

1. ไล่หา # เติม: ทีละจุด แทน pass (และค่าตั้งต้น) ด้วยโค้ดจริงตามคำใบ้
2. กด Run (Emulator) หรือ Program to Device (บอร์ด)
3. หายใจ/กำบอร์ด ดูคลาสเปลี่ยน ถ้าไม่ขึ้น กลับมาเช็ก indent กับลำดับชั้นในบันได

สี่ช่องนี้คือ pipeline ย่อของ classifier ทั้งตัว: แปลง (1,2) → ตัดสิน (3) → แสดง (4) เติมครบเมื่อไร คุณมี classifier ตัวแรกที่เข้าใจทุกบรรทัด

กฎมือ "อธิบายได้" — จุดแข็งที่ ML ยังตามยาก

จุดแข็งที่สุดของบันไดกฎคือ ทุกคำตัดสิน สืบย้อนได้ว่าชั้นไหนยิงออกมา ในฉบับเต็มเราให้ classify() คืนเหตุผลด้วย:

def classify(t, h, hi):
    if hi >= HI_DANGER:
        return "danger", "feels-like %.0f >= %.0f" % (hi, HI_DANGER)
    ...

• จอโชว์ why: feels-like 43 >= 41 — ผู้ใช้/วิศวกรเห็นเลยว่าทำไมถึงตัดสิน danger
• นี่คือ explainability ที่งานความปลอดภัย/การแพทย์ต้องการ: ตอบได้ว่า "ทำไม" ไม่ใช่แค่ "อะไร"
• ML ทั่วไปตอบ "ทำไม" ยากกว่ามาก (เป็นน้ำหนักในเครือข่าย) — เป็นเหตุผลจริงที่หลายระบบยังเลือกกฎ

เวลาเลือกระหว่างกฎกับ ML อย่าถามแค่ "อันไหนแม่นกว่า" ถามด้วยว่า "เราต้องอธิบายคำตัดสินได้ไหม" — บางงานคำตอบข้อนี้สำคัญกว่าความแม่นเสียอีก

ข้อจำกัดของกฎมือ — สะพานไปสู่ ML

กฎมือดีในหลายงาน แต่มันชนกำแพงเมื่อ pattern ซับซ้อนขึ้น — นี่คือเหตุผลที่คอร์สนี้พาไปต่อที่ Training:

• กฎบาน — จาก 2 ตัวแปร (t, h) ยังพอไล่ if ไหว แต่กับ 50 feature ของเสียง/การสั่น การเขียนกฎมือแทบเป็นไปไม่ได้
• เส้นแบ่งมนุษย์ตั้งอาจไม่ดีที่สุด — เราเดา 41, 32 จากมาตรฐาน แต่ข้อมูลจริงอาจบอกว่าเส้นที่ดีกว่าอยู่ตรงอื่น
• ไม่ปรับตามข้อมูลใหม่ — อากาศบ้านคุณกับในตำราต่างกัน กฎมือไม่รู้ ต้องแก้เอง ML เรียนใหม่ได้

วันนี้คุณจะได้ยินตัวเองพูดว่า "ถ้าเงื่อนไขเยอะกว่านี้ เขียน if ไม่ไหวแน่" — ความรู้สึกนั้นแหละคือ แรงจูงใจที่แท้จริงของ ML เก็บมันไว้ เดี๋ยวเราไปปลดล็อกกันที่ โมดูล 5 (Training)

แหล่งเรียนรู้เพิ่มเติม

อยากต่อยอดเรื่อง derived metric และการจำแนกด้วยกฎ ลองตามลิงก์เหล่านี้ (เปิดดูได้ตามสะดวก):

วิดีโอ (ช่องการศึกษาที่เชื่อถือได้)

• Decision Trees อธิบายชัดเจน (บันไดเงื่อนไขแบบที่ ML เรียนเส้นแบ่งเอง) — ช่อง StatQuest: https://www.youtube.com/@statquest
• จาก if-then สู่การเรียนรู้ของเครื่อง (ภาพรวมการจำแนก) — ช่อง 3Blue1Brown: https://www.youtube.com/@3blue1brown
• อัลกอริทึมและตรรกะเงื่อนไขในระบบจริง — ช่อง Computerphile: https://www.youtube.com/@Computerphile

ภาพ / บทความอ้างอิง

• จุดน้ำค้าง (Dew point) พร้อมสูตร Magnus: https://en.wikipedia.org/wiki/Dew_point (ที่มา: Wikipedia, CC BY-SA)
• ดัชนีความร้อน (Heat index) พร้อมตาราง NOAA: https://en.wikipedia.org/wiki/Heat_index (ที่มา: Wikipedia, CC BY-SA)
• ตารางดัชนีความร้อนของ NOAA: https://www.weather.gov/safety/heat-index (ที่มา: NOAA National Weather Service)

วิดีโอ/ภาพภายนอกเป็นของเจ้าของต้นฉบับ ใช้เพื่อการศึกษา อ้างอิงลิงก์ต้นทาง

ชัยชนะที่เห็นได้ + MVP ของชุดบทเรียนนี้

MVP ของบทเรียน 3.3–3.4 (เกณฑ์ผ่านของชุดบทเรียน): คุณเขียน classify() ด้วยบันไดกฎเอง แล้วบอร์ด/Emulator โชว์คลาสที่เปลี่ยนตามจริง เมื่อ temp/humidity เปลี่ยน (หายใจรด/กำบอร์ด)

• ใช้ derived metric อย่างน้อยหนึ่งตัว (heat_index หรือ dew_point) ในการตัดสิน
• อธิบายได้ว่าบันไดกฎ ลำดับชั้นสำคัญยังไง และคลาสไหนตัดสินจากค่าอะไร

"ตัดสินได้" ไม่ใช่แค่ "เห็นตัวหนังสือเปลี่ยน" — คุณต้องชี้ได้ว่าคลาส hot มาจากเงื่อนไข hi >= 32 และบอกได้ว่าทำไมใช้ hi ไม่ใช่ t

บันไดช่วยเหลือ — ใบ้ → เริ่มจากโครง → เฉลย → ฉบับเต็ม

ถ้าติด ให้ไต่บันไดนี้ทีละขั้น อย่าเพิ่งกระโดดไปดูเฉลย เพราะของจะเข้าหัวตอนที่คุณพยายามเองก่อน:

• ใบ้ — คำใบ้อยู่ในคอมเมนต์ # เติม: ทั้ง 4 จุด + ตารางหน้าที่แล้ว บอกว่าแต่ละช่องเติมอะไร
• เริ่มจากโครง — s07_rule_classifier.py มีโครงครบทั้งไฟล์ เหลือแค่ 4 จุดให้เติม (บันไดกฎยาวสุด)
• เฉลย — s07_rule_classifier.py เติมครบพร้อมคอมเมนต์อธิบายทุกชั้น (อ่านให้เข้าใจ ปิดไฟล์ แล้วพิมพ์เอง)
• ฉบับเต็ม — s07_rule_classifier_full.py เพิ่ม rule trace (why), เทียบกฎสำเร็จรูปพร้อมไฟตรง/ต่าง, และฮิสเทอรีซิสกันคลาสกระพริบ

ลองเขียนบันไดกฎเองให้สุดก่อนนะ พลาดลำดับชั้นก็ไม่เป็นไร นั่นแหละคือจุดที่เราจะได้เรียนรู้เรื่อง dead branch ด้วยกัน

เชื่อมโยงรากฐาน — วันนี้เราแตะอะไรไปบ้าง

การเขียน classifier ด้วยกฎ ซ่อนแนวคิดที่จะใช้ยาวไปถึง โมดูล 5 (Training) และ Apps:

ฝั่ง Edge AI / การจำแนก

• Classifier = ตัวเลข → คลาส — รูปเดียวกับโมเดล ML ต่างที่ "ข้างใน"
• Derived metric / feature — แปลงค่าดิบให้ตัดสินง่ายขึ้น (dew point, heat index) = feature engineering
• Threshold ladder — เส้นแบ่งหลายชั้น ลำดับสำคัญ; ตั้งเส้นเอง = hyperparameter ของกฎ
• Explainability — กฎอธิบายคำตัดสินได้ทุกครั้ง (จุดแข็งเหนือ ML หลายงาน)

ฝั่ง MicroPython / โครงโปรแกรม

• โครงร่วม — import → สร้างครั้งเดียว → ลูป (อ่าน→แปลง→ตัดสิน→วาด) → ui.poll
• สร้าง widget ครั้งเดียว — ในลูปแค่ .text() / .color() จอไม่กระพริบ
• ค่าคงที่รวมที่เดียว — เส้นแบ่งเป็นตัวแปรชื่อชัด ปรับที่เดียวขยับทั้งกฎ (ไม่ฝัง magic number)

ทั้งหมดนี้คือฐานของ ML: พอเข้าใจว่ากฎมือ "ตั้งเส้นแบ่งเอง" แล้ว คุณจะเข้าใจทันทีว่า ML คือการ "ให้เครื่องหาเส้นแบ่งจากข้อมูลแทนเรา" — คนละวิธี งานเดียวกัน

ใช้จริงที่ไหน — กฎ threshold ในโลกจริง

classifier แบบกฎไม่ใช่ของเล่นในห้องเรียน มันคือหัวใจของอุปกรณ์ควบคุมนับล้านชิ้นที่ทำงานอยู่ตอนนี้:

สังเกตข้อ 3: บางงาน กฎหมายกำหนดเส้นแบ่งไว้แล้ว (เช่นค่า WBGT เตือนความร้อน) งานพวกนี้ต้องใช้กฎ ไม่ใช่ ML เพราะต้องตรงตามเกณฑ์เป๊ะและอธิบายได้ — วิศวกรที่ดีเลือกเครื่องมือให้ตรงงาน

งานทำเอง + สรุปบทเรียน

งานทำเอง (ท้ายบทเรียน):

1. เติม s07_rule_classifier.py ให้ครบทั้ง 4 จุด รันได้จริง (Emulator หรือ AI Kit)
2. ทำให้เกิดคลาสอย่างน้อย 3 คลาสต่างกัน (เช่น หายใจรด→humid, กำบอร์ด→hot, ปกติ→comfortable) แล้วจดว่าต้องทำอะไรถึงได้แต่ละคลาส
3. ปรับเส้นแบ่งหนึ่งเส้น (เช่น เปลี่ยน hi >= 32 เป็น >= 30) แล้วอธิบายว่าคำตัดสินเปลี่ยนยังไง และทำไม

ใบ้ข้อ 3 — ลองหาค่าที่ "คร่อมเส้น" (เช่น heat index ~31–33) แล้วดูว่าเปลี่ยนเส้นแบ่งเล็กน้อยพลิกคำตัดสินได้จริง นี่คือสัมผัสแรกของ "การจูนเส้นแบ่ง" ที่ ML ทำอัตโนมัติในชุดบทเรียนหลัง

วันนี้เราได้: เข้าใจว่า classifier คืออะไร · แปลงค่าดิบเป็น derived metric (dew_point/heat_index) · เขียนบันไดกฎ threshold เอง · เห็นจุดแข็ง (อธิบายได้) และจุดอ่อน (กฎบาน) ของกฎมือ ที่ปูทางสู่ ML

ชุดบทเรียนถัดไป (บทเรียน 4.1–4.2) เราเข้าสู่ Pillar 3 · Analysis — เริ่มจากตัวกรองสัญญาณ (EMA/median/Kalman) ทำสัญญาณสั่นๆ ให้เนียนขึ้นแบบเห็นกับตา เจอกันครับ