معرفی دوره

در این قسمت از آموزش می پردازیم به معرفی و نصب مهم‌ترین کتابخانه ارتباطات اینترنت اشیا در پایتون که paho-mqtt هست. آن را نصب می‌کنیم و در نهایت به سادگی اولین کلاینت خود را هم ایجاد می‌کنیم.

در این قسمت از آموزش، پس از ایجاد client در پایتون با استفاده از paho-mqtt، پیکربندی و تنظیمات ابتدایی آن را انجام می‌دهیم. مواردی مانند client_id، client_session، ویرایش protocol ارتباطی توسط client (ورژن‌های مختلف از جمله 3.1.1 و 5.0) و نوع پروتکل ارتباطی برای تنظیمات مربوط به پیکربندی client در این ویدئو ذکر شده است که لازم است مورد توجه قرار گیرد.

در قسمت چهارم از این دوره کاربردی، نحوه اتصال به broker یا بروکر mqtt برای ورژن 3.1.1 از mqtt آموزش داده می‌شود. تنظیمات ابتدایی که برای اتصال یک client به بروکر محلی شامل مواردی از قبیل host، port و keepalive هستند. ابتدا در نظر داشته باشید با توجه به اینکه در این دوره از mosquitto به عنوان بروکر mqtt استفاده شده است، لازم است که آن را به شکل local یا محلی نصب کرده باشید.

در قسمت پنجم از این دوره، تنظیمات اتصال به broker یا بروکر mqtt برای ورژن 5.0 از mqtt آموزش داده می‌شود. این ورژن تنظیمات و ویژگی‌های بیشتری برای کنترل بیشتر روی اتصالات دارد که در این آموزش مورد بحث قرار می‌گیرد. یکی از مهم‌ترین تفاوت‌های این ورژن با ورژن قبلی، مربوط به تنظیمات session است که در اینجا به در هنگام اتصال انجام می‌شود. همان‌طور که در قسمت پیشین دیدید، این تنظیمات در ورژن قبلی در هنگام تعریف client پیکر‌بندی می‌شد.

در این قسمت از آموزش در خصوص callback function های مهم در کتابخانه paho_mqtt توضیحات لازم داده می‌شود که شامل on_connect، on_disconnect، on_subscribe، on_unsubscribe، on_message، on_publish و on_log است که برای اتصال به بروکر و قطع آن، اشتراک و لغو آن، دریافت و انتشار پیام و همچنین لاگ گرفتن که مورد اخیر برای حالت توسعه بیشتر کاربرد دارد، می‌باشد.

در قسمت هفتم آموزش استفاده از کتابخانه paho-mqtt برای ارتباطات اینترنت اشیا توسط پایتون، به توضیحات استفاده از رویداد on_connect برای ویرایش mqttv3.1.1 می‌پردازیم. Callback function مربوط به آن شامل پارامترهایی به شرح client, userdata, flags, rc است که rc نشان دهنده اتصال موفقیت آمیز عدم آن باشد. در واقع اگر rc برابر صف باشد یعنی اتصال کلاینت به بروکر موفقیت آمیز بوده است؛ هر یک از اعداد 1 تا 5 هم مفاهیمی دارند که در این ویدئوی آموزشی توضیح داده می‌شوند. برای مثال اگر مقدار rc برابر با 5 باشد، یعنی عدم احراز هویت موفقیت آمیز سبب شده است که اتصال به بروکر انجام نشود.

در قسمت هشتم از آموزش، به توضیحات استفاده از رویداد on_connect برای ویرایش mqttv5.0 می‌پردازیم. Callback function مربوط به آن شامل پارامترهایی به شرح client, userdata, flags, reason_code, propertiesc است که از ورژن قبلی بیشتر است تا بتوان کنترل بیشتری روی اتصالات و پاسخ‌های بروکر (ACKNOWLEGMENT) داشت. در این ویرایش، reason_code نشان دهنده اتصال موفقیت آمیز یا عدم آن است که توسط مستندات ارائه شده در وبسایتی در این ویدئوی آموزشی معرفی می‌شود، مفهوم هر کد بازگشت شده تحلیل و تفسیر می‌شود. اینجا نیز مقدار 0 نشان دهنده اتصال موفقیت‌آمیز است.

