การเชื่อมต่อ Platform ผ่าน MQTT (Message Queuing Telemetry Transport) ซึ่งเป็น Protocol ที่มีขนาดเล็กและได้รับความนิยมสำหรับการสื่อสารแบบ M2M ( Machine to Machine ) โดยสามารถใช้ MQTT Library ตัวใดก็ได้ที่รองรับกับ Device ที่ใช้งานอยู่ การเชื่อมต่อของ MQTT จะต้องใช้ 4 Parameters คือ Show
ค่าสำหรับระบุลง Parameters ทั้ง 4 ค่าที่กล่าวไปข้างต้น สามารถดูได้จาก https://portal.netpie.io ในส่วนของข้อมูล Device ดังรูปต่อไปนี้ MQTT API จะมีลักษณะการใช้งานเป็นแบบ Publish / Subscribe โดย Publish จะเป็นการส่งข้อมูลไปยัง Topic ที่ต้องการ ส่วน Subscribe จะเป็นการรอรับข้อมูลใน Topic ที่ต้องการ การสั่ง Subscribe Topic ใดก็ตามทำเพียงครั้งเดียวก็จะได้รับข้อมูลใน Topic นั้นไปตลอดจนกว่าจะสั่ง Unsubscribe Topic นั้น หรือการเชื่อมต่อกับ Platform หยุดลง Note ฟิลด์ Enable คือ ฟิลด์ที่ใช้เซ็ตสถานะเปิด/ปิดการใช้งานของ Device ถ้า Toggle แสดงแทบสีฟ้า หมายความว่า Device ถูกเปิดใช้งานปกติ แต่ถ้า Toggle แสดงแทบสีเทา หมายถึง Device ถูกปิดการใช้งาน ซึ่งจะไม่สามารถใช้ Key ดังกล่าวเชื่อมต่อ Platform ได้ หรือถ้ามีการเชื่อมต่ออยู่ก็จะถูกตัดการเชื่อมต่อแบบอัตโนมัติ ซึ่งจะใช้ในกรณีที่ต้องการปิดการทำงานของ Device ที่อยู่ห่างไกลที่ไม่สามารถเข้าไปจัดการที่ตัว Device โดยตรงได้ เป็นต้น ปุ่ม Resync Status ใช้สำหรับอัพเดทสถานะการเชื่อมต่อ Platform ให้ถูกต้อง ในกรณีที่การแสดงผลบนหน้า Portal ไม่ถูกต้อง ให้คลิกที่ปุ่มดังกล่าวเพื่ออัพเดทสถานะได้ Caution ควรสั่ง Subscribe Topic ก่อนที่จะมีการสั่ง Publish Topic เดียวกัน เพื่อให้ได้รับข้อมูลที่ถูกส่งมา ซึ่งข้อมูลที่ได้รับจะเป็นข้อมูลที่เกิดจากการ Publish หลังการ Subscribe เท่านั้น องค์ประกอบสำคัญที่จำเป็นต้องทราบสำหรับการใช้งาน MQTT API คือ Topic เพราะ Publish / Subscribe จำเป็นต้องระบุ Topic ที่ต้องการ Topic จะหน้าที่เหมือน Endpoint บน MQTT Broker เพื่อให้ MQTT Client มาเชื่อมต่อและสื่อสารกัน โดยจะรองรับคุณสมบัติดังต่อไปนี้
โครงสร้าง Topic ใน NETPIE Platform สามารถแยกได้เป็น 3 ประเภท ดังนี้ Message API Topic¶เป็นการกำหนด Topic สำหรับ Publish / Subscribe ข้อมูลเพื่อสื่อสารระหว่าง Devices ที่อยู่ภายในใต้ Group เดียวกัน การจัด Device เข้า Group มีขั้นตอนตามรูปต่อไปนี้ โดยเมื่อนำ Device เข้า Group เรียบร้อยแล้ว รูปแบบการใช้งานให้ขึ้นต้น Topic ด้วย @msg ตามด้วยโครงสร้าง Topic ที่ต้องการ ดังนี้
จะเห็นได้ว่า Topic สามารถระบุเป็นลำดับชั้นได้โดยการคั่นด้วย “/” นอกจากการระบุ Topic ที่เฉพาะเจาะจงแล้ว ยังรองรับการระบุ Topic แบบ Wildcard ด้วย มี 2 ลักษณะ คือ
Note Wildcard Topic
Shadow API Topic¶MQTT Topic ที่เกี่ยวข้องกับการจัดการ Device Shadow สามารถแยกได้เป็น Publish และ Subscribe โดย Publish จะใช้กรณีที่ต้องการขอข้อมูลหรืออัพเดทข้อมูลใน Device Shadow ส่วน Subscribe จะเป็นการรอรับข้อมูลในกรณีที่มีการ Publish ไปขอข้อมูล หรือในกรณีที่มีการเปลี่ยนข้อมูล Device Shadow และได้ทำการ Subscribe ไว้ ซึ่งการใช้งานจะมีรายละเอียด ดังนี้
Note Publish Topic คือ การส่งข้อความออกไปยัง Topic ตามที่ระบุ Subscribe Topic คือ การขอรับข้อความที่ถูกส่งเข้ามายัง Topic ตามที่ระบุ Shadow Batch Update อธิบายรายละเอียดและวิธีใช้งานในหัวข้อถัดไป Tip Publish Topic MQTT topic : MQTT payload : โดยมีเงื่อนไขว่า ถ้า timestamp ที่ใส่มานั้น เก่ากว่า timestamp ล่าสุดที่ระบุอยู่ใน Shadow Data ค่าใน Shadow Data จะไม่ถูกอัพเดต และถ้ามีการตั้งค่า Device Trigger ก็จะไม่มี Event Shadow Updated แจ้งออกไป แต่จะแค่ส่งข้อมูลไปเก็บลง Timeseries Database และทำให้เกิดจุดข้อมูลย้อนหลังในเวลาที่กำหนดมาเท่านั้น Shadow Batch Update¶จะใช้ในกรณีที่ IoT Device ไม่สามารถส่งข้อมูลขึ้น Cloud Platform ได้ตามเวลาที่กำหนด เช่น อาจจะเกิดจากปัญหาการเชื่อมต่ออินเตอร์เน็ต เป็นต้น ทำให้ IoT Device จำเป็นต้องเก็บข้อมูลไว้ที่หน่วยความจำของ Device เองก่อน เช่น เก็บลง SD Card เป็นต้น และเมื่อสามารถเชื่อมต่อ Cloud Platform ได้ จึงทำการส่งข้อมูลที่เก็บไว้ทั้งหมดขึ้น Cloud Platform อีกที โดยสามารถส่งค่าขึ้น Platform ครั้งละหลาย ๆ จุดพร้อมกันได้ การเขียน Shadow แบบ Batch ทำได้ 3 ช่องทาง ได้แก่
โดยวิธีนี้จะไม่มีการตอบกลับ แต่หากต้องการให้มีการตอบกลับ เพื่อยืนยันว่าการดำเนินการสำเร็จ ต้องเพิ่มฟิลด์ ackid ซึ่งสามารถตั้งเป็นค่าอะไรก็ได้ เป็นได้ Number หรือ String โดยทุกการตอบกลับจะมีการทวนค่า ackid เดิม เพื่อให้ผู้ใช้สามารถจับคู่ระหว่าง Request และ Response ได้ ตัวอย่างดังนี้
โดยการรอรับข้อความตอบกลับจะต้อง Subscribe ไปยัง Topic ที่กำหนด มีลักษณะดังนี้
ในส่วนของฟิลด์เวลาที่ระบุกำกับให้แต่ละจุดข้อมูลที่จะทำการเขียนลง Shadow มีหน่อยเป็น Millisecond สามารถใช้คำว่า ts หรือ timestamp เป็นชื่อฟิลด์ก็ได้ หากมีค่าต่ำกว่า 1000 * 2^23 = 8388608000 จะถือว่าเป็นค่า Relative Time กับเวลาปัจจุบัน ถ้ามีค่ามากกว่า จะถือเป็น timestamp แบบ Absolute Time สามารถใช้ค่าลบแทนเวลาในอดีตได้ ซึ่งจะเหมาะสำหรับการอัพเดตข้อมูลจุดย้อนหลัง ยกตัวอย่างเช่น ถ้ากำหนด ts หรือ timestamp เป็น -90000 และ timestamp ปัจจุบัน คือ 1619075885 เวลาที่เกิดจุดข้อมูลนั้นจะเป็น 1619075885 - 90000 = 1618985885 (เวลาย้อนหลังไปจากปัจจุบัน 90 วินาที) Note ในส่วนของฟิลด์ การทำงานของ Expression ที่กำหนดไว้ใน Schema และ Trigger กรณีเขียน Shadow แบบ Batch Expression ยังคงถูกคำนวณตามสูตรที่กำหนดไว้ทุกชุดข้อมูล เหมือนการ For Loop เขียน Shadow เอง แต่การเขียน Shadow แบบ Batch จะถูกหักโควต้า Shadow Read/Write เพียง 1 Operation เท่านั้น แต่โควต้า Shadow Expression จะถูกหักตามจำนวนชุดข้อมูลเช่นเดิม ยกตัวอย่างเช่น ชุดข้อมูลที่ส่งค่ามาบันทึก 100 จุด และมีฟิลด์ข้อมูลที่เซ็ต Expression ไว้ 1 ฟิลด์ จำนวน Shadow Expression ที่ถูกหักจะเท่ากับ 1 x 100 = 100 Operations เป็นต้น สำหรับ Trigger จะทำงานเฉพาะชุดข้อมูลที่เป็นค่าล่าสุด (Timestamp มีค่าสูงสุด) เท่านั้น และจะถูกหักโควต้าการใช้งานเหมือนการเขียนข้อมูลแค่ชุดเดียว
Caution ข้อจำกัดของการเขียน Shadow แบบ Batch คือ จำนวนชุดข้อมูลที่ส่งไปเขียนได้ต่อครั้งต้องไม่เกิน 100 ชุดข้อมูล (JSON Array ของฟิลด์ { "batch" : [ {"data":{"temp":25.9, "humid":9.6}, "ts":-90000}, {"data":{"temp":25.3, "humid":9.8}, "ts":-60000}, {"data":{"temp":24.5, "humid":9.1}, "ts":-30000}, {"data":{"temp":26.8, "humid":8.2}, "ts":0} ], "merged": true } แสดงว่ามีจำนวนชุดข้อมูลเท่ากับ 4 ชุดข้อมูล เป็นต้น หากมีส่งชุดข้อมูลไปเกินกว่าที่กำหนด ข้อมูลทั้งหมดจะไม่ถูกบันทึก และจะมีข้อความแจ้งเตือนกลับมาในรูปแบบ JSON ดังนี้
หมายความว่า การเขียนข้อมูลแบบ Batch ที่ ackid เป็น 140 ส่งชุดข้อมูลไปเกิน 100 ชุด โดยส่งไป 102 ชุด เป็นต้น ข้อใดเป็นการรับส่งข้อมูลของ MQTT (Message Queue Telemetry Transport)MQTT (Message Queue Telemetry Transport) คือโปรโตคอลในการส่งข้อมูลที่พัฒนามาเพื่อใช้ในระบบ IOT มันทำงานแบบ Broker and Clients Network มันถูกออกแบบให้สามารถส่งข้อมูลแบบ Real-Time ในปริมาณข้อมูลที่น้อย ทำให้ใช้พลังงานต่ำมันถูกพัฒนามาจาก TCP/IP ที่มีการส่งข้อมูลแบบ One-To-One ทำให้สิ้นเปลืองทรัพยากรณ์มากซึ่งไม่เหมาะกับ ...
กลไกเอ็มคิวทีที (MQTT) สื่อสารผ่านตัวกลางที่เรียกว่าอะไรโดยตัวโปรโตคอล MQTT เองไม่ได้ออกแบบให้เชื่อมต่อจากเซิร์ฟเวอร์เข้าไปยังไคลเอนต์แบบ HTTP ที่เว็บเบราว์เซอร์เชื่อมต่อกับเว็บเซิร์ฟเวอร์ แต่ MQTT อาศัยตัวกลางที่เรียกว่า broker ในการเชื่อมต่อไคลเอนต์ในระบบเข้าด้วยกัน ทำให้ไคลเอนต์แต่ละตัวสามารถรับข้อมูลจากไคลเอนต์ตัวอื่นๆ ได้
ข้อใดเป็นข้อจำกัดของการใช้งาน MQTTข้อจำกัดของการสื่อสารแบบ request/response มีดังนี้
การที่จะได้ข้อมูลนั้น ฝั่ง Clients จะต้องส่ง request ไปก่อน ซึ่งเราจะไม่สามารถรับข้อมูลได้เลย หากไม่ส่ง request ไปก่อน ในระบบของ IoT บางระบบนั้นไม่ได้ต้องการที่จะอัพเดตทุกครั้งที่ที่มีการกดส่งข้อมูล แต่ต้องการข้อมูลที่อัพเดตอยู่ตลอดเวลา
ข้อตกลงระหว่างผู้ส่ง(Publisher) ผู้รับข้อมูล (MQTT Broker) ในการรับประกันการส่งข้อมูลมีกี่ระดับ อะไรบ้างQoS (Quality of Service) 3 ระดับ คือ ข้อตกลงระหว่างผู้ส่ง (Publisher) และผู้รับ (MQTT Broker) ในการรับประกันการส่งข้อมูล QoS Level 0 : การส่งข้อมูลที่มีการรับประกันผลในระดับต่ำสุด หรือเป็นข้อมูลที่ต้องการความรวดเร็วในการส่ง คือ ไม่ต้องการการตอบกลับว่าข้อมูลถึง MQTT Broker แล้ว
|