คาบ 10 — MQTT (1883)

ดูของจริงก่อน — บอร์ดคุยกับคอมพิวเตอร์คนละเครื่อง

คาบ 9 บอร์ดของเราต่อเน็ตได้แล้ว รู้ IP ของตัวเอง และ ping ออกไปข้างนอกได้ แต่ยังไม่มีใครที่ปลายทาง

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

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

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

ปลายทางที่จับต้องได้ — MQTT Explorer บนคอมเห็นค่าจากบอร์ดทุก 5 วินาที และเราพิมพ์คำสั่งจากคอมกลับไปให้ LED บนบอร์ดสลับสถานะได้

คาบ 9 เราพิสูจน์ว่าสายดี · คาบนี้เราหาคนที่ปลายสายเจอ และคุยกันได้สองทาง

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

1. อธิบายได้ว่า publish/subscribe ต่างจาก client–server ตรงไหน และทำไม IoT ถึงเลือกแบบแรก
2. ออกแบบ topic ของทีม และ JSON payload ที่ขนาดพอเหมาะ พร้อมเหตุผลของทุกฟิลด์
3. ใช้ mqtt.connect() / publish() / subscribe() / get_message() ได้ถูกต้องตามข้อจำกัดจริงของเฟิร์มแวร์
4. ติดตั้ง TESAIoT Community Edition ด้วย Docker แล้วทำให้ข้อมูลของทีมขึ้นกราฟบนแพลตฟอร์มของตัวเอง

ปลายทางของวันนี้: MQTT Explorer เห็นค่าจากบอร์ดทุก 5 วินาที และเราพิมพ์คำสั่งจากคอมให้ LED บนบอร์ดสลับสถานะได้

คาบนี้เป็นคาบแรกที่ข้อมูลของเรา ออกจากบอร์ด ไปอยู่ในมือของโปรแกรมอื่น

ปลายทางของคาบนี้ — บอร์ดรายงานตัวขึ้น broker

• การ์ดบนคือ บันไดสามขั้นก่อนส่งได้ — 1) WiFi ได้ IP · 2) broker ต่อแล้ว · 3) publish กำลังส่ง — ขั้นที่ผ่านแล้วต้องเห็นด้วยตา
• การ์ดล่างนับใบที่ส่งไปแล้ว พร้อมแถบความคืบหน้าของ 10 ใบ — ส่งทุก 2 วินาที ดูเลขเดินขึ้น
• ผลลัพธ์จริงของคาบนี้ไปโผล่ที่ เครื่องอื่น — จอนี้บอกได้แค่ว่าบอร์ด "สั่งส่ง" แล้ว

ถ้าจอบอกว่าส่งแล้ว แต่ฝั่งรับไม่เห็นอะไร แปลว่ายังไม่จบ — คาบนี้ต้องดูสองจอพร้อมกัน

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

สองอย่างจากคาบที่แล้วที่ต้องเอามาใช้วันนี้ทั้งคู่ — wifi.connect() บล็อกได้นานถึงราว 85 วินาทีถ้ารหัสผิด จึงต้องต่อ WiFi ให้ได้ก่อนเสมอแล้วค่อยเริ่มเรื่อง MQTT และ wifi.ping() รับเฉพาะหมายเลข IP ไม่รับชื่อโฮสต์ — เดี๋ยวเราจะใช้มันตรวจว่าเครื่องที่รัน broker อยู่ในระยะที่คุยได้จริงก่อนจะเสียเวลาต่อ

ถ้า wifi.is_connected() เป็น False อย่าเพิ่งไปหาสาเหตุที่ MQTT — ปัญหายังไม่เดินทางมาถึงชั้นนั้น

client–server กับ pub/sub ต่างกันตรงไหน

ซ้าย คือแบบที่เราคุ้น (client–server) เว็บเบราว์เซอร์ต้องรู้ชื่อเซิร์ฟเวอร์ ต้องถามก่อนถึงจะได้คำตอบ ผู้ถามกับผู้ตอบ ผูกกันตรง ๆ ถ้าอีกฝั่งย้ายที่อยู่ ทุกฝั่งต้องแก้ตาม

ขวา คือ publish/subscribe ผู้เขียน (writer) โยนข้อมูลใส่ ชื่อเรื่อง ผู้อ่าน (reader) ขอรับตาม ชื่อเรื่อง — ทั้งสองฝั่งไม่เคยรู้จักกัน รู้จักแค่ชื่อเรื่องเดียวกัน

ผลที่ตามมาสามข้อ ซึ่งเป็นเหตุผลที่ IoT เลือกแบบหลัง

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

คำที่ต้องจำ: pub/sub แยกผู้ส่งออกจากผู้รับ ทั้งในเชิงพื้นที่และเชิงเวลา

broker อยู่ตรงกลาง — และมีคำสั่งอยู่แค่ไม่กี่คำ

broker ไม่ใช่ฐานข้อมูล มันคือ ที่ทำการไปรษณีย์ — รับเข้ามาแล้วส่งต่อทันที ไม่เก็บไว้ให้ (เว้นแต่สั่งให้เก็บ)

topic คือที่อยู่ — และมันเป็นต้นไม้ ไม่ใช่ชื่อแบน ๆ

topic ไม่ต้องประกาศล่วงหน้า — พิมพ์ publish ไปที่ชื่อไหน ชื่อนั้นก็เกิดขึ้นเดี๋ยวนั้น จึงต้องมีวินัยตั้งชื่อเอง

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

ทั้ง WiFi และ MQTT ทำงานอยู่บน CM33_NS คอร์เดียวกับที่รันโค้ด Python ของเรา ส่วน CM55 ที่วาดจอกับอ่านเซนเซอร์ไม่แตะเครือข่ายเลย — ทั้งสองบอร์ดจงใจอย่างนั้น เพราะสองคอร์แย่งอุปกรณ์ตัวเดียวกันเคยทำให้เครื่องล้มมาแล้ว · ภาพนี้จริงทั้ง Eva Kit และ Dev Kit เพราะโค้ด Wi-Fi/MQTT เป็นชุดเดียวกัน ต่างกันแค่ใครอ่าน IMU (Eva: คอร์จออ่านให้ · Dev Kit: CM33 อ่านเองจาก I2C) · เหตุผลที่คาบนี้ใช้ 1883 ไม่ใช่เรื่องหน่วยความจำ แต่เพราะโมดูล mqtt ส่งข้อมูลรับรอง TLS เป็นค่าว่างเสมอ (ดูตารางหกชื่อ) จึงต่อได้เฉพาะพอร์ตข้อความเปล่าบนบอร์ดไหนก็ตาม

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

