บทเรียน 4.8 — โมดูล tesaiot: MQTTs สู่แพลตฟอร์ม

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

สิ่งที่ทำให้แล้ว (70%)
การจับมือ TLS ทั้งหมด · การตรวจใบรับรองย้อนขึ้นไปถึง root · root CA ที่ฝังมากับเฟิร์มแวร์ · การเลือกพอร์ตจาก tls_mode · การประกอบ topic จาก device_id · ฝั่งแพลตฟอร์ม: broker EMQX, บริดจ์ที่รอ subscribe อยู่แล้ว, ฐานข้อมูลอนุกรมเวลา และกราฟที่สร้างจากชื่อคีย์ JSON อัตโนมัติ

สิ่งที่เป็นงานของเรา (30%)
ตั้งค่าตัวตนของอุปกรณ์ให้ถูกทั้งสี่ค่า · รอให้การเชื่อมต่อเสร็จจริงก่อนส่ง · เลือกว่าจะส่งฟิลด์อะไรเป็นตัวเลข · และแสดงหลักฐานบนจอให้คนอื่นตรวจได้โดยไม่ต้องเปิดโค้ด

ยิ่งไลบรารีทำให้เยอะ ความผิดพลาดที่เหลือยิ่ง เงียบ — เพราะสิ่งที่เหลือให้เราพลาดคือเรื่องที่ไลบรารีไม่มีทางรู้ว่าเราตั้งใจอะไร

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

พูดให้ตรง: ทั้งสองบอร์ดประกอบเฟิร์มแวร์ของคอร์จอด้วย ENABLE_OPTIGA ?= 0 สิบหกคำสั่งที่ข้ามคอร์จึงไม่มีชิปให้คุย · ซอร์สบอกว่าคอร์จอตอบ "ไม่มีให้" กลับมาโดยไม่รอชิป แล้วฝั่ง Python โยน OSError พร้อมข้อความ (เพดานรอ 10 วินาทีมีไว้กรณีคอร์จอไม่ตอบเลย) — ยังไม่ได้วัดเวลาจริงบนบอร์ดไหน ลอง t=time.ticks_ms(); tesaiot.health(); print(time.ticks_diff(time.ticks_ms(), t)) บนโต๊ะก่อนสอน แล้วบอกผู้เรียนด้วยตัวเลขที่วัดได้

เรื่องเดียวที่สองบอร์ดต่างกันจริง คือ tesaiot.protected_update() — บน Eva ไม่ได้ถูกคอมไพล์เข้ามา (OSError) แต่บน Dev Kit (ENABLE_OPTIGA_CLM=1) มันทำงานจริง: ขอชุด Protected Update จากแพลตฟอร์มแล้วเขียนใบรับรองลงช่อง E0E1 ของชิป OPTIGA และ csr=True สร้างคู่กุญแจใหม่ทับของเดิม — ห้ามเรียกในชุดบทเรียนนี้ ทั้งจากไฟล์ตัวอย่างและ REPL เพราะสิ่งที่เขียนลงชิปย้อนกลับเองไม่ได้

ชิป OPTIGA มีอยู่จริงและใช้ได้ ผ่านโมดูล optiga (สไลด์โบนัสท้ายบทเรียน) — Eva: I2C จาก CM33 ตรง ๆ · Dev Kit: ชิปอยู่บนบัสจอของ CM55 จอหยุดรับสัมผัสชั่วครู่ทุกครั้งที่เรียก และยังไม่ได้ตรวจว่าทุกบอร์ดมีชิปครบ — ลอง optiga.uid() ก่อน

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

tesaiot.publish() กับ mqtt.publish() สลับลำดับกัน — ชุดบทเรียนก่อนหน้าเขียน mqtt.publish(topic, payload) วันนี้เขียน tesaiot.publish(payload) สลับเมื่อไรได้ผลประหลาดทันทีโดยไม่มี error เพราะทั้งสองช่องรับสตริงเหมือนกัน

config_set() เก็บค่าไว้เฉย ๆ ยังไม่ได้ต่ออะไรทั้งนั้น พิมพ์คีย์ผิดจะไม่มีใครเตือนจนกว่าจะต่อไม่ติด — จึงต้อง print(tesaiot.config()) หนึ่งครั้งหลังตั้งค่าเสมอ

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

# --- ท่าที่ 1: ตั้งค่าตัวตนของอุปกรณ์ ---
tesaiot.config_set("device_id", DEVICE_ID)
tesaiot.config_set("api_key", API_KEY)
tesaiot.config_set("mqtt_pass", MQTT_PASS)
tesaiot.config_set("broker", BROKER)
tesaiot.config_set("sni_hostname", BROKER)     # ต้องเป็นชื่อเดียวกับ broker
print("config ปัจจุบัน:", tesaiot.config())

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

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

# --- connect() เป็น API แบบ asynchronous ---
tesaiot.connect()                       # คืนค่าทันที ยังไม่ได้แปลว่าต่อแล้ว
t0 = time.ticks_ms()
...
while not tesaiot.is_connected():       # ตัวจริงที่ตอบได้คือ is_connected()
    waited = time.ticks_diff(time.ticks_ms(), t0)
    if waited > WAIT_CEILING_S * 1000:  # WAIT_CEILING_S = 30 ตัวเลขเดียวกับบนจอ
        print("ต่อแพลตฟอร์มไม่สำเร็จใน 30 วินาที")
        break
    ...
    time.sleep_ms(500)

