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

حول الأتمتة
تقليديا ، يمكن تقسيم جميع الأتمتة إلى ثلاث فئات:
الفئة 1 - منفصلة "الذكية" الأجهزة. يمكنك الحصول على المصابيح الكهربائية وأقداح الشاي وغيرها من الشركات المصنعة المختلفة. الإيجابيات: كل جهاز يوسع الفرص ويزيد من الراحة. سلبيات: كل مصنع جديد يحتاج إلى تطبيق خاص به. غالبًا ما تكون بروتوكولات الأجهزة من جهات تصنيع مختلفة غير متوافقة مع بعضها البعض.
الفئة 2 - تثبيت كمبيوتر أحادي اللوحة أو متوافق مع x86. يؤدي ذلك إلى إزالة القيود المفروضة على طاقة الحوسبة ، ويتم تثبيت MajorDoMo أو أي توزيع خادم آخر لإدارة المنزل الذكي على هذا الجهاز. وبالتالي ، يتم توصيل أجهزة معظم الشركات المصنعة في مساحة معلومات واحدة. أي يبدو الخادم الخاص بك للمنزل الذكي. الايجابيات: التوافق تحت مركز واحد ، والذي يوفر قدرات الإدارة المتقدمة. السلبيات: في حالة تعطل / فشل الخادم ، يعود النظام بأكمله إلى المرحلة 1 ، أي تصبح مجزأة ، أو أصبحت عديمة الفائدة.
الفئة 3 هي النسخة الأكثر المتشددين. في مرحلة الإصلاح ، يتم وضع جميع الاتصالات وتكرار جميع الأنظمة. الايجابيات: كل شيء يتم إحضاره إلى المثل الأعلى ومن ثم يصبح المنزل ذكيًا. السلبيات: التكلفة الباهظة بالمقارنة مع الفئتين 1 و 2 ، والحاجة إلى التفكير قبل كل شيء ومراعاة كل شيء صغير.
حدد معظم المستخدمين الخيار الأول ، ثم انتقل إلى الخيار الثاني بسلاسة. وفي المستقبل ، خيار الوصول الأكثر ثباتًا 3.
ولكن هناك خيارًا يمكن تسميته بالنظام الموزع: سيكون كل جهاز فردي خادمًا وعميلًا. في الواقع ، هذه محاولة لاتخاذ الخيار الأول والخيار الثاني والجمع بينهما. خذ جميع إيجابياتهم والقضاء على السلبيات ، وقبض على الأرض الوسطى.
ربما يقول شخص ما أن مثل هذا الخيار قد تم تطويره بالفعل. لكن مثل هذه القرارات مستهدفة بدقة. للناس والدهاء في البرمجة. هدفنا هو خفض عتبة الدخول إلى هذه الأنظمة الموزعة في شكل أجهزة نهائية وفي شكل دمج الأجهزة الحالية في نظامنا. في حالة الترموستات ، يقوم المستخدم ببساطة بإزالة ترموستاته القديم ، ويقوم بتثبيت جهاز ذكي ، ويربط مستشعراته به. دون أي عمل إضافي.
دعنا نفكر في الاندماج في نظامنا باستخدام مثال.
تخيل أن لدينا 8 وحدات Sonoff في شبكتنا. قد يكون لدى بعض المستخدمين سيطرة كافية على سحابة Sonoff (الفئة 1). سيستخدم البعض البرامج الثابتة التابعة لجهات خارجية وينتقلون بسلاسة إلى الفئة 2. ويعمل الجزء الأكبر من البرامج الثابتة الخاصة بجهات أخرى على نفس المبدأ: نقل البيانات إلى خادم MQTT. يخدم OpenHub أو Majordomo أو أي خدمة أخرى الغرض نفسه - دمج الأجهزة المختلفة في مساحة معلومات واحدة موجودة إما على الإنترنت أو على شبكة محلية. لذلك ، فإن وجود خادم إلزامي. من هنا تنشأ المشكلة الرئيسية - عندما يفشل الخادم ، فإن النظام بأكمله يتوقف عن العمل بشكل مستقل. لمنع حدوث ذلك ، تصبح الأنظمة أكثر تعقيدًا ، تتم إضافة طرق التحكم اليدوي التي تؤدي إلى تكرار تلقائي في حالة حدوث فشل في الخادم.
لقد اتخذنا مسارًا مختلفًا ، حيث يكون كل جهاز مكتفًا ذاتيًا. وبالتالي ، فإن الخادم لا يلعب دورًا حاسمًا ، بل يوسع الوظيفة فقط.
العودة إلى تجربة التفكير. مرة أخرى ، خذ نفس الوحدات 8 Sonoff وتثبيت البرامج الثابتة Lytko فيها. في جميع البرامج الثابتة Lytko ، يتم تنفيذ وظيفة
SSDP . SSDP هو بروتوكول شبكة يستند إلى مجموعة من بروتوكولات الإنترنت المستخدمة للإعلان عن خدمات الشبكة واكتشافها. يمكن أن تكون الاستجابة للطلب إما قياسية أو متقدمة. بالإضافة إلى الوظائف القياسية ، قمنا بتضمين هذه الإجابة إنشاء قائمة بالأجهزة على الشبكة. وهكذا ، تجد الأجهزة نفسها بعضها البعض ، وسيكون لكل منها قائمة من هذا القبيل. مثال ورقة SSDP:
"ssdpList": { "id": 94967291, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967282, "ip": "192.168.xx", "type": "thermostat" }
كما ترى من المثال ، تتضمن القائمة معرف الجهاز وعنوان IP للشبكة ونوع البلوك (في حالتنا ، ترموستات قائم على Sonoff). يتم تحديث هذه القائمة مرة واحدة كل دقيقتين (هذه الفترة الزمنية كافية للاستجابة للتغيير الديناميكي في عدد الأجهزة على الشبكة). وبالتالي ، فإننا نتتبع إضافة وتعديل وقطع الأجهزة دون أي إجراء من قبل المستخدم. يتم إرسال هذه القائمة إلى متصفح أو تطبيق جوال ، ويشكل البرنامج النصي نفسه صفحة تحتوي على عدد معين من الكتل. كل كتلة يتوافق مع جهاز واحد / استشعار / تحكم. بصريا ، تبدو القائمة كما يلي:

