คาบ 11 — MQTTs (serverTLS) สู่แพลตฟอร์ม IoT

	คำถาม	คำตอบของคาบนี้	อยู่ช่วงไหน
Why	คาบ 10 ส่งขึ้น broker ได้แล้ว ทำไมต้องย้ายพอร์ตอีก	เพราะพอร์ต 1883 ไม่ได้ "ปลอดภัยน้อยกว่า" — มันไม่มีความปลอดภัยเลย รหัสผ่านของทีมเดินเป็นข้อความเปล่าให้ทุกคนในเครือข่ายเดียวกันอ่านได้ · และคาบนี้เป็นคาบแรกที่คำตอบที่ถูกที่สุดคือ "ได้ แต่แค่ระดับนี้"	ครึ่งแรก · ใบรับรอง · ห่วงโซ่ความเชื่อถือ · SNI
What	มีอะไรให้ใช้บ้าง	`import tesaiot` ได้มา 28 ชื่อ — ใช้ได้จริง เก้าตัว เหมือนกันทั้ง Eva Kit และ Dev Kit · สิบหกตัวข้ามคอร์ไปหาชิปที่เฟิร์มแวร์ของคอร์จอไม่ได้เปิดไว้ จึงได้ `OSError` (เวลาที่เสียไปยังไม่ได้วัดจริง) · อีกสามตัวเป็นคนละเรื่องกัน และหนึ่งในนั้น (`protected_update`) ห้ามเรียก เพราะบน Dev Kit มันเขียนลงชิปจริง	สไลด์ 28 ชื่อ + ตารางเต็มของเก้าตัวที่ใช้ได้
How	ประกอบยังไงให้ใช้งานได้จริง	ตั้งตัวตนด้วย `config_set()` → สั่ง `connect()` แล้ว วนรอจน `is_connected()` เป็นจริง เพราะฟังก์ชันคืนค่าไม่ได้แปลว่างานเสร็จ → `publish()` → เอาหลักฐานขึ้นจอ	หกไฟล์ตัวอย่าง + ใบฝึก

	คาบ 10 · 1883	วันนี้ · 8884
การเข้ารหัส	ไม่มีเลย	TLS 1.2
ตัวตนของ broker	ไม่มีการพิสูจน์	ใบรับรองที่ CA เซ็น + ตรวจ SNI
ตัวตนของอุปกรณ์	client_id ที่ใครก็อ้างได้	credentials ที่ provision รายทีม
ปลายทาง	CE ที่ทีมติดตั้งเอง	แพลตฟอร์ม TESAIoT
โมดูล	`mqtt`	`tesaiot`

เรียกอย่างไร	คืนอะไร	สิ่งที่ต้องรู้
`tesaiot.config()`	dict 19 คีย์	คีย์ครบชุด: `tls_mode` `device_id` `factory_uid` `api_key` `broker` `port` `sni_hostname` `qos` `keepalive` `timeout_ms` `max_retries` `retry_interval_ms` `api_host` `api_port` `api_endpoint` `wifi_ssid` `sntp_server` `sntp_timezone` `debug_level`
`tesaiot.config_set(key, value)`	`True` / `False`	รับ สตริงทั้งสองช่อง ตัวเลขก็ต้องส่งเป็นสตริง · คีย์ผิดคืน `False` เงียบ ๆ ต้องรับค่ากลับมาดู · ตั้ง `"tls_mode","server_tls"` แล้วอ่านกลับได้ `"serverTLS"` เพราะมันแปลงชื่อให้
`tesaiot.config_reset()`	`None`	ล้างกลับเป็นค่าโรงงาน ทั้ง 19 คีย์ ตัวตนของทีมหายหมด ต้องตั้งใหม่ทุกค่า
`tesaiot.config_reload()`	`True` / `False`	อ่านไฟล์ตั้งค่าจากแฟลชขึ้นมาใหม่ ทับค่าที่แก้ไว้ในหน่วยความจำ · ใช้ทิ้งการแก้ที่ยังไม่พอใจ
`tesaiot.connect()`	`True` / `False`	`True` แปลว่า งานเริ่มแล้ว ไม่ใช่ต่อเสร็จแล้ว ต้องวนรอ `is_connected()` เอง
`tesaiot.disconnect()`	`True` / `False`	ตัวนี้คืน bool ไม่เหมือน `mqtt.disconnect()` ที่คืน `None` — สองโมดูลไม่เหมือนกัน
`tesaiot.is_connected()`	`True` / `False`	ตัวจริงที่ตอบว่าต่อเสร็จหรือยัง
`tesaiot.publish(payload, topic=None)`	`True` / `False`	payload มาก่อน topic และ topic ใส่หรือไม่ใส่ก็ได้ ไม่ใส่แล้วเฟิร์มแวร์ประกอบให้จาก `device_id`
`tesaiot.slots()`	dict 13 คู่	ตอบได้ทันทีโดยไม่แตะชิป เพราะเป็นตารางชื่อในซอร์ส · ช่อง 4 ถูกกันไว้ จึงไม่อยู่ในรายการ