تشخیص disconnect شدن client از broker در ویرایش 3.1.1 از mqtt در این قسمت از آموزش توضیح داده شده است. رویداد قطع اتصال، on_disconect است که callback function آن نیز شامل چندین پارامتر rc، userdata و client است که در ورژن 3.1.1. در حالتی که به شکل تمیز یا clean، اتصال قطع می‌شود (با استفاده ازclient.disconnect())، مقدار آن برابر با صفر است. قطع اتصال غیر تمیز، شامل قطع ناگهانی یا crash است که شبیه‌سازی آن نیز با یک توقف در اتصال به بروکر با مدیریت مقدار keepalive انجام می‌شود تا مقدار rc برای مشاهده و آموزش چاپ شود.

تشخیص disconnect شدن client از broker در ویرایش 5.0 از mqtt در این قسمت از آموزش توضیح داده شده است. رویداد قطع اتصال در این ویرایش هم مانند ویرایش قبلی، on_disconect است که callback function آن نیز علاوه بر پارامترهای reason_code، userdata و client شامل properties نیز می‌باشد که در این قسمت نحوه استفاده از آن آموزش داده شده است. اینجا نیز قطع اتصال clean را با client.disconnect() انجام میدهیم.

دراین قسمت از آموزش می‌پردازیم به رویداد on_message که از مهم‌ترین رویدادهاس مربوط به پروتکل mqtt است؛ چرا که هدف اصلی از پروتکل mqtt، دریافت و ارسال پیام از طریق آن است. در واقع این رویداد وظیفه دریافت پیام‌های ارسال شده به یک topic را به عهده دارد. Callback function مربوط به آن شامل سه پارامتر است که عبارتند از client، userdada و msg که خود msg شامل چندین attribute از جمله payload و topic است. Payload همان پیام اصلی است که برای دریافت به عنوان یک رشته، باید به شکل utf-8 دیکد یا decode شود. در این قسمت همچنین loop_forever() توضیح داده می‌شود تا تفاوت آن با loop_start() و loop_stop() درک شود.

دراین قسمت از آموزش دوباره می‌پردازیم به ادامه رویداد on_message که قبلا گفتیم از مهم‌ترین رویدادهای مربوط به پروتکل mqtt است. همانطور که می‌دانیم، داده‌ها عموما شامل پارامترهای مختلفی هستند که برای این منظور لازم است از فرمت‌های مانند json استفاده کنیم. در این بخش داده را به شکل json ارسال می‌کنیم اما برای استفاده و تحلیل آن در سمت client و در هنگام دریافت توسط on_message، باید آن را ابتدا به شکل utf-8 دیکد یا decode کرد و همچنین پس آن را به شکل دیکشنری در آورد که با استفاده از json.loads() انجام می شود. در این ویدئو به خوبی این موارد را یاد می‌گیرید و همچنین روش مدیریت درست Exception ها را هم آموزش می‌بینید.

در قسمت سیزدهم از آموزش کدنویسی جهت ارتباطات اینترنت اشیا با پایتون، همچنان می‌پردازیم به رویداد مهم on_message. قبلا گفتیم که در callback function مربوط به این رویداد، پارامترهایی وجود دارند که عبارتند از client، userdata و msg. خود msg گفتیم که شامل payload و topic است؛ اما باید بدانیم که محدود به همین ها نیست بلکه شامل mid، retain و qos نیز می باشد که در این قسمت صرفا به معرفی آنها اکتفا می‌شود و کاربرد آنها بیشتر در قسمت‌های آینده مشخص خواهد شد. در ادامه به یکی دیگر از پارامترهای برگشت شده توسط ویرایش پنجم mqtt می‌پردازیم که عبارت است از properties. پس از دیدن این قسمت آماده هستید تا ارسال یا publish کردن پیام را هم در ادامه ببینید و بیاموزید.

