Jakiś czas temu przedstawiliśmy Ci . Dzisiejszy artykuł początkowo miał być demonstracją jego oprogramowania i systemu zarządzania. Aby jednak wyjaśnić logikę działania termostatu oraz to, co wdrożyliśmy, konieczne jest przedstawienie całej koncepcji w całości.
O automatyzacji
Zasadniczo, całą automatyzację można podzielić na trzy kategorie:
Kategoria 1 — oddzielne „inteligentne” urządzenia. Kupujesz od różnych producentów żarówki, czajniki itp. Plusy: każde urządzenie zwiększa możliwości i podnosi komfort. Minusy: dla każdego nowego producenta potrzebna jest swoją aplikacja. Protokoły urządzeń różnych producentów często są ze sobą niekompatybilne.
Kategoria 2 — instalacja komputera jednopłytkowego lub zgodnego z x86. To usuwa ograniczenia dotyczące mocy obliczeniowej, a na takim urządzeniu zainstalowany jest MajorDoMo lub inna dystrybucja serwerowa do zarządzania inteligentnym domem. W ten sposób urządzenia większości producentów łączą się w jednolitą przestrzeń informacyjną. Tzn. powstaje własny serwer dla inteligentnego domu. Plusy: kompatybilność w ramach jednego centrum, co daje rozszerzone możliwości zarządzania. Minusy: w przypadku awarii serwera cały system wraca do etapu 1, tzn. staje się rozdrobniony lub staje się bezużyteczny.
Kategoria 3 — najbardziej hardcore'owa opcja. Na etapie remontu zakładane są wszystkie komunikacje i duplikowane są wszystkie systemy. Plusy: wszystko doprowadzone do ideału i wtedy dom staje się naprawdę inteligentny. Minusy: skrajna drogość w porównaniu z kategoriami 1 i 2, potrzeba przemyślenia wszystkiego z wyprzedzeniem i uwzględnienia każdego szczegółu.
Większość użytkowników wybiera opcję pierwszą, a następnie stopniowo przechodzi do opcji drugiej. A w dalszym etapie najtrwalsi dochodzą do opcji trzeciej.
Istnieje jednak możliwość, którą można nazwać systemem rozproszonym: każde oddzielne urządzenie będzie jednocześnie serwerem i klientem. W istocie jest to próba połączenia opcji 1 i opcji 2. Wziąć wszystkie ich plusy i wyeliminować minusy, znaleźć złoty środek.
Możliwe, że ktoś powie, że taka opcja już została opracowana. Jednak takie rozwiązania są wąsko ukierunkowane; są przeznaczone dla osób dobrze zaznajomionych z programowaniem. Naszym celem jest obniżenie progu dostępu do takich rozproszonych systemów zarówno w postaci urządzeń końcowych, jak i integracji istniejących urządzeń w nasz system. W przypadku termostatu użytkownik po prostu demontuje swój stary termostat, instaluje inteligentny i podłącza do niego posiadane czujniki. Bez żadnych dodatkowych działań.
Rozważmy integrację w naszym systemie na przykładzie.
Załóżmy, że w naszej sieci znajduje się 8 modułów Sonoff. Niektórzy użytkownicy będą zadowoleni z zarządzania przez chmurę Sonoff (kategoria 1). Niektórzy z nich zaczną korzystać z oprogramowania innych firm i przejdą w płynny sposób do kategorii 2. Większość zewnętrznych oprogramowań działa na tej samej zasadzie: przesyłanie danych na serwer MQTT. OpenHub, Majordomo lub jakikolwiek inny służy jednemu celowi – połączeniu rozproszonych urządzeń w jedną przestrzeń informacyjną, znajdującą się albo w Internecie, albo w sieci lokalnej. W związku z tym obecność serwera jest obowiązkowa. Stąd wynika główny problem – w przypadku awarii serwera cały system przestaje działać autonomicznie. Aby temu zapobiec, systemy się komplikują, dodawane są ręczne metody zarządzania, które zdublują automatykę w przypadku awarii serwera.
My wybraliśmy inną drogę, w której każde urządzenie jest samowystarczalne. W ten sposób rola serwera nie jest decydująca, a jedynie rozszerza funkcjonalność.
Wróćmy do naszego eksperymentu myślowego. Ponownie weźmy te same 8 modułów Sonoff i zainstalujmy w nich oprogramowanie Lytko. W całym oprogramowaniu Lytko zaimplementowano funkcję . SSDP to protokół sieciowy oparty na zestawie protokołów Internetu, służący do ogłaszania i odkrywania usług sieciowych. Odpowiedź na zapytanie może mieć formę standardową lub rozszerzoną. Wprowadziliśmy w tej odpowiedzi oprócz standardowych funkcji tworzenie listy urządzeń w sieci. W ten sposób urządzenia same siebie znajdują, a każde z nich będzie miało taką listę. Przykład listy SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Jak widać z przykładu, lista obejmuje identyfikatory urządzeń, adresy IP w sieci, typ bloku (w naszym przypadku – termostat oparty na Sonoff). Ta lista jest aktualizowana co dwie minuty (ten czas jest wystarczający do reagowania na dynamiczne zmiany liczby urządzeń w sieci). W ten sposób monitorujemy dodawanie, zmianę i wyłączanie urządzeń bez jakichkolwiek działań ze strony użytkownika. Lista ta jest przesyłana do przeglądarki lub aplikacji mobilnej, a skrypt samodzielnie generuje stronę z określoną liczbą bloków. Każdy blok odpowiada jednemu urządzeniu/sensorowi/kontrolerowi. Wizualnie lista wygląda tak:
Ale co, jeśli do esp8266/esp32 są podłączone inne czujniki radiowe poprzez cc2530 (ZigBee) lub nrf24 (MySensors)?
O projektach
Na rynku istnieje wiele różnych systemów rozproszonych. Nasz system pozwala na integrację z najpopularniejszymi rozwiązaniami.
Poniżej przedstawione są projekty, które w różny sposób starają się zmienić sytuację z niespójnością różnych producentów. Na przykład, , lub . jest oparty na serwerze MQTT, dlatego nie nadaje się do tego przykładu.
Jednym z wariantów realizacji MySensors jest brama oparta na ESP8266. Pozostałe przykłady dotyczą ESP32. Można w nich wdrożyć naszą zasadę działania w zakresie wykrywania i tworzenia listy urządzeń.
Przeprowadzimy jeszcze jeden myślowy eksperyment. Mamy bramę ZESP32, SLS Gateway lub MySensors. Jak można je zintegrować w jednolitej przestrzeni informacyjnej? Do standardowych funkcji tych bram dodamy bibliotekę protokołu SSDP. Po zwróceniu się do tego kontrolera przez SSDP, doda on do standardowej odpowiedzi listę urządzeń, które są do niego podłączone. Na podstawie tych informacji przeglądarka wygeneruje stronę. W ogólnym zarysie będzie to wyglądać tak:
Interfejs webowy
Aplikacja PWA
"ssdpList":
{
"id": 94967291, // unikalny identyfikator urządzenia
"ip": "192.168.x.x", // adres IP w sieci
"type": "thermostat" // typ urządzenia
},
{
"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"
}
Z przykładu widać, że urządzenia są dodawane niezależnie jedno od drugiego. Podłączone są 3 termostaty z własnymi adresami IP oraz 5 różnych czujników z unikalnymi identyfikatorami. Jeśli czujnik jest podłączony do sieci Wi-Fi, będzie miał swój adres IP, a jeśli jest podłączony do bramy, adres IP urządzenia będzie adresem IP bramy.
Do komunikacji z urządzeniami stosujemy WebSocket. Pozwala to na minimalizację zużycia zasobów w porównaniu do zapytań GET i na uzyskiwanie informacji dynamicznie przy połączeniu lub zmianie.
Dane są pobierane bezpośrednio z urządzenia, do którego należy blok, omijając serwer. W ten sposób, w przypadku awarii dowolnego z urządzeń, system nadal działa. Na interfejsie webowym jedynie nie będzie wyświetlane zniknięte urządzenie z listy. Jednak informacja o jego zniknięciu, w razie potrzeby, przyjdzie w postaci powiadomienia w aplikacji użytkownika.
Pierwszą próbą realizacji takiego podejścia była aplikacja PWA. Pozwala to na przechowywanie bazy bloków na urządzeniu użytkownika i żądanie tylko niezbędnych danych. Jednak ze względu na szczególności struktury taka opcja jest niepełna. Wyjściem jest aplikacja natywna na Androida i iOS, która jest obecnie w fazie aktywnego rozwoju. Domyślnie, aplikacja będzie działać tylko w wewnętrznej sieci. W razie potrzeby, można wszystko przenieść na zdalne sterowanie. Tak więc, gdy użytkownik opuszcza lokalną sieć, aplikacja automatycznie przełącza się na chmurę.
Zdalne sterowanie — pełne duplikowanie strony. Po aktywacji strony użytkownik może zalogować się na serwerze i zarządzać urządzeniami przez swoje konto. Dzięki temu, serwer rozszerza funkcjonalność, pozwalając na zarządzanie urządzeniami będąc poza domem, bez konieczności korzystania z przekierowania portów lub dedykowanego adresu IP.
W ten sposób powyższa opcja pozbawiona jest wad podejścia serwerowego, a także ma szereg zalet w postaci elastyczności podłączania nowych urządzeń.
O termostacie
Rozważmy system zarządzania na przykładzie naszego termostatu.
Przewidziano:
- Regulację temperatury każdego termostatu (wyświetlaną jako oddzielny blok);
- Ustawianie harmonogramu pracy termostatu (rano, w ciągu dnia, wieczorem, w nocy);
- Wybór sieci Wi-Fi i podłączenie urządzenia do niej;
- Aktualizacja urządzenia "przez powietrze";
- Konfiguracja MQTT;
- Konfiguracja sieci, do której podłączone jest urządzenie.
Oprócz zarządzania za pomocą interfejsu webowego, przewidziano klasyczne - przyciski na wyświetlaczu. Na pokładzie znajduje się monitor Nextion NX3224T024 o przekątnej 2.4 cala. Zdecydowano się na niego ze względu na łatwość obsługi urządzenia. Jednak w przygotowaniu jest własny monitor oparty na STM32. Jego funkcjonalność nie ustępuje Nextionowi, ale będzie tańszy, co pozytywnie wpłynie na ostateczną cenę urządzenia.
Jak każdy szanowany ekran termostatu, nasz Nextion potrafi:
- ustawiać wymaganą przez użytkownika temperaturę (przyciskami po prawej);
- włączać i wyłączać tryb pracy zgodnie z harmonogramem (przycisk H);
- wyświetlać pracę przekaźnika (strzałka po lewej);
- posiada zabezpieczenie przed dziećmi (zablokowanie fizycznego nacisku, gdy zamek jest włączony);
- wyświetla poziom sygnału WiFi.
Ponadto, za pomocą monitora można:
- wybrać typ zainstalowanego przez użytkownika czujnika;
- zarządzać funkcją zabezpieczenia przed dziećmi;
- aktualizować oprogramowanie.
Po kliknięciu na pasek WiFi użytkownik uzyskuje informacje o podłączonej sieci. Kod QR jest używany do parowania urządzenia w oprogramowaniu HomeKit.
Demonstrowanie pracy z wyświetlaczem:
Opracowaliśmy z trzema podłączonymi termostatami.
Zapytasz: „Czym wyróżnia się Wasz termostat?” Obecnie na rynku istnieje wiele termostatów z funkcją Wi-Fi, działających zgodnie z harmonogramem, z obsługą dotykową. A entuzjaści stworzyli moduły do interakcji z większością popularnych systemów inteligentnego domu (Majordomo, HomeAssistant itd.).
Nasz termostat jest zgodny z tymi systemami i posiada wszystkie wymienione wcześniej funkcje. Jednak jego wyróżniającą cechą jest to, że termostat jest nieustannie rozwijany dzięki elastyczności systemu. Z każdą aktualizacją funkcjonalność będzie się rozszerzać. Do standardowego sposobu zarządzania systemem (według harmonogramu) dodamy tryb adaptacyjny. Aplikacja umożliwia uzyskanie geolokalizacji użytkownika. Dzięki temu system dynamicznie zmienia tryby pracy w zależności od jego lokalizacji. A moduł pogodowy pozwoli dostosować się do warunków atmosferycznych.
I rozszerzalność. Każdy chętny będzie mógł wymienić zainstalowany standardowy termostat na nasz. Z minimalnym wysiłkiem. Wybraliśmy 5 najpopularniejszych czujników dostępnych na rynku i dodaliśmy ich wsparcie. Jednak nawet w przypadku unikalnych właściwości czujnika użytkownik będzie mógł podłączyć go do naszego termostatu. W tym celu będzie trzeba skalibrować termostat do współpracy z konkretnym sensorem. Instrukcje dostarczymy.
Podłączając termostat lub jakiekolwiek inne urządzenie, pojawia się ono wszędzie: zarówno w interfejsie webowym, jak i w aplikacji PWA. Dodawanie urządzenia odbywa się automatycznie: wystarczy tylko podłączyć je do sieci Wi-Fi.
Nasz system nie potrzebuje serwera, a w przypadku jego awarii nie zamienia się w dynię. Nawet w przypadku awarii jednego z komponentów system nie zaczyna działać w trybie awaryjnym. Kontrolery, czujniki i urządzenia — każdy element jest zarówno serwerem, jak i klientem, dlatego jest całkowicie autonomiczny.
Dla zainteresowanych — nasze media społecznościowe: , , , , .
E-mail: shop@lytko.com
P. S. Nie namawiamy do rezygnacji z serwera. Oferujemy również wsparcie dla serwera MQTT oraz mamy własną chmurę. Naszym celem jest podniesienie stabilności i niezawodności systemu na wyższy poziom. Aby serwer nie był słabym punktem, a uzupełniał funkcjonalność i sprawiał, że system jest bardziej komfortowy.
Źródło: habr.com
