كنت أرغب في كتابة مقال مفصل حول هذا الموضوع ، ولكن من الواضح أن يدي لا تصلان. لذلك ، رسالة قصيرة. لقد طورت وطبقت بعدة لغات كرمز نموذجي نسخة من بروتوكول MQTT تحت اسم العمل MQTT / UDP. للصبر وأولئك الذين يفهمون بالفعل كل شيء ومن الواضح ، رمز
على Githubلماذاأعيش في شقة يسيطر عليها نظام المنزل الذكي الخاص بي تقريبًا لعدة سنوات. الضوء ، التحكم في المناخ ، أجهزة الاستشعار ، التشغيل الآلي السهل ، هذا كل شيء.
خلال هذا الوقت ، اكتشفت (نعم ، بالمناسبة ، لقد فهمت ذلك بالفعل) أن الخاصية الرئيسية لأنظمة UD هي الموثوقية.
جميع الأنظمة ذات العقدة المركزية ، بحكم تعريفها ، غير موثوقة. ومن هنا الرغبة في الحصول على ترابط بين مكونات النظام (وهناك الكثير منها في منزل ذكي حقيقي) دون استخدام أي محور مركزي.
في الوقت نفسه ، ننطلق من حقيقة أن حركة أنظمة UD صغيرة بشكل عام - نادرًا ما تحتاج أجهزة الاستشعار إلى التحديث أكثر من مرة واحدة في الدقيقة ، وبقية البيانات تستند إلى الحدث (تشغيل الضوء) ، وحركة المرور غير مهمة تمامًا. حتى كل تحديث ثان لجميع البيانات في النظام ليس فقط كارثة ، بل حتى مشكلة كبيرة.
الاستنتاج المنطقي هو أن بث UDP هو أداة مثالية.
(نعم ، أفترض أن الشبكة الداخلية للشقة مغلقة بواسطة جدار حماية).
ما في الايجابيات:تنفيذ بسيط للغاية. يمكن لوحدة التحكم الدقيقة ذات الذاكرة الصغيرة إرسال حزمة UDP. بالنسبة للمستشعر ، ليست هناك حاجة إلى استقبال UDP.
الكمون المنخفض للغاية. لا يوجد الأمام في المحور المركزي ، ووقت تسليم حزم UDP هو عمليًا الحد الأدنى للوقت في النظام الحديث.
لا توجد نقطة فشل مركزية في المحور / الوسيط. ضع في اعتبارك مخططًا بسيطًا: مستشعران لدرجة الحرارة ، ووحدة تحكم أرضية مدفأة ، ووحدة تحكم في بطارية التدفئة. باستخدام MQTT / UDP ، لا يؤدي فشل أي جزء من هذا النظام إلى فشل النظام ككل.
حركة مرور شبكة منخفضة. تحت أي مكان. يضيف TCP والإقرارات حركة المرور فقط ، ولكن لا تضيف الموثوقية. لن يعمل المستشعر الفاشل على استقبال TCP ACK. ونحدد الفشل بسبب عدم وجود تحديثات.
إن موثوقية بروتوكول UDP نفسه غير ذات أهمية - لا تزال أجهزة الاستشعار تقوم بتحديث البيانات بانتظام ، واختفاء العد غير مرئي تمامًا ، واختفاء أمر من ، على سبيل المثال ، يتم تأكيد التبديل بصريًا من خلال فشل النظام الهدف. ماذا يفعل الشخص؟ ينقر مرة أخرى. ومع ذلك ، هذا قيد رئيسي على تطبيق البروتوكول. مثالية لاستطلاعات الرأي المتكررة.
لا حاجة لتكوين النظام. لا يحتاج أحد إلى تسجيل عنوان الوسيط أو المركز ، إلخ. ومع ذلك ، لا يزال تكوين المستشعر مطلوبًا - تحتاج إلى تسجيل معرف المستشعر. ولكن عند نقل أجزاء أخرى من النظام إلى خوادم أخرى ، لا يلزم إعادة تكوين مكونات الاستجابة.
من المثير للاهتمام بشكل خاص أن هذا النموذج لتبادل البيانات يناسب بشكل جيد على وسائط البث الطبيعية مثل قناة راديو أو RS / 485. لم أقم بتجربة ذلك ، ويجب التحكم في البروتوكول في مثل هذه البيئات. من المنطقي هنا تطبيق CRC16 من modbus ، بالمناسبة.
السلبيات واضحة أيضًا: يتم تحديد موثوقية التسليم فقط من خلال الأجهزة وحركة المرور على الشبكة ، حسنًا ، إذا دخل العدو إلى الشبكة ، فسيتم هزيمة البروتوكول على الفور. صحيح أننا سنكون صريحين ، فإن اختراق بروتوكولات المنزل الذكي النموذجية الأخرى هو مجرد ثوان ، لذا فإن هذا عيب مثير للجدل لـ MQTT / UDP. آخر ناقص غير واضح بحد أقصى جهاز استقبال واحد لكل عنوان IP.
ما تم عمله ويكمن في مستودع شفرة المصدر:- تطبيقات العميل / الخادم بعدة لغات. هناك C و Python و Java. لم أتقن لوا (لم أستطع وضع كل ما تحتاجه ، كيف تعيش في هذا؟) و Codesys (لا يمكن تجميع الحزمة ، من اخترع هذه اللغة؟).
- بوابة الحد الأدنى ل MQTT التقليدية في بيثون
- أداة بدائية لعرض حركة مرور MQTT / UDP على شبكة
ماذا أفعل إذا كان لدي المزيد من الوقت:- أود أن أكتب وحدة نمطية لـ openHUB.
- سيصنع متغير بروتوكول على JSON على منفذ آخر ومحول إلى التنسيق الرئيسي والمنفذ. أو بوابة في الاتجاهين.
- أود أن أجعل فراغات التنفيذ للمنصات الرئيسية. بالنسبة إلى Arduino ، اتخذت نهجًا للوزن واختبرت الرمز حقًا ، لكنني لم أصمم كل شيء بشكل صحيح. بالنسبة لتوت العليق ، تكون حالات الاختبار في Python مناسبة.
- سيتم التوقيع والتشفير رقميا ، ولكن ليس من الواضح كيف.
- الإرسال المتعدد.
شكرا لك على ذلك ،
مرحبا بك في المستودعملاحظة:
يتم وصف نهج مماثل ، ولكن مع الإرسال المتعدد ، في هذه المقالة.