با توجه به اینکه تاکنون در خصوص on_message بحث مفصلی کرده‌ایم، در این قسمت روش انتشار پیام به یک topic را در ساده‌ترین شکل ممکن توضیح می‌دهیم. وقتی پیامی publish شده یا انتشار می‌یابد، مواردی مانند mid و rc را بر می‌گرداند که می‌توانند برای ردیابی پیام و فهمیدن ارسال موفقیت آمیز آن به کار روند. در این قسمت با توجه به اینکه فقط خواستیم پیامی ارسال کنیم از ساده ترین شکل استفاده کردیم و به جای loop از wait_for_publish() بهره گرفتیم. در قسمت بعد در خصوص رویداد on_publish بحث خواهیم کرد که مکمل این قسمت از آموزش است.

در این قسمت از آموزش می پردازیم به رویداد on_publish و callback function مربوط به آن. با استفاده از این رویداد و تابع بازگشتی آن می‌توان پیام‌هایی که منتشر می‌شوند را ردیابی کرد و آنهایی که انتشار داده شده اند اما به topic موردنظر به هر دلیل ارسال نهایی نشده‌اند را شناسایی کرد و برای آنها سناریوهای لازم را در نظر گرفت. این قسمت تکمیل کننده بخش قبل است و با یادگیری آن می‌توان گفت که تاکنون بخش اعظمی از کتابخانه paho_mqtt را یاد گرفته‌اید.

در این قسمت از آموزش به رویداد on_subscribe و callback function مربوط به آن می‌پردازیم. اگر بخواهیم بدانیم که آیا اتصال به topic یا topicهای مورد نظر ما انجام شده است، می‌توانیم با استفاده ازمقایسه mid رویداد مذکور و مقدار بازگشتی callback function آن به این هدف دست یابیم. در این ودئو نحوه دریافت mid در هنگام subscribe توضیحداده شده است. توجه شود که امکان مشترک شدن به تاپیک های گروهی یا چندگانه هم در یک دستور وجود دارد که آن نیز مورد بحث و بررسی قرار گرفته است.

پس از یادگیری رویداد on_subscribe و callback function مربوط به آن، در این جلسه به on_unsubscribe می‌پردازیم. از client.unsubscribe(topic) برای حذف اشتراک استفاده می‌شود که برای ردیابی انجام شدن آن، باز می‌توان از mid استفاده کرد که در این ویدئوی آموزشی به نحوه استفاده از آن پرداخته شده است.

در این قسمت به آخرین رویداد مهم و قابل ذکر برای کتابخانه paho_mqtt یعنی on_log می پردازیم که بخصوص در حالت توسعه می‌تواند کمک شایان توجهی به افرادی کند که سعی دارند تا به شکل لحظه به لحظه و با جزئیات بیشتر بفهمند که چه جریان داده‌ای شامل انواع درخواست‌ها و پاسخ‌ها در اتصالات mqtt ایجاد شده و در حال رخ دادن تا در صورتی که به مشکلی بر بخورند با بررسی آن، به رفع مشکلات موجود بپردازند. نکته لازم به ذکر این است که بهتر است برای جلوگیری از سنگین شدن و همینطور شلوغی بیش از حد با توجه به درج انواع لاگ‌های جریان داده‌ و بده بستان‌های پشت صحنه در ارتباطات mqtt که کم هم نیستند، تنها در حالت توسعه از این رویداد استفاده گردد.

در این قسمت به callback_api_version می پردازیم که در حال حاضر شامل ویرایش‌های 1 و 2 است که با توجه به منقضی شدن نسخه اول بهتر است از نسخه دوم استفاده شود. در واقع با انتخاب ویرایش یا ورژن 1، در حال حاضر در ظاهرمشکلی وجود ندارد و با یک هشدار برای آن مواجه می‌شویم که اظهار می دارد که این نسخه منقضی شده است. callback_api_version در واقع تعیین کننده امضا یا signature های مربوط به callback function هایی است که در جلسات قبل در خصوص آنها توضیحات لازم داده شد. به عنوان مثال در ویرایش دوم، properties هم جزو پارامترهایی است که در تابع connect_callback اضافه شده است و باید قید گردد.

