Преди време ви представихме Тази статия първоначално е била замислена като демонстрация на фърмуера и системата за управление. Но за да обясним логиката на работа на термостата и какво сме имплементирали, е необходимо да очертаем цялата концепция.
Относно автоматизацията
Обикновено цялата автоматизация може да бъде разделена на три категории:
Категория 1 — отделни интелигентни устройства. Купувате електрически крушки, чайници и др. от различни производители. Плюсове: всяко устройство разширява възможностите и подобрява удобството. Минуси: всеки нов производител изисква собствено приложение. Протоколите на устройствата от различни производители често са несъвместими.
Категория 2 — Инсталиране на едноплатков компютър или x86-съвместима система. Това премахва ограниченията на изчислителната мощност и на тази машина може да се инсталира MajorDoMo или друга сървърна дистрибуция за управление на интелигентен дом. По този начин устройства от повечето производители се свързват в едно информационно пространство, създавайки специален сървър за интелигентен дом. Плюсове: съвместимост под един контролен център, осигуряваща разширени възможности за управление. Минуси: ако сървърът се срине или откаже, цялата система се връща към етап 1, ставайки несвързана или безполезна.
Категория 3 — най-задълбоченият вариант. По време на фазата на ремонт се инсталират всички комунални услуги и се създават резервни копия на всички системи. Плюсове: всичко е доведено до съвършенство и тогава къщата става наистина умна. Минуси: изключително скъпо в сравнение с категории 1 и 2, необходимостта да се обмисли всичко предварително и да се отчете всеки детайл.
Повечето потребители избират вариант едно и след това постепенно преминават към вариант две. А след това най-упоритите преминават към вариант три.
Но има вариант, който може да се нарече разпределена система: всяко отделно устройство би било едновременно сървър и клиент. По същество това е опит да се комбинират варианти 1 и 2, като се вземат всички техни предимства и се елиминират недостатъците им, намирайки златната среда.
Някои биха могли да твърдят, че подобна опция вече е разработена. Подобни решения обаче са тясно специализирани и са предназначени за хора с умения за програмиране. Нашата цел е да намалим бариерата за навлизане в подобни разпределени системи, както под формата на крайни точки, така и чрез интегриране на съществуващи устройства в нашата система. В случай на термостат, потребителят просто премахва стария си термостат, инсталира интелигентен и свързва съществуващите си сензори към него. Не са необходими допълнителни стъпки.
Нека разгледаме интеграцията в нашата система, използвайки пример.
Нека си представим, че имаме 8 Sonoff модула в нашата мрежа. За някои потребители, контролът чрез Sonoff облака (категория 1) ще бъде достатъчен. Други ще използват фърмуер на трети страни и постепенно ще преминат към категория 2. Повечето фърмуер на трети страни работят на същия принцип: предаване на данни към MQTT сървър. OpenHub, Majordomo или всеки друг сървър служат на същата цел – да обединят различни устройства в едно информационно пространство, разположено или в интернет, или в локална мрежа. Следователно, сървърът е от съществено значение. Това води до основния проблем: ако сървърът се повреди, цялата система престава да функционира автономно. За да се предотврати това, системите стават по-сложни, като се добавят методи за ръчно управление, които поддържат автоматизираната система в случай на повреда на сървъра.
Ние предприехме различен подход, при който всяко устройство е самодостатъчно. Следователно, сървърът не играе решаваща роля, а просто разширява функционалността.
Нека се върнем към мисловния експеримент. Нека вземем същите осем Sonoff модула и инсталираме фърмуера на Lytko върху тях. Всички версии на фърмуера на Lytko реализират функцията 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)?
Относно проектите
На пазара се предлагат различни разпределени системи. Нашата система позволява интеграция с най-популярните от тях.
По-долу са дадени някои проекти, които се опитват да подобрят ситуацията с несъвместимостта между различните производители. Например , или . Той е свързан с 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"
}
Примерът показва, че устройствата се добавят независимо. Свързани са три термостата със собствени IP адреси и пет различни сензора с уникални идентификатори. Ако сензорът е свързан към Wi-Fi мрежа, той ще има собствен IP адрес; ако е свързан към шлюз, IP адресът на устройството ще бъде IP адресът на шлюза.
Използваме WebSockets за комуникация с устройства. Това минимизира използването на ресурси в сравнение с GET заявките и ни позволява да извличаме информация динамично при свързване или промяна.
Данните се извличат директно от устройството, към което принадлежи блокът, заобикаляйки сървъра. Това означава, че ако някое устройство се повреди, системата продължава да работи. Уеб интерфейсът просто не показва липсващото устройство. Ако е необходимо обаче, липсващото устройство ще бъде уведомено чрез известие в приложението на потребителя.
Първият опит за прилагане на този подход беше PWA приложение. То позволява съхраняване на база данни с блокове на устройството на потребителя и изискване само на необходимите данни. Поради специфичната структура на приложението обаче, този подход е непълен. Единственото решение е нативно приложение. Android и iOS, която в момента е в активна разработка. По подразбиране приложението ще работи само във вътрешната мрежа. Ако е необходимо, може да се превключи към външно управление. Така че, когато потребителят напусне локалната мрежа, приложението автоматично превключва към облака.
Външното управление е пълно копие на страницата. Когато страницата е активирана, потребителят може да влезе в сървъра и да управлява устройства чрез личния си акаунт. По този начин сървърът разширява функционалността си, позволявайки ви да управлявате устройства, докато сте далеч от дома, без да сте обвързани с пренасочване на портове или специален IP адрес.
По този начин, гореописаният вариант е свободен от недостатъците на сървърния подход, а също така има редица предимства под формата на гъвкавост при свързване на нови устройства.
Относно термостата
Нека разгледаме системата за управление, използвайки нашия термостат като пример.
Предоставено:
- Контрол на температурата на всеки термостат (показва се като отделен блок);
- Настройване на график на термостата (сутрин, ден, вечер, нощ);
- Избор на Wi-Fi мрежа и свързване на устройството към нея;
- Актуализация на устройството по въздух;
- Настройка на MQTT;
- Конфигурирайте мрежата, към която е свързано устройството.
В допълнение към уеб-базираното управление, устройството разполага и с традиционен сензорен интерфейс. Вграден е 2.4-инчов монитор Nextion NX3224T024. Той беше избран поради лесната му употреба. В момента обаче се разработва персонализиран монитор, базиран на STM32. Функционалността му не е по-лоша от тази на Nextion, но ще бъде по-евтин, което ще се отрази положително на крайната цена на устройството.
Като всеки уважаващ себе си термостат, нашият Nextion може:
- задайте желаната от потребителя температура (с помощта на бутоните отдясно);
- включване и изключване на режима на планирана работа (бутон H);
- покажете работата на релето (стрелка вляво);
- има защита за деца (физическото натискане е блокирано, докато ключалката не бъде отстранена);
- Показва силата на WiFi сигнала.
Освен това, използвайки монитора, можете:
- изберете типа сензор, инсталиран от потребителя;
- управлява функцията за закрила на детето;
- актуализирайте фърмуера.
Щракването върху лентата WiFi разкрива информация за свързаната мрежа. QR кодът се използва за сдвояване на устройството с фърмуера HomeKit.
Демонстрация на дисплея:
Ние сме разработили с три свързани термостата.
Може би ще попитате: „Какво е толкова специалното на вашия термостат?“ В момента на пазара се предлагат много термостати с Wi-Fi възможности, опции за планиране и сензорно управление. А ентусиастите са написали модули за взаимодействие с повечето популярни системи за интелигентен дом (Majordomo, HomeAssistant и др.).
Нашият термостат е съвместим с тези системи и предлага всички горепосочени функции. Но отличителната му черта е, че непрекъснато се усъвършенства благодарение на гъвкавостта на системата. С всяка актуализация функционалността ще се разширява. В допълнение към стандартното планирано управление на системата, ще добавим адаптивно управление. Приложението ви позволява да проследявате геолокацията на потребителя, което позволява на системата динамично да променя режимите на работа въз основа на местоположението му. А модулът за времето ще ви позволи да се адаптирате към променящите се метеорологични условия.
И разширяемост. Всеки може да замени съществуващия си термостат с нашия, с минимални усилия. Избрахме петте най-популярни сензора на пазара и добавихме поддръжка за тях. Дори ако даден сензор има уникални характеристики, потребителите все още могат да го свържат към нашия термостат. За да направят това, ще трябва да калибрират термостата, за да работи със специфичния сензор. Ще предоставим инструкции.
Когато свържете термостат или друго устройство, то се появява навсякъде: както в уеб интерфейса, така и в приложението PWA. Добавянето на устройство е автоматично: просто го свържете към вашата Wi-Fi мрежа.
Нашата система не изисква сървър и ако един откаже, тя не се превръща в тиква. Дори ако един компонент се повреди, системата не изпада в сценарий на срив. Контролери, сензори, устройства - всеки елемент е едновременно сървър и клиент, което я прави напълно автономна.
За тези, които се интересуват, ето нашите профили в социалните мрежи: , , , , .
Имейл: shop@lytko.com
PS Не се застъпваме за изоставянето на сървъра. Ние също така поддържаме MQTT сървъра и разполагаме със собствен облак. Нашата цел е да издигнем стабилността и надеждността на системата на съвсем ново ниво. Искаме сървърът да бъде допълваща функция и да подобри използваемостта на системата, а не да бъде пречка.
Източник: www.habr.com
