MQTT Archives - Page 3 of 3 - บริษัท ฮันนี่คอร์ปอเรชั่น จำกัด

May292026 by contentNo Comments

Industrial Router และ Edge Gateway: โครงสร้างเครือข่ายที่เชื่อมโยง Smart Factory ยุคใหม่

Article

📊 Market Insight 2026: ตลาด Industrial Router ทั่วโลกมีมูลค่ากว่า 3 พันล้านเหรียญสหรัฐ และคาดว่าจะเติบโตต่อเนื่องถึงปี 2031 ขับเคลื่อนด้วยความต้องการ Operational Efficiency และ Data-Driven Decision Making ในโรงงานอุตสาหกรรม Industrial Router คืออะไร? ทำไมโรงงานต้องใช้ Industrial Router หรือ Industrial Gateway คืออุปกรณ์เครือข่ายที่ออกแบบมาสำหรับสภาพแวดล้อมอุตสาหกรรมโดยเฉพาะ ทำหน้าที่เชื่อมต่ออุปกรณ์ IoT, PLC, Sensor และเครื่องจักรต่างๆ ภายในโรงงานเข้ากับระบบ IT และ Cloud Platform ต่างจาก Router ทั่วไปตรงที่ Industrial Router ต้องทนสภาพแวดล้อมที่รุนแรง เช่น อุณหภูมิสูง (-40°C ถึง +75°C), ความสั่นสะเทือน, ฝุ่น, ความชื้น และสัญญาณรบกวนทางแม่เหล็กไฟฟ้า (EMI) ที่พบได้ทั่วไปในโรงงานอุตสาหกรรม Industrial Router vs Consumer Router คุณสมบัติ Consumer Router Industrial Router Operating Temp 0°C ถึง 40°C -40°C ถึง +75°C MTBF ~50,000 ชั่วโมง 200,000+ ชั่วโมง Power Input AC 220V เท่านั้น DC 12-48V, Redundant Power DIN Rail Mount ไม่รองรับ รองรับ ✓ Protocol Support TCP/IP, WiFi Modbus, OPC UA, MQTT, Profinet, EtherCAT VPN / Security พื้นฐาน IPSec, WireGuard, Firewall, IEC 62443 Cellular (4G/5G) บางรุ่น Built-in 4G LTE / 5G, Dual SIM ประเภทของ Industrial Router / Gateway 1.…

May252026 by contentNo Comments

CoAP (Constrained Application Protocol) สำหรับ IIoT: โปรโตคอลว่ายน้ำหนักเบาสำหรับอุปกรณ์ IoT ขนาดเล็ก

Article

