خانه / مطالب علمی / Mini PC - مینی PC / رزبری پای - Raspberry PI / اینرنت اشیا با رزبری پای و ESP8266 (بررسی MQTT)

اینرنت اشیا با رزبری پای و ESP8266 (بررسی MQTT)

MQTT یک پروتکل ماشین به ماشین (M2M) برای اتصالات اینترنت اشیاء (LOT) است

در قسمت اول این نوشته به بررسی پروتکل MQTT برای ارتباط مابین رزبری پای و ESP8266 می پردازیم. برای ایجاد تعامل میان دستگاه‌های اینترنت اشیا به پروتکل‌هایی با overhead کمتر (بار اضافی کمتر) از قبیل MQTT نیاز است.در دنیای اینترنت اشیا ؛ چیزی که بسیار با آن سروکار داریم، جدا از خود اشیا، پیام‌های ردوبدل شده میان آن‌ها است. دستگاه‌های اینترنت اشیا IoT هنگام ایجاد پیام، اطلاعاتی از قبیل گزارش وضعیت و ارزیابی محیط را ارسال کرده و هنگام دریافت اطلاعات، از آن‌ها خواسته می‌شود تا کاری را انجام دهند یا اطلاعات سایر دستگاه‌ها را ذخیره کنند و یا موارد کاربردی بی‌شمار دیگر. سرعت افزایش تعداد دستگاه‌های اینترنت اشیا مدام به نسبت روز قبل بیشتر شده و به‌تبع آن تجمع ترافیک پیام‌ها نیز با سرعتی باورنکردنی در حال رشد است. با بسط و توسعه اینترنت اشیا، اپلیکیشن هایی نیز روی گوشی‌های هوشمند، تبلت ها و کامپیوترها اجرا می‌شوند که همه نیازمند سرویس پیام‌رسان مشابهی هستند.

 

روش‌های متعددی برای مدیریت پیام‌ها در اینترنت اشیا وجود دارد که یک از اثرگذارترین و جالب‌ترین تکنولوژی‌ها، بروکرهای پیام (message brokers) هستند. ویکی‌پدیا بروکرهای پیام را این‌چنین تعریف می‌کند:

بروکر پیام (message brokers) یک ماژول برنامه واسط است که پیام را از پروتکل انتقال پیام ارسال‌کننده به پروتکل انتقال پیام گیرنده ترجمه می‌کند. بروکرهای پیام، اجزایی در شبکه‌های ارتباطات یا کامپیوتر هستند که اپلیکیشن های نرم‌افزاری در آنجا از طریق تبادل پیام‌های تعریف‌شده ارتباط برقرار می‌کنند. بروکرهای پیام یک بلوک سازنده پیام میان‌افزار به شمار می‌رود. بروکر یک الگوی معماری برای ارزیابی، انتقال و مسیریابی پیام به شمار می‌رود. بروکر به‌عنوان یک واسط با به حداقل رساندن آگاهی دوطرفه‌ای که اپلیکیشن ها برای تبادل پیام باید از وضعیت ارتباطی یکدیگر داشته باشند ارتباط میان اپلیکیشن ها را ممکن ساخته و از تکرار جلوگیری می‌کند. بروکرها از الگوی publish-subscribe استفاده می‌کنند. در این الگو subscriber (کلاینتی که پیام‌های مربوط به موضوع خاصی را دریافت می‌کنند) برای دریافت پیام‌هایی که publisher ها (ارسال‌کننده پیام بدون آنکه گیرنده خاصی برای دریافت آن پیام در نظر داشته باشد) به بروکر ارسال می‌کنند، با یک یا چند بروکر ارتباط برقرار می‌کنند. یک subscriber نیز تا حدودی می‌تواند هم‌زمان به‌عنوان یک publisher عمل کند.

تئوری دیگر کافیست! اکنون به یکی از رایج‌ترین و تأثیرگذارترین پروتکل‌های بروکر یعنی MQ Telemetry Transport یا MQTT می‌پردازیم. توجه داشته باشید که نام اصلی این پروتکل در حال حاضر کمتر استفاده می‌شود و نام اختصاری آن یعنی MQTT به‌عنوان نام پروتکل بکار می‌رود. نام‌های قدیمی پروتکل MQTT عبارت‌اند از

SCADA Device (MQIsdp) و WebSphere MQTT” (WMQTT)

بر اساس توضیحات mqtt.org:

MQTT، یک پروتکل انتقال پیام کاملاً ساده و بسیار سبک و مبتنی بر الگوی publish/subscribe (ثبت/انتشار) (ارسال/دریافت) است که برای دستگاه‌هایی که دارای محدودیت پردازش و ذخیره‌سازی (مانند دستگاه‌های اینترنت اشیا) هستند یا شبکه‌هایی که پهنای باند کم، تأخیر زمانی بالا و عدم ثبات دارند، طراحی گردیده است. اصول طراحی پروتکل MQTT به‌گونه‌ای است که پهنای باند و منابع موردنیاز دستگاه‌ها را به حداقل رسانده و درعین‌حال اعتماد و اطمینان برای دریافت پیام‌ها را نیز تضمین می‌کند. بعلاوه این اصول، پروتکل MQTT را برای ارتباط ماشین به ماشین (M2M) و یا دستگاه‌های متصل در دنیای اینترنت اشیا (IoT) و همچنین اپلیکیشن های موبایل که از مصرف باتری و پهنای باند کم برخوردار هستند، ایدئال می‌سازد.