پیام های retain در mqtt از آن جهت اهمیت دارند که با استفاده از آن می‌توان آخرین پیامی که یک client منتشر کننده انتشار داده است را دریافت کرد، حتی هنگامی که آن client آفلاین شده باشد. کاربردهای پیام retain بستگی به نوع پروژه دارد؛ اما در این قسمت از آموزش ما از آن برای نشان دادن وضعیت اتصال یا قطع اتصال منتشر کننده پیام به یک topic استفاده کردیم که می‌توانید آن را به خوبی مانیتور کنید. برای اینکه یک پیام به شکل retain ارسال کنم، باید مقدار آن را در هنگام انتشار یا publish، برابر با True قرار دهیم. همچنین در سمت مشترک نیز برای تشخیص اینکه آیا پیام به شکل retain است یا خیر، می‌توان با استفاد از یک دستور شرطی و از طریق attribute مربوط به msg در callback function مربوط به on_message که یک مقدار Boolean است، بدان دست یافت. این ویدئوی آموزشی را ببینید تا مواردی که در توضیحات فوق گفته شد را درک کنید.

با توجه به اینکه ممکن است، ارتباط یک client با یک حادثه ناخواسته، به طور ناگهانی قطع شود، در پروتکل mqtt امکانی به نام last will گنجانده شده است که به مفهوم آخرین پیام (آخرین خواسته یا وصیت نامه) می‌باشد. این مفهوم یکی از موارد کاربردی است که می‌تواند کمک خوبی به سایر کلاینت‌ها کند تا به عنوان مثال آخرین وضعیت یک منتشر کننده پیام (سنسور یا هر منبع ارسال پیام) در پروتکل mqtt را بدانند. در این ویدئوی آموزشی نحوه استفاده از آن شرح داده شده است و در خصوص روش صحیح تنظیم آن که با استفاده ازclient.will_set() انجام می‌شود، توضیحات لازم داده شده تا یک گام دیگر به پیکربندی حرفه‌ای clientهای مربوط به پروتکل mqtt نزدیک شوید.

qos از دیگرمفاهیم مهمی است که در پروتکل mqtt مطرح است و اهمیت دارد و مخفف quality of service است که در فارسی به «کیفیت سرویس» ترجمه می‌شود. در دوره « پروتکل mqtt مقدماتی» گفته شد سه سطح 0، 1 و 2 برای qos وجود دارد که هر یک کاربردهای خاصی دارند: هنگامی که از دست رفتن چند پیام اهمیت ندارد، مقدار 0 در نظر گرفته می شود که همان مقدار پیش‌فرض است؛ وقتی داده لازم است حتما ارسال شود و یا دریافت داده حیاتی است، مقادیر 1 و 2 باید برای آن تنظیم شوند. اما اینکه از دو مقدار 1 و 2 کدامیک ارجح هستند، با توجه به نوع پروژه تعیین می‌شود. مقدار 1 حداقل یک بار مقادیر را ارسال می‌کند، اما مقدار 2 مطمئن می‌شود که تنها و تنها یک بار مقادیر ارسال شوند که البته مورد اخیر سنگین‌تر بوده و سبب مصرف منابع بیشتری می‌شود و در استفاده از آن باید محتاط بود تا در صورتی که حتما لازم است از آن بهره گرفت. تنظیم qos هنگام subscribe شدن و publish به هر تاپیک انجام می‌شود و این نکته هم لازم به ذکر است که اگر دو کلاینت منتشر کننده و مشترک به یک تاپیک، مقادیر qos متفاوتی از هم داشته باشند، کمتریم مقدار آنها ملاک عمل قرار می‌گیرد. دقت شود برای اینکه بخواهیم اگر مشترک به طور ناگهانی قطع شد؛ پس از اتصال مجدد پیام‌های از دست رفته را نیز دریافت کند، مسلما qos نباید صفر باشد و همچنین باید client_id هم برای آن client تنظیم شده باشد و پاک شدن session هم برای آن False شود. در پایان به این نکته هم دقت شود که پیام‌های last will هم باید با qos 1 ارسال شوند. ویدئوی آموزشی را ببینید تا جزئیات بیشتری را مشاهده کنید.

