{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko \u0142\u0105czy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jaki\u015b czas temu przedstawili\u015bmy Ci inteligentny termostat<\/a><\/noindex>. Dzisiejszy artyku\u0142 pocz\u0105tkowo mia\u0142 by\u0107 demonstracj\u0105 jego oprogramowania i systemu zarz\u0105dzania. Aby jednak wyja\u015bni\u0107 logik\u0119 dzia\u0142ania termostatu oraz to, co wdro\u017cyli\u015bmy, konieczne jest przedstawienie ca\u0142ej koncepcji w ca\u0142o\u015bci.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

O automatyzacji<\/h3>\n

\nZasadniczo, ca\u0142\u0105 automatyzacj\u0119 mo\u017cna podzieli\u0107 na trzy kategorie:
\nKategoria 1<\/u> \u2014 oddzielne \u201einteligentne\u201d urz\u0105dzenia. Kupujesz od r\u00f3\u017cnych producent\u00f3w \u017car\u00f3wki, czajniki itp. Plusy: ka\u017cde urz\u0105dzenie zwi\u0119ksza mo\u017cliwo\u015bci i podnosi komfort. Minusy: dla ka\u017cdego nowego producenta potrzebna jest swoj\u0105 aplikacja. Protoko\u0142y urz\u0105dze\u0144 r\u00f3\u017cnych producent\u00f3w cz\u0119sto s\u0105 ze sob\u0105 niekompatybilne.<\/p>\n

Kategoria 2<\/u> \u2014 instalacja komputera jednop\u0142ytkowego lub zgodnego z x86. To usuwa ograniczenia dotycz\u0105ce mocy obliczeniowej, a na takim urz\u0105dzeniu zainstalowany jest MajorDoMo lub inna dystrybucja serwerowa do zarz\u0105dzania inteligentnym domem. W ten spos\u00f3b urz\u0105dzenia wi\u0119kszo\u015bci producent\u00f3w \u0142\u0105cz\u0105 si\u0119 w jednolit\u0105 przestrze\u0144 informacyjn\u0105. Tzn. powstaje w\u0142asny serwer dla inteligentnego domu. Plusy: kompatybilno\u015b\u0107 w ramach jednego centrum, co daje rozszerzone mo\u017cliwo\u015bci zarz\u0105dzania. Minusy: w przypadku awarii serwera ca\u0142y system wraca do etapu 1, tzn. staje si\u0119 rozdrobniony lub staje si\u0119 bezu\u017cyteczny.<\/p>\n

Kategoria 3<\/u> \u2014 najbardziej hardcore'owa opcja. Na etapie remontu zak\u0142adane s\u0105 wszystkie komunikacje i duplikowane s\u0105 wszystkie systemy. Plusy: wszystko doprowadzone do idea\u0142u i wtedy dom staje si\u0119 naprawd\u0119 inteligentny. Minusy: skrajna drogo\u015b\u0107 w por\u00f3wnaniu z kategoriami 1 i 2, potrzeba przemy\u015blenia wszystkiego z wyprzedzeniem i uwzgl\u0119dnienia ka\u017cdego szczeg\u00f3\u0142u.<\/p>\n

Wi\u0119kszo\u015b\u0107 u\u017cytkownik\u00f3w wybiera opcj\u0119 pierwsz\u0105, a nast\u0119pnie stopniowo przechodzi do opcji drugiej. A w dalszym etapie najtrwalsi dochodz\u0105 do opcji trzeciej. <\/p>\n

Istnieje jednak mo\u017cliwo\u015b\u0107, kt\u00f3r\u0105 mo\u017cna nazwa\u0107 systemem rozproszonym: ka\u017cde oddzielne urz\u0105dzenie b\u0119dzie jednocze\u015bnie serwerem i klientem. W istocie jest to pr\u00f3ba po\u0142\u0105czenia opcji 1 i opcji 2. Wzi\u0105\u0107 wszystkie ich plusy i wyeliminowa\u0107 minusy, znale\u017a\u0107 z\u0142oty \u015brodek. <\/p>\n

Mo\u017cliwe, \u017ce kto\u015b powie, \u017ce taka opcja ju\u017c zosta\u0142a opracowana. Jednak takie rozwi\u0105zania s\u0105 w\u0105sko ukierunkowane; s\u0105 przeznaczone dla os\u00f3b dobrze zaznajomionych z programowaniem. Naszym celem jest obni\u017cenie progu dost\u0119pu do takich rozproszonych system\u00f3w zar\u00f3wno w postaci urz\u0105dze\u0144 ko\u0144cowych, jak i integracji istniej\u0105cych urz\u0105dze\u0144 w nasz system. W przypadku termostatu u\u017cytkownik po prostu demontuje sw\u00f3j stary termostat, instaluje inteligentny i pod\u0142\u0105cza do niego posiadane czujniki. Bez \u017cadnych dodatkowych dzia\u0142a\u0144.<\/p>\n

Rozwa\u017cmy integracj\u0119 w naszym systemie na przyk\u0142adzie. <\/p>\n

Za\u0142\u00f3\u017cmy, \u017ce w naszej sieci znajduje si\u0119 8 modu\u0142\u00f3w Sonoff. Niekt\u00f3rzy u\u017cytkownicy b\u0119d\u0105 zadowoleni z zarz\u0105dzania przez chmur\u0119 Sonoff (kategoria 1). Niekt\u00f3rzy z nich zaczn\u0105 korzysta\u0107 z oprogramowania innych firm i przejd\u0105 w p\u0142ynny spos\u00f3b do kategorii 2. Wi\u0119kszo\u015b\u0107 zewn\u0119trznych oprogramowa\u0144 dzia\u0142a na tej samej zasadzie: przesy\u0142anie danych na serwer MQTT. OpenHub, Majordomo lub jakikolwiek inny s\u0142u\u017cy jednemu celowi \u2013 po\u0142\u0105czeniu rozproszonych urz\u0105dze\u0144 w jedn\u0105 przestrze\u0144 informacyjn\u0105, znajduj\u0105c\u0105 si\u0119 albo w Internecie, albo w sieci lokalnej. W zwi\u0105zku z tym obecno\u015b\u0107 serwera jest obowi\u0105zkowa. St\u0105d wynika g\u0142\u00f3wny problem \u2013 w przypadku awarii serwera ca\u0142y system przestaje dzia\u0142a\u0107 autonomicznie. Aby temu zapobiec, systemy si\u0119 komplikuj\u0105, dodawane s\u0105 r\u0119czne metody zarz\u0105dzania, kt\u00f3re zdubluj\u0105 automatyk\u0119 w przypadku awarii serwera. <\/p>\n

My wybrali\u015bmy inn\u0105 drog\u0119, w kt\u00f3rej ka\u017cde urz\u0105dzenie jest samowystarczalne. W ten spos\u00f3b rola serwera nie jest decyduj\u0105ca, a jedynie rozszerza funkcjonalno\u015b\u0107.<\/p>\n

Wr\u00f3\u0107my do naszego eksperymentu my\u015blowego. Ponownie we\u017amy te same 8 modu\u0142\u00f3w Sonoff i zainstalujmy w nich oprogramowanie Lytko. W ca\u0142ym oprogramowaniu Lytko zaimplementowano funkcj\u0119 SSDP<\/a><\/noindex>. SSDP to protok\u00f3\u0142 sieciowy oparty na zestawie protoko\u0142\u00f3w Internetu, s\u0142u\u017c\u0105cy do og\u0142aszania i odkrywania us\u0142ug sieciowych. Odpowied\u017a na zapytanie mo\u017ce mie\u0107 form\u0119 standardow\u0105 lub rozszerzon\u0105. Wprowadzili\u015bmy w tej odpowiedzi opr\u00f3cz standardowych funkcji tworzenie listy urz\u0105dze\u0144 w sieci. W ten spos\u00f3b urz\u0105dzenia same siebie znajduj\u0105, a ka\u017cde z nich b\u0119dzie mia\u0142o tak\u0105 list\u0119. Przyk\u0142ad listy SSDP:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostat\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostat\"\n\t}<\/code><\/pre>\n
\nJak wida\u0107 z przyk\u0142adu, lista obejmuje identyfikatory urz\u0105dze\u0144, adresy IP w sieci, typ bloku (w naszym przypadku \u2013 termostat oparty na Sonoff). Ta lista jest aktualizowana co dwie minuty (ten czas jest wystarczaj\u0105cy do reagowania na dynamiczne zmiany liczby urz\u0105dze\u0144 w sieci). W ten spos\u00f3b monitorujemy dodawanie, zmian\u0119 i wy\u0142\u0105czanie urz\u0105dze\u0144 bez jakichkolwiek dzia\u0142a\u0144 ze strony u\u017cytkownika. Lista ta jest przesy\u0142ana do przegl\u0105darki lub aplikacji mobilnej, a skrypt samodzielnie generuje stron\u0119 z okre\u015blon\u0105 liczb\u0105 blok\u00f3w. Ka\u017cdy blok odpowiada jednemu urz\u0105dzeniu\/sensorowi\/kontrolerowi. Wizualnie lista wygl\u0105da tak:<\/p>\n
\"Lytko
\n
\nAle co, je\u015bli do esp8266\/esp32 s\u0105 pod\u0142\u0105czone inne czujniki radiowe poprzez cc2530 (ZigBee) lub nrf24 (MySensors)? <\/p>\n
O projektach<\/h3>\n
\nNa rynku istnieje wiele r\u00f3\u017cnych system\u00f3w rozproszonych. Nasz system pozwala na integracj\u0119 z najpopularniejszymi rozwi\u0105zaniami. <\/p>\n
Poni\u017cej przedstawione s\u0105 projekty, kt\u00f3re w r\u00f3\u017cny spos\u00f3b staraj\u0105 si\u0119 zmieni\u0107 sytuacj\u0119 z niesp\u00f3jno\u015bci\u0105 r\u00f3\u017cnych producent\u00f3w. Na przyk\u0142ad, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> lub ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> jest oparty na serwerze MQTT, dlatego nie nadaje si\u0119 do tego przyk\u0142adu. <\/p>\n
Jednym z wariant\u00f3w realizacji MySensors jest brama oparta na ESP8266. Pozosta\u0142e przyk\u0142ady dotycz\u0105 ESP32. Mo\u017cna w nich wdro\u017cy\u0107 nasz\u0105 zasad\u0119 dzia\u0142ania w zakresie wykrywania i tworzenia listy urz\u0105dze\u0144. <\/p>\n
Przeprowadzimy jeszcze jeden my\u015blowy eksperyment. Mamy bram\u0119 ZESP32, SLS Gateway lub MySensors. Jak mo\u017cna je zintegrowa\u0107 w jednolitej przestrzeni informacyjnej? Do standardowych funkcji tych bram dodamy bibliotek\u0119 protoko\u0142u SSDP. Po zwr\u00f3ceniu si\u0119 do tego kontrolera przez SSDP, doda on do standardowej odpowiedzi list\u0119 urz\u0105dze\u0144, kt\u00f3re s\u0105 do niego pod\u0142\u0105czone. Na podstawie tych informacji przegl\u0105darka wygeneruje stron\u0119. W og\u00f3lnym zarysie b\u0119dzie to wygl\u0105da\u0107 tak:<\/p>\n
\"Lytko
\nInterfejs webowy<\/i><\/p>\n
\"Lytko
\nAplikacja PWA<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ unikalny identyfikator urz\u0105dzenia\n   \"ip\": \"192.168.x.x\", \/\/ adres ip w sieci\n   \"type\": \"termostat\" \/\/ typ urz\u0105dzenia\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostat\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostat\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"prze\u0142\u0105cznik\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"czujnik dymu\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"czujnik_kontaktowy\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"czujnik_temperatury_wilgotno\u015bci_ci\u015bnienia\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"czujnik_temperatury_wilgotno\u015bci\"\n}\n<\/code><\/pre>\n
\nZ przyk\u0142adu wida\u0107, \u017ce urz\u0105dzenia s\u0105 dodawane niezale\u017cnie jedno od drugiego. Pod\u0142\u0105czone s\u0105 3 termostaty z w\u0142asnymi adresami IP oraz 5 r\u00f3\u017cnych czujnik\u00f3w z unikalnymi identyfikatorami. Je\u015bli czujnik jest pod\u0142\u0105czony do sieci Wi-Fi, b\u0119dzie mia\u0142 sw\u00f3j adres IP, a je\u015bli jest pod\u0142\u0105czony do bramy, adres IP urz\u0105dzenia b\u0119dzie adresem IP bramy.<\/p>\n
Do komunikacji z urz\u0105dzeniami stosujemy WebSocket. Pozwala to na minimalizacj\u0119 zu\u017cycia zasob\u00f3w w por\u00f3wnaniu do zapyta\u0144 GET i na uzyskiwanie informacji dynamicznie przy po\u0142\u0105czeniu lub zmianie. <\/p>\n
Dane s\u0105 pobierane bezpo\u015brednio z urz\u0105dzenia, do kt\u00f3rego nale\u017cy blok, omijaj\u0105c serwer. W ten spos\u00f3b, w przypadku awarii dowolnego z urz\u0105dze\u0144, system nadal dzia\u0142a. Na interfejsie webowym jedynie nie b\u0119dzie wy\u015bwietlane znikni\u0119te urz\u0105dzenie z listy. Jednak informacja o jego znikni\u0119ciu, w razie potrzeby, przyjdzie w postaci powiadomienia w aplikacji u\u017cytkownika. <\/p>\n
Pierwsz\u0105 pr\u00f3b\u0105 realizacji takiego podej\u015bcia by\u0142a aplikacja PWA. Pozwala to na przechowywanie bazy blok\u00f3w na urz\u0105dzeniu u\u017cytkownika i \u017c\u0105danie tylko niezb\u0119dnych danych. Jednak ze wzgl\u0119du na szczeg\u00f3lno\u015bci struktury taka opcja jest niepe\u0142na. Wyj\u015bciem jest aplikacja natywna na Androida i iOS, kt\u00f3ra jest obecnie w fazie aktywnego rozwoju. Domy\u015blnie, aplikacja b\u0119dzie dzia\u0142a\u0107 tylko w wewn\u0119trznej sieci. W razie potrzeby, mo\u017cna wszystko przenie\u015b\u0107 na zdalne sterowanie. Tak wi\u0119c, gdy u\u017cytkownik opuszcza lokaln\u0105 sie\u0107, aplikacja automatycznie prze\u0142\u0105cza si\u0119 na chmur\u0119. <\/p>\n
Zdalne sterowanie \u2014 pe\u0142ne duplikowanie strony. Po aktywacji strony u\u017cytkownik mo\u017ce zalogowa\u0107 si\u0119 na serwerze i zarz\u0105dza\u0107 urz\u0105dzeniami przez swoje konto. Dzi\u0119ki temu, serwer rozszerza funkcjonalno\u015b\u0107, pozwalaj\u0105c na zarz\u0105dzanie urz\u0105dzeniami b\u0119d\u0105c poza domem, bez konieczno\u015bci korzystania z przekierowania port\u00f3w lub dedykowanego adresu IP.<\/p>\n
W ten spos\u00f3b powy\u017csza opcja pozbawiona jest wad podej\u015bcia serwerowego, a tak\u017ce ma szereg zalet w postaci elastyczno\u015bci pod\u0142\u0105czania nowych urz\u0105dze\u0144.<\/p>\n
O termostacie<\/h3>\n
\nRozwa\u017cmy system zarz\u0105dzania na przyk\u0142adzie naszego termostatu.<\/p>\n
Przewidziano:<\/p>\n
    \n
  1. Regulacj\u0119 temperatury ka\u017cdego termostatu (wy\u015bwietlan\u0105 jako oddzielny blok);<\/li>\n
  2. Ustawianie harmonogramu pracy termostatu (rano, w ci\u0105gu dnia, wieczorem, w nocy);<\/li>\n
  3. Wyb\u00f3r sieci Wi-Fi i pod\u0142\u0105czenie urz\u0105dzenia do niej;<\/li>\n
  4. Aktualizacja urz\u0105dzenia \"przez powietrze\";<\/li>\n
  5. Konfiguracja MQTT;<\/li>\n
  6. Konfiguracja sieci, do kt\u00f3rej pod\u0142\u0105czone jest urz\u0105dzenie.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nOpr\u00f3cz zarz\u0105dzania za pomoc\u0105 interfejsu webowego, przewidziano klasyczne - przyciski na wy\u015bwietlaczu. Na pok\u0142adzie znajduje si\u0119 monitor Nextion NX3224T024 o przek\u0105tnej 2.4 cala. Zdecydowano si\u0119 na niego ze wzgl\u0119du na \u0142atwo\u015b\u0107 obs\u0142ugi urz\u0105dzenia. Jednak w przygotowaniu jest w\u0142asny monitor oparty na STM32. Jego funkcjonalno\u015b\u0107 nie ust\u0119puje Nextionowi, ale b\u0119dzie ta\u0144szy, co pozytywnie wp\u0142ynie na ostateczn\u0105 cen\u0119 urz\u0105dzenia.<\/p>\n
    \"Lytko
    \n
    \nJak ka\u017cdy szanowany ekran termostatu, nasz Nextion potrafi:<\/p>\n