ليتكو ​​يوحد

منذ بعض الوقت قدمنا ​​لك ترموستات ذكي. كان المقصود من هذه المقالة في الأصل أن تكون عرضًا للبرامج الثابتة ونظام التحكم الخاص بها. ولكن من أجل شرح منطق منظم الحرارة وما قمنا بتنفيذه، من الضروري تحديد المفهوم بأكمله ككل.

حول الأتمتة

تقليديا، يمكن تقسيم جميع الأتمتة إلى ثلاث فئات:
الفئة 1 - أجهزة "ذكية" منفصلة. يمكنك شراء المصابيح الكهربائية وأباريق الشاي وما إلى ذلك من شركات مصنعة مختلفة. الإيجابيات: يعمل كل جهاز على توسيع القدرات وزيادة الراحة. السلبيات: كل مصنع جديد يتطلب تطبيقه الخاص. غالبًا ما تكون بروتوكولات الأجهزة من مختلف الشركات المصنعة غير متوافقة مع بعضها البعض.

الفئة 2 - تركيب جهاز كمبيوتر أحادي اللوحة أو متوافق مع x86. يؤدي هذا إلى إزالة القيود المفروضة على قوة الحوسبة، ويتم تثبيت MajorDoMo أو أي توزيعة خادم أخرى لإدارة المنزل الذكي على هذا الجهاز. وبالتالي، يتم توصيل الأجهزة من معظم الشركات المصنعة في مساحة معلومات واحدة. أولئك. يظهر الخادم الخاص بك للمنزل الذكي. الإيجابيات: التوافق في مركز واحد، مما يوفر إمكانات إدارية محسنة. السلبيات: إذا فشل الخادم، يعود النظام بأكمله إلى المرحلة 1، أي. تصبح مجزأة أو تصبح عديمة الفائدة.

الفئة 3 - الخيار الأكثر المتشددين. في مرحلة الإصلاح، يتم وضع جميع الاتصالات وتكرار جميع الأنظمة. الإيجابيات: كل شيء يصل إلى الكمال ومن ثم يصبح المنزل ذكيًا حقًا. العيوب: مكلفة للغاية مقارنة بالفئتين 1 و 2، والحاجة إلى التفكير في كل شيء مقدمًا ومراعاة كل التفاصيل الصغيرة.

يختار معظم المستخدمين الخيار الأول ثم ينتقلون بسلاسة إلى الخيار الثاني. وبعد ذلك يصل الأكثر ثباتًا إلى الخيار 3.

ولكن هناك خيار يمكن تسميته بالنظام الموزع: سيكون كل جهاز على حدة خادمًا وعميلًا. في الأساس، هذه محاولة لأخذ الخيار 1 والخيار 2 والجمع بينهما. خذ كل إيجابياتهم وتخلص من السلبيات، للوصول إلى الوسط الذهبي.

ربما سيقول شخص ما أن مثل هذا الخيار قد تم تطويره بالفعل. لكن مثل هذه القرارات تكون ذات تركيز ضيق؛ للأشخاص الأذكياء في البرمجة. هدفنا هو تقليل حاجز الدخول إلى مثل هذه الأنظمة الموزعة، سواء في شكل أجهزة نهائية أو في شكل دمج الأجهزة الموجودة في نظامنا. في حالة منظم الحرارة، يقوم المستخدم ببساطة بإزالة منظم الحرارة القديم الخاص به، وتثبيت جهاز ذكي، وتوصيل أجهزة الاستشعار الموجودة به. دون أي خطوات إضافية.

دعونا نلقي نظرة على التكامل في نظامنا باستخدام مثال.

لنتخيل أن لدينا 8 وحدات Sonoff على شبكتنا. بالنسبة لبعض المستخدمين، سيكون التحكم عبر سحابة Sonoff (الفئة 1) كافيًا. سيبدأ البعض في استخدام البرامج الثابتة التابعة لجهات خارجية وسينتقلون بسلاسة إلى الفئة 2. يعمل الجزء الأكبر من البرامج الثابتة التابعة لجهات خارجية على نفس المبدأ: نقل البيانات إلى خادم MQTT. يخدم OpenHub أو Majordomo أو أي شيء آخر غرضًا واحدًا - وهو توحيد الأجهزة المتباينة في مساحة معلومات واحدة موجودة إما على الإنترنت أو على شبكة محلية. ولذلك، فإن وجود الخادم إلزامي. هذا هو المكان الذي تنشأ فيه المشكلة الرئيسية - في حالة فشل الخادم، يتوقف النظام بأكمله عن العمل بشكل مستقل. ولمنع ذلك، تصبح الأنظمة أكثر تعقيدًا، ويتم إضافة طرق التحكم اليدوية التي تكرر الأتمتة في حالة فشل الخادم.