วิธีรันบนบอร์ด

เปิดหน้า BENTO Playground บนบอร์ดค้างไว้ แล้วต่อ WiFi ให้เรียบร้อยก่อน (wifi.connect() ของคาบ 9 บล็อกได้นานถึงราว 85 วินาทีถ้ารหัสผิด)
เปิด practise_codes/s11_secure_telemetry.py^↗ แก้ห้าบรรทัดบนหัวไฟล์ให้เป็นค่าของทีม
เติมช่องว่างท่าที่ 1 ให้ครบ กด Program to Device แล้วดูว่า print(tesaiot.config()) ขึ้นค่าครบและสะกดถูก ก่อน ไปท่าที่ 2
เติมท่าที่ 2 แล้วรัน — จับเวลาว่ากี่วินาที is_connected() จึงเป็น True แล้วจดลงใบงานข้อ 4.2
เติมท่าที่ 3 และ 4 แล้วเปิด dashboard ของแพลตฟอร์ม เลือกอุปกรณ์ของทีม ดูกราฟขยับพร้อมกับตัวนับบนจอบอร์ด
ถ่ายภาพทั้งสองจอเก็บไว้เป็นหลักฐาน แล้วค่อยไปทำตารางเทียบข้อ 4.3

ตัวอย่างชุดคาบ 11 — สามไฟล์แรกคือชุดที่ย้ายลูปส่งข้อมูลขึ้นช่องที่เข้ารหัส

ต้องทำในคาบ · เปิดตามลำดับนี้ ทั้งชุดราว 29 นาที

ลำดับ · เรื่อง · เวลา	ไฟล์	ลงมือทำอะไร แล้วจะเข้าใจอะไร
1 · อ่านค่าที่บอร์ดเก็บไว้ก่อนต่ออะไร · 6 นาที	`examples/s11/01_config_store.py`^↗	กรอกกล่องข้อ 4.1 จากค่าที่บอร์ดตอบจริง ไม่ใช่จากใบที่ผู้สอนแจก · จะเข้าใจว่าต้องอ่านค่าที่บอร์ดเก็บไว้ให้ครบก่อน แล้วค่อยสั่งต่ออะไร
2 · รอให้ต่อเสร็จเป็น · 8 นาที	`examples/s11/05_wait_for_connected.py`^↗	เขียนลูปรอด้วย `is_connected()` และจับเวลาจริงลงใบงานข้อ 4.2 · จะเข้าใจว่า `connect()` คืนค่าก่อนต่อเสร็จ จึงต้องรอเป็น ไม่ใช่เชื่อว่าคืนค่าแล้วคือพร้อม
3 · ลูปส่ง telemetry บนช่องที่เข้ารหัส · 15 นาที	`examples/s11/06_secure_publish_loop.py`^↗	ประกอบ MVP ของคาบนี้ — ตัวนับเดินขึ้นบนจอ พร้อมกราฟที่ขยับบน dashboard · จะเห็นว่าลูปส่ง telemetry ตัวเดิมย้ายขึ้นช่องที่เข้ารหัสได้ โดยรูปร่างของลูปไม่เปลี่ยน

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