به‌عبارت‌دیگر، پیاده‌سازی MQTT، انتخابی است ایدئال برای دستگاه‌هایی از قبیل کامپیوتر Raspberry Pi، Arduino، تلفن‌های هوشمند OSes و هر پلتفرمی که می‌خواهد از انتقال پیام ساده با overhead کم بهره‌مند شود. تاکنون، پروتکل MQTT با نسخه ۳٫۱٫۱ و بر اساس استاندارد OASIS بوده است اگرچه در بازار این پروتکل با نسخه ۳٫۱٫۰ ارائه می‌شود. جدیدترین نسخه نسبت به نسخه قبلی به‌طور قابل‌ملاحظه‌ای توسعه یافته است و از این پس بروکرهای MQTT را با عنوان سرورهای MQTT نام برده خواهند شد.

انجمن آیانا (IANA)، پورت ۱۸۸۳ از TCP/IP را جهت استفاده توسط بروکرهای MQTT و همچنین پورت ۸۸۸۳ را برای استفاده از MQTT بر روی SSL رزرو کرده است (باید توجه داشت که استفاده از SSL، overhead بیشتری در ارتباطات ایجاد می‌کند.) اغلب پیاده‌سازی‌های سرور نحت پروتکل MQTT از WebSockets پشتیبانی می‌کنند.

پروتکل MQTT از ۵ ویژگی مهم برخورداراست:
  • مسیریابی مبتنی بر Topic (موضوع): در پیاده‌سازی MQTT پیام‌ها بر اساس رتبه‌بندی موضوعی طبقه‌بندی می‌شوند مانند شهر، ساختمان، اتاق، دستگاه، سنسور. در پیام‌های ارسالی می‌توان از wildcard نیز استفاده کرد. به‌طور مثال کلیه اطلاعات مربوط به سنسورهای موجود در تمامی آزمایشگاه‌های واقع در کلیه ساختمان‌های کالیفرنیا را می‌توان به‌صورت california/+/laboratory/# ثبت کرد. علامت +، وایلد کارد در یک سطح و وایلد کارد # کلیه سطوح پایین‌تر را که در متعاقباً آمده است، شامل می‌شود.
  • پشتیبانی از Clean Sessions(حذف session ها): زمانی که دستگاه endpoint برای اولین بار به سرور MQTT متصل می‌شود، session جدید MQTT ایجاد و توسط سرور و کلاینت ذخیره می‌شود. ذخیره session، این امکان را برای بروکر فراهم می‌کند تا پس از برقراری مجدد ارتباط نیز دریافت پیام‌ها را از سر بگیرد. بطوریکه پیام‌هایی که به علت قطع ارتباط، دریافت یا ارسال نشده‌اند، دریافت می‌شوند. Clean Sessions(حذف session ها) یک گزینه انتخابی است.

 

  • کیفیت سرویس: پشتیبانی MQTT از QoS، این امکان را در اختیار subscriber ها و publisher ها قرار می‌دهد تا یکی از سه سطوح سرویس زیرا انتخاب کنند:

QoS 0: این سطح از کیفیت خدمات نیاز به تائید از جانب گیرنده پیام ندارد. در این حالت، کیفیت و اطمینان خدمات، قربانی سرعت انتقال می‌شوند (احتمال از دست رفتن پیام‌ها وجود دارد).

QoS 1 : از ارسال‌کننده می‌خواهد تا در صورت عدم دریافت پیام تائید در مهلت زمانی تعین شده، مجدداً پیام را ارسال کند. در اتصال اینترنتی ضعیف، تلاش مجدد QoS 1 در ارسال پیام ممکن است، در عملکرد انتقال پیام‌ها تأثیر گذاشته و احتمال ارسال پیام‌های تکراری وجود دارد.

QoS 2 : مشابه عملکرد QoS 1 است با این تفاوت که برای اطمینان از عدم ارسال تکراری پیام‌ها، پی‌درپی وضعیت خود را تغییر می‌دهد.

  • ذخیره پیام‌ها: زمانی که Publisher پیامی را با عنوان “ذخیره شود” علامت‌گذاری می‌کند، آن پیام پیش از سایر پیام‌ها به endpoint ای که برای آن تاپیک Subscribe کرده است می‌رسد. در هر تاپیک فقط یک پیام را می‌توان ذخیره کرد.
  • پیام‌هایLWT: ا Publisher یا subscriber هنگام اتصال به سرور می‌توانند برای Topic خود یک پیام LWT تنظیم کنند، در این حالت در صورت قطع ناخواسته ارتباط endpoint، کلیه کاربرانی که آن topic را دنبال می‌کنند، پیام را دریافت خواهند کرد. در صورت قطع ارتباط عمدی، پیام‌های LWT ارسال نخواهند شد.

در قسمت بعدی آموزش با نصب و تست MQTT روی رزبری پای آشنا میشویم.

منبع: iott .ir

درباره ی علی عزتی

علی عزتی هستم. رشته ی مهندسی برق الکترونیک رو خوندم. علاقه ی من به یادگیری و به اشتراک گذاشتن چیز هایی که یاد گرفتم. باعث شده تا بنویسم. علاقه ی زیادی به الکترونیک دارم. و دوست دارم چیزهای جدید یادبگیرم و بسازم ... :))

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*

code