เครือข่ายกับหน้าจออยู่คนละคอร์ — ถ้าจอค้าง MQTT อาจยังวิ่งอยู่ และในทางกลับกันด้วย

เกร็ด: หัวข้อความสองไบต์ กับมาตรฐานที่ใช้เวลาสิบห้าปี

ดูแถวบนสุดของภาพ: 16 บิต = 2 ไบต์ นั่นคือส่วนหัวคงที่ของ MQTT ทั้งหมด — ชนิดแพ็กเก็ต, ธง DUP, ระดับ QoS, ธง RETAIN และความยาว อัดอยู่ในสองไบต์นั้น

เทียบกับ HTTP ที่ส่วนหัวเป็นข้อความยาวหลายร้อยไบต์ต่อคำขอหนึ่งครั้ง ("GET /… HTTP/1.1", "Host:", "User-Agent:", …) ความต่างนี้ไม่ใช่เรื่องความสวยงาม แต่คือ ค่าไฟกับค่าเน็ตของอุปกรณ์ที่ต้องส่งข้อมูลทุกห้าวินาที เป็นปี

มาตรฐานเองก็ไม่ได้เกิดในวันเดียว: MQTT 3.1.1 ถูกอนุมัติเป็นมาตรฐาน OASIS เมื่อ 2014-10-29 และ 5.0 เมื่อ 2019-03-07 เวอร์ชันที่อุปกรณ์ฝังตัวใช้กันแพร่หลายที่สุดจนถึงวันนี้ยังเป็น 3.1.1

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

กลไกหลักของคาบ — get_message() มีช่องรับเพียงช่องเดียว

นี่คือข้อจำกัดที่เราต้อง สอน ไม่ใช่ซ่อน เพราะมันไม่ส่งเสียงเวลาเกิด

ความล้มเหลวที่แย่ที่สุดสำหรับผู้เรียนคือความล้มเหลวที่เงียบ — จำสี่แถวนี้ไว้ แล้วจะประหยัดเวลาดีบักไปทั้งคาบ

QoS 0/1/2 — ราคาของคำว่า "แน่ใจ"

เลือก QoS จากคำถามเดียว: "ถ้าข้อความนี้หายไปหนึ่งใบ ใครเดือดร้อน"

งบข้อมูลต่อรอบ — ทำไมเป็น 5 วินาที ไม่ใช่ 100 มิลลิวินาที

$$\text{ปริมาณข้อมูล} \approx \frac{\text{ขนาด payload}}{T_{\text{publish}}} \qquad \frac{80\ \text{B}}{5\ \text{s}} = 16\ \text{B/s} \qquad \text{payload ขาเข้า} \le 255\ \text{B}$$

ตัวเลข 5 วินาทีไม่ได้มาจากความรู้สึก แต่มาจากคำถามว่า ค่าที่เราวัดเปลี่ยนเร็วแค่ไหน อุณหภูมิห้องเปลี่ยนช้ามาก ส่งทุก 5 วินาทีก็ละเอียดเกินพอ ส่วนความสั่นของมอเตอร์เปลี่ยนใน 10 มิลลิวินาที — ค่าแบบนั้นไม่ควรส่งดิบ ๆ ขึ้น MQTT แต่ควรให้บอร์ดสรุปก่อน (ค่าสูงสุด ค่า RMS หรือจำนวนครั้งที่เกินเกณฑ์ในช่วงนั้น) แล้วค่อยส่ง

"ส่งให้ถี่ที่สุดเท่าที่ทำได้" เป็นการออกแบบที่แย่เสมอ — ถามก่อนว่าใครจะใช้ค่านี้ทำอะไร

ออกแบบ topic และ payload ของทีม

กติกาการตั้งชื่อ topic ที่ใช้ได้ทั้งชีวิตการทำงาน: เรียงจากกว้างไปแคบ (bento/team03/telemetry ไม่ใช่ telemetry/team03/bento) · ห้ามขึ้นต้นด้วย / เพราะจะได้ช่องว่างเปล่าเป็นชั้นแรก · ห้ามใส่ช่องว่างหรือภาษาไทย · และ อย่าใส่ค่าที่เปลี่ยนบ่อยลงในชื่อ topic (เช่น .../temp/25.4) เพราะผู้รับจะ subscribe ไม่ถูก

สตริงที่เป็นข้อความ เช่น {"status":"ok"} ส่งขึ้นไปได้และเก็บได้ แต่ จะไม่กลายเป็นเส้นกราฟ เพราะกราฟต้องการตัวเลข ถ้าอยากให้เห็นบนกราฟ ให้แปลงเป็นตัวเลขก่อน เช่น {"ok": 1}

ชื่อ topic กับรูปร่าง payload คือ สัญญาระหว่างทีมเรากับทุกคนที่จะใช้ข้อมูลนี้ต่อ เปลี่ยนทีหลังแปลว่าพังทุกฝั่งพร้อมกัน

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

สิ่งที่ทำให้แล้ว (70%)
สแตก TCP/IP และการต่อ WiFi · การเข้ารหัสแพ็กเก็ต MQTT ตามมาตรฐาน · การส่ง keepalive ให้เองเป็นระยะ · ฝั่งแพลตฟอร์ม: broker EMQX, บริดจ์ที่ subscribe device/+/telemetry รออยู่แล้ว, ฐานข้อมูลอนุกรมเวลา และกราฟที่สร้างจากชื่อคีย์ JSON อัตโนมัติ

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

สังเกตว่าโค้ดของคาบนี้สั้นกว่าคาบ 8 มาก แต่การตัดสินใจหนักกว่า — นี่คือหน้าตาของงานวิศวกรรมระบบจริง

โค้ดที่สั้นลงไม่ได้แปลว่างานง่ายลง มันแปลว่าน้ำหนักย้ายไปอยู่ที่การออกแบบ

โมดูล mqtt มีหกชื่อ เท่านี้จริง ๆ — และเพดานของแต่ละตัว

retain ไม่ใช่พารามิเตอร์ เอกสารในเครื่องมือบางที่เขียนว่า mqtt.publish(topic, payload, qos=0, retain=False) แต่ตัวจริงรับได้แค่สามอาร์กิวเมนต์ ใส่ retain=True ไปจะได้ TypeError ทันที และในซอร์สค่านั้นถูกตั้งเป็น false ตายตัวอยู่แล้ว

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

ครึ่งหลังของคาบ — แพลตฟอร์มที่เราติดตั้งเอง

