Преди известно време Ви представихме . Настоящата статия първоначално беше замислена като демонстрация на неговия софтуер и система за управление. Но за да обясним логиката на работа на термостата и това, което сме реализирали, е необходимо да представим цялата концепция в цялост.

За автоматизацията
Условно, цялата автоматизация може да бъде разделена на три категории:
Категория 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": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Както виждате от примера, списъкът включва 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": "термостат" // тип на устройството
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "термостат"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "термостат"
},
{
"id": 13587532,
"type": "ключ"
},
{
"id": 98412557,
"type": "димна"
},
{
"id": 57995113,
"type": "сензор за контакт"
},
{
"id": 74123668,
"type": "сензор за температура и влажност"
},
{
"id": 74621883,
"type": "сензор за температура и влажност"
}
От примера е видно, че устройствата се добавят независимо едно от друго. Свързани са 3 термостата с собствени IP адреси и 5 различни сензора с уникални ID. Ако сензорът е свързан към 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