ติดตรงไหน เปิดอันนี้

อาการที่เจอ	ไฟล์ที่ตอบอาการนั้น
ต่อไม่ติด และแยกไม่ออกว่าติดที่ WiFi หรือที่แพลตฟอร์ม	`examples/s09/04_ping_two_targets.py`^↗ — พิสูจน์ให้จบก่อนว่าออกอินเทอร์เน็ตได้จริง แล้วค่อยโทษ TLS
ตอบไม่ได้ว่าวันนี้ต่างจากคาบ 10 ตรงไหน	`examples/s10/03_connect_and_publish.py`^↗ — เปิดคู่กับไฟล์ที่ 3 ข้างบน แล้วเทียบทีละบรรทัดว่าอะไรเปลี่ยน

อ่านเสริมนอกเวลา — เรื่องนี้อยู่นอกเกณฑ์ผ่านของคาบ 11 แต่เป็นนิสัยที่ใช้ได้ทั้งคาบ 10 และคาบนี้: examples/s10/06_sent_is_not_delivered.py^↗ สอนให้นับใบที่ ถึงปลายทาง ไม่ใช่นับใบที่เราสั่งส่ง · ส่วนตัวอย่างที่เทียบ 1883 กับ 8884 ให้เห็นด้วยตาว่า TLS ปกป้องอะไร ยังไม่มีในคลัง วันนี้จึงใช้ตารางข้อ 4.3 กับผลดักฟังในสไลด์แทน

ก่อนหน้านี้คาบนี้มีตัวอย่างอีกสามไฟล์ที่บันทึกพฤติกรรมแปลกของ tesaiot.config() ไว้ (ตั้งค่าแล้วอ่านกลับได้อีกคำ · พิมพ์ผิดแล้วยังคืน True · คีย์ port ที่ไม่มีใครอ่าน) ทั้งสามถูกถอดออก เพราะเป็นรายงานบั๊กของเฟิร์มแวร์ ไม่ใช่นิสัยที่เอาไปใช้กับงานตัวเองได้ ความจริงเรื่องพอร์ตยังอยู่ในสไลด์ "พอร์ตมาจาก tls_mode ไม่ใช่คีย์ port" และในตารางกับดัก

อย่าเติมครบทั้งห้าจุดแล้วค่อยรัน — บนเส้นทางที่มี TLS อยู่ตรงกลาง จุดที่พังได้มีมากกว่าคาบที่แล้ว และไม่มีจุดไหนส่งเสียงเลย

อาการ	สาเหตุที่แท้จริง	วิธีแก้
ต่อไม่ติด ไม่มีข้อความอะไรเลย	`sni_hostname` ไม่ตรงกับ `broker` เซิร์ฟเวอร์ยื่นใบผิดใบ	ตั้งสองค่านี้เป็นสตริงเดียวกันเสมอ
ต่อไม่ติดกับ CE ที่ทีมติดตั้งเอง	CE สุ่ม root CA ใหม่ทุกการติดตั้ง บอร์ดฝัง CA ของแพลตฟอร์มไว้	ใช้โฮสต์ที่ผู้สอนให้ — MQTTs เข้า CE ต้อง build เฟิร์มแวร์ใหม่
ตั้ง `port` แล้วพอร์ตไม่เปลี่ยน	พอร์ตมาจาก `tls_mode` คีย์ `port` เปลี่ยนแค่ป้ายที่แสดง	ดู `tls_mode` เป็นคำตอบ อย่าดูคีย์ `port`
`publish()` ไม่ error แต่ไม่มีข้อมูลบนแพลตฟอร์ม	ยิงก่อน `is_connected()` เป็น True เพราะ `connect()` เป็น async	วนรอด้วย `while not tesaiot.is_connected()` พร้อม timeout
โปรแกรมค้างตรงลูปรอ ไม่ไปไหนเลย	ลูปรอไม่มี timeout วันที่เน็ตล่มจึงวนตลอดกาล	`time.ticks_diff()` เกิน 30000 ms แล้ว `break`
ทั้งห้องหลุดสลับกันเป็นจังหวะ	หลายทีมใช้ `device_id` ค่าเริ่มต้นตัวเดียวกัน broker เตะตัวเก่าออก	หนึ่งทีมหนึ่ง `device_id` ที่ provision มา
ข้อมูลขึ้นแต่ไม่มีเส้นกราฟ	ส่งค่าเป็นสตริง	ส่งตัวเลขจริง ไม่ใช่ `"25.5"`
ชื่อวัดขึ้นต้นด้วย `data_` และไม่มีหน่วย	ห่อ payload เองด้วย `{"data": ...}`	ส่งแบน bridge ห่อให้เองอยู่แล้ว

