บทความ IoT
ไม่ว่าจะ ข่าวสาร บทสัมภาษณ์ และ Digital Skill บนสื่อ
มีให้คุณได้อ่านบทความดี ๆ มากมายแล้วที่นี่
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 2)
หลังจากบทความที่ผ่านมา เราพูดถึง MQTT Basics ซึ่งผู้เขียนเองได้พูดถึงการ Publish และ การ Subscribe เบื้องต้นClient, Broker, and Connection EstablishmentMQTT Publish, Subscribe, and Unsubscribeและ MQTT Topicsบทความนี้เราจะพูดก็คือ QoS หรือ Quality of Service ค่ะQoS คืออะไร? QoS คือ ข้อตกลงระหว่างผู้ส่ง และ ผู้รับ Message ซึ่งกำหนดไว้เพื่อเป็นการการันตีว่า Message นั้น สามารถถูกส่งไปถึงผู้รับแน่นอน ซึ่งใน MQTT จะมีอยู่ 3 ระดับค่ะAt most once (0)At least once (1)Exactly once (2)ในการกำหนดค่า QoS ใน MQTT เราจะพิจารณาการรับส่ง Message เป็น 2 ส่วนนะคะ คือส่วนที่ 1 : Message ที่ถูกส่งจาก Publisher ไป Brokerส่วนที่ 2 : Message ที่ถูกส่งจาก Broker ไป Subscriberสาเหตุที่เราต้องพิจารณาเป็น 2 ส่วน เพราะว่า ถึงแม้ ว่าจะเป็นการส่ง Message ที่มี Content เดียวกัน แต่ว่าผู้ส่งและผู้รับในส่วนที่ 1 และ ส่วนที่ 2 แตกต่างกันนะคะเวลาที่ Publisher ต้องการส่ง Message ให้กับ Broker ตัว Publisher จะเป็นฝ่ายกำหนดค่า QoS ให้กับ Message นั้นๆ แต่ตรงกันข้ามเวลา Broker จะส่งต่อ Message ให้กับ Subscriber เนี่ย จะใช้ค่า QoS ที่ถูกกำหนดโดย Subscriber ค่ะแล้วถ้าเกิดค่า QoS ระหว่างส่วนที่ 1 และ ส่วนที่ 2 ต่างกันแล้วเราจะต้องใช้ค่าไหน? ถ้าหากค่า QoS จากส่วนที่ 2 มีค่าต่ำกว่าค่า QoS ในส่วนที่ 1 ตัว Broker จะใช้ค่า QoS ที่ต่ำกว่า ซึ่งก็คือค่า QoS จากส่วนที่ 2 ค่ะจะเห็นว่า QoS นั้นมีความสำคัญกับ MQTT ไม่น้อยเลย นั่นเพราะว่า QoS ถือว่าเป็น Key Feature นึงของ MQTT Protocol ค่ะ QoS ให้อิสระกับ Client (Publisher/Subscriber) ในการกำหนดค่า เพื่อให้รองรับกับประสิทธิภาพของ Network และ ApplicationQoS ทำให้การรับส่ง Message เป็นไปอย่างราบรื่น ถึงแม้จะเจอข้อจำกัดทาง Network (Unreliable Network ) เพราะว่า MQTT สามารถจัดการเรื่อง Message Retransmission และ มีการการันตีว่า Message จะได้รับแน่นอนถึงตรงนี้เราลองมาดูกันค่ะว่าแต่ละเลเวลของ QoS มีความหมาย และ ทำงานอย่างไรในระบบของ MQTT Protocolระดับของ QoSQoS 0 — at most onceระดับ QoS ที่น้อยที่สุดคือ ศูนย์ (0) ค่ะ ซึ่งค่านี้จะไม่มีการการันตีการได้รับ Message เลย ( Best-Effort Delivery ) ในระดับ QoS นี้ Message จะไม่ถูกจัดเก็บเพื่อทำการ Retransmission ค่ะQoS 0 จะมักจะถูกเรียกว่า ‘Fire and Forget’ และจะมีเลเวลการการันตีการได้รับ Message ตาม TCP Protocol ใน Layer ด้านล่างค่ะ (เพราะ MQTT Protocol อยู่ใน Application Layer ตาม TCP/IP Network Model ค่ะ)QoS 0 จะมักจะถูกเรียกว่า ‘Fire and Forget’ และจะมีเลเวลการการันตีการได้รับ Message ตาม TCP Protocol ใน Layer ด้านล่างค่ะ (เพราะ MQTT Protocol อยู่ใน Application Layer ตาม TCP/IP Network Model ค่ะ)Qos 0 — at most onceQoS 1 — at least onceQoS 1 นั้น จะการันตีว่าผู้รับจะได้รับ Message อย่างน้อย 1 ครั้ง ซึ่งผู้ส่งจะจัดเก็บ Message นี้ไว้จนกระทั่ง ได้รับ PUBACK Packet จากผู้รับซึ่งถือเป็นการตอบรับว่าได้รับ Message นั้นๆแล้ว ซึ่งในเลเวลนี้เป็นไปได้ว่า จะมีการส่ง หรือ รับ Message ได้มากกว่า 1 ครั้งQos 1 — at least onceใน PUBACK Packet จะมีรายละเอียดเกี่ยวกับ Packet ID ค่ะ ซึ่งตัวผู้ส่งเองจะใช้ไอดีนี้ในการตรวจสอบว่าผู้รับได้รับ Message หรือยัง ถ้าหากว่า ผู้ส่ง ไม่ได้รับ PUBACK Packet ในระยะเวลาที่เหมาะสม ผู้ส่งจะเริ่มทำการส่ง Message อีกครั้งค่ะ (ผู้ส่งใน MQTT เป็นได้ทั้ง Publisher และ Broker นะคะ เพราะเราแบ่งการส่ง Message เป็น 2 ส่วน สามารถย้อนไปอ่านข้างบนได้ค่ะ)ในกรณีที่ ผู้รับ ได้รับ Message ที่มี QoS 1 และถ้าผู้รับคือ Broker หลังจากได้รับ Message แล้ว Broker จะส่งต่อ Message ให้ Subscriber ทุกตัว ที่ได้ Subscribe ไว้ และทำการส่ง PUBACK Packet กลับไปยัง Publisher ค่ะ ถ้าหากว่า Message ที่ได้มีการตอบรับด้วย PUBACK Packet แล้วแต่มีการส่งซ้ำจากผู้ส่ง Message นั้นจะถูกเซทค่า DUP Flag ซึ่งเป็นค่านี้จะไม่ถูกนำไปใช้โดยผู้รับ (Broker/Subscriber) นั่นหมายความว่าไม่ว่า Message นั้น จะถูกตอบรับ ด้วย PUBACK Packet หรือไม่ เมื่อไหร่ที่ผู้รับได้รับ Message (ที่มี หรือ ไม่มี DUP Flag) ผู้รับก็จะทำการส่งกลับ PUBACK Packet ไปยังผู้ส่งทุกครั้งQoS 2 — exactly onceQoS 2 ถือว่าเป็นค่าสูงที่สุด ในระดับ QoS ใน MQTT ซึ่งการันตีว่าแต่ละ Message จะถูกส่ง และได้รับเพียงครั้งเดียวเท่านั้น ซึ่งถึงแม้ว่าการใช้ QoS 2 จะเป็นวิธีที่ให้ความมั่นใจได้ว่าผู้รับจะได้รับ Message และ ไม่มีการส่งซ้ำ(หากมีการได้รับ Message แล้ว) แต่ก็เป็นระดับ QoS ที่มีการทำงานช้าตามไปด้วย เพราะจำเป็นต้องใช้การส่งและรับ Request/Response อย่างน้อยถึง 2 ครั้ง (ซึ่งเท่ากับการทำ Handsharke 4 ครั้ง) ระหว่าง ผู้รับ และ ผู้ส่ง ใน QoS 2 ก็จะใช้ Packet ID ในการจัดการการรับส่ง Message เช่นเดียวกับใน QoS 1Qos 2 — exactly onceหลังจากที่ผู้รับ ได้รับ Message แล้ว ตัวผู้รับจะทำตอบกลับผู้ส่งด้วย PUBREC Packet ถ้าหากผู้ส่งไม่ได้รับ PUBREC Packet ผู้ส่งจะส่ง Message เดิมอีกครั้งด้วย DUP Flag จนกว่าจะได้รับ PUBREC Packetและทันทีที่ผู้รับได้รับ PUBREC Packet แล้ว ผู้ส่งจะทำการจัดเก็บ PUBREC Packet ไว้ และทำการส่ง PUBREL Packet กลับไปให้ผู้รับ และผู้รับก็จะทำการรีเซทState ทั้งหมด และจัดส่ง PUBCOMP Packet ไปให้ผู้ส่ง( ซึ่งผู้ส่งก็จะทำการรีเซท State เช่นกัน เมื่อได้รับ PUBCOMP Packet จากผู้รับ) ในระหว่างการรับส่ง Message นี้ ก่อนที่จะมีการตอบรับจากผู้ส่ง ด้วย PUBCOMP Packet ตัวผู้รับจะทำการจดจำ Packet ID ไว้ ซึ่งถือว่าเป็นกระบวนการที่สำคัญมากในการหลีกเลี่ยงการส่ง Message ซ้ำอีกครั้งหลังจากที่ผู้รับ ได้รับ PUBCOMP Packet แล้ว Packet ID นี้ก็จะถูกนำไปวนใช้ต่อไปค่ะ ซึ่งตามหลักการแล้วหากมีการนำตัวเลขนี้ไปวนใช้อีก Packet ID จะมีค่าได้ไม่เกิน 65535 ค่ะ แต่หากโชคไม่ดี เกิด Message หายระหว่างทาง ไม่มีการตอบรับจากผู้รับในช่วงเวลาที่กำหนด ผู้ส่งก็จะทำการจัดส่ง Message อีกครั้งค่ะถึงตรงนี้ อาจจะมีข้อสงสัยว่า…แล้วจะเลือกใช้ QoS ยังไงดี?การเลือกใช้ระดับของ QoSถ้าหากว่าเรามี Network ที่ค่อนข้าง Stable เช่น มีการใช้สายแลนเชื่อมต่อระหว่าง Publisher/Subscriber (มั่นใจว่าการเชื่อมต่อไม่หลุดง่ายๆแน่นอน) หรือ เรายอมรับได้กับ Message ที่หล่นหายไปบ้างระหว่างทาง ซึ่ง Message นั้นอาจจะไม่สำคัญมากเท่าไหร่ หรือ เราส่งถี่มากพอที่การสูญหายของ Message จะไม่มีผลกระทบมากมาย หรือ หากเราไม่ต้องการให้ Message ทำการ Queuing (Message Queuing มีผลเมื่อเลือกใช้ QoS 1 หรือ QoS 2 และมีการใช้ Persistent Session จะกลับมาอธิบาย Persistent Session ในบทความถัดไปนะคะ ) เลือกใช้ QoS 0 เลยค่ะแต่ถ้าหากว่าระบบของเรามีความจำเป็นที่ต้องได้รับทุก Message ที่ถูก Publish (ห้ามพลาดเลย) มีสองทางเลือกค่ะ คือ QoS 1 หรือ QoS2 หลังจากนั้นมาลองพิจารณาค่ะว่าหากเกิดการรับส่งซ้ำของ Message แล้วเนี้ย ระบบของเรารับได้มั้ย จะมีปัญหากับ Application ที่เราใช้รึป่าว หากไม่ติดปัญหาเรื่องการส่งซ้ำของ Message ได้ QoS 1 เป็นตัวเลือกที่เหมาะสมที่สุดค่ะ เพราะเมื่อเทียบกับ QoS 2 แล้ว QoS 1 ทำการรับส่งได้เร็วกว่ามากคะบทความถัดไป จะพูดคุยเพิ่มเติมเรื่อง Persistent Session ค่ะ ซึ่งสำคัญมาก หากอุปกรณ์ IoT ของเราเกิดอยู่ๆ Offline ไป แล้ว MQTT จะมีการจัดการเรื่องนี้ให้เรายังไง คอยติดตามอ่านกันนะคะ สวัสดีค่ะ
โดย: Laris
| IoT
รู้จัก MQTT Protocol (ตอนที่ 1)
ในการพัฒนาระบบทางด้าน IoT นั้นมีหลายโพรโตคอล (Protocol) ให้เราเลือกใช้ ซึ่งทางผู้เขียนเห็นว่า MQTT เป็นตัวเลือกที่ดีในการเริ่มต้นกับงาน หรือการเขียนโปรแกรมทางด้าน IoT ค่ะIntroducing MQTTMQTT เป็น Protocol ที่แรกเริ่มได้ถูกออกแบบเพื่อนำไปใช้ในการติดต่อระหว่างท่อน้ำมันและดาวเทียม ดังนั้น Protocol ตัวนี้จะต้องใช้พลังงาน และ Bandwidth น้อยที่สุด MQTT ถูกใช้โดย IBM เพียงผู้เดียว มาเกือบทศวรรษ หลังจากถูกคิดค้นออกแบบ หลังจากนั้น IBM ก็ได้ปล่อยตัว MQTT 3.1 ให้คนภายนอกได้ใช้กันปี 2014 MQTT 3.1.1 ได้รับการรับรองมาตรฐานโดย OASIS และ ISO และจากเดิมที่เคยเป็นเพียง acronym (MQTT — MQ Telemetry Transport) MQTTได้กลายมาเป็นชื่อของ Protocol ซึ่งถูกใช้อย่างแพร่หลายในโลกของ IoT และ M2M(Machine to Machine) เพราะมีข้อดีที่ว่ามีขนาดเล็ก สามารถส่งข้อมูลได้เกือบ Real-time โดยใช้ Bandwidth ต่ำ และมี Delivery Guarantee ถึงแม้จะใช้กับ Network ที่ไม่ค่อยสถียร และ ที่สำคัญ ไม่ยุ่งยากสำหรับ DevelopersPublish & Subscribe Basicspublish / subscribe หรือ ที่รู้จักกันว่า pub / sub ซึ่งเป็นอีก Architecture นึง ที่แตกต่างไปจาก Client-Server ที่เราๆรู้จักและใช้กันมานาน เพราะ Publisher หรือ Client ที่ใช้ส่งข้อความ และ Subscriber หรือ Client ที่ใช้รับข้อความ จะไม่คุยกันโดยตรง เหมือนเช่น Client และ Server แต่จะพูดคุยผ่าน Broker ซึ่ง Broker เองก็มีหน้าที่สำคัญในการ Filter ข้อความที่ได้รับจาก Publisher เพื่อจัดส่งต่อไปยัง Subscriber ที่สนใจจะรับข้อความนั้นได้อย่างถูกต้องการแยก Publisher และ Subscriber ไม่ให้คุยกันโดยตรง มีข้อดีหลายอย่าง Publisher และ Subscriber ไม่จำเป็นต้องรู้จักกัน ไม่จำเป็นต้องรู้ว่าใคร IP หรือ Port อะไร และไม่จำเป็นต้อง Online พร้อมกัน เพราะมี Broker เป็นตัวควบคุมดูแลอยู่ และทำให้การ Scale up ง่ายมากขึ้นBroker จะมีวิธีการ Filter ข้อความ หลากหลายแบบ เช่นSubject-Based Filtering ที่จะ Filter เอาแต่ข้อความที่มี Subject หรือ Topic เป็นส่วนหนึ่งข้อความนั้นๆ ซึ่งโดยทั่วไปตัว Topic จะอยู่ในรูปแบบของ String ที่มีโครงสร้างแบบขั้นเลเวล (Hierachical Structure)Content-Based Filtering ที่จะ Filter เอาแต่ข้อความที่มีContent ตามที่ได้ Subscribe ไว้ ซึ่งจะมีข้อเสียตรงที่เราจำเป็นต้องรู้ Content ของข้อความล่วงหน้า และ เป็นการยากที่จะ Encrypt ข้อความType-Based Filtering เมื่อ Object-Oriented Language ถูกนำมาใช้ ข้อความก็จะถูก Filter จาก Type หรือ Class ของข้อความซึ่งคุณสมบัติต่างๆใน โมเดล Publish /Subscribe ที่พูดถึงข้างต้นนี้ เราสามารถพบเจอได้ใน MQTT ใน MQTT Publisher และ Subscriber จะถูกแยกออกจากกัน เวลาที่ต้องการส่งหรือรับข้อความ ตัว Publisher/Subscriber ต้องการรู้เพียงแค่ Host/IP/Port ของตัว Broker เท่านั้นถึงแม้ว่าโดยปกติแล้ว MQTT จะรับส่งข้อมูลแบบเกือบ Real-Time​ (Near Real-Time) แต่ MQTT สามารถ Store ข้อความให้ Client ที่ Offline ได้ นอกจากนี้ โดยปติแล้ว MQTT ทำงานแบบ Asynchronous แต่ในบางกรณี MQTT ก็รองรับ Synchronous เช่นกัน ในด้านการ Filter ข้อความนั้น MQTT นั้นใช้วิธี Filter แบบ Subject-Basedเพื่อป้องกันปัญหาที่อาจจะเกิดขึ้นในระบบ Pub/Sub MQTT มีการใช้ QoS เพื่อใช้การันตีว่ามีการส่งข้อมูลเรียบร้อย ไม่ว่าจะส่งจาก Broker ไป Client หรือ จาก Client ไป Broker ซึ่งบางครั้งอาจจะเป็นไปได้ว่าไม่มี Clientไหน Subscribe ตัว Topic นี้เลย ดังนั้น ตัว Broker เองต้องมีวิธีที่จะจัดการกับเคสที่ว่าด้วยหลังจากทำความเข้าใจเบื้องต้นเกี่ยวกับระบบ Pub/Sub และ MQTT แล้ว จะเห็นได้ว่า MQTT นั้นมีความแตกต่างจาก Message QueueMessage Queue จะเก็บข้อความไว้จนกว่าจะถูกนำไปใช้โดย Client แต่ใน MQTT บาง Topic ก็ไม่มี Client ตัวไหนสนใจ Subscribe เลยข้อความใน Message Queue จะสามารถถูกนำไปใช้โดย Client รายเดียวเท่านั้น ซึ่งในขณะเดียวกัน MQTT ที่ไม่มีข้อจำกัดตรงนี้Queue ใน Message Queue ที่ถูกสร้างขึ้นและตั้งชื่อแล้วเท่านั้นถึงจะ Publish ได้ ซึ่งต่างจาก MQTT ที่สามารถสร้าง On the fly ได้Client, Broker and Connection Establishmentหลังจากที่พอเข้าใจคร่าวๆเกี่ยวกับ Pub/Subและ MQTT กันแล้ว เราลองมาทำความเข้าใจให้ละเอียดเกี่ยวกับ Client และ BrokerMQTT Client หมายถึง deviceใดๆก็ได้ที่ใช้ MQTT Library และมีการเชื่อมต่อกับ MQTT BrokerMQTT Broker ถือเป็นหัวใจสำคัญของระบบ Pub/Sub เลยทีเดียว หน้าที่สำคัญของ Broker ก็คือ การรับข้อความ และนำข้อความนั้นมา Filter เพื่อให้ทราบว่าจะต้องส่งต่อข้อความนั้นไปให้ Client ที่ Subscribe ไว้ตัวไหนบ้างเมื่อมี Client แล้ว มี Broker แล้ว สองตัวนี้จะต้องเชื่อมต่อกันเพื่อให้เกิด MQTT Connectionโดยเริ่มจากการส่ง CONNECT Message จาก Client ไป Broker หลังจากนั้น Broker จะตอบกลับด้วย CONNACK message และ Status Code ไปที่ Client การเชื่อมต่อจะถูกหยุดลงเมื่อ Client ส่งคำสั่ง Disconnect มาที่ BrokerMQTT Publish, Subscribe & UnsubscribeMQTT Client สามารถ Publish ข้อความได้ทันทีหลังจาก ทำการเชื่อมต่อกับ MQTT Broker ซึ่งในแต่ละข้อความนอกจากจะต้องมี Topic ที่ MQTT Broker สามารถนำไป Filter ได้แล้ว ยังมีส่วนของ Payload ที่มีข้อมูลที่ต้องการส่งหลากหลายรูปแบบ เช่น Text หรือ Image หรือ เกือบทุกรูปแบบที่สามารถอยู่ในรูปแบบของ Binaryได้และเมื่อ Client ต้องการรับข้อความใน Topic ที่สนใจ ซึ่งสามารถทำได้โดยการส่ง SUBSCRIBE Message ไปให้ Broker ซึ่ง ใน SUBSCRIBE Message นี้ก็จะมีลิส ของ Topic ที่ Client สนใจอยู่ และ Broker ทำการตอบรับด้วยการส่ง SUBACK MessageClient สามารถยกเลิกการรายการที่เคย Subscribe ไว้กับ Broker ด้วยการส่ง UNSUBSCRIBE Message และเช่นเคย Broker จะทำการตอบรับด้วยการส่ง UNSUBACK Message เพื่อเป็นการยืนยันกับ Client ว่าคำร้องขอยกเลิกได้ถูกคอนเฟิร์มแล้วMQTT TopicsMQTT Topic คือ UTF-8 String ที่ถูกใช้โดย Broker ในการ Filter ข้อความ ซึ่ง Topic สามารถมีได้หลายเลเวล แต่ละเลเวลจะถูกแบ่งด้วยเครื่องหมาย / (Slash) ในแต่ละ Topic ต้องมีอย่างน้อย 1 ตัวอักษรClient สามารถเลือกที่จะ Subscribe เฉพาะเจาะจง Topic หรือ สามารถ ใช้ Wildcard ในการเลือกรับหลายๆ Topic ซึ่งก็จะมีการใช้อยู่ 2 แบบ คือ แบบ Single Level และ แบบ Multi LevelSingle Level ( + ) Wildcard สามารถใช้แทนที่ Topic เพียง หนึ่ง เลเวล โดยใช้เครื่องหมาย + (Plus)Multi Level (#) Wildcard สามารใช้แทนได้มากกว่าหนึ่ง Topic ซึ่ง # (Sharp) จะต้องอยู่เป็นตัวอักษรสุดท้าย และต้องมี /(Slash) นำหน้าบทความนี้ก็อาจจะหนักหัวหน่อยนะคะ แต่รับรองคุ้มค่าที่จะรู้จักกับ MQTT ค่ะ แต่ยังมีความสามารถอีกหลายอย่างเลยที่เรายังไม่ได้พูดถึง เราจะค่อยๆเรียนรู้ไปด้วยกันนะคะ แล้วพบกันใหม่ในตอนหน้าค่ะ
โดย: Laris
| IoT
มาเริ่มต้นเขียนโปรแกรม IoT กันดีกว่า
สวัสดีค่ะท่านผู้อ่านทุกท่าน วันนี้เราจะมาเริ่มเขียนโปรแกรมลงบนบอร์ด ESP32 ตามสัญญากันนะคะ ซึ่งบทความเราจะเริ่มติดต่อกับอุปกรณ์ IoT หรือว่าแตะฝั่ง Hardware กันแล้วค่ะ (ตื่นเต้นกันมั้ย :p) และเพื่อความง่ายต่อการเริ่มต้นเราจะใช้ Framework: Arduino มาเขียนโปรแกรมกันวันนี้ค่ะบอร์ด TTGO T8หากเราไปค้นคำว่า “Arduino” ใน Google เราอาจจะเจอ “บอร์ด Arduino” มากมายอย่าเพิ่งตกใจไปนะคะ เพราะว่า Arduino มีทั้ง Board และ Framework ซึ่งใบบทความนี้เราจะใช้ ESP32 Board ร่วมกับ “Framework Arduino” และ Hardware ที่จะใช้วันนี้คือบอร์ด TTGO T8 ซึ่งใช้ชิป ESP32 ของบริษัท Espressif Systems ค่ะ ส่วนใครที่มีบอร์ดอื่นๆที่เป็น ESP32 ก็สามารถเอามาใช้ได้เลยนะคะ บอร์ดนี้ใกล้มือผู้เขียน ติดกระเป๋ามาด้วย เลยหยิบมาทำ Demo ให้ดูกันค่ะเริ่ม ติดตั้ง Arduino กันก่อนทุกระบบปฏิบัติการ สามารถดาวน์โหลด Arduino IDE ได้ที่ https://www.arduino.cc/en/Main/Software แต่ ก็ยังมี Editor หรือ IDE อีกหลายตัวที่เรายังสามารถเขียน Arduino และ ESP32 อีกนะคะ แต่วันนี้เราไปลุยกับ Arduino IDE กันก่อนเนอะarduino.ccหลังจากนั้นเปิดโปรแกรมแล้วจะได้หน้าตาแบบภาพข้างล่างค่ะ แต่ Arduino IDE อย่างเดียวไม่สามารถเขียน ESP32 ได้ เราต้องลงเพิ่มอีกนิดหน่อยค่ะหน้าจอเขียนโปรแกรม Arduinoติดตั้ง ESP32 SDKเข้าเมนู Arduino → Preferences แล้วในช่อง Additional Boards Manager URLs ใส่ https://dl.espressif.com/dl/package_esp32_index.json (คลิ๊กเพื่อ อ่านเพิ่มเติม)หน้าจอ Preferencesเมื่อเข้ามา Board Manager แล้ว รอสักครู่ หลังจากนั้นเลือก esp32 by Espressif Systems แล้วกด Install ได้เลยค่ะติดตั้งบอร์ด ESP32 เริ่มต้นเขียนโปรแกรม Arduinoเริ่มต้นด้วยการ เปิดตัวอย่าง Blink ขึ้นมาจากเมนู Examples → Blinkแล้วทดสอบอัพโหลดโปรแกรม เอาฤกษ์ โดยการกดปุ่ม Sketch → Upload เอาชัยกันก่อนด้วยโปรแกรม Blink ค่ะ… (อย่าลืมแก้หมายเลข Pin ให้เป็นไปตามคู่มือของบอร์ดนะคะ อย่าง TTGO T8 จะเป็นขา 21ผลการรันโปรแกรม Blinkเริ่มต้นเขียนโปรแกรม IoTหลังจากผ่านด่านทดสอบกันมาแล้ว เราจะเริ่มมาเขียนโปรแกรมสำหรับเชื่อมในแบบ Internet of things กันค่ะ เราจะลองเล่นกันไปก่อนนะคะ แล้วจะค่อยๆกลับมาเรียนกันอีกทีตอนหลังค่ะ (อย่าเพิ่งตกใจกันไปก่อนหน้าาา)ซึ่งเราจะเริ่มกันด้วยลง Library: ArduinoJson (v5.13.3) และ CMMC MQTT Connector (v1.2.0) โดยการเข้าที่เมนู Sketch → Include Library → Manage Libraries กดค้นหาแล้วเลือก Install ได้เลยค่ะหลังจากนั้นเลือกเปิดตัวอย่าง basic_mqtt ขึ้นมาค่ะหน้าจอตัวอย่างโปรแกรม basic_mqttหลังจากนั้นเปิดหน้าต่าง _config.h แล้วแก้ไขข้อมูลเบื้องต้นของเราค่ะ ซึ่งเราเลือก MQTT Broker ของ hivemq มาใช้กันนะคะ (จากในภาพจะแก้หลักๆที่ DEVICE_NAME และ MQTT_PREFIX) ที่เหลือคงกันไว้เหมือนเดิมกันก่อนนะคะ_config.hหลังจากนั้นเกิด Serial Monitor ขึ้นมาก็จะเห็นภาพข้างล่างนี้ค่ะSerial Monitor Consoleหลังจากนั้นเราจะมาลองควบคุมอุปกรณ์เราผ่าน hivemq web client กันนะคะ แต่จะต่างกับบทความก่อนๆที่เราจะใช้ mosquitto_pub ซึ่งเป็น client แบบ native แต่ที่เรากำลังใช้กันเป็น webclient ซึ่งวิ่งบน websocket protocol ซึ่งจะ binding เข้ากับ mqtt protocol (ซึ่งเป็น tcp) และตรงข้อนี้จะเป็น Feature ของ MQTT Broker นะคะ ซึ่งไม่ได้ถูกกำหนดไว้ใน Spec ของ MQTT Standard นะคะ แต่เราค่อยมาพูดถึง MQTT กันต่อในบทความถัดๆไปกันนะคะส่วนวันนี้เราจะเข้า http://www.hivemq.com/demos/websocket-client/ ไปและกด connect กันก่อนได้เลยค่ะ ในช่อง Publish: Topic เราก็ใส่ Prefix และ Device Name ของเราไป อย่างในโค๊ดตัวอย่างก็จะใส่ MYAPP/DEVICE001/$/commandและสั่ง ON และ OFF เพื่อสั่งเปิดและ ปิดค่ะ (ตามในโค๊ดดูได้ที่ไฟล์ _receive.h ค่ะ)หน้าจอแสดง mqtt websocket clientหลังจากนั้นก็ลองกด Publish ดู ก็จะให้ผลแบบในภาพค่ะภาพสาธิตแสดงการ Publish ข้อมูลเข้าบอร์ด ESP32เท่านี้ก็จะสั่งงานเปิด-ปิด อุปกรณ์ IoT ของเราได้แล้วค่ะ ไม่ยากเลยใช่มั้ยคะหลังจากนี้เราจะเอา IoT Device มาเชื่อมต่อกับ Home Assistant กัน เพื่อเริ่มต้นทำ Home Automation กันนะคะ ส่วนรายละเอียดส่วนอื่นๆ ก็จะทยอยเพิ่มเติมให้ในบทความถัดๆไปเช่นกันนะคะ
โดย: Laris
| IoT
รู้จัก Home Assistant ตอนที่ 2
บทความที่แล้ว เราได้ทำการติดตั้งและเปิดใช้งานเจ้า Home Assistant กันไปแล้ว วันนี้เราจะมาพูดถึง Sensor Component เบื้องต้นกันนะคะ นั่นก็คือ MQTT Binary Sensor ค่ะMQTT Binary Sensor ComponentMQTT Binary Sensorจุดเด่นของ MQTT Binary Sensor Component คือ ความสามารถในการเชื่อม Home Assistant ของเราเข้ากับ MQTT Protocol และมีการรับ Input เป็นการแสดงสถานะ ‘เปิด’ หรือ ‘ปิด’ และแสดงสถานะปัจจุบันของอุปกรณ์ค่ะเริ่มต้น Config MQTT Binary Sensor Componentเริ่มจากการเปิด Web Interface ของ Home Assistant กันก่อนค่ะ สามารถเข้าไปดูได้ที่ http://<ip-address>:8123 เช่น http://127.0.0.1:8123ตัวอย่างหน้า Loginหน้า Overview ของ Home Assistantครั้งแรกที่เข้าหน้า Web เราต้องสร้าง User ก่อนค่ะ สร้างเสร็จและทำการ Login แล้ว จะเห็นหน้า Overview ค่ะ ถึงตรงนี้ Home Assistant ก็พร้อมให้เราใช้งานแล้วค่ะ สิ่งแรกที่ต้องทำ คือ หาไฟล์ configuration.yaml กันก่อนค่ะ configuration.yaml เป็นไฟล์ที่เก็บ Configuration ของ Component ที่เราจะใช้ค่ะ ซึ่งหาได้ตามข้างล่างนี้เลยค่ะตำแหน่งของไฟล์ Configuration ในแต่ละ ระบบปฏิบัติการเมื่อหาไฟล์เจอแล้ว.. ก็เปิดขึ้นมาดูเลยค่ะ จะเห็นค่า Default Configurations ที่ใช้สำหรับเปิดหน้า Web Interface และ Device Discovery ค่ะ หากว่าเราต้องการใช้งาน Component ไหนใน HASS ง่ายๆค่ะ เราแค่เพิ่มค่า Settings ของ Component นั้นๆ ใน configuration.yaml ค่ะ และตามสัญญาค่ะ จากบทความที่แล้ว เราได้เกริ่นไว้ว่าเราจะมาลองหนึ่งใน Component ยอดฮิตของ Home Asistant กัน ซึ่งก็คือ MQTT Binary Sensor ค่ะการปรับแต่ง Home Assistant เพื่อเชื่อมต่อกับ MQTT Brokermqtt: broker: IP_ADDRESS_BROKERเสร็จแล้วก็มาเซทค่าให้ MQTT Binary Sensor ค่ะ ซึ่ง MQTT Binary Sensor Platform จะใช้ MQTT Message Payload ในการตั้งค่าสถานะ (State) ของ Binary Sensor ซึ่งมีด้วยกันอยู่ 2 สถานะค่ะ ‘ON’ หรือ ‘OFF’ หรือ ปิดและเปิดนั่นเองค่ะเสร็จแล้วก็มาเซทค่าให้ MQTT Binary Sensor ค่ะ ซึ่ง MQTT Binary Sensor Platform จะใช้ MQTT Message Payload ในการตั้งค่าสถานะ (State) ของ Binary Sensor ซึ่งมีด้วยกันอยู่ 2 สถานะค่ะ ‘ON’ หรือ ‘OFF’ หรือ ปิดและเปิดนั่นเองค่ะค่าสถานะ (State) จะมีการอัพเดทก็ต่อเมื่อมี Message ใหม่ถูก Publish ตามที่เซทไว้ที่ state_topic และมี Payload ที่ตรงกับค่า payload_on และ payload_offที่เราตั้งค่าไว้ค่ะ ซึ่งอาจจะเป็น ‘ON/OFF’ หรือ ‘1/0’ อันนี้ก็แล้วแต่เราจะตั้งนะคะbinary_sensor:- platform: mqttname: "Window Contact Sensor"state_topic: "home-assistant/window/contact"payload_on: "ON"payload_off: "OFF"availability_topic: "home-assistant/window/availability"payload_available: "online"payload_not_available: "offline"หลังจากตั้งค่า Configuration สำหรับ MQTT Binary Sensor …อย่าลืม RESTART นะคะ….. (Configuration > General > Server Management)เราสามารถตั้งค่าให้ MQTT Binary Sensor รับค่าเวลา Offline ได้ค่ะ โดยจะใช้ availability_topic เป็นตัวกำหนดค่ะ หาก มีการเซทค่าให้กับ availability_topic และ Device ของเรา Offline ไป (เช่น Offline ด้วยการ Publish payload_not_available ใน Topic ชื่อ availability_topic) ใน Home Assistant ก็จะขึ้นว่า unavailable ในหน้า Web ค่ะ (Figure 3) ตัว MQTT Protocol เองก็จะมีฟีเจอร์ LWT (Last-will and Testament) และ Retain เอาไว้ช่วยอัพเดตสถานะของอุปกรณ์ได้โดยอัตโนมัติ หรือหากลองก็สามารถลองได้ด้วยคำสั่งด้านล่าง$ mosquitto_pub -h <your running broker> -t home-assistant/window/availability -m "offline"หากต้องการให้ Device เรา เปลี่ยน State เป็น ON/OFF ก็สามารถทำได้ ด้วย Command Line เราก็จะได้หน้า Overview บน Web เช่นรูปข้างล่างค่ะ (Figure 4)$ mosquitto_pub -h <your running broker> -p 1883 -t home-assistant/window/contact -m "ON"$ mosquitto_pub -h <your running broker> -p 1883 -t home-assistant/window/contact -m "OFF"Figure 3Figure 4อ้างอิงจาก Home Assistant : MQTT Binary Sensor
โดย: Laris
| IoT
รู้จัก Home Assistant ตอนที่ 1
สวัสดีท่านผู้อ่านทุกท่านค่ะ หลังจากบทความที่ผ่านมา เราคุยกันถึงเรื่อง คำจำกัดความของ “Internet of Things” โดยการพูดถึง “IoT Reference Model” เพื่อเป็นการจูน หรือทำความรู้จักโลกของ IoT กันไปแล้วทางผู้เขียนก็ตั้งใจกันไว้ว่าหลังจากนี้จะค่อยๆลงลึกทางด้านเทคนิคมากขึ้น ซึ่งในบทความนี้ผู้เขียนเลือกใช้วิธีการเรียนรู้ IoT จาก OpenSource Software กันไปก่อนค่อยๆปูทางลงไปก่อนจะไปถึงการเขียนโปรแกรมลงใน Embedded Device หรือพวก Hardware ต่างๆนั่นเองผู้เขียนได้เลือก “Home Assistant” มาให้ทำความรู้จักกันก่อนค่ะHome Assistant เป็น Open Source สำหรับทำ Home Automation เป็นหลัก และเขียนขึ้นด้วย Python และสามารถใช้ Track, Control, และใช้ Automate Device ได้ โดยที่ไม่จำเป็นต้อง Store ข้อมูลไว้บน Cloud ไม่ต้องห่วงว่าข้อมูลส่วนตัวเราจะถูกเปิดเผยค่ะ ตัว Home Assistant Architecture แบ่งได้ 3 layers โดยจะมีHome Control ทำหน้าที่ควบคุมและเก็บข้อมูลจาก devicesHome Automation รับข้อมูลมาจาก Home Control และส่ง Commands ไปยัง devices ผ่าน Home Controller ซึ่ง Commands เหล่านี้มาจาก Configuration ที่ User ได้ตั้งค่าไว้Smart Home ทำตาม Commands ที่เกิดจากการเรียนรู้ด้วยตัวเอง (Self — learning)Home Assistant ComponentHome Assistant สามารถขยายขีดความสามารถไปได้อีกด้วย ‘Componet’ ซึ่งในแต่ละ Component จะมีหน้าที่ของแต่ละตัวเฉพาะเจาะจง ตัว Component นั้นถูกเขียนด้วยภาษา Python นั่นหมายความว่า อะไรที่ Python ทำได้ เจ้า Component นี่ก็ทำได้เหมือนกัน นอกจากนี้ Home Assistant เองก็ได้ทำ Built-in Components เพื่อให้นำมาใช้ได้เลยอีกด้วย แต่ถ้าหากเราอยาก Custom ของเราเอง ก็ใช้ Component มาทำได้เลยค่ะตัว Home Assistant Frontend เองก็ได้ถูกออกแบบมาเพื่อสำหรับใช้ในรูปแบบ Mobile โดยเฉพาะ ซึ่งได้ Polymer Framework เข้ามาช่วยในส่วน Frontend จะเห็นว่าหน้าตาของ Home Assistant Frontend มีความคล้ายกับการใช้งาน Mobile Application จริงๆ ในส่วนของ Home Assistant Backend ก็จะใช้ Python 3 ซึ่งถูกสร้างมาเพื่อให้สามารถ Extend ได้ โดยใช้ Components ค่ะตัวอย่าง หน้าตาของ Home Assistant Frontendการติดตั้ง Home Assistantในส่วนของการติดตั้ง Home Assistant นั้นสามารถติดตั้งได้หลายวิธีนะคะ แต่วันนี้ทางผู้เขียนอยากจะขอแนะนำวิธีการติดตั้งด้วย 2 วิธีดังนี้ค่ะติดตั้งด้วย Python 3 + Virtual Environmentติดตั้งด้วย Docker1. วิธีการติดตั้งด้วย Python 3 + Virtual Environmentเริ่มจากการสร้าง Virtual Environment กันก่อนเลยค่ะ ในจุดที่ต้องการด้วยคำสั่ง (อย่าลืม ติดตั้ง Python3 ก่อนนะคะ)$ python3 -m venv homeassistantสร้างเสร็จแล้วก็เปิดใช้งาน Virtual Environment ค่ะ$ cd homeassistant$ source bin/activateจากนั้นก็ติดตั้ง wheel และ homeassistant ค่ะ$ python3 -m pip install wheel$ python3 -m pip install homeassistantเริ่มเปิดใช้งาน Home Assistant เลยค่ะ$ hass --open-ui2. วิธีการติดตั้งด้วย Dockerสามารถทำได้ในหลาย Platform เลยค่ะ ไม่ว่าจะเป็นLinuxRaspberry Pi (Raspbian)macOS 1. LINUX$ docker run -d — name="home-assistant" -v /PATH_TO_YOUR_CONFIG:/config -v /etc/localtime:/etc/localtime:ro — net=host homeassistant/home-assistant2. RASPBERRY PI 3 (RASPBIAN)$ docker run -d — name="home-assistant" -v /PATH_TO_YOUR_CONFIG:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/raspberrypi3-homeassistant3. macOS$ docker run -d — name="home-assistant" -v /PATH_TO_YOUR_CONFIG:/config -e "TZ=Asia/Bangkok" -p 8123:8123 homeassistant/home-assistantสำคัญว่าอย่าลืมแก้ไข /PATH_TO_YOUR_CONFIG ให้เป็นตำแหน่งที่เก็บ Configuration ค่ะตัวอย่าง ถ้าที่อยู่ไฟล์เป็น /home/pi/homeassistant คำสั่งที่ใช้ก็จะเป็น$ docker run -d — name="home-assistant" -v /home/pi/homeassistant:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/raspberrypi3-homeassistantบทความนี้เราได้ทำความรู้จักกับ Home Assistant พร้อมทั้งวิธีการติดตั้ง และการทดลองใช้งาน Home Assistant กันไปแล้ว ในรอบถัดไปเราจะมารู้จักกับ Component ยอดฮิต อย่าง MQTT Binary Sensor ว่าคืออะไร ใช้งานอย่างไร ส่งข้อมูลหากันได้ยังไง แล้วจะค่อยๆลงลึกไปถึงระดับ Protocol ยอดฮิตอย่าง MQTT กันต่อไปค่ะ
โดย: Laris
| IoT
เรียนรู้โลกของ IoT และรู้จักกับ IoT Reference Model
สวัสดีผู้อ่านทุกท่านค่ะ วันนี้ผู้เขียนจะมาพูดถึงการพัฒนา หรือเขียนโปรแกรมในระบบ IoT กันนะคะ โดยเราจะเริ่มกันที่ทฤษฎี หรือ Reference กันสักนิดนึงก่อน แล้วจะค่อยๆลงไปทางการเขียนโปรแกรม ทั้งเรื่อง MQTT Protocol, Arduino Framework, HomeAssistant และอื่นๆ กันอีกต่อไปค่ะ สำหรับวันนี้เรามาเริ่มกันที่ IoT Reference Model กันก่อนนะคะในระบบ IoT หรือ Internet of Things นั้น โดยรวมแล้วเราจะต้องมีองค์ประกอบอย่างน้อย 3 ส่วนนี้เสมอThingsCommunication & DataApplicationแต่ว่าในปัจจุบัน เรายังไม่มี การกำหนด Standard Model ให้กับ IoT พูดง่ายๆก็คือ ยังไม่มีใครเข้ามากำหนดมาตรฐานต่างๆให้กับ IoT เหมือนเช่นใน Network Communications ที่มีทั้ง OSI Model หรือ TCP/IP Protocol Suite ใช้สำหรับอ้างอิง จึงทำให้ IoT มีคำนิยามต่างกันไปตามบริบทที่ต่างกัน ซึ่งในบทความนี้ผู้เขียนจะอ้างถึง Internet of Things ในฉบับของ Internet of Things World Forum​ (IoTWF) กันนะคะ และเราจะใช้เป็น Reference Model เพื่อให้มีความเข้าใจตรงกัน เวลาเราพูดถึง IoT และ IoT EcosystemIoT World Forum ได้แบ่ง IoT Ecosystem เป็น 7 เลเวล ซึ่งในแต่ละเลเวลจะมีคำนิยาม และ หน้าที่ของตัวเอง และ บทบาทที่เกี่ยวข้องกับเลเวลถัดไป ดังนี้1. Physical devices & controllersPhysical devices และ controllers ที่ใช้ควบคุม device เหล่านี้คือสิ่งที่ถูกเรียกว่า ‘Things’ ใน IoTเนื่องจากไม่มีกฎตายตัวว่า Devices พวกนี้จะต้องมีไซส์ใหญ่เล็กแค่ไหน หรือว่า ผลิตจากแหล่งไหน IoT References Model จึงได้กำหนดความสามารถเบื้องต้นของอุปกรณ์ที่จะสามารถเรียกว่าเป็น Device ใน IoT ว่า Device ต้องมีควมสามารถในการเปลี่ยนจาก analog เป็น digital ได้ สามารถผลิต data ได้ และ สามารถเรียกข้อมูล และ สามารถถูกควบคุมผ่าน Internet ได้2. Connectivityสิ่งสำคัญในเลเวลนี้ก็คือ การรับส่งข้อมูลได้ถูกต้องภายในระยะเวลาที่กำหนด การรับส่งข้อมูลนี้รวมไปถึง การรับส่งระหว่างอุปกรณ์ในเลเวล 1 และ Network หรือ ระหว่าง Network ด้วยกัน หรือ ระหว่าง Network ในเลเวลนี้ และ เลเวล 3 ที่อยู่ถัดไปนอกจากนั้น ในเลเวลนี้ยังมีการนำ Protocols หลายชนิดมาใช้ ซึ่งจำเป็นต้องมีการแปลความหมายของ Protocol แต่ละชนิด เพื่อให้สามารถทำงานร่วมกันได้ เพราะ Protocol ต่างชนิดกัน จะมีการสื่อสารและแปลความหมายแตกต่างกันไป รวมไปถึงเรื่อง Security ในระดับ Network อีกด้วย และในเลเวลนี้ Network เองก็จะเรียนรู้เกี่ยวกับ Network Anaylytics ด้วยตัวเอง (Self Learning)3. Edge (Fog) Computingในเลเวลนี้ข้อมูลจะถูกคัดกรอง รวบรวม และ ย่อยให้เป็นข้อมูลที่ถูกต้องและเหมาะสมกับการจัดเก็บ และ ถูกนำไปใช้ในเลเวลถัดไป (Data Accumulation)4. Data Accumulationในเลเวลนี้ข้อมูลจะถูกทำให้อยู่ในสภาวะที่เสถียรที่สุด ไม่มีการเปลี่ยนแปลง (at rest) และจะถูกจัดเก็บไว้ใน Memory หรือ Disk ซึ่งเป็นข้อมูลที่สามารถนำไปใช้กับ Application ที่ไม่ใช่แบบ Real Time (non-realtime basis) นั่นหมายความว่า Application สามารถเข้าถึงข้อมูลเหล่านี้ได้ตลอดเวลาที่ต้องการจะเห็นได้ว่าหน้าที่หลักของเลเวลนี้คือการเปลี่ยนข้อมูลให้อยู่ในรูปแบบที่สามารถเรียกดูได้ (Query-Based) ซึ่งมีความสำคัญต่อการเชื่อมต่อระหว่าง Real-Time Network และ Non-Real-Time Applications5. Data Abstractionเนื่องจากข้อมูลที่ได้มาจากอุปกรณ์หลากหลายชนิด หลากหลายที่ และ ด้วยความหลากหลายนี้ทำให้ข้อมูลเหล่านี้ไม่สามารถถูกจัดเก็บไว้ที่แหล่งจัดเก็บข้อมูลที่เดียวกัน ได้ทั้งหมด ซึ่งมีหลายสาเหตุที่เป็นไปได้ เช่น ข้อมูลที่เยอะเกินไปสำหรับจัดเก็บไว้ที่เดียว ดังนั้นหน้าที่หลักของเลเวลนี้คือการจัดการข้อมูลแล้วแหล่งจัดเก็บที่เหมาะสมกับข้อมูลเพื่อให้ง่ายสำหรับการพัฒนาและเพิ่มประสิทธิภาพให้กับ Application ที่ใช้งานข้อมูลเหล่านี้6. Applicationสำหรับ เลเวลนี้ IoT Reference Model ไม่ได้กำหนดตายตัว ซึ่ง Application เหล่านี้สามารถเป็นได้ตามแต่ลักษณะของข้อมูลจากอุปกรณ์นั้นๆ หรือ แล้วแต่ความต้องการทางธุรกิจ ตัวอย่างเช่น Applicaiton บางกลุ่มก็จะเน้นเฉพาะไปที่ข้อมูลที่ได้จากการ Monitoring หรือ Controlling บางกลุ่มมีการรวบรวมข้อมูลที่มาจากตัวอุปกรณ์เอง หรือจากอุปกรณ์อื่นก็ได้ทั้งสิ้น7. Collaboration & Processesในเลเวลนี้ หลักๆจะเป็นความเกี่ยวข้องของผู้ใช้และ IoT System ที่มีผลในเชิงธุรกิจ ให้มีประสิทธิภาพที่สุดจะเห็นได้ว่าแต่ละเลเวล ตั้งแต่เลเวลล่างสุด (เลเวล 1) จนถึงเลเวลสูงสุด(เลเวล 7 ) มีความสัมพันธ์ที่เห็นได้ชัดเจนเลยคือ อุปกรณ์ (Devices) เป็นตัวรับและส่งข้อมูล ซึ่งเชื่อมต่อกับ Network และ Network จะส่งต่อข้อมูล โดยผ่าน Edge Computing ก่อนที่จะจัดเก็บเข้าสู่ Databases เพื่อให้ Applications สามารถดึงข้อมูลมาประมวลผลก่อนที่จะนำเสนอสู่ ผู้ใช้ เพื่อนำไปใช้ประโยชน์ต่อไปหลังจากทำความเข้าใจกับ IoT Ecosystem กันพอคร่าวๆแล้ว ในบทความถัดไปเราจะมาเริ่มต้นความสนุกกับ IoT ในแบบฉบับโปรแกรมเมอร์กันแล้วนะคะ (ไวเนอะ) หลังจากนี้ก็เราจะค่อยๆเรียนรู้จาก Opensource Tools ในโลกของ IoT และการเขียนโปรแกรมไปพร้อมๆกับลงมือทำกันค่ะ

พบบทสัมภาษณ์ได้ที่นี่เร็ว ๆ นี้

พบDigital Skill บนสื่อ ได้ที่นี่เร็ว ๆ นี้