เราจะไม่ยืมแดชบอร์ดของใคร — แต่ละทีมติดตั้ง TESAIoT Community Edition บนเครื่องของตัวเองด้วย Docker

• make install (ธง PREBUILT=1 ดึงอิมเมจสำเร็จรูป) ใช้เวลาราว 15–30 นาที
• ลำดับสำคัญ: make up ต้องมาก่อน make init-pki ถ้าสลับกันจะค้างตั้งแต่บูตแรก
• RAM อย่างน้อย 8 GB ตามเอกสารไทยของ repo — น้อยกว่านี้ฐานข้อมูลถูกระบบฆ่าทิ้งกลางทาง
• มีเอกสารภาษาไทยครบ — README.th.md และ docs/th/ อีก 15 ไฟล์

นี่คือครั้งแรกที่ทีมได้เป็นเจ้าของ ทั้งอุปกรณ์และแพลตฟอร์ม ไม่ใช่แค่ผู้ใช้บริการของใคร

กับดักพอร์ต 1883 — เอกสารบอกอย่าง ไฟล์ตั้งค่าทำอีกอย่าง

เอกสารของ CE ทุกฉบับเขียนว่าพอร์ต 1883 แต่ docker-compose.yml เผยแพร่จริงเป็น 127.0.0.1:11883:1883 คือทั้งเลขพอร์ตต่างจากที่เขียนไว้ และผูกกับ loopback ทำให้ บอร์ดที่อยู่ใน LAN เดียวกันเข้าไม่ถึงเลย (คอมเมนต์ในไฟล์บอกว่าทำไว้เลี่ยงชนกับซอฟต์แวร์ตัวอื่นบนเครื่องผู้พัฒนา)

-      - "127.0.0.1:11883:1883"
+      - "0.0.0.0:1883:1883"     # classroom only - plaintext MQTT บน LAN

ใช้ docker compose up -d emqx เท่านั้น — restart จะไม่อ่านการตั้งค่าพอร์ตใหม่

เอกสารกับไฟล์ตั้งค่าขัดกันได้เสมอ — ไฟล์ตั้งค่าคือความจริง เพราะมันคือสิ่งที่เครื่องอ่าน

1883 ส่งรหัสผ่านเป็นข้อความเปล่า — พูดให้ตรง

พอร์ต 1883 ไม่มีการเข้ารหัส ทั้ง username, password และ payload ทุกไบต์ เดินทางบน WiFi ห้องเรียนในรูปข้อความอ่านออกได้ ใครที่ดักจับสัญญาณได้ ก็อ่านรหัสของทีมเราได้ และ ปลอมเป็นอุปกรณ์ของเราส่งข้อมูลปลอมเข้าแพลตฟอร์มได้ทันที

• CE เองระบุไว้ในไฟล์ตั้งค่าว่าพอร์ต 1883 มีไว้สำหรับ local/dev เท่านั้น
• API ของแพลตฟอร์มจะเขียน log เตือนทุกครั้งที่อุปกรณ์โหมด server_tls เข้ามาทางพอร์ต 1883
• ดังนั้นสิ่งที่เราทำวันนี้คือ การฝึกในสนามซ้อมที่ปิดล้อม ไม่ใช่วิธีที่ใช้กับของจริง

คาบหน้า (คาบ 11) เราจะเปลี่ยนไปพอร์ต 8884 พร้อม TLS แล้วเทียบให้เห็นด้วยตาว่าสิ่งที่ดักได้ต่างกันอย่างไร — วันนี้จึงเป็นครึ่งแรกของบทเรียนเรื่องความปลอดภัย ไม่ใช่บทเรียนที่จบในตัว

จำประโยคนี้ให้ได้: "ต่อได้" กับ "ต่อได้อย่างปลอดภัย" เป็นคนละคำถาม และเราเพิ่งตอบข้อแรก

ขึ้นทะเบียนอุปกรณ์ก่อน แล้วค่อยต่อ

แพลตฟอร์มนี้ ไม่มีการลงทะเบียนอัตโนมัติ — อุปกรณ์ที่ไม่รู้จักถูกปฏิเสธตั้งแต่ตอน CONNECT

1. Devices → Add device แล้ว ตั้ง device_id เองให้สั้น เช่น team03 (ระบบรับ 3–64 ตัว) — ถ้าปล่อยให้สุ่ม จะได้ UUID ยาว 36 ตัว ยาวเกิน 31 ตัวที่โมดูล mqtt รับได้ ถูกตัดเงียบ แล้วต่อไม่ติดโดยไม่บอกสาเหตุ
2. ขอรหัส: POST /api/v1/devices/<id>/reset-mqtt-password คืน mqtt_username และรหัสผ่านมาตรง ๆ (อย่าใช้ /reset-password ซึ่งคืนคนละอย่าง)
3. ตรวจว่าสถานะอุปกรณ์เป็น active และโหมดเป็น server_tls (ค่าเริ่มต้นอยู่แล้ว)
4. กรอกลงโค้ดโดยให้ client_id == username == device_id ตรงกันเป๊ะ

ที่นี่ไม่ยอมรับ "เกือบตรง" — ผิดตัวเดียวใน device_id คือถูกปฏิเสธ และข้อความปฏิเสธไม่ได้บอกว่าผิดตรงไหน

แกะโค้ดจริง — ท่าที่ 1 ต่อ WiFi แล้วต่อ broker

# --- ท่าที่ 1: ต่อเน็ตให้ได้ก่อน แล้วค่อยแนะนำตัวกับ broker ---
wifi.connect(WIFI_SSID, WIFI_PASSWORD)
lcd.print("WiFi:", wifi.ip())

ok = mqtt.connect(BROKER, port=1883, client_id=DEVICE_ID,
                  username=DEVICE_ID, password=MQTT_PASS, keepalive=60)
lcd.print("<span class=ok>MQTT ต่อแล้ว</span>" if ok else "MQTT ต่อไม่ได้")

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

แกะโค้ดจริง — ท่าที่ 2 ส่งค่าจริงทุก 5 วินาที

    # --- ท่าที่ 2: อ่านเซนเซอร์ → ประกอบ JSON → publish (ใน publish_telemetry) ---
    try:
        ax, ay, az, gx, gy, gz = sensors.bmi270.motion()
        data = {"ax": round(ax, 2), "ay": round(ay, 2), "az": round(az, 2),
                "pot": round(sensors.pot.percent(), 1)}
    except OSError:
        return None                            # อ่านพลาดหนึ่งรอบ ข้ามไปรอบหน้า
    ...
    mqtt.publish(TOPIC_PUB, json.dumps(data))  # แบน ไม่ห่อ แพลตฟอร์มห่อให้เอง

