Некаторы час таму мы прадставілі Вам . Цяперашні артыкул першапачаткова задумвалася як дэманстрацыя яго прашыўкі і сістэмы кіравання. Але для таго, каб растлумачыць логіку працы тэрмастата і тое, што мы рэалізавалі, неабходна абмаляваць усю канцэпцыю ў цэлым.
Пра аўтаматызацыю
Умоўна, усю аўтаматызацыю можна падзяліць на тры катэгорыі:
Катэгорыя 1 - асобныя "разумныя" прылады. Вы набываеце ў розных вытворцаў лямпачкі, чайнікі і г.д. Плюсы: кожная прылада пашырае магчымасці і павялічвае камфорт. Мінусы: для кожнага новага вытворцы неабходна сваё прыкладанне. Пратаколы прылад розных вытворцаў часта не сумяшчальныя паміж сабой.
Катэгорыя 2 - усталёўка аднаплатнага ПК або х86 сумяшчальнага. Гэта здымае абмежаванні па вылічальнай магутнасці, і на дадзеную машыну ўсталёўваецца 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": "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 розных сэнсараў з унікальнымі id. Калі сэнсар падлучаны да Wi-Fi сеткі, то ён будзе мець свой ip, калі падлучаны да шлюза, то ip-адрас прылады будзе з'яўляцца ip-адрасам шлюза.
Для сувязі з прыладамі мы ўжываем WebSocket. Гэта дазваляе мінімізаваць выдаткі рэсурсаў у параўнанні з get-запытамі і атрымліваць інфармацыю дынамічна пры падлучэнні ці змене.
Дадзеныя бяруцца напрамую з той прылады, якому належыць блок, абыходзячы сервер. Такім чынам, пры адмове любога з прылад сістэма працягвае працаваць. На web-інтэрфейсе толькі не адлюстроўваецца зніклае са спісу прылада. Але сігнал аб згубе, пры неабходнасці, прыйдзе ў выглядзе апавяшчэння ў дадатку карыстальніка.
Першай спробай рэалізацыі такога падыходу было PWA-дадатак. Гэта дазваляе захоўваць базу блокаў на прыладзе карыстальніка і запытваць толькі неабходныя дадзеныя. Але з прычыны асаблівасцяў структуры такі варыянт непаўнавартасны. І выхад адзін - натыўнае прыкладанні для Android і IOS, якое цяпер знаходзіцца ў актыўнай распрацоўцы. Па змаўчанні, прыкладанне будзе працаваць толькі ва ўнутранай сетцы. Пры неабходнасці можна перавесці ўсё на знешняе кіраванне. Так, калі карыстач пакідае лакальную сетку, прыкладанне аўтаматычна перамыкаецца на воблака.
Вонкавае кіраванне - поўнае дубляванне старонкі. Пры актывацыі старонкі карыстач можа залагініцца на серверы і кіраваць прыладамі праз асабісты кабінет. Такім чынам, Сервер пашырае функцыянал, дазваляючы кіраваць прыладамі, знаходзячыся за межамі хаты, і не быць прывязаным да пракіду партоў ці вылучанаму ip.
Такім чынам, вышэйапісаны варыянт пазбаўлены недахопаў сервернага падыходу, а таксама мае шэраг пераваг у выглядзе гнуткасці падлучэння новых прылад.
Пра тэрмастат
Разгледзім сістэму кіравання на прыкладзе нашага тэрмастата.
Прадугледжана:
- Рэгуляванне тэмпературы кожнага тэрмастата (адлюстроўваецца ў выглядзе асобнага блока);
- Настройка раскладу работы тэрмастата (раніца, дзень, вечар, ноч);
- Выбар Wi-Fi сеткі і падлучэнні да яе прылады;
- Абнаўленне прылады "па паветры";
- Настройка MQTT;
- Настройка сеткі, да якой падключана прылада.
Акрамя кіравання пасродкам web-інтэрфейсу, прадугледзелі класічнае – націскамі па дысплеі. На борце стаіць манітор Nextion NX3224T024 2.4/32 цалі. Выбар упаў на яго з прычыны прастаты працы з дэвайсам. Але ў распрацоўцы знаходзіцца ўласны манітор на аснове STMXNUMX. Яго функцыянал ані не горш, чым у Nextion, але каштаваць будзе ён танней, што дадатна адаб'ецца на канчатковай цане прылады.
Як і любы які паважае сябе экран тэрмастата, наш Nextion умее:
- выстаўляць неабходную карыстачу тэмпературу (кнопкамі справа);
- уключаць і выключаць рэжым працы па раскладзе (кнопка Н);
- адлюстроўваць працу рэле (стрэлка злева);
- мае абарону ад дзяцей (блакуюцца фізічныя націскі, пакуль замак не зняты);
- адлюстроўвае ўзровень сігналу WiFi.
Акрамя таго, з дапамогай манітора можна:
- абраць тып усталяванага ў карыстача датчыка;
- кіраваць функцыяй абароны ад дзяцей;
- абнавіць прашыўку.
Па зграі на бар WiFi карыстач пазнае інфармацыю аб падлучанай сетцы. QR код выкарыстоўваецца для спалучэння прылады ў прашыўцы HomeKit.
Дэма працы з дысплеем:
Мы распрацавалі з трыма падлучанымі тэрмастатамі.
Вы спытаеце: "У чым асаблівасць вашага тэрмастата?" Цяпер на рынку існуе мноства тэрмастатаў з функцыяй Wi-Fi, працай па раскладзе, сэнсарным кіраваннем. А энтузіясты напісалі модулі для ўзаемадзеяння з большасцю папулярных сістэм разумны дом (Majordomo, HomeAssistant і да т.п.).
Наш тэрмастат сумяшчальны з такімі сістэмамі і валодае ўсім вышэйпералічаным. Але адметная асаблівасць у тым, што тэрмастат увесь час дапрацоўваецца, дзякуючы гнуткасці сістэмы. З кожным абнаўленнем функцыянал будзе пашырацца. Да стандартнага спосабу кіравання сістэмай (па раскладзе), мы дадамо адаптыўны. Прыкладанне дазваляе атрымліваць геолокацию карыстальніка. Дзякуючы гэтаму, сістэма будзе дынамічна мяняць рэжымы працы ў залежнасці ад яго месцазнаходжання. А модуль надвор'я дазволіць падладжвацца да ўмоў надвор'я.
І пашыральнасць. Любы жадаючы зможа замяніць усталяваны ў яго звычайны тэрмастат на наш. З мінімальнымі намаганнямі. Мы выбралі 5 самых папулярных датчыкаў, прадстаўленых на рынку, і дадалі іх падтрымку. Але нават у выпадку эксклюзіўных характарыстык датчыка, карыстач зможа падлучыць яго да нашага тэрмастата. Для гэтага спатрэбіцца вырабіць каліброўку тэрмастата для працы з пэўным сэнсарам. Інструкцыі мы дамо.
Падлучаючы тэрмастат або любая іншая прылада, яно адначасова з'яўляецца ўсюды: і ў web-інтэрфейсе, і ў PWA-прыкладанні. Даданне прылады адбываецца аўтаматычна: дастаткова толькі падлучыць яго да Wi-Fi сеткі.
Наша сістэма не мае патрэбы ў Серверы, і ў выпадку яго адмовы не ператвараецца ў гарбуз. Нават пры адмове аднаго з кампанентаў сістэма не пачынае працаваць па аварыйным сцэнары. Кантролеры, датчыкі, прылады - кожны элемент з'яўляецца і Серверам, і кліентам, таму цалкам аўтаномны.
Для тых, хто зацікавіўся, нашы сацсеткі: , , , , .
пошта: [электронная пошта абаронена]
PS мы не заклікаем адмаўляцца ад Сервера. У нас таксама прысутнічае падтрымка MQTT-сервера і ёсць уласнае воблака. Наша мэта - вывесці стабільнасць і надзейнасць сістэмы на якасна новы ўзровень. Каб Сервер не з'яўляўся слабым месцам, а дапаўняў функцыянал і рабіў сістэму зручнейшай.
Крыніца: habr.com