อาการ	สาเหตุที่แท้จริง	วิธีแก้
เรียก `device_id()` `health()` `random()` แล้วได้ `OSError` "... failed"	ตัวในกลุ่มสิบหกส่ง IPC ไปคอร์จอ ซึ่งทั้ง Eva และ Dev Kit ประกอบมาโดยไม่มี OPTIGA — คอร์จอตอบ "ไม่มีให้" กลับมา (เวลาที่เสียไปยังไม่ได้วัดจริง)	อย่าเรียกกลุ่มนั้นบนบอร์ดไหนเลย · อยากคุยกับชิปจริงให้ใช้โมดูล `optiga` แทน
บน Dev Kit เรียก `tesaiot.protected_update()` แล้วคืน `True` ไม่มี error	ฟังก์ชันนี้ทำงานจริงบน Dev Kit (`ENABLE_OPTIGA_CLM=1`) — มันขอชุด Protected Update จากแพลตฟอร์มแล้วเขียนใบรับรองลงชิป OPTIGA	ห้ามเรียกในคาบนี้ ทั้งสองบอร์ด — บน Eva ได้ `OSError` แต่บน Dev Kit สิ่งที่เขียนลงชิปย้อนกลับจากในห้องเรียนไม่ได้
`publish()` คืน True แต่ข้อมูลไปโผล่ผิด topic	สลับลำดับเป็น `tesaiot.publish(topic, payload)` ตามความเคยชินจากคาบ 10	ตัวนี้ payload มาก่อน เขียน `tesaiot.publish(json.dumps(payload))`
ตั้ง `tls_mode` เป็น `"server_tls"` แล้วอ่านกลับได้คนละคำ	เฟิร์มแวร์แปลงชื่อโหมดให้เป็น `"serverTLS"`	ปกติ ไม่ใช่บั๊ก เทียบค่าด้วยคำที่อ่านกลับมา อย่าเทียบกับคำที่เราส่งไป
`if tesaiot.disconnect():` ทำงาน แต่ `if mqtt.disconnect():` ไม่เคยจริง	สองโมดูลคืนคนละชนิด ตัวแรกคืน bool ตัวหลังคืน `None`	อย่าจำรวมกัน เปิดตารางดูทุกครั้งที่สลับโมดูล

คาบ 11 — MQTTs (serverTLS)

จากพอร์ต 1883 ที่ใครก็อ่านได้ ไปพอร์ต 8884 ที่รู้ว่ากำลังคุยกับใคร

ดูของจริงก่อน — รหัสผ่านของทีมเราบนหน้าจอคนอื่น

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

เป้าหมายของคาบนี้

ปลายทางของคาบนี้ — ข้อความเดิม แต่เดินในท่อที่เข้ารหัสแล้ว

ทบทวนคาบ 10 — เราหยุดไว้ตรงไหน

ก่อนเริ่มคาบ — ทุกทีมต้องมีตัวตนของตัวเอง

กุญแจ ลายเซ็น และแฮช — สามชิ้นที่ TLS ประกอบขึ้นมา

ใบรับรองคืออะไรกันแน่ — เปิดดูข้างในทีละช่อง

ห่วงโซ่ความเชื่อถือ — root → intermediate → leaf