sensors.bmi270.motion() คืนหกค่าในการอ่านครั้งเดียว — อ่านทีเดียวดีกว่าเรียกหลายฟังก์ชัน เพราะค่าทั้งหกมาจากช่วงเวลาเดียวกันจริง · บรรทัดที่อ่านค่าอยู่ใน try เพราะอ่านพลาดหนึ่งรอบต้องไม่ทำให้ทั้งโปรแกรมตาย

round() ไม่ใช่เรื่องความสวยงาม: 0.1234567890 กิน 12 ไบต์ ส่วน 0.12 กิน 4 ไบต์ — คูณด้วยจำนวนฟิลด์และรอบต่อวันแล้วคือค่าเน็ตที่ประหยัดได้ฟรี · json.dumps() แปลง dict เป็นสตริงที่ทุกภาษาอ่านออก คือจุดที่ข้อมูลเลิกเป็นของ Python

ส่งแบน ไม่ต้องห่อ บริดจ์เป็นคนห่อให้เอง แล้วเติม device_id (จาก topic) กับ timestamp ให้ด้วย
ห่อเองซ้ำจะได้ชื่อวัดขึ้นต้น data_ แล้วตารางหน่วยฝั่งเซิร์ฟเวอร์หาไม่เจอ

แกะโค้ดจริง — ท่าที่ 3 รับคำสั่งกลับมาสั่ง LED

mqtt.subscribe(TOPIC_CMD)               # ท่าที่ 3: subscribe ครั้งเดียว แล้ว poll ถี่ ๆ ในลูปเดียวกับ publish
...
    msg = mqtt.get_message()            # ไม่มีข้อความ = None
    if msg is not None:
        try:
            cmd = json.loads(msg[1].decode())   # msg[1] คือ payload เป็น bytes
        except ValueError:
            cmd = {}                    # คนส่งมั่วได้เสมอ โปรแกรมต้องไม่ตาย
        if cmd.get("cmd") == "toggle":
            led_on = not led_on         # จำสถานะเอง
            lamp.value(1 if led_on else 0)      # lamp = led_named("RGB_GREEN", "LED2")
            led_remote.value(1 if led_on else 0)
    ...
    time.sleep_ms(100)

get_message() คืน tuple (topic, payload) หรือ None ต้องตรวจ is not None ก่อนเสมอ · payload เป็น bytes จึงต้อง .decode() ก่อน json.loads() · ต้อง จำสถานะ LED ในตัวแปร Python เอง เพราะ gpio.led().value() ตอบแค่ระดับของขา ณ วินาทีที่ถาม · lamp ถูกเลือกตามชื่อ — led_named("RGB_GREEN", "LED2") หาดวงสีเขียวจาก gpio.board_info()["led_names"]: Dev Kit ได้ RGB_GREEN · Eva ได้ LED2 เพราะเลขดัชนีต่างกันตามบอร์ด และ led(0)/led(1) บน Dev Kit อยู่บน SoM ซึ่งยังไม่มีใครยืนยันว่ามองเห็นบนบอร์ดประกอบ

คำสั่งจากภายนอกคือ ข้อมูลที่เราไม่ได้เขียนเอง — ตรวจก่อนใช้เสมอ ทั้งว่ามีจริงไหม แปลงได้ไหม และอยู่ในชุดค่าที่เรารู้จักไหม

ท่าที่ 4 ที่ไม่มีในโครง — mqtt.disconnect() และเหตุผลที่ควรเรียก

# --- จบงานแล้วบอก broker ให้รู้ ไม่ใช่หายไปเฉย ๆ ---
mqtt.disconnect()                 # คืน None ไม่ใช่ True
print(mqtt.is_connected())        # False ทันที ไม่ต้องรอ keepalive หมดอายุ

โค้ดหลักของคาบนี้วนลูปไม่รู้จบ จึงไม่เคยเดินมาถึงบรรทัด disconnect() แต่พอทีมกด Ctrl-C หรือกดรันใหม่ บอร์ดหายไปโดยที่ broker ยังนับว่าเรายังอยู่ เพราะฝั่งนั้นรอจนครบ keepalive ก่อนถึงจะยอมรับว่าเราไปแล้ว ระหว่างนั้นชื่อ client_id เดิมยังถูกจองอยู่

disconnect() จึงมีค่าที่สุดตอน เลิกใช้งานตามตั้งใจ ไม่ใช่ตอนพัง เขียนไว้ท้ายไฟล์ หรือใน except KeyboardInterrupt: แล้วอาการ "ต่อติดแล้วหลุดสลับกัน" ที่อยู่ในตารางกับดักจะหายไปเองครึ่งหนึ่ง

ลองไฟล์ examples/s10/07_disconnect_frees_id.py^↗ — มันต่อ ส่ง ตัด แล้วต่อใหม่ด้วยชื่อเดิมทันที ให้เห็นว่าทำได้จริงเมื่อบอกลาอย่างถูกวิธี

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

จุดตรวจที่ใช้ได้จริงเวลาข้อมูลไม่ขึ้น: MQTT Explorer เห็นข้อความไหม ถ้าเห็น แปลว่าสองกล่องแรกและ broker ทำงานครบ ปัญหาอยู่ที่ topic ผิดรูปหรือ JSON ไม่ถูกต้อง (บริดจ์ทิ้ง JSON เสียเงียบ ๆ พร้อมเขียน log) ถ้าไม่เห็น ปัญหายังอยู่ฝั่งบอร์ด

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

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

1. บนเครื่องที่รัน CE — ตรวจว่า docker compose ps เห็น emqx สถานะ up และพอร์ตขึ้นเป็น 0.0.0.0:1883 แล้วจริง
2. หา IP ของเครื่องนั้นใน LAN (ไม่ใช่ localhost — บอร์ดอยู่คนละเครื่อง) แล้วทดสอบจากบอร์ดด้วย wifi.ping("192.168.1.50") ก่อน ถ้า ping ไม่ผ่าน อย่าเพิ่งเสียเวลากับ MQTT
3. บนคอม เปิด MQTT Explorer ต่อไปที่ IP เดียวกัน พอร์ต 1883 ด้วยชื่อผู้ใช้/รหัสของทีม แล้ว subscribe device/# ไว้ล่วงหน้า
4. บนบอร์ด เปิดหน้า BENTO Playground ค้างไว้ แล้วเปิด practise_codes/s10_mqtt_telemetry.py^↗ แก้ค่าบนหัวไฟล์ให้เป็นของทีม
5. เติมช่องว่าง pass ให้ครบ แล้วกด Program to Device — จากนั้นมองสองจอสลับกัน
6. ทดสอบขากลับ: ใน MQTT Explorer พิมพ์ publish ไปที่ device/<device_id>/commands ด้วย payload {"cmd":"toggle"} แล้วดู LED