tesaiot.connect() เป็น API แบบ asynchronous คืนค่าทันทีเพื่อไม่บล็อกโปรแกรม — ค่าที่คืนมา ไม่ใช่สถานะสุดท้าย สิ่งเดียวที่ตอบได้ว่าต่อเสร็จหรือยังคือ tesaiot.is_connected() · โจทย์ต่อ: ให้ลบลูปนี้ออกแล้วรันหนึ่งรอบ — จะเห็นด้วยตาว่า publish ที่ยิงเร็วเกินไป ไม่ error และไม่ถึงแพลตฟอร์ม

"ฟังก์ชันคืนค่าแล้ว" กับ "งานเสร็จแล้ว" เป็นคนละเรื่องเสมอสำหรับ API แบบ async — ความต่างนั้นวัดได้เป็นวินาที

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

m = sensors.bmi270.motion()                       # (ax, ay, az, gx, gy, gz)
payload = {"accel_x": round(m[0], 2),
           "heading": round(sensors.bmm350.heading(), 1),
           "pot": sensors.pot.percent()}
tesaiot.publish(json.dumps(payload))              # ไม่ต้องใส่ topic เฟิร์มแวร์ประกอบให้
cfg = tesaiot.config()
lcd.print("ส่งครั้งที่", sent, "| โหมด", cfg["tls_mode"], "-> 8884")

tesaiot.publish(payload) รับ ตัวข้อมูลอย่างเดียว — ต่างจาก mqtt.publish(topic, payload) ของชุดบทเรียนที่แล้ว เพราะเฟิร์มแวร์ประกอบ topic ให้เองจาก device_id ที่เราตั้งไว้ในท่าที่ 1 (จะระบุ topic เองก็ได้ แต่ชุดบทเรียนนี้ไม่ต้อง) · ส่ง ตัวเลขจริง ไม่ใช่สตริง ไม่งั้น dashboard จะขึ้นค่าแต่วาดกราฟไม่ได้ — กับดักเดียวกับบทเรียน 4.4–4.6

จอบอร์ดต้องตอบคำถาม MVP ได้เอง: ทีมไหน · โหมดอะไร · ส่งไปกี่ครั้งแล้ว สามอย่างนี้ทำให้คนอื่นตรวจงานเราได้โดยไม่ต้องถาม

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

ระบบยาวหกกล่อง แต่การดีบักไม่เคยยาวกว่า "หาให้เจอว่ากล่องสุดท้ายที่ยังเห็นข้อมูลคือกล่องไหน" — ชุดบทเรียนนี้กล่องแรกที่ต้องตรวจคือ is_connected()

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

# --- ล้างแล้วตั้งใหม่: ทางออกเมื่อตั้งค่ามั่วจนไม่รู้ว่าเหลืออะไรอยู่ ---
tesaiot.config_reset()            # คืน None และล้างครบทั้ง 19 คีย์
tesaiot.config_set("device_id", DEVICE_ID)   # ต้องตั้งใหม่ทุกค่า

# --- ทิ้งการแก้ที่ยังไม่พอใจ แล้วดึงของเดิมจากแฟลชกลับมา ---
tesaiot.config_reload()           # True ถ้าอ่านไฟล์ตั้งค่าสำเร็จ

# --- ชื่อช่องเก็บความลับ ตอบได้โดยไม่ต้องแตะชิป ---
print(tesaiot.slots())            # {'device_id': 0, 'license': 1, ...}

# --- ปิดงานให้เรียบร้อย ตัวนี้คืน bool ไม่เหมือน mqtt.disconnect() ---
tesaiot.disconnect()

config_reset() ล้างของจริง ส่วน config_reload() แค่ย้อนกลับไปหาของที่เซฟไว้ — ตั้งค่ามั่วจนงงว่าเหลืออะไรอยู่ ให้ config_reset() แล้วเริ่มใหม่จากศูนย์ ดีกว่าไล่แก้ทีละคีย์ · slots() ตอบได้โดยไม่ต้องข้ามคอร์ไปถามชิป เพราะอ่านตารางชื่อในเฟิร์มแวร์ — แผนที่ว่าถ้าวันหนึ่งเปิด OPTIGA ได้ ความลับแต่ละอย่างจะไปนอนช่องไหน · tesaiot.disconnect() คืน True/False ไม่เหมือน mqtt.disconnect() ที่คืน None อย่าจำรวมกัน

01_config_store.py ไล่คีย์ทั้ง 19 · 02_config_reset_reload.py สองตัวที่สลับกันง่าย · 03_slots_and_the_dead_half.py จับเวลาครึ่งที่ต้องมีชิป · 04_disconnect_and_republish.py ปิดแล้วเปิดใหม่

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

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

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

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

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

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

อ่านเสริมนอกเวลา — เรื่องนี้อยู่นอกเกณฑ์ผ่านของบทเรียน 4.7–4.9 แต่เป็นนิสัยที่ใช้ได้ทั้งบทเรียน 4.4–4.6 และชุดบทเรียนนี้: 06_sent_is_not_delivered.py สอนให้นับใบที่ ถึงปลายทาง ไม่ใช่นับใบที่เราสั่งส่ง · ส่วนตัวอย่างที่เทียบ 1883 กับ 8884 ให้เห็นด้วยตาว่า TLS ปกป้องอะไร ยังไม่มีในคลัง วันนี้จึงใช้ตารางเทียบในบันทึกการเรียน กับผลดักฟังในสไลด์แทน

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

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