CoAP คืออะไร? โปรโตคอลที่ออกแบบมาเพื่ออุปกรณ์ Constrained ในโลกของ Industrial IoT อุปกรณ์จำนวนมากยังคงใช้ไมโครคอนโทรลเลอร์ขนาดเล็กที่มี RAM เพียง 10-100 KB และ Flash Memory ไม่เกิน 250 KB อุปกรณ์เหล่านี้ไม่สามารถรัน HTTP/TCP stack ที่หนักและซับซ้อนได้ CoAP (Constrained Application Protocol) จึงถูกพัฒนาขึ้นโดย IETF (RFC 7252) เพื่อเป็นโปรโตคอลระดับแอปพลิเคชันสำหรับอุปกรณ์ประเภทนี้โดยเฉพาะ CoAP ทำงานบน UDP แทน TCP ทำให้ overhead ต่ำกว่า HTTP อย่างมีนัยสำคัญ — packet header ของ CoAP มีขนาดเพียง 4 bytes เทียบกับ HTTP header ที่อาจมีขนาดหลายร้อย bytes แต่กระนั้น CoAP ยังคงรักษาโมเดล Request-Response ที่คุ้นเคย พร้อมรองรับ RESTful interaction เช่น GET, POST, PUT, DELETE เหมือน HTTP 💡 ข้อควรรู้: CoAP ไม่ได้มาแทนที่ MQTT แต่มาเติมเต็มช่องว่างที่ MQTT ทำไม่ได้ — โดยเฉพาะกรณีที่ต้องการ Request-Response pattern, Resource Discovery และการทำงานแบบ Multicast ในเครือข่ายท้องถิ่น สถาปัตยกรรม CoAP: เลเยอร์ที่ทำให้มันพิเศษ CoAP ถูกออกแบบมาด้วยสถาปัตยกรรมแบบ 2 เลเยอร์: Message Layer — จัดการการส่ง-รับข้อมูลผ่าน UDP รองรับ Confirmable (CON) และ Non-confirmable (NON) message, พร้อม mechanism ตรวจสอบ duplicate message โดยอัตโนมัติ Request/Response Layer — ทำงานเหนือ Message Layer จัดการ RESTful method (GET, POST, PUT, DELETE) และ response code ที่คล้าย HTTP (2.05…

May182026 by contentNo Comments

AMQP สำหรับ IIoT: Advanced Message Queuing Protocol — โปรโตคอลระดับ Enterprise เพื่อการส่งข้อมูลอุตสาหกรรมแบบไร้สูญหาย

Article

AMQP คืออะไร? โปรโตคอลสื่อสารที่มีความน่าเชื่อถือสูงสำหรับ IIoT ในโลกของ Industrial IoT (IIoT) ที่มีอุปกรณ์และระบบจำนวนมากต้องสื่อสารกันอย่างต่อเนื่อง การเลือกโปรโตคอลที่เหมาะสมจึงเป็นปัจจัยสำคัญต่อความสำเร็จของระบบ AMQP (Advanced Message Queuing Protocol) คือโปรโตคอลระดับ Application Layer ที่ออกแบบมาเพื่อการส่งข้อความอย่างน่าเชื่อถือ มีมาตรฐาน OASIS รองรับ และเหมาะกับงานอุตสาหกรรมที่ข้อมูลต้องถึงจุดหมาย แน่นอน 100% สถาปัตยกรรมของ AMQP: Exchange, Queue และ Binding AMQP ใช้โมเดล Broker-Based Messaging ที่มีองค์ประกอบหลักดังนี้: Exchange — จุดรับข้อความจาก Publisher แล้วกระจายไปยัง Queue ตามกฎ (Routing Rule) Queue — พื้นที่เก็บข้อความชั่วคราว รอให้ Consumer มารับไปประมวลผล Binding — กฎเชื่อมระหว่าง Exchange กับ Queue ด้วย Routing Key Routing Key — รหัสที่ใช้ตัดสินใจว่าข้อความจะไป Queue ไหน การออกแบบแบบนี้ทำให้ AMQP รองรับ Publish-Subscribe, Point-to-Point และ Request-Reply ได้ในโปรโตคอลเดียว ประเภท Exchange ใน AMQP 1.0 Exchange Type พฤติกรรม Routing Use Case ในอุตสาหกรรม Directตรงกับ Routing Key แบบ Exact Matchส่งคำสั่งควบคุมไปยัง PLC เครื่องจักรเฉพาะเครื่อง Fanoutส่งไปทุก Queue ที่ผูกกับ ExchangeBroadcast สถานะระบบไปทุก Dashboard Topicตรงกับ Routing Key แบบ Patternกรองข้อมูล Sensor ตาม Zone/Line Headersตรงกับ Header Attributesจัดกลุ่มข้อความตาม Priority หรือ Type AMQP vs MQTT: เลือกอย่างไรให้โรงงาน? Feature AMQP MQTT ขนาด Overhead8 byte frame + header2 byte ต่อ packet…

Mar262026 by contentNo Comments

OPC UA: มาตรฐานการสื่อสารที่ช่วยเชื่อมต่อระบบ OT กับ IT ในโรงงาน

Article

OPC UA คืออะไร? OPC Unified Architecture (UA) คือมาตรฐานการสื่อสารที่พัฒนาโดย OPC Foundation เพื่อเป็น "ภาษาสากล" ของระบบอุตสาหกรรม ต่างจากโปรโตคอลดั้งเดิมอย่าง Modbus, Profibus หรือ EtherNet/IP ที่แต่ละยี่ห้อใช้ภาษาเฉพาะตัว OPC UA ถูกออกแบบมาให้เป็น open standard ที่ทุกอุปกรณ์ — ไม่ว่าจะเป็น PLC ยี่ห้อใดก็ตาม — สามารถสื่อสารกันได้โดยไม่ต้องพึ่ง gateway หรือ middleware เฉพาะทาง จุดเด่นสำคัญของ OPC UA คือ platform independence — ทำงานได้ทั้งบน Windows, Linux, หรือแม้แต่ embedded system ที่มี RAM เพียง 50 KB นี่เป็นข้อได้เปรียบมหาศาลเมื่อเทียบกับ OPC Classic ที่ต้องอาศัย COM/DCOM ของ Windows แต่เดิม ทำไม OPC UA ถึงเหมาะกับ IIoT มากกว่าโปรโตคอลดั้งเดิม ในโรงงานอัจฉริยะยุคใหม่ ระบบ Operational Technology (OT) ต้อง "คุย" กับระบบ Information Technology (IT) ได้อย่างไร้รอยต่อ — ไม่ว่าจะเป็น SCADA, MES, ERP หรือ cloud analytics platform โปรโตคอลดั้งเดิมถูกออกแบบมาเพื่อการสื่อสารภายในโรงงานเท่านั้น พวกมันไม่มี security model ที่เพียงพอ และไม่รองรับ semantic information (ข้อมูลที่มีความหมายในตัว) OPC UA แก้ปัญหานี้ด้วยการออกแบบที่ครอบคลุม: หน่วยข้อมูลที่ซับซ้อน: ไม่ใช่แค่ 0/1 หรือตัวเลข แต่รองรับ alarm, event, historical data และ complex data types Transport layer ที่ยืดหยุ่น: ใช้ได้ทั้ง TCP/IP แบบดั้งเดิม และ MQTT/AMQP สำหรับ IIoT use cases Built-in security: มี encryption (AES-256),…

Mar262026 by contentNo Comments

SCADA สู่ IoT: การยกระดับระบบควบคุมอุตสาหกรรมสู่ยุคดิจิทัล

Article

ระบบ SCADA (Supervisory Control and Data Acquisition) เป็นหัวใจหลักของการควบคุมโรงงานมาตั้งแต่ทศวรรษ 1970 แต่ระบบ SCADA รุ่นเก่าหลายระบบยังคงทำงานบนโปรโตคอลและฮาร์ดแวร์ที่ไม่ได้ออกแบบมาเพื่อเชื่อมต่อกับโลกดิจิทัล การยกระดับ SCADA ให้รองรับ IoT จึงเป็นความท้าทายที่ผู้ประกอบการไทยต้องเผชิญในการแข่งขันยุค Industry 4.0ความท้าทายของ SCADA รุ่นเก่าSCADA ดั้งเดิมถูกออกแบบมาเพื่อการทำงานแบบ Isolated Network ไม่มีการเข้ารหัสข้อมูล การยืนยันตัวตนที่เข้มงวด หรือการเชื่อมต่อกับระบบ Cloud ทำให้เมื่อต้อง Modernize ต้องเผชิญกับความท้าทายหลายประการปัญหาสำคัญคือ Protocol ที่ไม่รองรับ IP เช่น Modbus RTU ที่ใช้ RS-485 ซึ่งต้องมี Gateway แปลงข้อมูลก่อน อีกปัญหาคือ Legacy Hardware ที่ไม่สามารถรับการอัปเดต firmware ได้ รวมถึงความเสี่ยงจากการหยุดระบบ (Downtime) ที่มักส่งผลกระทบต่อการผลิตโดยตรง3 แนวทางการยกระดับ SCADAแนวทางที่ 1: Edge Gateway + Cloud Integrationติดตั้ง IoT Edge Gateway ที่ทำหน้าที่เป็นตัวกลางระหว่างระบบ SCADA เดิมกับ Cloud Platform โดย Gateway จะรวบรวมข้อมูลจาก PLC และ RTU ผ่านโปรโตคอลอุตสาหกรรม แปลงเป็น MQTT หรือ OPC UA แล้วส่งไปยัง Azure IoT Hub, AWS IoT Core หรือ Google Cloud IoTข้อดีของแนวทางนี้คือไม่ต้องแก้ไขระบบ SCADA เดิมมาก สามารถเริ่มจากจุดเดียวแล้วขยายได้ ตัวอย่างเช่น โรงงานผลิตยาในกรุงเทพฯ ที่ใช้ Edge Gateway เชื่อมต่อ SCADA รุ่น 15 ปีกับ Power BI Dashboard สำหรับ Real-time monitoringแนวทางที่ 2: IIoT Platform บน Edgeใช้แพลตฟอร์มอย่าง Predictive Maintenance as a Service ที่ติดตั้งบน Edge Device ใกล้เครื่องจักร ระบบจะเรียนรู้ Pattern การทำงานปกติของเครื่องจักร และส่ง Alert เมื่อพบความผิดปกติ โดยไม่ต้องส่งข้อมูลดิบทั้งหมดไปยัง…

Mar242026 by contentNo Comments

เจาะลึกเทคโนโลยีสื่อสารยุคใหม่ (NB-IoT / LoRaWAN / Sigfox): เลือกอย่างไรให้เหมาะกับโปรเจกต์ IoT ของคุณ

Article

ทำไมต้องสนใจเรื่องนี้? โปรเจกต์ IoT จะ "ปัง" หรือ "พัง" มักเริ่มต้นที่การเลือก "วิธีการสื่อสาร" ครับ หากเลือกผิด ชีวิตเปลี่ยนทันที! เพราะเทคโนโลยีที่เหมาะกับฟาร์มอัจฉริยะอาจไม่ใช่ตัวเลือกที่ดีที่สุดสำหรับโรงงานอุตสาหกรรม และระบบวัดน้ำประปาก็ไม่ควรใช้ LoRaWAN ในทุกกรณี วันนี้เราจะพาทุกท่านเจาะลึก 3 เทคโนโลยี LPWAN (Low Power Wide Area Network) ยอดฮิต พร้อมตารางเปรียบเทียบและแนวทางการเลือกที่ชัดเจน เปรียบเทียบภาพรวม 3 เทคโนโลยี LPWAN เกณฑ์ NB-IoT LoRaWAN Sigfox ความถี่ใช้งาน 1800 MHz (เครือข่ายมือถือ) 923 MHz (Unlicensed) 923 MHz (Unlicensed) ระยะส่งข้อมูล ไม่จำกัด (ใช้เครือข่ายมือถือ) 2-15 กม. (ที่โล่ง) 3-12 กม. (ที่โล่ง) ความเร็วส่งข้อมูล สูง (Up to 250 kbps) ปานกลาง (0.3-50 kbps) ต่ำ (100 bps) อายุแบตเตอรี่ 5-10 ปี 10+ ปี 10-15 ปี ค่าใช้จ่าย ค่าบริการ SIM (ต่อปี) ซื้อ Gateway ครั้งเดียว + ค่าบริการ ค่าบริการตามจำนวนข้อความ ต้อง Gateway ของตัวเอง ❌ ไม่ต้อง ✅ ต้องการ ❌ ไม่ต้อง Penetration (ทะลุวัสดุ) ✅ ดีเยี่ยม ✅ ดีมาก ดี 1. NB-IoT (Narrowband IoT) หลักการทำงาน NB-IoT เป็นเทคโนโลยีที่พัฒนาบนโครงสร้างเครือข่ายมือถือที่มีอยู่เดิม ออกแบบมาเพื่อ IoT โดยเฉพาะ ส่งข้อมูลน้อยๆ แต่ความเสถียรสูงมาก จุดเด่น ใช้เสาสัญญาณโทรศัพท์มือถือที่มีอยู่แล้ว (AIS, True, DTAC) สัญญาณทะลุทะลวงดีมาก แม้แต่ในท่อระบายน้ำหรือชั้นใต้ดิน เสถียรภาพสูง เครือข่ายมือถือมี SLA ที่ชัดเจน รองรับ Firmware Update ผ่าน OTA ได้ ข้อจำกัด ต้องจ่ายค่าบริการ…

Mar242026 by contentNo Comments

เจาะลึก OEE (Overall Equipment Effectiveness): ดัชนีชี้วัดความอยู่รอดของโรงงานในยุค Digital

Article

ทำไมต้องสนใจเรื่องนี้? ถ้าคุณดูแลโรงงานผลิตอยู่ ลองนึกดูว่า เครื่องจักรเดินตลอดเวลา แต่ยอดผลิตกลับต่ำกว่าเป้า — สาเหตุที่แท้จริงซ่อนอยู่ตรงไหน? ตามมาตรฐาน JIPM (Japan Institute of Plant Maintenance) โรงงานที่มี OEE ต่ำกว่า 85% ถือว่ายังมีโอกาสปรับปรุงได้อีกมาก และในความเป็นจริง โรงงานส่วนใหญ่ทั่วโลกมี OEE เฉลี่ยเพียง 60-65% ซึ่งหมายความว่ากำลังการผลิตที่มีศักยภาพสูญเสียไปถึง 1 ใน 3 โดยไม่รู้ตัว วันนี้เล่าให้ฟังว่า OEE คืออะไร มันบอกอะไรเราได้บ้าง และทำไม IIoT ถึงเปลี่ยนเกมการวัดผลในโรงงานยุคใหม่ OEE คืออะไร? OEE ย่อมาจาก Overall Equipment Effectiveness คือดัชนีชี้วัดประสิทธิผลโดยรวมของเครื่องจักร ถูกคิดค้นโดย Seiichi Nakajima จาก JIPM ในปี 1960s โดยมีสูตรหัวใจดังนี้: OEE = Availability × Performance × Quality 3 ปัจจัยหลักของ OEE 1. Availability — ความพร้อมเดินเครื่อง วัดว่าเครื่องจักรทำงานได้ตามเวลาที่กำหนดหรือไม่ คำนวณจาก: Availability = (Run Time ÷ Planned Production Time) × 100 สาเหตุที่เครื่องไม่พร้อมทำงาน เช่น เครื่องเสีย, เปลี่ยนงาน (Changeover), ขาดวัตถุดิบ 2. Performance — ประสิทธิภาพการเดินเครื่อง วัดว่าเครื่องจักรทำงานเร็วแค่ไหนเมื่อเทียบกับความเร็วมาตรฐาน คำนวณจาก: Performance = (Ideal Cycle Time × Total Count ÷ Run Time) × 100 สาเหตุที่ประสิทธิภาพต่ำ เช่น หยุดชั่วคราว (Short Stop), เดินช้ากว่าความเร็วมาตรฐาน 3. Quality — คุณภาพ วัดสัดส่วนของผลิตภัณฑ์ที่ผ่านเกณฑ์ คำนวณจาก: Quality = (Good Count ÷ Total Count) × 100 ของเสียเกิดจากหลายสาเหตุ เช่น วัตถุดิบไม่ได้มาตรฐาน หรือเครื่องจักรไม่แม่นยำ ตัวอย่างการคำนวณ OEE…

Mar242026 by contentNo Comments

จาก SCADA สู่ IIoT: ปลดล็อกศักยภาพโรงงานอัจฉริยะด้วยการเชื่อมต่อไร้รอยต่อ

Article

ทำไมต้องสนใจเรื่องนี้? ลองนึกดูว่า โรงงานของคุณมี SCADA ที่ลงทุนไปนับสิบปี ยังทำงานได้ดี แต่ข้อมูลมันอยู่แต่ในห้อง Control Room ผู้บริหารไม่เห็น ไม่สามารถนำไปวิเคราะห์ต่อได้ ขณะที่คู่แข่งเขาใช้ AI คาดการณ์การเสียของเครื่องจักรได้ล่วงหน้า คุณยังต้องรอให้เครื่องเสียก่อนถึงรู้ว่ามีปัญหา ตามรายงานของ MarketsandMarkets ตลาด IIoT ทั่วโลกมีมูลค่าสูงถึง 115.7 พันล้านเหรียญสหรัฐ ในปี 2024 และคาดว่าจะเติบโตเฉลี่ย 9.6% ต่อปี นโยบาย Thailand 4.0 ก็ผลักดันให้โรงงานไทยต้องยกระดับสู่ Smart Manufacturing ด้วยเช่นกัน วันนี้เล่าให้ฟังว่า ทำไม SCADA เก่าถึงยังมีคุณค่า และทำไมการ "ต่อยอด" ด้วย IIoT ถึงเป็นทางเลือกที่ดีกว่าการ "เปลี่ยนทิ้ง" SCADA vs IIoT: ทำความเข้าใจความแตกต่าง SCADA — ระบบควบคุมในวงปิด SCADA (Supervisory Control and Data Acquisition) คือระบบที่ทำหน้าที่ควบคุมและเก็บข้อมูลจากเครื่องจักรในโรงงานมาอย่างยาวนาน เน้นความเสถียร (Reliability) และการสั่งการแบบ Real-time แต่ข้อจำกัดหลักคือ: ข้อมูลถูกเก็บในวงปิด (Silos) — ยากต่อการนำไปวิเคราะห์หรือใช้งานร่วมกับระบบอื่น Protocol ตกรุ่น — หลายระบบยังใช้ Modbus, Profibus ที่เชื่อมต่อกับ Cloud ได้ยาก ขาดความยืดหยุ่น — การขยายระบบหรือเพิ่มเซ็นเซอร์ใหม่มีความซับซ้อนสูง IIoT — ระบบเชื่อมต่อไร้พรมแดน IIoT (Industrial Internet of Things) คือการนำเซ็นเซอร์และอุปกรณ์จำนวนมากเชื่อมต่อผ่านเครือข่ายอินเทอร์เน็ต เพื่อเก็บ Big Data ไปวิเคราะห์บน Cloud หรือ Edge Computing สร้าง Insight ที่ซ่อนอยู่ ใช้ Protocol ยุคใหม่อย่าง MQTT, OPC-UA และ RESTful API 3 แนวทางการผสานรวมระบบ (Integration Methods) 1. Gateway-based Integration (แนะนำ) ติดตั้งอุปกรณ์ Edge Gateway เชื่อมต่อกับ PLC หรือ RTU เดิม ทำหน้าที่แปลง Protocol และส่งข้อมูลไปยัง Cloud ผ่าน MQTT หรือ…

Mar242026 by contentNo Comments

MQTT vs REST API: ทำไม MQTT ถึงเป็นมาตรฐานการสื่อสารใน IIoT

Article

ทำไมต้องสนใจเรื่องโปรโตคอลการสื่อสาร? ถ้าคุณเป็นเจ้าของโรงงานหรือวิศวกรที่กำลังจะเอา IoT เข้ามาใช้ในการผลิต สิ่งที่ต้องตัดสินใจตั้งแต่แรกๆ เลยก็คือ “จะให้เครื่องมันคุยกันยังไง” — คำตอบนี้ส่งผลต่อทุกอย่างตั้งแต่ความเร็วในการรับส่งข้อมูล ไปจนถึงค่าใช้จ่ายในการดูแลระบบ วันนี้เล่าให้ฟังเรื่อง MQTT กับ REST API สองตัวเลือกที่ใช้กันมากในโลก IIoT ว่าแต่ละตัวมันต่างกันยังไง และทำไมเดี๋ยวนี้หลายโรงงานถึงเลือกใช้ MQTT MQTT คืออะไร? MQTT (Message Queuing Telemetry Transport) เป็นโปรโตคอลที่ออกแบบมาสำหรับเชื่อมต่ออุปกรณ์ IoT โดยเฉพาะ ถูกพัฒนาขึ้นโดยวิศวกรของ IBM ตั้งแต่ปี 1999 และกลายเป็นมาตรฐานสากลตั้งแต่ปี 2013 จนถึงตอนนี้ MQTT เป็นหนึ่งในโปรโตคอลที่ได้รับความนิยมมากที่สุดในโลก IIoT หลักการทำงานของ MQTT MQTT ใช้หลักการที่เรียกว่า Publish/Subscribe (Pub/Sub) — พูดง่ายๆ ก็คือ อุปกรณ์ที่ส่งข้อมูล (Publisher) จะไม่ส่งตรงไปหาใคร แต่ส่งไปที่ Broker ซึ่งเป็นตัวกลาง แล้ว Broker กระจายข้อมูลไปให้อุปกรณ์ที่สนใจ (Subscriber) เอง องค์ประกอบหลักๆ มีแค่ 4 ตัว: Broker — ตัวกลางที่คอยรับข้อมูลแล้วกระจายต่อ Publisher — อุปกรณ์ที่ส่งข้อมูล เช่น เซ็นเซอร์วัดอุณหภูมิ Subscriber — อุปกรณ์หรือแอปที่รับข้อมูล เช่น Dashboard, SCADA Topic — ช่องทางสำหรับส่งข้อมูล เช่น factory1/sensors/temperature ทำไม MQTT ถึงเหมาะกับงาน IIoT มากกว่า REST API? 1. ขนาดเล็ก กินแบนด์น้อยมาก MQTT มี overhead แค่ 2 bytes ต่อ message เทียบกับ REST API ที่ใช้ HTTP Header หลายร้อย bytes ขึ้นไป สำหรับอุปกรณ์ IoT ที่ใช้พลังงานต่ำและเครือข่ายจำกัด ตรงนี้สำคัญมาก 2. Push-based — ข้อมูลมาถึงทันที ไม่ต้องคอยถาม REST API ทำงานแบบ “ถาม-ตอบ” คือต้องไปขอข้อมูลเรื่อยๆ (polling) ซึ่งเปลืองแบนด์และช้า MQTT จะส่งข้อมูลไปให้ทันทีเมื่อมีการเปลี่ยนแปลง ไม่ต้องคอยถาม 3.…