บทความ IoT
ไม่ว่าจะ ข่าวสาร บทสัมภาษณ์ และ Digital Skill บนสื่อ
มีให้คุณได้อ่านบทความดี ๆ มากมายแล้วที่นี่
โดย: Laris
| IoT
รู้จัก Home Assistant (ตอนที่ 4)
สวัสดีค่ะท่านผู้อ่านทุกท่านวันนี้เราจะกลับมาพบกับ Home Assistant กันอีกครั้งนะคะ จากบทความก่อน เราเริ่มติดตั้งและปรับแต่งกันไปบ้างแล้ว อย่างเช่นพวกสวิตซ์ (Switch) เปิดปิดไฟต่างๆ มีใครพอจะนึกออกบ้างไหมคะว่าถ้าเรามีสวิตช์ หลอดไฟ หรือเซ็นเซอร์ จำนวนมากๆ มันจะเป็นเกิดเหตุการณ์ยังไง? ถ้าใครนึกไม่ออกลองดูภาพข้างล่างนี้ค่ะภาพตัวอย่างของ Sensor ที่ไม่มีกลุ่มค่ะเข้าใจเลยใช่ไหมคะว่าถ้าเรามีจำนวนอุปกรณ์มากๆ หรือถ้าเราต้องการจัดหมวดหมู่ของอุปกรณ์ โดยแบ่งกันไปเป็นห้อง หรือชั้นต่างๆ หากอุปกรณ์มีเยอะมากๆ ก็คงจะปวดหัวน่าดูเลยนะคะ Home Assistant Group Componentวันนี้เรามาเรียนรู้วิธีการจัดการเรื่องพวกนี้ด้วย Group กันนะคะ หน้าตาของ Group ก็จะหน้าตาประมาณนี้ค่ะ สวยงามตามท้องเรื่องตัวอย่างของ Home Assistant ที่มีการจัด Groupสำหรับบทความนี้ Group เป็นสิ่งที่จะมาช่วยเราแก้ปัญหาและอัพเกรดเลเวลของเราเพิ่มขึ้นค่ะ แต่เราจะต้องมารู้จัก Home Assistant เพิ่มขึ้นกันอีกนิดนะคะ ซึ่งสิ่งที่เราจะต้องเรียนรู้กันต่อไปก็คือ Entities, Groups และ Viewsค่ะเริ่มต้นสร้าง Groupก่อนที่เราจะสร้าง และเพิ่มอุปกรณ์เข้าไปใน Group นั้น เราต้องเข้าใจ Default groups กันก่อนนะคะ เดี๋ยวจะงงกันไปก่อน ว่าทำไมหลอดไฟ (Light) ของสวิตช์ (Switch) ของเราไปโผล่ใน Group ได้ยังไง?Default groupsใน Home Assistant จะมี Default Group ด้วย ซึ่งบาง Component จะสร้าง Group พิเศษขึ้นมาซึ่งทั้งหมดจะขึ้นต้นด้วยชื่อแบบนี้ group.all_ ซึ่งหน้าตาก็จะประมาณข้างล่างนี้ค่ะgroup.all_switchesgroup.all_lightsgroup.all_devicesgroup.all_scriptsGroup.all_automationsซึ่งเราสามารถดูได้จากกด Developer Tools → Statesแสดงข้อมูล Entity ทั้งหมดจากกลุ่ม Lightเมื่อเราใช้งาน Component ประเภทหลอดไฟ (Light) หรือประเภทสวิตช์ (Switch) มันจะถูกเพิ่มเข้าไปใน Group ประเภทของตัวเองอัตโนมัติ (Lights, Switches) แต่อาจจะเรียงลำดับไม่ถูกใจเรา ถ้าอยากให้จัดเรียงอยู่ตำแหน่งให้ได้ดั่งใจ ให้ใช้ order เข้ามาช่วยตาม Configuration ข้างล่างเลยนะคะhttps://gist.github.com/hassy-bloggy/bbc510167417755ecdd547366c95dc17การแสดงผลจาก Group Switchโดยปกติแล้วทุกๆ Group จะถูกเรียกมาให้แสดงในแท็ป HOME ค่ะ แต่หากว่าเรามีการสร้าง default_view และ view: true ภายใต้ Group จะถือว่าเราต้องการสร้างหน้า Home เองทั้งหมด (Override หน้า Home เดิม)เมื่อได้ข้อมูลดังนี้แล้วเราลองเล่นในแบบต่างๆ ตาม Configuration นี้ดูนะคะhttps://gist.github.com/hassy-bloggy/5beb3c0dd7acdc869728c8840f79a7d8ผลลัพธ์จะออกแบบมาเป็นหน้า Application ที่มี Tab โผล่มาอีก 2 อันคือ Room 1 และ Room 3 ส่วน Room 2 จะไม่แสดงเป็น Tab แต่จะแสดงเป็น Group ในหน้า Default View แทนอย่าเพิ่งงงนะคะ เรามาดูภาพกันดีกว่าค่ะ ซึ่งเราจะได้ผลลัพธ์ออกมาแบบนี้เมื่อเราปรับ Configuration ในส่วนที่เป็น default_view แล้วกำหนด view: truegroup: default_view: view: true icon: mdi:home entities: - group.room_2 - light.mock_laris_light_00a - light.mock_laris_light_00b - switch.laris_plug_00aUI แสดงผลตาม Configuration ของหน้า Homeหลังจากพูดถึงหน้า default_viewไปแล้ว เราก็จะมาดูค่า Configuration ของ แท็บ Room 1 กันบ้างนะคะ แทบจะเหมือนกันเลย เพียงแค่ตั้งค่า view: trueเพื่อให้แสดงเป็น Tab ขึ้นมาอีกหนึ่งอันข้างบนRoom 1: view: true entities: - light.mock_laris_light_00c - light.mock_laris_light_00d - switch.laris_plug_00bUI แสดงผลตาม Configuration ของหน้า Room 1จะเห็นว่าเราสามารถสร้าง Tab ใหม่ได้ง่ายๆ โดยการกำหนด view: trueเราก็จะได้หน้า หรือ Tab ใหม่ขึ้นมาเลยEntity Idแต่ทำมาถึงตรงนี้สงสัยกันมั้ยคะว่าจะเอาชื่อ Entity Id มาใส่ Configuration ได้จากที่ไหน?คำตอบอยู่ที่ไอคอน State <>หลังจากกดเข้ามาหน้า State แล้วเราจะพบกับ Entity Id ของทุกอุปกรณ์ใน Home Assistant ของเราค่ะหน้า Developer Tools → State แสดง Entity Id ของระบบในหน้า Developer Tools จะบอกชื่อ Friendly Name และ Entity Id เราก๊อบส่วนที่เป็น Entity Id มาใช้ได้เลยค่ะ เมื่อเอามาทำ Group เราก็จะได้ Configuration ออกมาประมาณนี้ (แบบข้างบนเลยค่ะ)group: default_view: view: true icon: mdi:home entities: - light.mock_laris_light_00a - light.mock_laris_light_00b - switch.laris_plug_00a - group.room_2 Room 1: view: true # icon: mdi:ninja entities: - switch.laris_plug_00b - light.mock_laris_light_00c - light.mock_laris_light_00d Room 2: view: false entities: - switch.laris_plug_00b - light.mock_laris_light_00c - light.mock_laris_light_00d Room 3: view: true entities: - group.room_2 - light.mock_laris_light_00aเป็นยังไงกันบ้างคะ หลังจากที่เราปรับแต่ง Group กันไปอย่างเข้มข้นแล้ว ตอนนี้ Smart Home App เราคงจะมีสีสัน และน่าสนใจมากขึ้นแล้วใช่ไหมคะคราวหน้าเราจะเริ่มไปลุยกันเรื่องอื่นกันบ้างแล้วนะคะ แล้วพบกันตอนหน้าค่ะ
โดย: Laris
| IoT
รู้จัก Home Assistant (ตอนที่ 3)
สวัสดีค่ะ หลังจากที่คราวที่แล้ว พูดถึง MQTT และ Home Assistant และ MQTT Connector กันไปบ้างแล้ว วันนี้เราจะมาพูดถึงในส่วนของการส่งข้อมูลจากอุปกรณ์ และนำไปแสดงผลใน Home Assistant กันนะคะหลังจากที่ทบทวนการปรับแต่งโค๊ดกันในส่วนข้อมูลของอุปกรณ์ และข้อมูล MQTT กันไปแล้ว คราวนี้เราจะมาเชื่อม Hardware ของเราเข้ากับ Home Assistant กันคะกลับมาที่ฝั่ง Arduino ให้เปิดตัวอย่าง basic_mqtt เพื่อเริ่มต้นทบทวนบทความที่ผ่านมากันนะคะFile → Examples → CMMC MQTT Connector → basic_mqttเริ่มจากทบทวนของเก่ากันก่อนให้เราใช้ Library CMMC MQTT Connector กันเหมือนเดิม แก้ Device Name และ MQTT และ Prefix กันก่อนค่ะ_config.h หน้าจอปรับแต่งข้อมูล MQTTหลังจากนั้นก็เข้า HomeAssistant เพื่อปรับแต่งค่า MQTT ให้เหมือนกันค่ะ เริ่มเข้าผ่านทางหน้า Configuration → Integrationsได้เลยเลือก MQTT และกด Configureปรับแต่งค่า Brokerหลังจากนั้นเราก็ไปปรับแต่งค่าใน configuration.yaml เพื่อให้รองรับการเปิด-ปิดหลอดไฟค่ะ โดยเราจะกำหนดค่าตามข้างล่างนี้คะsource codeหลังจากนั้น ก็เปิด HomeAssistant ขึ้นมาก็จะเจอ UI สำหรับเปิดปิดหลอดไฟโผล่ขึ้นมาค่ะ เท่านี้เราก็จะควบคุมอุปกรณ์ผ่านหน้าเว็ปกันได้แล้วนะคะการแสดงผลของ Home Assistant บน iOSลองสั่ง เปิด — ปิด ไฟกันดูก่อนค่ะ ซึ่งทางผู้เขียน จะใช้ mosquitto-clients เข้ามา monitor ข้อมูลที่วิ่งไปวิ่งมาระหว่าง อุปกรณ์ และ Broker ด้วยคำสั่งmosquitto_sub -t "MYAPP/#" -h broker.hivemq.com -vmosquitto_sub -t "MYAPP/#" -h broker.hivemq.com -vจะเห็นว่าเพียงไม่กี่ขั้นตอน เราก็สามารถเปิดปิดไฟผ่านแอปได้แล้วค่ะ ไม่ยากใช่มั้ยคะ ถ้าใครยังงงๆอยู่ เราค่อยๆไปกันเรื่อยๆนะคะ เดี๋ยวเราจะทำโจทย์ที่เป็นการประยุกต์ที่เห็นภาพขึ้นเรื่อยๆนะคะ คราวหน้าเรามาลองเล่นกับการจัด group และการแสดงผลค่าจาก Sensor กันค่ะ
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 6)
หลังจากที่ได้ทำความรู้จักกับอีกหนึ่ง Feature ใน MQTT — LWT หรือ Last Will Testment กันไปแล้วนะคะ จะเห็นว่า LWT สามารถเข้ามาช่วยเราจัดการกับการปัญหาการเชื่อมต่อขาดๆหายๆได้อย่างไร แล้วถ้าเอามาจับคู่กับ Retained Message ก็จะยิ่งช่วยเพิ่มประสิทธิภาพให้กับ MQTT ขึ้นมาอีกเยอะเลยค่ะ และในบทความที่แล้วเราก็ยังค้างกันอยู่ที่ Keep Alive ค่ะ ว่าคืออะไร เกี่ยวข้องกับ LWT Message ยังไง วันนี้มาทำความรู้จักกันค่ะMQTT Keep Alive เป็นอีก Feature นึง ของ MQTT ค่ะ ซึ่งมีบทบาทสำคัญเลยสำหรับ Mobile Network ค่ะอย่างที่ทราบนะคะว่า MQTT ใช้การเชื่อมแต่แบบ TCP/IP ซึ่งมีความน่าเชื่อถือสูง มีการการันตีว่าการส่งข้อมูลจะถึงมือผู้รับแน่นอน ไม่มีผิดเพี้ยนแต่…..ในระหว่างการเชื่อมต่อนี้(ระหว่าง Broker และ Client) อาจจะมีฝ่ายใดฝ่ายนึงเกิดหลุด sync กันไปค่ะ (out of synchronization) อย่างเช่น ถ้าเกิดฝ่ายใดฝ่ายนึงเกิด crash ขึ้นมา ไม่สามารถทำงานได้ตามปกติค่ะ โดยที่อีกฝ่ายไม่สามารถรับรู้ได้เลยว่า อีกฝั่งนึงนั้นได้ตายไปแล้ว ก็จะยังคงส่งข้อความไปให้เรื่อยๆ และรอรับ ACK Message ซึ่งสภาวะแบบนี้ใน TCP จะเรียกว่า half-open connection ค่ะ ซึ่งถือว่าเป็นปัญหาสำคัญเลยคะดังนั้น MQTT จึงได้นำ Keep Alive เข้ามาช่วยแก้ปัญหา half-open connection ตรงนี้ค่ะ หรืออย่างน้อยก็สามารถบอกได้ว่าเกิดภาวะ half-open connection ขึ้น Keep Alive จะช่วยเชคและการันตีว่าการเชื่อมต่อระหว่าง Broker และ Client นั้นยังเปิดอยู่Client จะเป็นคนกำหนด ค่า Keep Alive ซึ่งจะกำหนดไว้ในช่วงเริ่มแรกที่ทำการขอเชื่อมต่อกับ Broker ค่านี้มีหน่วยเป็นวินาทีค่ะ (สามารถตั้งค่าได้มากสุด 18 ชั่วโม 12 นาที 15 วินาที หรือ 65535 วินาที ค่ะ) ซึ่งการที่ Client เป็นคนกำหนด Keep Alive เองจะช่วยให้ Client สามารถปรับค่า Keep Alive ให้ตรงกับความแรงของสัญญาณเนทเวิคของตัวเองได้หลังจากทำการเชื่อมต่อ ในระหว่างนี้หาก Client ไม่ทำการส่ง Control Message ใดๆ เช่น PUBLISH, PINGREQ, หรือ DISCONNECT ให้กับ Broker ​ไม่เกินระยะเวลาที่กำหนดใน Keep Alive ตัว Broker จะยังไม่ถือว่า Client ได้ตัดขาดการเชื่อมต่อไป ยังถือว่าการเชื่อมต่อกับ Client นี้ยังเปิดอยู่ แต่ Client จะต้องส่ง PINGREQ ไปให้ Broker นะค่ะ (ไม่ใช่หายไปเลยนะ) ซึ่ง Client จะส่ง PINGREQ เมื่อไหร่ก็ได้ค่ะ ซึ่ง Broker เองก็ต้องตอบกลับด้วย PINGRESP นะคะ เพื่อที่จะให้ Client มั่นใจว่า ​Broker เองก็อยังอยู่ดีค่ะ ยังมีการเชื่อมต่อกับ Client อยู่แต่สำหรับ Broker หากว่าไม่มี Message หรือว่า PINGREQ จาก Client ส่งมาภายใน 1.5 * Keep Alive Period แล้วละก็ Broker จะทำการ Disconnect ไปเลยค่ะ และจะส่ง LWT Message ให้ค่ะ(ถ้า Client ได้กำหนด LWT ไว้นะคะ)โดยปกติแล้วใน MQTT ถ้า Broker เจอว่ามี half-open connection ค้างอยู่ Broker จะจัดการด้วยสิ่งที่เรียกว่า Client Take-over ค่ะ นั่นคือ Broker จะทำการ Disconnect การเชื่อมต่อก่อนหน้านี้กับ Cleint ตัวนี้ หลังจากนั้นก็จะทำการเชื่อมต่อให้ Client ตัวนี้ใหม่ค่ะ เพื่อให้มั่นใจว่าปัญหา half-open connection นี้จะไม่เป็นอุปสรรคต่อ Client ที่ถูก Disconnect ไป แล้วต้องการอยากจะกลับมา Connect ใหม่ค่ะอ้างอิงจาก MQTT Essentials Part 10: Keep Alive and Client Take-Over
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 5)
มาต่อกันกับอีก Feature นึง ของ MQTT ค่ะ ซึ่งก็คือ Last Will and Testament ค่ะเนื่องจาก MQTT มักจะถูกนิยมนำมาใช้ในเคสที่ Network ไม่มีความเสถียรสักเท่าไหร่ อย่างเช่น สัญญาณไม่แรงและแกว่งเป็นต้นค่ะ ในเคสที่สัญญาณไม่เสถียรแบบนี้ การเชื่อมต่อระหว่าง Broker และ Client ต้องมีปัญหาแน่นอนค่ะ บางครั้งการเชื่อมต่อก็อาจจะขาดหายไปดื้อๆแบบไม่ตั้งใจ ซึ่งอาจจะเกิดจากปัญหาที่ตัวสัญญาณเอง หรือ แบตเตอรีหมด และเป็นไปได้อีกหลายสาเหตุค่ะ การขาดหายของสัญญาณแบบนี้จะเรียกว่า Ungracefully Disconnect ค่ะ ไม่มีการแจ้งเตือนมาก่อนว่าจะ Disconnect ค่ะ เพราะปกติแล้ว ใน MQTT การจะ Disconnect (แบบมีมารยาท และ ตั้งใจที่จะตัดการเชื่อมต่อ) จะต้องมีการส่ง MQTT Disconnect Message ค่ะ เรียกอีกอย่างก็ Gracefully Disconnect ค่ะ ดังนั้น Broker จึงจำเป็นต้องทราบค่ะ ว่าการขาดหายของการเชื่อมต่อระหว่าง Broker และ Cleint นั้นเป็นการ Disconnect แบบไหน ตั้งใจ (Gracefully) หรือ ไม่ตั้งใจ (Ungracefully) เพื่อที่ Broker จะได้จัดการกับสถานการณ์ได้อย่างถูกต้องค่ะหากมีการเชื่อมต่อของ Client ตัวใดตัวนึงขาดหายไปแบบ Ungracefully ตัว Broker จะใช้ Last Will and Testament (LWT) แจ้งไปยัง Client อื่นๆที่เหลือ เพื่อบอกกล่าวว่า Client ตัวนี้ได้ Offline ไปแล้วค่ะClient แต่ละตัว สามารถฝาก Last Will Message ให้กับ Broker ได้ ในระหว่างที่เริ่มทำการ Connect กับ Broker ซึ่งตัว Last Will Message นี้ก็คือ MQTT Message ธรรมดาทั่วไปนี่แหละค่ะ ข้างในก็จะมี Topic, Retained Message Flag, QoS, และ Payload อย่างเช่นในรูป Fig 1 ข้างล่างค่ะFig 1. MQTT Connect MessageBroker จะรับฝาก Last Will Message ไว้จนกว่าจะมีการ Disconnect จาก Client นั้นๆค่ะ ซึ่งถ้าการ Disconnect เป็นแบบ Ungracefully ตัว Broker ก็จะทำการส่ง Last Will Message นี้ให้กับ Client ที่เหลือที่ได้ทำการ Subscribe ตรงกับ Topic ที่ระบุไว้ใน Last Will Message ค่ะ แล้วเคสไหนที่ Broker ถือว่าเปนการ Ungracefully Disconnect ลองมาดูกันค่ะ ว่ามีเคสไหนบ้างเมื่อ Broker เจอว่ามี Error เกิดขึ้นของ I/O หรือ Network เมื่อไม่มี Message ใดๆ จาก Client ส่งมาในช่วงเวลาที่กำหนด หรือ Keep Alive Period (Keep Alive คืออะไร? ในบทความถัดไป มาทำความรู้จักกันค่ะ….)เมื่อพบว่า Client ไม่มีการส่ง Disconnect Message มาให้ก่อนที่จะมีการปิดการเชื่อมต่อไปเมื่อ Broker เองเป็นคนตัดการปิดการเชื่อมต่อเนื่องจาก Error ของ MQTT Protocol เองแต่ถ้าหากมีการส่ง MQTT Disconnect Message — Gracefully Disconnect (Fig 2) ตัว Broker ก็จะลบ Last Will Message ที่เก็บไว้ให้ทิ้งค่ะFig 2. MQTT Disconnect Messageจะเห็นว่า LWT มีความบทบาทสำคัญในการแจ้งเตือน Client ตัวอื่นๆ โดยเฉพาะ Client ที่ได้ทำการ Subscribe ไว้กับ Client ตัวที่ได้ขาดการติดต่อไปแบบ Ungracefully DisconnectLWT มักจะถูกนำมาใช้คู่กับ Retained Message เพื่อทำการเก็บ State ล่าสุด(ของ Topic ใด Topic นึง) ของ Client ไว้ ถึงตรงนี้อาจจะยังนึกไม่ออกนะคะ ว่าจะเอา LWT และ Retained Message มาใช้เก็บ State ล่าสุดยังไง ลองมาดูตัวอย่างค่ะ…..Client1 เริ่มทำการเชื่อมต่อกับ Broker ด้วยการส่ง Connect Message ให้ Broker และ ใน Connect Message นี้ก็ระบุ payload ของ lastWillMessageไว้ว่า ‘Offline’ และ มีการเซท lastwillRetain ให้เป็น true และ มี lastWillTopic เป็น ‘client1/status’ (เลื่อนขึ้นไปดู ตัวอย่าง Connect Message ได้นะค่ะ — Fig 1)หลังจากทำการเชื่อมต่อเรียบร้อย Client ก็สามารถเริ่ม Publish ข้อความที่มี Payload ว่า ‘Online’ และ retaionFlag เซทเป็น true ไปที่ Topic ที่ตั้งไว้ตอนทำการเชื่อมต่อค่ะ (client1/status) ซึ่งในระหว่างนี้หากไม่มีการ Disconnect เกิดขึ้น Client ที่ได้ทำการเข้ามา Subscribe ใหม่ที่ Topic นี้ (client1/status) จะได้รับ Retained Message ที่มี Payload ว่า ‘Online’แต่หากว่าการเชื่อมต่อ ระหว่าง Client1 และ Broker มีการ Ungracefully Disconnect เกิดขึ้น Broker จะทำการ Publish LWT Message (ซึ่งมี Payload ว่า ‘Offline’) แทน Retained Message เดิม (ซึ่งมี Payload ว่า ‘Online’) นั่นหมายความว่าถ้ามี Client เข้ามา Subscribe หลังจากที่ Client1 ขาดการติดต่อไป จะได้รับ Message ที่มี Payload ว่า Offline ถึงตรงนี้แล้วพอจะนึกภาพออกแล้วใช่มั้ยคะ ว่าคู่บัดดี้ LWT Message และ Retained Message เข้ามาช่วยจัดการเกี่ยวกับ State ล่าสุดของ Topic ได้ยังไงในบทความถัดไป เราจะพูดถึงเรื่อง Keep Alive ค่ะ ซึ่งนี่ก็เป็น Feature เด่นอีกอย่างนึงของ MQTT ที่จะช่วยให้ Broker รู้ถึงสถานะของ Client ได้ค่ะ ว่า Online อยู่ หรือ Offline ไปแล้วอ้างอิงจาก MQTT Essentials Part 9: Last Will and Testament
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 4)
Message ที่ถูก Publish ใน MQTT จะไม่สามารถทราบได้ว่า Client ที่ Subscribe ไว้นั้น จะได้รับ Message หรือไม่ แต่ Client ที่เป็น Publisher นี้ รู้แน่นอนว่า Message ถูกส่งไปให้ Broker ได้ถูกรับเรียบร้อยแล้ว เช่นเดียวกัน Client ที่เป็น Subscriber เอง ก็ไม่สามารถจะรู้ได้ว่า Publisher จะส่ง Message มาให้เมื่อไหร่ (เพราะ Client จะไม่สามารถติดต่อกันได้โดยตรงค่ะ ต้องมี Broker มาคั่นกลาง) ซึ่งอาจจะแค่ไม่กี่วินาที หรือ อาจจะนานหลายชั่วโมง จึงมีการนำ Retained Message เข้ามาช่วยแก้ปัญหานี้ค่ะRetained Message ก็คือ MQTT Message นี่แหละค่ะ แต่ว่าจะถูก Publish มาพร้อมค่า retainFlag ที่ตั้งว่าไว้เป็น True ค่ะ ซึ่ง Broker จะทำการเก็บ payload และ QoS ของ Message สำหรับ Topic นี้ไว้ แล้วถ้ามี Client เข้ามาทำการ Subscribe ตรงกับ Topic ที่มี Retained Message เก็บไว้ Broker ก็จะส่ง Message นี้ ให้ Client โดยทันทีค่ะ ซึ่งในแต่ละ Topic นั้น Broker จะทำการเก็บ Retained Message ไว้แค่ค่าสุดท้ายค่าเดียวนะคะไม่เพียงแต่ Client ที่ทำการ Subscribe ใน Topic ที่ตรงกับ Retained Message ที่ Broker เก็บไว้นะคะ ถ้าหากว่า Client ทำการ Subscribe ใน Topic ที่มีเครื่องหมาย Wildcard (#) ร่วมใน Topic นั้นด้วย Client ก็จะได้รับ Retained Message ของ Topic นั้นเช่นกันค่ะตัวอย่างของการ RetainClient A ได้ทำการ Publish Retained Message ไปที่ Topic myhome/livingroom/temperature หลังจากนั้น Client B ได้เข้ามาทำการ Subscribe ที่ Topic myhome/# ทันทีที่ Subscribe เรียบร้อยแล้ว Client B จะได้รับ Retained Message (จาก Topic myhome/livingroom/temperature) ทันทีค่ะ ซึ่ง Client B สามารถรู้ได้ว่านี่คือ Retained Message โดยดูจาก retainFlag ที่ Broker ส่งมาให้ค่ะจะเห็นว่า ข้อดี ของ Retained Message ก็คือ การที่ Client สามารถรับรู้ได้ทันทีหลังจากที่ได้เข้ามาทำการ Subscribe ว่าตอนนี้ สถานะ ของ Topic นี้เป็นยังไง โดยที่ไม่ต้องรอให้ถึงจนกว่า Pusblisher จะทำการส่ง Message อีกครั้ง ซึ่ง Retained Message นี้ไม่จำเป็นว่าจะเป็น Message ล่าสุดที่ถูกส่งมานะคะ แต่ต้องเป็น Message ล่าสุดที่ถูกส่งมาพร้อมค่า retainFlag เป็น True ค่ะการลบค่าที่ระบบ Retain เอาไว้ถ้าหากว่าเราต้องการที่จะลบ Retained Message นี้ออก ก็ทำได้ง่ายๆเลยค่ะ เราแค่จัดการให้ Publisher ส่ง Message ที่ไม่มี payload (มี payload เป็น 0 Byte) พร้อมกับค่า retainFlag เท่ากับ True ค่ะ แค่นี้ Broker ก็จำทำการลบ Retained Message ของ Topic นั้นๆออกให้ค่ะ หลังจากนี้ Client ที่เข้ามาทำการ Subscribe ก็จะไม่ได้รับ Retained Message ค่ะการประยุกต์ใช้งานฟีเจอร์ RetainRetained Message เหมาะสมจะนำมาใช้เมื่อเราต้องการให้ Client ใหม่ ที่มา Subscribe ได้รับค่าอัพเดทล่าสุด อย่างเช่น เมื่อต้องการรู้ว่าอุปกรณ์นั้น Offline หรือ Online อยู่ค่ะ ถ้าหากไม่นำ Retained Message เข้ามาใช้ Client ก็จะต้องรอจนกว่าจะมีการ Publish อีกครั้งนึงค่ะ
โดย: Laris
| IoT
มารู้จัก MQTT Protocol กันดีกว่า (ตอนที่ 3)
บทความที่แล้วเราได้พูดถึงหนึ่งใน Feature สำคัญของ MQTT กันไปแล้วนะคะ ซึ่งก็คือ QoS หรือ Quality of Service ค่ะ และ ในช่วงท้ายๆของบทความ ได้พูดถึง Persistent Session แต่ยังไม่ได้อธิบายว่าคืออะไร บทความนี้ก็มาพูดถึงกันเลยค่ะถึงแม้ว่า MQTT (ตามคำนิยามแล้ว) ไม่ใช่ Message Queue แต่….. MQTT มีความสามารถที่จะทำ Message Queueing ได้ค่ะ ด้วยการใช้ Persistent Sessionหาก Client ต้องการรับ Message จาก Broker ตัว Client ต้องทำการเชื่อมต่อกับ Broker และ ทำการสร้าง Subscription ของ Topic ที่ตัว Client สนใจขึ้นมา ในระหว่างนี้ หากการเชื่อมต่อระหว่าง Client และ Broker มีปัญหาเกิดขึ้นทำให้การเชื่อมต่อมีข้อผิดพลาด และ ถ้าการเชื่อมต่อนั้นไม่ใช่แบบ Persistent Session จะทำให้ Client ไม่ได้รับ Message จาก Topic นั้นได้ ดังนั้น Client จำเป็นจะต้องทำการ Subscribe ใหม่อีกครั้งเมื่อมีการเชื่อมต่อกับ Broker ​ซึ่งการทำการเชื่อมต่อระหว่าง Broker และ Client ใหม่ซ้ำๆทุกครั้งที่มีปัญหาขาดการเชื่อมต่อย่อมทำให้เกิดปัญหา ยิ่งถ้าเรามีข้อจำกัดเรื่องอินเตอร์เนทอยู่ด้วยแล้วละก็ ปัญหาใหญ่แน่นอนค่ะ ดังนั้นเพื่อที่จะหลีกเลี่ยงปัญหานี้ ตัว Client จะต้องทำการเชื่อมต่อกับ Broker แบบ Persistent Session ค่ะการเชื่อมต่อแบบ Persistent Session นี้ จะช่วยเราเก็บข้อมูลทุกอย่างที่เกี่ยวข้องไว้บน Broker ค่ะ โดยจะใช้ ClientId เป็นตัวบ่งบอกว่า Session ไหนเป็นของ Client ตัวไหนข้อมูลต่างๆที่ Broker จะเก็บไว้ให้ Client ก็จะมีตามนี้เลยค่ะ (ถึงแม้ว่า Client จะ Offline ไป แต่เมื่อไหร่ที่ Client กลับมา Online ข้อมูลเหล่านี้ก็จะถูกจัดเตรียมให้ Client ทันทีเลยคะ)สถานะของ Session (ถึงแม้ว่าจะไม่มีการ Subscription)ข้อมูล Subscription ทุกอย่างของ ClientMessage (ที่ได้กำหนด QoS 1 หรือ 2) ต่างๆที่เกิดขึ้น และ Client ยังไม่ได้ทำการยืนยันMessage (ที่ได้กำหนด QoS 1 หรือ 2) ที่เกิดขึ้นใหม่ระหว่างที่ Client ได้ Offline ไปMessage (ที่ได้กำหนด QoS 2) ที่ได้รับจาก Client ที่ยังไม่ได้รับการตอบรับหาก Client ต้องการจะเชื่อมต่อแบบ Persistent Session กับ Broker ตัว Client สามารถทำได้โดยการกำหนดค่าของ cleanSession เพื่อบอกให้ Broker รู้ว่า Client ต้องการที่จะทำการเชื่อมต่อแบบไหน (Persistent Session หรือ Clean Session)ถ้าต้องการให้มีการเชื่อมต่อแบบ Clean Session ค่าของ cleanSession จะเป็น True ค่ะ ถ้าเกิดมีปัญหากับการเชื่อมต่อเกิดขึ้น ข้อมูลทุกอย่างก็จะหายไปค่ะ รวมไปถึง Message ที่ถูก Queue ไว้จาก Persistent Session ก่อนหน้านี้ก็จะหายไปด้วยค่ะตรงกันข้ามค่ะ ถ้าต้องการให้มีการเชื่อมต่อแบบ Persistent Session ค่าของ cleanSession จะถูกตั้งค่าให้เป็น False ตัว Broker ก็จะทำการสร้าง Persistent Session ให้ค่ะ ข้อมูลต่างๆ และ Message จะถูกเก็บไว้ให้โดย Broker จนกว่า Client จะขอทำการเชื่อมต่อแบบ Clean Session (ตั้งค่า cleanSession เป็น True) ค่ะ ถ้าเกิดว่ามีการขอเชื่อมต่อแบบ Persistent Session แต่ว่า ณ เวลานั้น Broker ได้ทำการเชื่อมต่อกับ Client เรียบร้อยแล้ว ในเคสนี้ Broker จะใช้ Session ที่เชื่อมต่ออยู่ และจะทำการส่ง Message ทั้งหมดที่เคย Queue ไว้ให้กับ Client ค่ะหลังจากที่การเชื่อมต่อแล้ว Client จะรู้ได้ยังไงว่า Broker ได้ทำการจัดเก็บข้อมูลต่างๆให้เราแล้ว …..Client สามารถรู้ได้จาก CONNACK Message จาก Broker ค่ะ ใน CONNACK จะมีข้อมูลเกี่ยวกับ sessionPresent ค่ะ ซึ่งก็จะบอกได้ว่า Session ที่ Client ได้ทำการเชื่อมต่อกับ Broker นั้นยังมีการเชื่อมต่ออยู่รึป่าว และยังสามารถใช้ได้อยู่รึป่าวMQTT CONNACK Messageไม่ใช่เฉพาะ Broker นะคะ ที่ต้องเก็บข้อมูลไว้ หากมีการเชื่อมต่อแบบ Persistent Session ตัว Client เองก็ต้องทำการเก็บข้อมูลไว้เหมือนกันค่ะ ซึ่งก็จะเก็บข้อมูลตามนี้ค่ะMessage (ที่ได้กำหนด QoS 1 หรือ 2) ต่างๆที่เกิดขึ้น และ Broker ยังไม่ได้ทำการยืนยันMessage (ที่ได้กำหนด QoS 2) ที่ได้รับจาก Broker ที่ยังไม่ได้รับการตอบรับการเลือกเชื่อมต่อกับ MQTT Brokerวิธีเลือกว่าจะทำการเชื่อมต่อ Client กับ Broker แบบไหนดี ระหว่าง Persistent Session กับ Clean Session ให้ลองพิจารณาตามนี้ค่ะจะเลือกใช้ Persistent Session เมื่อไหร่?เมื่อ Client ต้องการได้รับ Message ทั้งหมด จาก Topic ที่ได้ทำการ Subscribe ไว้ ไม่ว่า Client จะ Offline ไป Broker จะทำการ Queue ข้อความไว้ให้ และจะส่งให้ Client ทันทีที่กลับมา Onlineเมื่อ Client มีข้อจำกัดทางทรัพยากรที่มีผลกระทบต่อการเชื่อมต่อ แต่ต้องการให้ Broker เก็บ ข้อมูลการ Subscription ไว้ให้ และต้องการให้มีการกู้คืนเมื่อการเชื่อมต่อถูกรบกวนเมื่อ Client ต้องการที่จะ Publish ข้อความ (Qos 1 และ 2) หลังจากมีการกลับมาเชื่อมต่ออีกครั้งจะเลือกใช้ Clean Session เมื่อไหร่?ถ้าหาก Client (ที่เป็น Publisher) ต้องการแค่ Publish ข้อความClient (ที่เป็น Subscriber) ไม่ได้ต้องการที่จะ Subscribe และไม่ได้สนใจที่จะรับ Message ถ้าหากว่า Client เกิด Offline ไปBroker ไม่จำเป็นต้อทำการเก็บข้อมูลเกี่ยวกับ SessionBroker ไม่จำเป็นต้องพยายามส่ง Message (Qos 1 และ 2) อีกครั้ง เมื่อไม่สามารถส่ง Message ได้สำเร็จแล้ว Broker จะเก็บข้อมูลไว้ให้เรานานแค่ไหน?Broker จะทำการเก็บข้อมูลไว้จนกว่า Client จะกลับมา Online อีกครั้งและได้รับ Message ที่ไม่ได้รับในระหว่างที่ Offline ไปค่ะ ละถ้าเกิด Offline ไปเป็นเวลานานมากๆละ.. คำตอบก็คือ แล้วแต่เคสค่ะ โดยปกติแล้ว Memory ก็จะเต็มซะก่อน Message ที่ถูก Queue ไว้ก็จะถูกลบไปโดยปริยายค่ะหนักหัวต่ออีกนิดนะคะ แต่ก็ใกล้จะจบแล้วค่ะ ไว้คราวหน้าเราจะพูดถึงการเก็บข้อมูล หรือการ Retain ในระบบของ MQTT กันค่ะ แล้วพบกันนะคะ สวัสดีค่ะ
โดย: 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

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

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

หมวดหมู่

พบหมวดหมู่ ได้ที่นี่เร็ว ๆ นี้

พบหมวดหมู่ ได้ที่นี่เร็ว ๆ นี้

Tags

พบคำสำคัญ ได้ที่นี่เร็ว ๆ นี้

พบคำสำคัญ ได้ที่นี่เร็ว ๆ นี้

พบคำสำคัญ ได้ที่นี่เร็ว ๆ นี้