ตัวอย่างชุดคาบ 10 — สามไฟล์แรกคือชุดที่พา JSON ใบแรกขึ้น broker แล้วสั่งกลับมาได้

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

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

อ่านเสริมนอกเวลา — เรื่องนี้เป็นเนื้อหาของคาบ 11 ไม่ใช่เกณฑ์ผ่านของวันนี้: examples/s11/06_secure_publish_loop.py^↗ คือลูปเดียวกันนี้ แต่วิ่งบนช่องที่เข้ารหัสไปยังแพลตฟอร์ม วันนี้ยังรันไม่ได้จนกว่าทีมจะได้ device_id ของตัวเอง เปิดอ่านเทียบโครงได้ แต่อย่าเพิ่งพยายามรัน

ทีมละหนึ่งบอร์ดหนึ่ง device_id — ห้ามสองทีมใช้ client_id เดียวกัน เพราะ broker จะเตะเครื่องเก่าออกทุกครั้งที่เครื่องใหม่ต่อเข้ามา แล้วทั้งสองทีมจะหลุดสลับกันเป็นลูป

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

สองทาง — publish JSON เซนเซอร์จริงทุก 5 วินาที + สั่ง toggle LED จาก MQTT Explorer ผ่าน topic ของทีม

แปลเป็นสิ่งที่ตรวจได้จริง:

• [ ] MQTT Explorer เห็นข้อความเข้ามาที่ topic ของทีม ห่างกัน 5 วินาที ต่อเนื่องอย่างน้อย 1 นาที
• [ ] payload เป็น JSON ที่ถูกต้อง มีค่าจากเซนเซอร์จริงอย่างน้อย 3 ฟิลด์ และค่าจะเปลี่ยนเมื่อขยับบอร์ด
• [ ] พิมพ์ {"cmd":"toggle"} จาก MQTT Explorer แล้ว LED บนบอร์ดสลับสถานะ ได้ทั้งติดและดับ
• [ ] ข้อมูลขึ้นกราฟใน Device Details → Telemetry ของ TESAIoT CE ที่ทีมติดตั้งเอง
• [ ] อธิบายได้ว่า client_id, username, device_id และช่องที่สองของ topic ต้องสัมพันธ์กันอย่างไร
• [ ] บันทึกภาพหน้าจอทั้งสองฝั่งลง worksheet

ข้อที่สามคือหัวใจ — ถ้าขาดข้อนี้ เราสร้างได้แค่ เครื่องส่งข้อมูล ยังไม่ใช่ อุปกรณ์ที่สั่งได้

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

สิบเอ็ดจากสิบสองแถวนี้ ไม่ส่ง error ที่ตรงกับสาเหตุ — จึงต้องอ่านตารางนี้ก่อนเจอปัญหา ไม่ใช่หลังเจอ

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

# เติม: ok = mqtt.connect(BROKER, port=1883, client_id=DEVICE_ID, username=DEVICE_ID, password=MQTT_PASS, keepalive=60)
pass
        # เติม: data = {"ax": round(ax, 2), "ay": round(ay, 2), "az": round(az, 2), "pot": round(sensors.pot.percent(), 1)}
        pass
    # เติม: mqtt.publish(TOPIC_PUB, json.dumps(data))
    pass
# เติม: mqtt.subscribe(TOPIC_CMD)
pass
    # เติม: msg = mqtt.get_message()
    pass
            # เติม: lamp.value(1 if led_on else 0)
            pass

ปิดวงจร — เอาเลขแต่งออก ใส่เซนเซอร์จริงเข้าไป

เจ็ดไฟล์ที่ผ่านมาส่งเลขที่เราแต่งขึ้นเอง โดยตั้งใจ — กลไก MQTT มีเรื่องให้ผิดพลาดมากพออยู่แล้ว · ตอนนี้กลไกแน่นแล้ว examples/s10/08_real_sensor_leaves_the_board.py^↗ เอาเลขแต่งออก แล้วต่อ ชิปบนบอร์ด → WiFi → broker ให้ครบวง

ค่าที่ไฟล์นี้ส่งคือ อุณหภูมิ อ่านผ่านฟังก์ชัน read_temp() ในไฟล์ — sensors.snapshot() ไม่มีช่องอุณหภูมิบนบอร์ดไหนเลย ไฟล์จึงถามก่อนว่าบอร์ดมี sensors.sht40 ไหม: บน Dev Kit ได้อุณหภูมิห้องจริงจาก SHT40 ส่วน บน Eva ไม่มีเซนเซอร์อุณหภูมิ ลูกบิดจึงเล่นบทแทน (0–100 % = 15–45 °C) และ console บอกไว้ตั้งแต่รอบแรกว่าค่ามาจากไหน — หมุนลูกบิดแล้วเห็นเส้นวิ่งทั่วกราฟช่วง 20–35 °C ได้ในห้องเรียน ไฟล์นี้ยังไม่มีเกณฑ์ตัดสิน (เงื่อนไข 0.3 องศาคือการบ้านท้ายไฟล์)

เลขสองตัวนี้ไม่เท่ากัน และไม่ควรเท่ากัน — ถ้าส่งทุก 200 ms คือ 5 ข้อความต่อวินาทีต่อบอร์ด สิบห้าโต๊ะก็ 75 ข้อความต่อวินาทีเข้า broker ตัวเดียว นั่นคือวิธีทำให้ห้องเรียนล่มโดยไม่มีใครเขียนโค้ดผิดสักบรรทัด

บนจอจะเห็นสองเส้น — ฟ้าคือค่าที่วัดได้ทุกรอบ เขียวคือค่าที่ส่งออกไปจริง เส้นเขียวเป็นขั้นบันได นั่นคือภาพของประโยคที่จริงเสมอในงาน IoT: จอเห็นบ่อยกว่าที่คลาวด์เห็น

ตาคุณ — เพิ่มเงื่อนไข "ส่งเฉพาะเมื่อค่าเปลี่ยนเกิน 0.3 องศา" แล้วดูว่าจำนวนครั้งที่ส่งลดลงเท่าไร โดยที่คนดูปลายทางยังเห็นภาพเดิมทุกประการ

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