ولكن إذا كانت أجهزة استشعار الراديو الأخرى متصلة بـ esp8266 / esp32 عبر cc2530 (ZigBee) أو nrf24 (MySensors)؟
عن المشاريع
هناك العديد من النظم الموزعة في السوق. نظامنا يسمح لك بالاندماج مع الأكثر شعبية.
فيما يلي المشاريع التي تحاول بطريقة ما تغيير الموقف مع عدم توافق مختلف الشركات المصنعة فيما بينها. هذا ، على سبيل المثال ،
بوابة SLS ،
MySensors أو
ZESP32 . يرتبط ZigBee2MQTT بخادم MQTT ، لذلك فهو غير مناسب على سبيل المثال.
خيار واحد لتطبيق MySensors هو بوابة قائمة على ESP8266. توجد أمثلة أخرى على ESP32. وفيها يمكنك تطبيق مبدأ اكتشاف وإنشاء قائمة من الأجهزة.
دعونا نفعل تجربة فكرية أخرى. لدينا بوابة ZESP32 أو SLS Gateway ، أو MySensors. كيف يمكن دمجها في مساحة معلومات واحدة؟ سنضيف مكتبة بروتوكول SSDP إلى الوظائف القياسية لهذه العبارات. عند الوصول إلى وحدة التحكم هذه عبر SSDP ، ستضيف إلى الإجابة القياسية قائمة بالأجهزة المتصلة بها. بناءً على هذه المعلومات ، سيقوم المستعرض بتكوين صفحة. بعبارات عامة ، سيبدو كما يلي:
واجهة الويب
تطبيق PWA "ssdpList": { "id": 94967291, // "ip": "192.168.xx", // ip "type": "thermostat" // }, { "id": 94967292, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967293, "ip": "192.168.xx", "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 مخصص.
وبالتالي ، فإن الخيار أعلاه خالٍ من عيوب نهج الخادم ، ولديه أيضًا العديد من المزايا في شكل مرونة توصيل الأجهزة الجديدة.
حول الحرارة
النظر في نظام التحكم باستخدام الحرارة لدينا كمثال.
مقدمة من:
- التحكم في درجة الحرارة من كل ترموستات (عرض كوحدة منفصلة) ؛
- تحديد جدول منظم الحرارة (الصباح ، اليوم ، المساء ، الليل) ؛
- اختيار شبكة Wi-Fi وتوصيل جهاز بها ؛
- تحديث الجهاز "على الهواء" ؛
- تكوين MQTT.
- قم بتكوين الشبكة التي يتصل بها الجهاز.

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

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

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

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

قمنا بتطوير
صفحة تجريبية مع ثلاثة الحرارة المتصلة.
أنت تسأل: "ما هي خصوصية ترموستاتك؟" الآن هناك العديد من منظمات الحرارة في السوق مع وظيفة Wi-Fi ، العمل المجدول ، التحكم باللمس. وقد كتب المتحمسون وحدات للتفاعل مع أنظمة المنزل الذكي الأكثر شعبية (Majordomo ، HomeAssistant ، إلخ).
ترموستات لدينا متوافق مع مثل هذه الأنظمة ويحتوي على كل ما سبق. لكن الميزة المميزة هي أن ترموستات يتم تحسينه باستمرار ، بفضل مرونة النظام. مع كل تحديث ، سيتم توسيع الوظيفة. بالنسبة للطريقة القياسية لإدارة النظام (وفقًا للجدول الزمني) ، سنضيف طريقة تكيفية. يسمح لك التطبيق بالحصول على الموقع الجغرافي للمستخدم. نتيجة لهذا ، سيغير النظام أوضاع التشغيل ديناميكيًا حسب موقعه. وسوف تسمح لك وحدة الطقس بالتكيف مع الظروف الجوية.
والتمدد. يمكن لأي شخص استبدال ترموستات المعتاد المثبتة معه لدينا. مع الحد الأدنى من الجهد. اخترنا أكثر 5 أجهزة استشعار شعبية في السوق وأضفنا دعمهم. ولكن حتى في حالة خصائص المستشعر الحصري ، سيتمكن المستخدم من توصيله إلى منظم الحرارة. للقيام بذلك ، تحتاج إلى معايرة الترموستات للعمل مع جهاز استشعار معين. سوف نقدم التعليمات.
عند توصيل جهاز ترموستات أو أي جهاز آخر ، يظهر في نفس الوقت في كل مكان: سواء في واجهة الويب أو في تطبيق PWA. تتم إضافة جهاز تلقائيًا: ما عليك سوى توصيله بشبكة Wi-Fi.
لا يحتاج نظامنا إلى خادم ، وفي حالة الفشل فإنه لا يتحول إلى قرع. حتى في حالة فشل أحد المكونات ، لا يبدأ النظام وفقًا لسيناريو الطوارئ. أجهزة التحكم ، وأجهزة الاستشعار ، والأجهزة - كل عنصر هو خادم وعميل ، وبالتالي فهو مستقل تمامًا.
للمهتمين ، شبكاتنا الاجتماعية:
Telegram و
Instagram و
Telegram News و
VK و
Facebook .
البريد الإلكتروني: shop@lytko.com
PS نحن لا نحث على التخلي عن الخادم. لدينا أيضًا دعم لخادم MQTT ولدينا سحابة خاصة بنا. هدفنا هو تحقيق الاستقرار وموثوقية النظام إلى مستوى جديد كليا. بحيث لا يعد الخادم نقطة ضعف ، ولكنه يكمل الوظيفة ويجعل النظام أكثر ملاءمة.