wildcardها از دیگر مفاهیمی هستند که در پروتکل mqtt اهمیت دارند و دارای دو نماد یا سمبل به شکل + و # هستند. از wildcard تنها در هنگام مشترک شدن (نه انتشار) استفاده می‌شود. سمبل + تنها یک سطح را جایگزین می‌شود و مابقی سطوح باید به عیناً نوشته شوند اما سمبل # از سطح خود به بعد را شامل می‌شود. شایان ذکر است که می‌توان به شکل ترکیبی نیز از این سمبل‌ها استفاده کرد یا حتی از هر سمبل برای چندین بار هم بهره گیری کرد. مسلما مانند مشترک شدن معمولی به یک تاپیک، می‌توان qos، retain و سایر مورادی که برای subscribe به کار می‌روند را نیز برای آنها تنظیم کرد. در این ویدئوی آموزشی با مثال‌های عینی مواردی که توضیح داده شده است، آموزش داده شده است.

قبلا در خصوص retain message صحبت کردیم. می‌دانید که آخرین پیام‌های retain مربوط به یک topic نگه داشته می‌شوند و در صورت subscribe شدن هر مشترک به آن، توسط آن مشترک دریافت می‌شود. در این قسمت در خصوص حذف پیام‌های retain آموزش‌های لازم داده می‌شود که به منظور حذف پیام retain شده، باید یک پیام یا payload خالی به topic مشترک قبلی ارسال کنید تا پیام retain حذف شود.

در این قسمت از آموزش، با توجه به اینکه گاهی اوقات لازم است تا از بروکرهای ابری برای رد و بدل کردن پیام‌ها استفاده شود، به آموزش نحوه استفاده از آن نیز خواهیم پرداخت. در واقع در اینجا پس از ساخت یک اکانت بر روی یک بروکر ابری mqtt، کدهای پایتون لازم برای ارتباط با یک کلاینت که ممکن است در هر نقطه از کره زمین که به اینترنت دسترسی دارد، تحت بستر اینترنت و در قالب پروتکل mqtt را تهیه می‌کنیم و از آن بهره می‌گیریم. دقت شود که تنظیمات نام کاربری و رمز عبور و همینطور تنظیمات tls نیز برای برقراری این ارتباط در کتابخانه paho_mqtt، ارائه شده است. شما می‌توانید همه آنچه پیش از این گفته شد را روی این بروکر هم پیاده سازی کنید و به مدیریت اینترنت اشیای پروژه‌های خودتان بپردازید.

شرح پروژه پایانی در این قسمت از آموزش ذکر شده است که برای ارسال داده‌های شبیه‌سازی شده از سنسورهای دما و زطوبت استفاده می‌شود تا در صورتی که از حدی این مقادیر بیشتر شدند، نمایش داده شوند و در صورت لزوم هشدار صوتی نیز صادر شود. این پروژه به نحوی در نظر گرفته شده است که به خوبی با یک مدیریت یک پروژه اینترنت اشیا آشنا شوید و بتوانید موارد خواسته شده از شما برای این پروژه‌ها را مدیریت نمایید.

در این قسمت، ایجاد یک کلاینت publisher جهت شبیه‌سازی ارسال دما و رطوبت در یک اتاق را استارت می‌زنیم که بتوانیم پروژه نهایی را به انجام برسانیم. دقت کنید که در پروژه‌های اینترنت اشیا، این مقادیر به صورت واقعی و توسط سنسورها و بردهای اینترنت اشیا ارسال می‌شوند؛ اما برای اینکه ما ارسال مقادیر هم انجام دهیم، به شکل شبیه‌سازی شده و با کدنویسی پایتون، مقادیر را به شکل تصادفی تولید خواهیم کرد و به تاپیک‌های موردنظرمان جهت استفاده توسط مشترکینی که بدانها subscribe کرده‌اند، انتشار می‌دهیم.