วันนี้เราได้: ส่งข้อมูลออกจากบอร์ดไปให้โปรแกรมอื่นใช้ · รับคำสั่งจากภายนอกมาสั่งฮาร์ดแวร์จริง · ติดตั้งแพลตฟอร์ม IoT ด้วยตัวเองและเห็นข้อมูลขึ้นกราฟโดยไม่ต้องสร้างแดชบอร์ด · และรู้ข้อจำกัดจริงสี่ข้อของโมดูล mqtt ที่ไม่ส่งเสียงเวลาเกิน

สิ่งที่ติดตัวไปแม้เปลี่ยนภาษาและเปลี่ยนบอร์ด: การออกแบบชื่อ topic และรูปร่าง payload ในฐานะ สัญญา ที่แก้ทีหลังแล้วพังทั้งระบบ · การเลือกความถี่การส่งจากคำถามว่าใครใช้ค่านี้ทำอะไร · และนิสัยตรวจค่าที่รับมาจากภายนอกก่อนใช้เสมอ

งานทำเอง 30%: เลือกทำ 1 ข้อจากสี่ข้อในสไลด์ต่อยอด บันทึกลง worksheet ข้อ 8

คาบหน้า: เปลี่ยนจากพอร์ต 1883 ไปเป็น 8884 พร้อม TLS แล้วดักจับสัญญาณเทียบกันให้เห็นด้วยตาว่าสิ่งที่คนดักได้ต่างกันอย่างไร

วันนี้บอร์ดพูดได้และฟังเป็นแล้ว คาบหน้าเราจะทำให้ คนอื่นแอบฟังไม่ได้

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

WIFI_SSID = "AIoT-Class"
WIFI_PASSWORD = "<รหัสผ่านของห้องเรียน>"
BROKER = "192.168.1.50"                # IP ของเครื่องที่รัน TESAIoT CE ในแลน (ไม่ใช่ localhost)
DEVICE_ID = "team03"                   # ต้องตรงกับ device_id ที่ขึ้นทะเบียน · <= 31 ตัวอักษร
MQTT_PASS = "bento"                    # broker ฝึกไม่ตรวจ แต่ของห้องเรียนจะตรวจ
TOPIC_PUB = "device/team03/telemetry"
TOPIC_CMD = "device/team03/commands"
...
try:
    sensors.bmi270.motion()            # อุ่นเครื่องหนึ่งครั้ง ให้การรอไปเกิดก่อนต่อเน็ต
except OSError:
    print("อ่านเซนเซอร์รอบแรกยังไม่ได้ - ลองใหม่ตอนส่ง")
...
wifi.connect(WIFI_SSID, WIFI_PASSWORD)
lcd.print("WiFi:", wifi.ip())

บน Eva Kit คอร์จอ (CM55) เป็นเจ้าของบัสเซนเซอร์ sensors.init() และ sensors.scan() จึงถูกปฏิเสธด้วย OSError ส่วน sensors.bmi270.* capsense.* pot.* เรียกได้ทันทีผ่าน snapshot ที่คอร์จอเก็บไว้ให้ · บน Dev Kit init() ทำงานได้จริง แต่ก็ไม่ต้องเรียก เพราะเฟิร์มแวร์ปลุกเซนเซอร์ไว้ตั้งแต่บูต — โค้ดเดียวกันจึงรันได้ทั้งสองบอร์ด · sensors.snapshot() คืน dict รูปเดียวกันทั้งสองบอร์ด (คีย์ bmi270 capsense pot) และไม่มีคีย์อุณหภูมิ

เขียนค่าที่ต้องตรงกันไว้ที่เดียว แล้วบั๊กประเภท "ลืมแก้ที่หนึ่ง" จะหายไปทั้งตระกูล

เฉลย — แผงเฝ้าลิงก์ สร้าง ก่อน ต่อเน็ต

ui.screen()
time.sleep_ms(200)
ui.Label("MQTT Telemetry - คาบ 10", x=24, y=36, color=COL_TEXT, value=20)
led_wifi = ui.Led(x=328, y=16, w=48, h=48, color=COL_OK, value=0)
...
led_mqtt = ui.Led(x=440, y=16, w=48, h=48, color=COL_OK, value=0)
...
led_stale = ui.Led(x=552, y=16, w=48, h=48, color=COL_WARN, value=0)
...
led_remote = ui.Led(x=664, y=16, w=48, h=48, color=COL_RUN, value=0)
...
ui.Panel(x=24, y=112, w=232, h=280, color=COL_CARD, min=COL_DIM, max=12, value=1)
...
lbl_pot = ui.Label("- %", x=40, y=160, color=COL_TEXT, value=24)
bar_pot = ui.Bar(x=40, y=204, w=200, h=12, color=0x4A9EFF, min=0, max=100, value=0)
sc_pot = ui.Scale(x=40, y=224, w=200, h=44, color=COL_TEXT, min=0, max=100)
sc_pot.ticks(11, 5)
...
seg_sent = ui.Seg7("0", x=40, y=324, w=200, h=48, color=COL_TEXT)
...
lst_sent = ui.List(x=288, y=160, w=208, h=168)
...
btn_go = ui.Button("เริ่มส่ง", x=544, y=240, w=88, h=88, color=0x30A46C, value=20)
btn_hold = ui.Button("หยุดส่ง", x=664, y=240, w=88, h=88, color=0x3A4150, value=20)
ui.poll()

wifi.connect(WIFI_SSID, WIFI_PASSWORD)
lcd.print("WiFi:", wifi.ip())
led_wifi.value(1 if wifi.is_connected() else 0)

จอถูกสร้าง ก่อน wifi.connect() โดยตั้งใจ — การต่อเน็ตคือช่วงที่น่าดูที่สุดของโปรแกรมนี้ ถ้าสร้างจอทีหลัง ช่วงนั้นผ่านไปโดยไม่มีใครเห็น · ไฟสี่ดวงไล่ตาม เส้นทางจริงของข้อมูล: WiFi → MQTT → "ค่าค้าง" → หลอดจริงที่คนอีกห้องสั่งได้ · ui.Scale ใต้ ui.Bar ทำให้ค่า pot มีพิสัยกำกับ — ตัวเลข 14.6 ที่มีไม้บรรทัด 0–100 อยู่ใต้มันบอกทันทีว่าสูงไหม · การ์ดสร้างก่อนของที่วางบนมัน (LVGL วาดตามลำดับสร้าง) · ปุ่มสองปุ่มสูง 88 = เป้าสัมผัสตามเกณฑ์ และจบที่ y=328 เพราะมุมขวาล่างเป็นของปุ่ม Console

