ليتكو ​​يوحد

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

حول الأتمتة

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

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

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

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

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

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

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

لنتخيل أن لدينا 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. زيجبي 2 ام كيو تي تي مرتبط بخادم 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، سيتمكن المستخدم من معرفة معلومات حول الشبكة المتصلة. يتم استخدام رمز الاستجابة السريعة QR لإقران الجهاز في البرامج الثابتة HomeKit.

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

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

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

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

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

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

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

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

البريد الإلكتروني: shop@lytko.com

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

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