مرحبا
كما كتبت مؤخرًا (
المقالة القصيرة الأولى حول MQTT / UDP ) ، MQTT / UDP هو بروتوكول قائم على MQTT ، ولكن:
- يتصدر بث UDP (لا حاجة إلى وسيط ، لا حاجة إلى التكوين تقريبًا)
- التنفيذ سهل للغاية (10 خطوط على حزمة C + UDP / IP - ويمكنك إرسال البيانات من المستشعر)
- الجميع يسمع الجميع
بطريقة ما ، يمكن أن يكون ذلك ، ولكن أعلى Ethernet.
لماذا
لقد كانت شقتي تعيش فعليًا لعدة سنوات تحت سيطرة نظام مثل "المنزل ليس قهريًا حقًا". سيكون من الضروري أن نسميها ذكاء ، لكن الضوء والمناخ آليان. لتخيل حجم الكارثة - يحتل النظام رفًا مكتظًا بالكامل يبلغ عرضه 19 بوصة وارتفاعه مترين. هناك جداران للحامل مشغولان على الأرض تقريبًا.
عندما صممت كل هذا ، جاءت قضية التسامح مع الخطأ أولاً. لقد أظهرت عدة سنوات من التشغيل: هذا صحيح. ينكر كل شيء. عاجلا أم آجلا. لكن المرحلات الكهروميكانيكية لم تفشل بعد ، وهي تمثل آخر مستوى من الحماية ضد الفشل.
المشكلة التالية بعد التسامح مع الخطأ هي حديقة الحيوان. نظرًا لطبيعة الحياة الطبيعية ، فضولي واحتياجاتي الملحة ، و Unix المعتادة على جهاز كمبيوتر عادي ، Aries PLC ، Raspberr + Orange PI ، وحدات Atmega ، الوحدات النمطية المستندة إلى NodeMCU (ESP8266) ، تعيش في النظام ، وهذا كله يذهب إلى بعضها البعض عبر modbus 485 و modbus TCP و http وعلى الجانب يعلقان وسيط MQTT لا يهدأ ، كإرث من محاولة فاشلة للتبديل إليها باستخدام معسكر كامل.
لماذا محاولة التبديل إلى MQTT غير ناجحة. أولاً ، بالنسبة لجزء من الحديد فهو ثقيل أو معقد. على جزء Pascal الذي يختبئ في CodeSys PLC ، لا يُمكن إلا لمازوشي أن يكتب MQTT. ولكن بعد ذلك تحتاج إلى تصحيح. وبالمثل على atmega: يمكنك حشر ، ولكن عن كثب. لكن هذه ليست المشكلة كلها.
تصر MQTT كما هي (وهي مقبولة في كل مكان 3.1.1) على إرسال حزمة PUBLISH (أي رسالتنا إلى الوسيط) إلى جميع المستلمين ، بما في ذلك المرسل. تأثير هذا الجنون هو السحر - نفس OpenHAB لا يمكن إرسال واستقبال البيانات في MQTT تحت نفس الاسم. هذا يعني أنه من المستحيل تنظيم ناقل يعتمد على MQTT (عدة وحدات تقوم بتحديث قيمة نفس الكائن واستخدامه). وهذه هي بالضبط الطريقة التي ينبغي بها تنظيم اتصالات PLC ، حيث يعيش التحكم الرئيسي في الإضاءة ، OpenHAB ، الذي يتحكم في الإضاءة من واجهة الويب وتطبيقات الهاتف المحمول ، والمفاتيح الذكية ، التي أود إضافتها هنا وهنا. هذا ، بالطبع ، يمكن التحايل على هذه المشكلة ، ولكن في الواقع ، فهذا يعني بناء بروتوكول خاص بك SURFACE MQTT ، ويبدو أن هذا بالفعل كثير للغاية.
في نفس الوقت ، ماذا أحتاج؟ إرسال تحديث قيمة المعلمة والحصول عليها في جميع النقاط المهتمة. لماذا ، في الواقع ، فعل الأجداد UDP إلى عنوان البث.
بعد آخر مشاركة على Habré أحد القراء لفترة طويلة وبخ لي مع عدم موثوقية بروتوكول UDP. أجبته بشكل مضاربه أنه بالنسبة لإنترنت الأشياء ، فإن UDP موثوق بها أكثر من TCP: مع فقدان 50٪ من الحزمة على الشبكة ، لن يستلقي TCP فقط ، ولكن بشكل عام ، وفقد قياسات استشعار درجة الحرارة التي ترسل عبر UDP ستفقد نصف العدد ، مما سيؤثر على تشغيل النظام بأي شكل من الأشكال. عموما.
لكنها كانت مضاربة. ومع ذلك ، تم منح إجازات رأس السنة الجديدة لشخص من أجل إنهاء شرب الشمبانيا ليسأل نفسه: هل سنضع شبكتنا المحلية على المجارف اليوم؟ وبغض النظر عما.
أخذت MQTT / UDP وكتبت اختبار بدائي. يرسل أحد الجانبين الحزم المتتالية دون توقف بين الحزم قدر الإمكان. والثاني يعتبر السرعة وفقدان الحزمة. كانت التجربة بسيطة: أطلقنا هذا السخرية ، وفي موازاة ذلك ، يعرض جهازي تلفزيون HD أفلامًا من الإنترنت ، ويقوم كمبيوتر سطح المكتب بكتابة ملف ضخم إلى NAS.
تقييم النتيجة. انتظرت كل شيء ، لكن ... وصلت الخسارة القصوى لـ UDP إلى نصف بالمائة ، وتوقف كلا التلفزيونين عن العرض. لذلك كنت لا زلت متشائما. في شبكة منزلية حقيقية ، تكون موثوقية تسليم UDP قريبة من المطلقة. ومع ذلك ، من المحتمل أن أقوم بإنشاء إصدار بتأكيدات وإعادة إرسال الحزم. هناك القليل من الصعوبات ، ولكن تمت إزالة السؤال بالكامل.
السؤال الثاني هو الأمن ، لكن إذا اقتحموا شبكتي المنزلية ، فإن فقدان البيانات من أجهزة استشعار درجة الحرارة هو آخر شيء سأحزن عليه. ومع ذلك ، مرة أخرى ، تكون مهمة توقيع الحزم رقمياً في تعقب المشكلة موجودة ، وأنا أفهم بالفعل كيفية توسيع حزم MQTT لتنفيذه.
بشكل عام ، أخطط لأول زوج من الأجهزة في الشبكة المنزلية للتبديل إلى MQTT / UDP في اليوم الآخر فقط.
أقترح عليك تجربتها في البرامج والأجهزة الخاصة بك:
المستودع والوثائق باللغة الإنجليزية .
ما هو متاح:
تطبيقات كاملة جميلة في Java و Python و C. التنفيذ الأساسي على لوا. حتى الآن ، فقط إرسال ل Arduino و CodeSys PLC (اختبارها ويعمل على الحمل ، ولكن ينبغي أن تفعل أي شيء).
أداة واجهة المستخدم الرسومية للنظر في ما يحدث والتدخل:
برامج لإرسال واستقبال البيانات في بيثون ولوا وجافا.
موصلات بيثون للتكامل مع MQTT العادية ومباشرة مع OpenHAB. إنها تعمل على حماية ضد الدورات ، وتمنع البث العكسي للرسالة لمدة 5 ثوان بعد المرور في الاتجاه الأمامي. بالإضافة إلى ذلك ، هناك مكتبة للحد من تدفق البيانات المتكررة. تقوم بالتحقق مما إذا كان هناك بالفعل تحديث لهذا الموضوع للوقت المحدد ، وإذا فعلت ذلك ، فإنها تتخطى التحديث الجديد فقط إذا تغيرت البيانات.
أخطط للانتقال تدريجياً إلى هذا البروتوكول تمامًا ، وفيما يلي مثال على ما أريد الحصول عليه باستخدام المستشعرات:
هناك ثلاثة أجهزة استشعار في غرفة واحدة (جيدًا ، أو في الشارع ، لا يهم). يرسلون عينات من خلال MQTT / UDP. يتم تلقي هذه القراءات في وقت واحد عن طريق نظام المنزل الذكي الرئيسي (OpenHAB) ، وقاعدة بيانات تاريخية وشاشة حائط تعرض درجة حرارة السكان.
إن سحر MQTT / UDP كله هو أنه في مثل هذا المخطط ، فإن فشل أي كتلة لا يخلق أي مشاكل لأي شخص آخر. وهذا مع بساطة ساحرة للبروتوكول.
علاوة على ذلك ، يتم بسهولة تنفيذ مخططات التحكم الزائدة مع الازدواجية في نفس المخطط. يمكن تكرار خادم قاعدة البيانات دون أي مشاكل على الإطلاق. سيكون من الصعب تكرار الوحدات التي تتعامل مع الإدارة. على سبيل المثال ، الاستماع إلى درجة الحرارة يعطي إجراء تحكم على المشعات. ولكن ربما هذه هي القصة التالية. أخطط اليوم للتركيز على جمع إشارات من أجهزة الاستشعار والتبادل بين وحدات المنزل الذكي.