ui.List ไม่ใช่ ui.Label เรียงกัน เพราะรายการนี้ถูกล้างแล้วเขียนใหม่ทุกห้าวินาที ถ้าทำด้วย Label ต้องนับพิกเซลใหม่ทุกครั้งที่ข้อความยาวไม่เท่าเดิม

เฉลย — ส่วนที่สอง: ลูปหลัก และทำไมเรียงสามท่าแบบนี้

mqtt.subscribe(TOPIC_CMD)                  # ต่อจากท่าที่ 1 ที่ connect แล้ว
...
while True:
    if sending and time.ticks_diff(time.ticks_ms(), t_last) >= SEND_MS:
        d = publish_telemetry()            # ท่าที่ 2 ทั้งท่าอยู่ในฟังก์ชันนี้
        if d is not None:
            sent += 1
            t_good = time.ticks_ms()
            ...
            lbl_pot.text(str(pot) + " %")  # จอขยับทุก 5 วินาที ไม่ใช่ทุกรอบลูป
            bar_pot.value(int(pot))
            seg_sent.text(str(sent))
            ...
        t_last = time.ticks_ms()
    ...

ท่า 2 ส่งออกก่อนรับเข้า เพราะขาส่งตรวจง่ายกว่า — ถ้าถึงท่า 3 แล้วไม่ทำงาน รู้แน่ว่าปัญหาอยู่ที่ topic ของคำสั่ง

เฉลย — ส่วนที่สอง (ต่อ): ครึ่งหลังของลูป — สามนาฬิกาในลูปเดียว

    ...
    stale = time.ticks_diff(time.ticks_ms(), t_good) >= STALE_MS
    if stale != stale_shown:               # เขียนเฉพาะตอนเปลี่ยน
        stale_shown = stale
        led_stale.value(1 if stale else 0)

    msg = mqtt.get_message()               # ถามทุกรอบลูป
    if msg is not None:
        ...                                # แปลง JSON แล้วสั่งไฟ - เหมือนท่าที่ 3
    if time.ticks_diff(time.ticks_ms(), t_ui) >= 200:
        t_ui = time.ticks_ms()
        for ev in ui.poll():
            ...                            # ปุ่มเริ่มส่ง / หยุดส่ง
    time.sleep_ms(100)

สังเกตว่าลูปนี้มีนาฬิกา สามเรือน ไม่ใช่เรือนเดียว: เรือนของการส่ง (5 วินาที) เรือนของนิ้ว (200 ms) และเรือนของ get_message() ซึ่งถามทุกรอบ ถ้ายุบทั้งสามให้เดินจังหวะเดียวกัน จะได้โปรแกรมที่ไม่ตอบคำสั่งหรือไม่ก็ยิงจอทิ้งเปล่า

if stale != stale_shown: ไม่ได้เขียนไว้ให้สวย — คิวคำสั่งของจอมีก้นถัง พอมันเต็ม เฟิร์มแวร์ทิ้งคำสั่งเปลี่ยนข้อความก่อนเป็นอย่างแรก (ipc_ui.c ระบุ SET_TEXT ว่าเป็นคำสั่งที่ทิ้งได้) โปรแกรมที่ยิงคำสั่งจอสิบครั้งต่อวินาที จึงเห็นตัวเลขค้างเป็นบางครั้งโดยไม่มี error สักบรรทัด แก้ที่ยิงให้น้อยลง ไม่ใช่ยิงซ้ำให้มากขึ้น

try/except มีไว้เพราะคำสั่งมาจากคนพิมพ์ — โปรแกรมต้องไม่ตายเพราะคนอื่นพิมพ์ผิด

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

คำถามคิดต่อ: ถ้าเน็ตห้องเราหลุดไปสองนาที ข้อมูลช่วงนั้นควรหายไปเลย หรือบอร์ดควรเก็บไว้ส่งทีหลัง · ใครควรเป็นคนตัดสินใจว่าค่าไหนผิดปกติ ระหว่างบอร์ดกับแพลตฟอร์ม · ถ้ามีอุปกรณ์ 500 ตัวส่งทุก 5 วินาที broker ตัวเดียวรับไหวไหม และเราจะรู้ได้อย่างไรก่อนจะสาย

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

ทั้งสี่มุมนี้ใช้คำสั่งชุดเดียวกับที่เราเพิ่งเขียนวันนี้ ต่างกันแค่จำนวนอุปกรณ์และความสำคัญของข้อมูล

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

เรียนรู้ MQTT และควบคุมอุปกรณ์ IoTs จากทุกมุมโลกด้วย MQTT เข้าใจง่าย — IT around U · 21 นาที 26 วินาที · ไทย — ตัวเลือกภาษาไทยที่ครบที่สุด: ตั้ง broker เอง สาธิต pub/sub และคุมอุปกรณ์จริง (ข้ามส่วนติดตั้งได้ที่นาทีที่ 10)

MQTT Essentials Part 1 — What is MQTT — HiveMQ · 6 นาที 26 วินาที · อังกฤษ — อธิบายว่าทำไม IoT ไม่เลือก HTTP ตั้งแต่ต้น เป็นตอนแรกของซีรีส์ที่เราหยิบตอน 6 และ 7 มาใช้แล้ว

อ่านต่อสำหรับคนอยากรู้ลึก

• MQTT Core Concepts — EMQX (topic, wildcard, QoS, retained, will ครบในหน้าเดียว): https://docs.emqx.com/en/emqx/latest/messaging/mqtt-concepts.html
• MQTT Topics and Wildcards: A Beginner's Guide — EMQX (มีตัวอย่างที่แมตช์และไม่แมตช์ให้ฝึก): https://www.emqx.com/en/blog/advanced-features-of-mqtt-topics
• MQTT และการใช้งานสำหรับ Linux (ตอนที่ 1) — IoT Engineering Education, KMUTNB: https://iot-kmutnb.github.io/blogs/training/mqtt_linux_part-1/

คลิปเหล่านี้ไม่อยู่ในเกณฑ์ผ่าน แต่คนที่ดูจะเข้าใจคาบ 11 เรื่อง TLS ได้เร็วกว่าเพื่อน

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

ข้อ 1 · ฟังทั้งห้องด้วย wildcard — subscribe device/+/telemetry แล้วบันทึกว่าแต่ละทีมส่งฟิลด์อะไร ทำตารางเทียบ แล้วเสนอว่า ถ้าทั้งห้องต้องใช้ schema เดียวกัน ควรมีฟิลด์ใดบ้างและชื่อว่าอะไร พร้อมเหตุผล

