Наскоро представихме на вас . Настоящата статия първоначално беше замислена като демонстрация на неговия софтуер и система за управление. Но за да се обясни логиката на работа на термостата и какво сме реализирали, е необходимо да се очертае цялата концепция в общи линии.
Относно автоматизацията
Условно, цялата автоматизация може да бъде разделена на три категории:
Категория 1 — отделни "умни" устройства. Вие закупувате от различни производители крушки, електрически чайници и т.н. Плюсове: всяко устройство разширява възможностите и увеличава комфорта. Минуси: за всеки нов производител е необходимо собствено приложение. Протоколите на устройствата от различни производители често не са съвместими помежду си.
Категория 2 — инсталиране на одноплатен компютър или x86-съвместим. Това премахва ограниченията по изчислителната мощ и на тази машина се инсталира MajorDoMo или друг сървърен дистрибутив за управление на умния дом. По този начин устройствата на повечето производители се свързват в единно информационно пространство. Т.е. появява се собствен сървър за умния дом. Плюсове: съвместимост под единен център, което предоставя разширени възможности за управление. Минуси: при повреда на сървъра цялата система се връща в стадий 1, т.е. става разрознена или става безполезна.
Категория 3 — най-хардкорният вариант. На етапа на ремонта се закриват всички комуникации и се дублират всички системи. Плюсове: всичко е доведено до идеал и тогава домът наистина става умен. Минуси: крайна цена в сравнение с категории 1 и 2, необходимост от предварително обмисляне на всичко и отчитане на всяка подробност.
Повечето потребители избират вариант едно, а след това плавно преминават към вариант две. А впоследствие най-упоритите стигат до вариант 3.
Но съществува вариант, който може да бъде наречен разпределена система: всяко отделно устройство ще бъде и сървър, и клиент. Всъщност, това е опит да се вземат и обединят вариант 1 и вариант 2. Да се вземат всички техни плюсове и да се изключат минусите, улавяйки златната среда.
Възможно е някой да каже, че такъв вариант вече е разработен. Но такива решения са насочени към конкретни потребители, запознати с програмирането. Нашата цел е да намалим прага на влизане в подобни разпределени системи както под формата на крайни устройства, така и под формата на интеграция на съществуващи устройства в нашата система. В случая с термостата, потребителят просто сваля стария термостат, инсталира интелигентния такъв и свързва наличните датчици към него. Без никакви допълнителни действия.
Нека да разгледаме интеграцията в нашата система на примера.
Да си представим, че в мрежата имаме 8 модула Sonoff. На някои потребители им е достатъчно управлението през облака Sonoff (категория 1). Някои ще започнат да използват трета страна на фърмуер и плавно ще премине в категория 2. Основната част от третите страни на фърмуерите работят на един и същ принцип: предаване на данни на MQTT сървър. OpenHub, Majordomo или какъвто и да е друг служат на една и съща цел – да обединят разпокъсаните устройства в единно информационно пространство, разположено или в Интернет, или в локалната мрежа. Следователно, наличието на Сервер е задължително. Оттук произтича основният проблем – при отказ на Сервера цялата система спира да работи автономно. За да предотвратим това, системите се усложняват, добавят се ръчни методи за управление, които дублират автоматизацията в случай на отказ на Сервера.
Ние решихме да поемем по друг път, където всеки компонент е самодостатъчен. По този начин, Сървера не играе решаваща роля, а само разширява функционалността.
Нека да се върнем към мисловния експеримент. Отново взимаме същите 8 модула Sonoff и инсталираме фърмуера Lytko в тях. Във всички фърмуери Lytko е реализирана функцията . SSDP – мрежов протокол, базиран на набор от интернет протоколи, служещ за обявяване и откриване на мрежови услуги. Отговорът на запитването може да бъде както стандартен, така и разширен. Включихме в този отговор освен стандартните функции и създаването на списък с устройства в мрежата. По този начин устройствата сами се откриват едно друго, и всяко от тях ще има такъв списък. Примерен списък SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "термостат"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "термостат"
}Както е видно от примера, списъкът включва id на устройствата, ip адрес в мрежата, тип на блока (в нашия случай - термостат на базата на Sonoff). Този списък се обновява веднъж на две минути (този период е достатъчен, за да реагира на динамичните промени в броя на устройствата в мрежата). По този начин проследяваме добавянето, промяната и изключването на устройства без никакви действия от страна на потребителя. Списъкът се изпраща в браузъра или мобилното приложение, а скриптът сам формулира страницата с определен брой блока. Всеки блок отговаря на едно устройство/сензор/контролер. Визуално списъкът изглежда така:
Но ако към esp8266/esp32 са свързани други радио-сензори чрез cc2530 (ZigBee) или nrf24 (MySensors)?
Проекти
На пазара се предлагат различни разпределени системи. Нашата система позволява интеграция с най-популярните.
По-долу са представени проекти, които по един или друг начин се опитват да променят ситуацията с несъвместимостта между различните производители. Например, , или . е свързан с MQTT сървър, така че не подхожда за примера.
Един от вариантите за реализация на MySensors е шлюз, базиран на ESP8266. Останалите примери са на ESP32. В тях може да бъде внедрен нашият принцип на работа за откриване и създаване на списък с устройства.
Нека проведем още един мислен експеримент. Имаме шлюз ZESP32 или SLS Gateway или MySensors. Как можем да ги обединим в единна информационна среда? Към стандартните функции на тези шлюзове ще добавим библиотека на протокола SSDP. При запитване към този контролер по SSDP, той ще добави списък с устройствата, които са свързани към него, към стандартния отговор. На базата на тази информация браузърът ще формулира страницата. В общ вид това ще изглежда така:
Web-интерфейс
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. Това позволява да се минимизират разходите за ресурс в сравнение с GET заявки и да се получава информация динамично при свързване или промяна.
Данните се извличат директно от устройството, на което принадлежи блока, без да минават през сървъра. Така, при отказ на което и да е от устройствата, системата продължава да работи. В уеб интерфейса само няма да се показва липсващото устройство. Но сигнал за загуба, при необходимост, ще дойде под формата на известие в приложението на потребителя.
Първият опит за реализиране на такъв подход беше PWA приложение. Това позволява да се съхранява базата данни с блокове на устройството на потребителя и да се запитват само необходимите данни. Но заради особеностите на структурата, този вариант не е напълно функционален. И единственият изход е нативно приложение за Android и iOS, което сега е в активна разработка. По подразбиране, приложението ще работи само във вътрешната мрежа. При необходимост, може да се преведе на външно управление. Така, когато потребителят напуска локалната мрежа, приложението автоматично се прехвърля на облака.
Външното управление е пълно дублиране на страницата. При активиране на страницата потребителят може да се логне на сървъра и да управлява устройствата през личния си кабинет. По този начин, сървърът разширява функционалността, позволявайки управление на устройствата, докато е извън дома и да не бъде привързан към проброс на портове или статичен IP.
Така описаният вариант е лишен от недостатъците на сървърния подход и предлага редица предимства под формата на гъвкавост при свързването на нови устройства.
За термостата
Нека разгледаме системата за управление на примера на нашия термостат.
Предвидено е:
- Регулиране на температурата на всеки термостат (показва се в отделен блок);
- Настройка на график за работа на термостата (сутрин, ден, вечер, нощ);
- Избор на Wi-Fi мрежа и свързване на устройството към нея;
- Актуализация на устройството "по въздуха";
- Настройка на MQTT;
- Настройка на свързаната мрежа.
В допълнение към управлението чрез уеб интерфейса, предвидихме и класически метод — с натиска на екрана. На борда се намира монитор Nextion NX3224T024 с размер 2.4 инча. Изборът падна върху него заради лесната работа с устройството. Но се разработва собствен монитор на базата на STM32. Неговата функционалност никак не е по-лоша от тази на Nextion, но ще струва по-малко, което ще се отрази положително на крайната цена на устройството.
Както всеки уважаващ себе си екран на термостат, нашият Nextion е способен на:
- установяване на необходимата температура за потребителя (с бутони от дясно);
- включване и изключване на режима на работа по график (бутон Н);
- показване на работата на реле (стрелка отляво);
- има защита от деца (физическите натискания се блокират, докато заключването не бъде отключено);
- показва нивото на WiFi сигнала.
Освен това, с помощта на монитора потребителят може:
- да избере типа инсталиран сензор;
- да управлява функцията за защита от деца;
- да обнови фърмуера.
С клик върху WiFi лентата потребителят получава информация за свързаната мрежа. QR кодът се използва за свързване на устройството с HomeKit фърмуера.
Демо на работа с дисплея:
Разработихме с три свързани термостата.
Ще попитате: “Каква е особеността на вашия термостат?” В момента на пазара има множество термостати с Wi-Fi функция, работа по график и сензорно управление. А ентусиасти написаха модули за взаимодействие с повечето популярни системи за умни домове (Majordomo, HomeAssistant и т.н.).
Нашият термостат е съвместим с такива системи и разполага с всичко изброено по-горе. Но отличителна черта е, че термостатът постоянно се подобрява поради гъвкавостта на системата. С всяко обновление функционалността ще се разширява. Освен стандартния метод за управление на системата (по график), ще добавим адаптивен. Приложението позволява получаване на геолокация на потребителя. Благодарение на това системата ще променя динамично режимите на работа в зависимост от местоположението му. А модула за времето ще се адаптира към метеорологичните условия.
И ма разширяемост. Всеки, който желае, може да замени установения си стандартен термостат с нашия. С минимални усилия. Избрахме 5 от най-популярните датчици на пазара и добавихме тяхната поддръжка. Но дори и при ексклузивни характеристики на датчика, потребителят може да го свърже към нашия термостат. За това е необходимо да се направи калибровка на термостата за работа с конкретния сензор. Инструкции ще предоставим.
При свързване на термостата или което и да е друго устройство, то едновременно се появява навсякъде: и в уеб интерфейса, и в PWA приложението. Добавянето на устройството става автоматично: достатъчно е само да го свържете към Wi-Fi мрежата.
Нашата система не се нуждае от сървър и в случай на отказ не се превръща в тикун. Дори при отказ на един от компонентите системата не преминава в аварийния сценарий. Контролерите, датчиците, устройствата — всеки елемент е и сървър, и клиент, затова е напълно автономен.
За заинтересованите — нашите социални мрежи: , , , , .
Поща: shop@lytko.com
P. S. не призоваваме да се откажете от сървъра. При нас има поддръжка на MQTT сървър и имаме собствено облако. Целта ни е да изведем стабилността и надеждността на системата на качествено ново ниво. За да не е сървърът слабо място, а да допълва функционалността и да прави системата по-удобна.
Източник: habr.com