لقد سلكنا طريقًا مختلفًا، حيث يتمتع كل جهاز بالاكتفاء الذاتي. وبالتالي، لا يلعب الخادم دورًا حاسمًا، ولكنه يعمل فقط على توسيع الوظيفة.

دعنا نعود إلى التجربة الفكرية. لنأخذ نفس وحدات Sonoff الثمانية نفسها مرة أخرى ونثبت البرامج الثابتة Lytko فيها. جميع البرامج الثابتة Lytko لديها الوظيفة SSDP. SSDP هو بروتوكول شبكة يعتمد على مجموعة بروتوكولات الإنترنت للإعلان واكتشاف خدمات الشبكة. يمكن أن تكون الاستجابة للطلب قياسية أو موسعة. بالإضافة إلى الوظائف القياسية، أدرجنا في هذه الإجابة إنشاء قائمة بالأجهزة الموجودة على الشبكة. وبالتالي، فإن الأجهزة نفسها تجد بعضها البعض، وسيكون لكل منها مثل هذه القائمة. مثال على ورقة SSDP:

"ssdpList": 
	{
		"id": 94967291,  
		"ip": "192.168.x.x",
                "type": "thermostat"
	}, 
	{
		"id": 94967282,
		"ip": "192.168.x.x",
                "type": "thermostat"
	}

كما ترون من المثال، تتضمن القائمة معرفات الأجهزة، وعنوان IP على الشبكة، ونوع الوحدة (في حالتنا، منظم الحرارة المستند إلى Sonoff). يتم تحديث هذه القائمة مرة كل دقيقتين (هذه الفترة كافية للاستجابة للتغيرات الديناميكية في عدد الأجهزة الموجودة على الشبكة). بهذه الطريقة، نتتبع الأجهزة المضافة، والمتغيرة، والمعطلة دون أي إجراء من جانب المستخدم. يتم إرسال هذه القائمة إلى المتصفح أو تطبيق الهاتف المحمول، ويقوم البرنامج النصي نفسه بإنشاء صفحة تحتوي على عدد معين من الكتل. تتوافق كل كتلة مع جهاز/مستشعر/وحدة تحكم واحدة. بصريا تبدو القائمة كما يلي:

ولكن ماذا لو كانت أجهزة استشعار الراديو الأخرى متصلة بـ esp8266/esp32 عبر cc2530 (ZigBee) أو nrf24 (MySensors)؟

حول المشاريع

هناك أنظمة موزعة مختلفة في السوق. يتيح لك نظامنا التكامل مع الأنظمة الأكثر شيوعًا.

فيما يلي المشاريع التي تحاول بطريقة أو بأخرى تغيير الوضع مع عدم توافق الشركات المصنعة المختلفة مع بعضها البعض. هذا، على سبيل المثال، بوابة SLS, MySensors أو زيسب32. زيجبي2MQTT مرتبط بخادم MQTT، لذا فهو غير مناسب للمثال.

أحد الخيارات لتطبيق MySensors هو بوابة تعتمد على ESP8266. باقي الأمثلة موجودة على ESP32. وفيها يمكنك تنفيذ مبدأ التشغيل الخاص بنا المتمثل في اكتشاف قائمة الأجهزة وإنشاءها.

دعونا نقوم بتجربة فكرية أخرى. لدينا بوابة ZESP32 أو بوابة SLS أو MySensors. وكيف يمكن دمجهما في مساحة معلوماتية واحدة؟ سنضيف مكتبة بروتوكول SSDP إلى الوظائف القياسية لهذه البوابات. عند الوصول إلى وحدة التحكم هذه عبر SSDP، ستضيف قائمة بالأجهزة المتصلة بها إلى الاستجابة القياسية. وبناءً على هذه المعلومات، سيقوم المتصفح بإنشاء صفحة. بشكل عام سيبدو مثل هذا:

واجهة ويب

تطبيق PWA