ข้อ 2 · คำสั่งชุดใหญ่ขึ้น — ขยายคำสั่งเป็น {"cmd":"set","led":"RGB_GREEN","on":1} ให้คุม LED ได้ทุกดวงของบอร์ดแยกกัน (gpio.num_leds() ดวง — 3 บน Eva, 5 บน Dev Kit — ระบุดวงด้วยชื่อจาก board_info()["led_names"] ไม่ใช่เลข เพราะเลขเดียวกันคือคนละหลอดบนคนละบอร์ด) และให้บอร์ด publish สถานะกลับ ไปที่ .../status ทุกครั้งที่เปลี่ยน เพื่อให้ฝั่งคอมไม่ต้องเดา

ข้อ 3 · วัดเพดาน 255 ไบต์ด้วยมือตัวเอง — ส่งคำสั่งที่ยาวขึ้นทีละ 10 ไบต์จนโปรแกรมเริ่มพัง บันทึกว่าพังที่ความยาวเท่าไรและอาการเป็นอย่างไร แล้วเขียนวิธีป้องกันที่ดีกว่าการเดา

ข้อ 4 · ส่งเมื่อค่าเปลี่ยน แทนการส่งตามเวลา — เปลี่ยนเงื่อนไขเป็น "ค่าเปลี่ยนเกินเกณฑ์ หรือ ครบ 60 วินาทีแล้วยังไม่ได้ส่ง" แล้ววัดว่าจำนวนข้อความต่อนาทีลดลงกี่เปอร์เซ็นต์ พร้อมอธิบายว่าทำไมยังต้องมีเงื่อนไขข้อหลัง

เขียนคำตอบลง worksheet ข้อ 8 แล้วเอามาเล่าให้เพื่อนฟังต้นคาบหน้า

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

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

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

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

มาตรฐานและเอกสารโพรโทคอล

• MQTT Version 3.1.1, OASIS Standard (อนุมัติ 2014-10-29) — https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
• MQTT Version 5.0, OASIS Standard (อนุมัติ 2019-03-07) — https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
• MQTT Core Concepts — EMQX Documentation — https://docs.emqx.com/en/emqx/latest/messaging/mqtt-concepts.html
• MQTT Topics and Wildcards: A Beginner's Guide — EMQX — https://www.emqx.com/en/blog/advanced-features-of-mqtt-topics
• MQTT Essentials — HiveMQ — https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/
• Eclipse Mosquitto test broker — https://test.mosquitto.org/

วิดีโอ

• อะไรคือ MQTT ? — code maow maow | โค้ดแมวแมว — https://www.youtube.com/watch?v=qVLOZYzBU-g
• MQTT Essentials Part 6 — Topic Best Practices — HiveMQ — https://www.youtube.com/watch?v=juq_l70Vg1w
• MQTT Essentials Part 7 — Quality of Service — HiveMQ — https://www.youtube.com/watch?v=hvhtJORsE5Y
• MQTT Essentials Part 1 — What is MQTT — HiveMQ — https://www.youtube.com/watch?v=jTeJxQFD8Ak
• เรียนรู้ MQTT และควบคุมอุปกรณ์ IoTs จากทุกมุมโลกด้วย MQTT เข้าใจง่าย — IT around U — https://www.youtube.com/watch?v=Gu9txMng_nQ
• MQTT และการใช้งานสำหรับ Linux (ตอนที่ 1) — IoT Engineering Education, KMUTNB — https://iot-kmutnb.github.io/blogs/training/mqtt_linux_part-1/

ภาพ (ทุกไฟล์เก็บไว้ใน slides/img/ ไม่ได้ลิงก์ข้ามเว็บ) — จาก Wikimedia Commons:

• s10_mqtt_publish_flow.png (Brivadeneira, CC BY-SA 4.0) · s10_mqtt_topic_wildcards.svg (Ademant, CC BY-SA 4.0) · s10_mqtt_session_flow.svg (Simon A. Eugster, CC BY-SA 4.0)
• s10_mqtt_publish_packet.svg (Blacktron, CC BY-SA 4.0) · s10_clientserver_sequence.png (Michel Bakni, CC BY-SA 4.0) · s10_pubsub_topic_decoupling.svg (Mathieu.clabaut, CC BY-SA 4.0) · s10_mitm_attack.svg (Miraceti, CC BY-SA 3.0)
• s10_ce_devices.png, s10_ce_dashboard.png — ภาพหน้าจอ TESAIoT Community Edition v1.1.8, docs/images/screenshots/ (Apache-2.0)

ข้อเท็จจริงของเฟิร์มแวร์และแพลตฟอร์ม

ข้อจำกัดของโมดูล mqtt (ช่องรับ 1 ข้อความ, payload ขาเข้า 255 ไบต์, client_id/username 31 ตัวอักษร, ไม่มี retain, คีย์เวิร์ด keepalive) ตรวจจากซอร์ส modmqtt.c ใน BENTO-TESAIoT-libraries ซึ่งเป็นโค้ดร่วมของทั้ง Eva Kit และ TESAIoT Dev Kit (เพดานทุกตัวจึงเท่ากันสองบอร์ด) · การที่ sensors.init() ถูกปฏิเสธบน Eva Kit และค่าทั้งหมดมาจาก sensors.snapshot() ของคอร์จอ ตรวจจาก modsensors.c (sensors_init() บรรทัด 549 และ sensors_snapshot() บรรทัด 825) · บน Dev Kit snapshot() คืน dict รูปเดียวกัน (IMU อ่านตรงจาก CM33, CapSense/pot จากคอร์จอ) และไม่มีคีย์อุณหภูมิบนบอร์ดไหน — ห้าไฟล์ของคาบ 9–12 จึงอ่านอุณหภูมิผ่าน read_temp() (SHT40 บน Dev Kit / ลูกบิดแทนบน Eva) · ข้อเท็จจริงของ TESAIoT CE (พอร์ต 127.0.0.1:11883, listener 0.0.0.0:1883, reset-mqtt-password, username == client_id == device_id, ACL, การเติม device_id/timestamp และการแบนค่าซ้อนเป็น accel_x) ตรวจจาก repo tesaiot/tesaiot-community-edition v1.3.1 เมื่อ 2026-08-12

ทุกตัวเลขบนสไลด์นี้สืบกลับไปที่ซอร์สโค้ดหรือเอกสารต้นทางได้ ถ้าเจอที่ไม่ตรง บอกผู้สอนได้เลย