การจับมือ TLS ทีละขั้น — ในภาษาที่เราใช้กันจริง

เกร็ด: TLS 1.3 ตัดรอบไป-กลับออกไปหนึ่งรอบ

SNI — ชื่อที่เดินไปก่อนการเข้ารหัส

เข้าใจฮาร์ดแวร์ · TLS วิ่งอยู่ตรงไหนบนบอร์ด

กลไกหลักของคาบ — พอร์ตมาจาก tls_mode ไม่ใช่คีย์ port

ทำไม MQTTs ยิงเข้า CE ที่ทีมติดตั้งเองไม่ได้

serverTLS พิสูจน์ตัวตนได้ข้างเดียว

1883 กับ 8884 — ตารางที่ทีมต้องกรอกให้ได้เอง

เรื่องที่เราให้ 70% น้อง ๆ เขียน 30%

import tesaiot ได้มา 28 ชื่อ — ใช้ได้จริงเก้าตัว ทั้ง Eva Kit และ Dev Kit

เก้าตัวที่ใช้ได้ — ตารางเต็มพร้อมกับดักของแต่ละตัว

แกะโค้ดจริง — ท่าที่ 1 ตั้งค่าตัวตนของอุปกรณ์

แกะโค้ดจริง — ท่าที่ 2 สั่งต่อ แล้ววนรอจนต่อเสร็จจริง

แกะโค้ดจริง — ท่าที่ 3 และ 4 ส่งค่าจริง แล้วโชว์หลักฐานบนจอ

ข้อมูลไหลไปทางไหน — ตั้งแต่เซนเซอร์ถึงกราฟ

อีกสี่ตัวที่โครงหลักไม่ได้เรียก — แต่ต้องเคยลอง

วิธีรันบนบอร์ด

ตัวอย่างชุดคาบ 11 — สามไฟล์แรกคือชุดที่ย้ายลูปส่งข้อมูลขึ้นช่องที่เข้ารหัส

MVP checkpoint — ผ่านคาบนี้เมื่อ

กับดักที่เจอบ่อย

กับดักที่เจอบ่อย (ต่อ) — ขอบเขตของโมดูล tesaiot

ลงมือทำ — เติมช่องว่างในไฟล์ฝึก

โบนัส · ตัวตนที่ฝังอยู่ในซิลิคอน (สาธิต ไม่คิดคะแนน)

เชื่อมโยงรากฐาน + สรุปคาบ

เฉลย s11_secure_telemetry.py↗ — ส่วนที่หนึ่ง

เฉลย — ตัวตนที่ตั้งไว้ ต้องมองเห็นได้ ไม่ใช่เชื่อเอา

เฉลย — ส่วนที่สอง: ลูปหลัก

เฉลย — ทำไมเรียงสี่ท่าแบบนี้

เชื่อมจุดให้เห็นภาพ — วันนี้อยู่ตรงไหนของเส้นทาง

ใช้จริงที่ไหน — สี่มุมที่ TLS ทำงานอยู่ตอนนี้

ดูเพิ่มเติมนอกเวลา — วิดีโอที่ตรวจแล้วว่าเปิดได้

ต่อยอด — คิดต่อเอง (เลือกทำ 1 ข้อ)

ปิดวงจร — ค่าที่วัดได้จริง ออกไปแบบที่คนกลางอ่านไม่ได้

หน้าจอของทุกไฟล์ในคาบนี้ (1/2)

หน้าจอของทุกไฟล์ในคาบนี้ (2/2)

อ้างอิงและเครดิต

กลไกหลักของคาบ — พอร์ตมาจาก `tls_mode` ไม่ใช่คีย์ `port`

`import tesaiot` ได้มา 28 ชื่อ — ใช้ได้จริงเก้าตัว ทั้ง Eva Kit และ Dev Kit

กับดักที่เจอบ่อย (ต่อ) — ขอบเขตของโมดูล `tesaiot`

เฉลย `s11_secure_telemetry.py`^↗ — ส่วนที่หนึ่ง