در این قسمت، ادامه ایجاد کلاینت publisher جهت شبیه‌سازی ارسال دما و رطوبت در یک اتاق را استارت می‌زنیم که و دادهای تصادفی را جهت تولید و در قالب json ارسال می کنیم. علاوه بر دما و رطوبت، زمان را هم به شکل هجری شمسی و با فرمت مورد نظرمان ارسال می‌کنیم تا چنانچه مشترک یا subscriber بدان نیاز داشته باشد، از آن بهره‌گیری کند. در پایان یک publisher دیگر هم می‌سازیم تا دمای اتاق را ارسال کند. هر کلاینت در اینجا معرف یک اتاق مجرا است؛ هرچند می‌توان دمای هر اتاق را به تاپیک جداگانه‌ای ارسال کرد، اما ما از یک تاپیک استفاده کردیم و client_id را هم به عنوان یک شناسه برای هر منشر کننده به مشترک ارسال کردیم که با دیدن فیلم آموزشی همراه این توضیحات می‌توانید نحوه شبیه‌سازی ارسال پیام را درک کنید.

در این قسمت، یک بهینه‌سازی جهت مدیریت استثنا و داشتن کنترل بهتر روی کلاینت منتشر کننده پیام انجام دادیم که با دیدن ویدئوی آموزشی آن را هم می‌توانید در پروژه‌های خود بکار گیرید. دقت شود که در پروژ‌ه های اینترنت اشیا، بخش publusher به احتمال خیلی زیاد از یک منبع بیرونی به topic مورد نظر شما ارسال می‌شود که ممکن است توسط سنسورها، بردهای اینترنت اشیا و یا سیستم‌های دیگر باشد که ما در این پروژه خودمان آن را شبیه‌سازی کردیم.

در ادامه آموزش و در این قسمت شروع به ایجاد کلاینت subscriber می کنیم که باید دیتاهای منتشر شده را دریافت نموده، در صورت لزوم تحلیل کرده ونمایش دهد. همان‌طور که می‌دانید برای این منظور به همان topic قبل subscribe می‌شود. رویدادهای on_connect، on_message و on_subscribe هم تنظیم می‌شوند تا اطلاع کافی از جریان داده‌ها داشته باشیم. با دین ویدئوی آموزشی می‌توانید به پیاده‌سازی مواردی ذکر شده بپردازید و برای تکمیل آن در جلسه بعد آماده شوید.

در ادامه آموزش به تکمیل subscriber می‌پردازیم. برای این منظور پس از مدیریت استثناها جهت کنترل بهتر بر دیتای دریافتی، داده‌های دریافتی را ار json به dictionary تبدیل می‌کنیم که این مساله با json.loads() انجام می‌شود. پس از این، هر یک از مقادیر temperature، humidity و نام publisher را از دیکشنری بیرون می‌کشیم و در نهایت با مقادیر آستانه‌ای که در معرفی پروژه پایانی گفتیم، مقایسه می‌کنیم. چنانچه این مقادیر از حدود مشخص شده بیشتر باشند، به شکل ویژوال به اطلاع کاربر رسانده می‌شود که همه اینها را با مشاهده ویدئوی ضمیمه شده می‌توانید مشاهده و بکارگیری نمایید.

ممکن است در پروژه‌های اینترنت اشیا بخواهیم اگر دما از محدوده‌ای بالا رفت دستوری صادر کنیم (مثلا تهویه هوا) یا مثلا در یک مثال عینی اگر بالا رفتن دما به نحوی که آن را آتش‌سوزی تشخیص دهد، این مورد به کاربر اطلاع یابد، مثلا با استفاده از پیامک، ایمیل، صدای آژیر و ... . این موارد در این قسمت بحث می‌شود و در نهایت با یک هشدار صوتی برای کاربر، این پروژه را به پایان خواهیم برد و به این ترتیب می‌توان گفت که شما به خوبی روش کار با یک پروژه اینترنت اشیا را خواهید آموخت تا در بستر پروتکل ارتباطی mqtt و کدنویسی پایتون با استفاده از کتابخانه paho_mqtt، به پیاده‌سازی آنچه که مورد نظرتان است بپردازید. این نکته لازم به ذکر است که پروژه‌های اینترنت اشیا می‌توانند دامنه‌های وسیعی داشته باشند؛ اما با دیدن همین آموزش‌ها و آشنایی نسبی با زبان پایتون و قدری خلاقیت می‌توانید هر آنچه از شما درخواست می‌شود را به اجرا در آورید و پاسخگوی نیازهایتان باشید.