"ssdpList": 
{
   "id": 94967291, // уникальный идентификатор устройства
   "ip": "192.168.x.x", // ip адрес в сети
   "type": "thermostat" // тип устройства
},
{
   "id": 94967292,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{
   "id": 94967293,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{  
   "id": 13587532, 
   "type": "switch"  
},
{  
   "id": 98412557, 
   "type": "smoke"
},
{  
   "id": 57995113, 
   "type": "contact_sensor"
},
{  
   "id": 74123668,
   "type": "temperature_humidity_pressure_sensor"
},
{
    "id": 74621883, 
    "type": "temperature_humidity_sensor"
}

يوضح المثال أن الأجهزة تتم إضافتها بشكل مستقل عن بعضها البعض. يتم توصيل 3 منظمات حرارة بعناوين IP الخاصة بها و5 أجهزة استشعار مختلفة بمعرفات فريدة. إذا كان المستشعر متصلاً بشبكة Wi-Fi، فسيكون له عنوان IP خاص به؛ وإذا كان متصلاً ببوابة، فسيكون عنوان IP الخاص بالجهاز هو عنوان IP الخاص بالبوابة.

نستخدم WebSocket للتواصل مع الأجهزة. يتيح لك ذلك تقليل تكاليف الموارد مقارنةً بالحصول على الطلبات والحصول على المعلومات ديناميكيًا عند الاتصال أو التغيير.

يتم أخذ البيانات مباشرة من الجهاز الذي تنتمي إليه الكتلة، متجاوزًا الخادم. وبالتالي، في حالة فشل أي من الأجهزة، يستمر النظام في العمل. لا تعرض واجهة الويب الجهاز المفقود من القائمة. ولكن إشارة الخسارة، إذا لزم الأمر، سوف تأتي في شكل إشعار في تطبيق المستخدم.

كانت المحاولة الأولى لتنفيذ هذا النهج هي تطبيق PWA. يتيح لك ذلك تخزين قاعدة كتلة على جهاز المستخدم وطلب البيانات الضرورية فقط. ولكن نظرا لخصائص الهيكل، فإن هذا الخيار غير مكتمل. والطريقة الوحيدة للخروج هي تطبيق أصلي لنظامي Android وIOS، وهو قيد التطوير النشط حاليًا. بشكل افتراضي، سيعمل التطبيق فقط على الشبكة الداخلية. إذا لزم الأمر، يمكنك نقل كل شيء إلى التحكم الخارجي. لذلك، عندما يغادر المستخدم الشبكة المحلية، يتحول التطبيق تلقائيًا إلى السحابة.

التحكم الخارجي - الازدواجية الكاملة للصفحة. عند تفعيل الصفحة، يمكن للمستخدم تسجيل الدخول إلى الخادم وإدارة الأجهزة من خلال حسابه الشخصي. وبالتالي، يقوم الخادم بتوسيع وظائفه، مما يسمح لك بإدارة الأجهزة أثناء تواجدك خارج المنزل، وعدم ربطه بإعادة توجيه المنفذ أو عنوان IP مخصص.

وبالتالي، فإن الخيار أعلاه ليس له عيوب نهج الخادم، وله أيضًا عدد من المزايا في شكل مرونة في توصيل الأجهزة الجديدة.

حول منظم الحرارة

دعونا نلقي نظرة على نظام التحكم باستخدام منظم الحرارة الخاص بنا كمثال.

متاح:

1. التحكم في درجة الحرارة لكل منظم حرارة (يتم عرضه ككتلة منفصلة)؛
2. ضبط جدول تشغيل الترموستات (الصباح، بعد الظهر، المساء، الليل)؛
3. تحديد شبكة Wi-Fi وتوصيل الجهاز بها؛
4. تحديث الجهاز "عبر الأثير"؛
5. إعداد MQTT؛
6. قم بتكوين الشبكة التي يتصل بها الجهاز.

بالإضافة إلى التحكم عبر واجهة الويب، قمنا بتوفير الواجهة الكلاسيكية - من خلال النقر على الشاشة. توجد شاشة Nextion NX3224T024 مقاس 2.4 بوصة على اللوحة. وقع الاختيار عليه لسهولة العمل مع الجهاز. لكننا نعمل على تطوير شاشتنا الخاصة استنادًا إلى STM32. وظيفتها ليست أسوأ من وظيفة Nextion، لكنها ستكون أقل تكلفة، مما سيكون له تأثير إيجابي على السعر النهائي للجهاز.

مثل أي شاشة ترموستات تحترم نفسها، يمكن لـ Nextion لدينا:

• ضبط درجة الحرارة المطلوبة من قبل المستخدم (باستخدام الأزرار الموجودة على اليمين)؛
• تشغيل وإيقاف وضع التشغيل المجدول (الزر H)؛
• عرض عملية التتابع (السهم على اليسار)؛
• لديه حماية للأطفال (يتم حظر النقرات المادية حتى تتم إزالة القفل)؛
• يعرض قوة إشارة WiFi.

بالإضافة إلى ذلك، باستخدام الشاشة يمكنك:

• حدد نوع المستشعر الذي قام المستخدم بتثبيته؛
• إدارة ميزة قفل الطفل.
• تحديث البرامج الثابتة.

من خلال النقر على شريط WiFi، سيكتشف المستخدم معلومات حول الشبكة المتصلة. يتم استخدام رمز الاستجابة السريعة لإقران الجهاز في البرنامج الثابت HomeKit.

عرض توضيحي للعمل مع الشاشة:

لقد تطورنا الصفحة التجريبية مع ثلاثة منظمات حرارة متصلة.

قد تتساءل: "ما الذي يميز منظم الحرارة لديك؟" يوجد الآن في السوق العديد من منظمات الحرارة المزودة بوظيفة Wi-Fi والتشغيل المجدول والتحكم باللمس. وقد كتب المتحمسون وحدات للتفاعل مع أنظمة المنزل الذكي الأكثر شيوعًا (Majordomo، HomeAssistant، وما إلى ذلك).

منظم الحرارة الخاص بنا متوافق مع هذه الأنظمة ويحتوي على كل ما سبق. لكن الميزة المميزة هي أن منظم الحرارة يتم تحسينه باستمرار، وذلك بفضل مرونة النظام. مع كل تحديث سيتم توسيع الوظيفة. إلى الطريقة القياسية لإدارة النظام (وفقًا لجدول زمني)، سنضيف طريقة تكيفية. يتيح لك التطبيق الحصول على الموقع الجغرافي للمستخدم. بفضل هذا، سيقوم النظام بتغيير أوضاع التشغيل ديناميكيًا اعتمادًا على موقعه. وستسمح لك وحدة الطقس بالتكيف مع الظروف الجوية.

وقابلية التوسع. يمكن لأي شخص استبدال منظم الحرارة التقليدي الموجود لديه بمنظم الحرارة الخاص بنا. بأقل جهد. لقد اخترنا 5 من أجهزة الاستشعار الأكثر شيوعًا في السوق وأضفنا الدعم لها. ولكن حتى لو كان المستشعر يتمتع بخصائص حصرية، فسيتمكن المستخدم من توصيله بمنظم الحرارة الخاص بنا. للقيام بذلك، سوف تحتاج إلى معايرة منظم الحرارة للعمل مع جهاز استشعار معين. سوف نقدم التعليمات.

عند توصيل منظم الحرارة أو أي جهاز آخر، يظهر في نفس الوقت في كل مكان: سواء في واجهة الويب أو في تطبيق PWA. تتم إضافة جهاز تلقائيًا: ما عليك سوى توصيله بشبكة Wi-Fi.

نظامنا لا يحتاج إلى خادم، وإذا فشل لا يتحول إلى يقطينة. حتى في حالة فشل أحد المكونات، لا يبدأ النظام في العمل في سيناريو الطوارئ. وحدات التحكم وأجهزة الاستشعار والأجهزة - كل عنصر هو خادم وعميل في نفس الوقت، وبالتالي فهو مستقل تمامًا.

للمهتمين، شبكاتنا الاجتماعية: تیلیجرام, إنستغرام, أخبار تيليجرام, VK, فيسبوك.

البريد الإلكتروني: [البريد الإلكتروني محمي]

PS نحن لا نشجعك على التخلي عن الخادم. نحن ندعم أيضًا خادم MQTT ولدينا سحابة خاصة بنا. هدفنا هو الارتقاء باستقرار وموثوقية النظام إلى مستوى جديد تمامًا. بحيث لا يكون الخادم نقطة ضعف، بل يكمل الوظيفة ويجعل النظام أكثر ملاءمة.

المصدر: www.habr.com