Cykl „MeshCore poza wiadomościami” · poziom 2 (lokalny) · część 2.1. Poprzednio, w części 1.1, wszystko działało: był prąd, internet i Wi-Fi, a MeshCore docierał tam, gdzie Wi-Fi nie sięga. Teraz odejmujemy internet i sieć komórkową. Zostaje lokalny komputer z Home Assistantem. Wszystkie opublikowane części cyklu znajdziesz na stronie cyklu.

MeshCore może być czymś więcej niż komunikatorem

MeshCore przekazuje krótkie wiadomości przez radia LoRa, bez masztów operatora i bez internetu. To już samo w sobie jest ciekawe, ale nasuwa się kolejne pytanie: co można zrobić z wiadomością, kiedy dotrze do odbiorcy?

Nie musi to być tekst do przeczytania przez człowieka. Wiadomość może być zapytaniem do bazy danych, zgłoszeniem nowej oferty, poleceniem dla urządzenia albo sygnałem, który uruchamia cały proces.

Stąd pomysł, by na MeshCore zbudować warstwę prostych, praktycznych usług dla lokalnej społeczności. Internetu nie zastąpią, ale mają działać bez stałego połączenia z zewnętrznymi serwerami.

Home Assistant – gotowa baza do eksperymentów

Do takiego zadania dobrze nadaje się Home Assistant. Kojarzy się z automatyką domową, ale jego mechanizmy przydają się także poza inteligentnym domem: obsługuje zdarzenia, sprawdza warunki, uruchamia automatyzacje, pamięta stany i łączy kilka czynności w jeden proces. Jeśli trafiają do niego wiadomości z MeshCore, każda może uruchomić kolejną procedurę.

W praktyce schemat może wyglądać następująco:

  1. Użytkownik wysyła wiadomość przez urządzenie MeshCore.
  2. Wiadomość dociera do systemu, który odbiera zdarzenia z sieci.
  3. Home Assistant sprawdza jej treść, kanał i inne dostępne informacje.
  4. Odpowiednia automatyzacja rozpoznaje rodzaj żądania i wykonuje przypisane zadanie.
  5. System odsyła odpowiedź przez MeshCore.

Nie trzeba przy tym pisać od zera osobnego programu dla każdej usługi. Wystarczy istniejące środowisko automatyzacji i nowa warstwa zastosowań.

Część tego da się sprawdzić już dziś. Integracja MeshCore dla Home Assistanta (meshcore-ha, instalowana przez HACS) pozwala reagować na zdarzenia związane z wiadomościami, a automatyzacje mogą analizować ich treść, filtrować komunikaty i wywoływać konkretne akcje. To techniczny punkt wyjścia. Opisane dalej usługi nie są jednak gotowe: ich logikę i sposób przechowywania danych trzeba dopiero zaprojektować.

Jedno centrum usług zamiast komputera dla każdej usługi

Najważniejsze założenie: jeden lokalny komputer z Home Assistantem obsługuje wiele usług dla jednej społeczności. W cyklu nazywamy go centrum usług. Bazar, wypożyczalnia narzędzi i system powiadomień nie potrzebują osobnych maszyn – każda usługa ma własne zasady, ale wszystkie korzystają z tego samego zaplecza.

Punktami dostępu do usług mogą być kanały MeshCore, czyli grupowe rozmowy w sieci: jeden do ogłoszeń, drugi do narzędzi, trzeci do zgłoszeń lokalnych potrzeb. Kanał nie musi zawierać logiki usługi. Wystarczy, że wiadomości z niego trafiają do odpowiednich automatyzacji. Jedna usługa może też w przyszłości korzystać z kilku kanałów.

Taki podział ma ważną zaletę: rozwijając jedną usługę, nie przebudowujemy pozostałych. Wspólne mogą być odbiór wiadomości, rozpoznawanie nadawcy, sprawdzanie poprawności danych i wysyłanie odpowiedzi, a sposób obsługi konkretnych żądań zależy od modułu danej usługi.

Automatyzacje jako mechanizm obsługi usług

Automatyzacje Home Assistanta mogą reagować na zdarzenia z MeshCore, sprawdzać treść wiadomości, rozpoznawać wzorce i decydować, co dalej. Polecenie sterujące system sprawdza, wykonuje na urządzeniu i potwierdza. Na zapytanie informacyjne pobiera dane z lokalnego rejestru i odsyła krótką odpowiedź. Zgłoszenie nowej oferty sprawdza pod kątem wymaganych pól, nadaje mu identyfikator i zapisuje.

Można zacząć od prostych reguł, warunków i akcji, a z czasem dodawać dokładniejszą walidację, kontrolę uprawnień oraz moduły do przechowywania i wyszukiwania danych.

Logikę trzeba jednak dobrze przemyśleć. Wiadomości mogą dotrzeć dwa razy, przyjść niekompletne albo zawierać polecenia, których system nie powinien wykonać. Potrzebne są więc filtrowanie komunikatów, rozpoznawanie duplikatów, weryfikacja nadawców tam, gdzie to możliwe, i jednoznaczne potwierdzanie operacji. Przy działaniach, które dotyczą bezpieczeństwa albo dostępu do zasobów, sama analiza tekstu nie wystarczy – potrzebna jest dodatkowa autoryzacja.

Bazar – przykład usługi opartej na lokalnych danych

Różnicę między zwykłym kanałem a usługą dobrze widać na przykładzie lokalnego Bazaru.

W kanale ogłoszeniowym oferta szybko ginie wśród kolejnych wiadomości, a po pewnym czasie nie wiadomo, czy jest jeszcze aktualna.

Bazar zapisywałby ogłoszenia w uporządkowanej lokalnej bazie danych. Każda oferta miałaby identyfikator, nazwę produktu, ilość, sposób kontaktu, datę publikacji i status. Użytkownik mógłby zapytać o konkretny produkt, a automatyzacja przekazałaby pytanie do modułu wyszukiwania i odesłała wynik przez MeshCore. Sprzedający mógłby dodać ofertę, a później ją zmienić albo wycofać.

Z wymiany komunikatów robi się w ten sposób prosty system ewidencji i wyszukiwania, dostępny przez radio. Na tej samej zasadzie mogłyby działać wypożyczalnia narzędzi, rejestr wspólnych zasobów, ogłoszenia o pomocy sąsiedzkiej czy zgłoszenia dotyczące wspólnych przedsięwzięć. Każda z tych usług potrzebuje innego modelu danych i innych reguł, ale niekoniecznie innego komputera.

A może również skrytki odbiorcze?

Innym kierunkiem jest lokalny punkt odbioru przesyłek albo eksperymentalny system skrytek. MeshCore przesyłałby zgłoszenia i powiadomienia, a Home Assistant koordynowałby obsługę urządzeń.

Komunikację trzeba tu jednak oddzielić od bezpieczeństwa fizycznego. Sama wiadomość radiowa nie powinna otwierać skrytki. Potrzebne byłyby uwierzytelnianie, uprawnienia, ograniczenia czasowe i rejestr operacji. To możliwy kierunek rozwoju – samo połączenie MeshCore z Home Assistantem takiej funkcji nie zapewnia.

Czy sztuczna inteligencja jest konieczna?

Nie. Wyszukiwanie ofert, sprawdzanie dostępności narzędzi, rejestrowanie zgłoszeń czy sterowanie prostym urządzeniem da się zrobić lokalnymi regułami i danymi. Takie rozwiązania łatwiej przewidzieć, potrzebują mniej mocy obliczeniowej i nie zależą od zewnętrznych usług.

Sztuczna inteligencja mogłaby pomóc w rozumieniu swobodniej sformułowanych pytań albo w redagowaniu odpowiedzi. Jeśli jednak system ma działać bez internetu, podstawowe funkcje nie mogą zależeć od zewnętrznego modelu – w grę wchodzi wtedy model lokalny albo prosty zestaw poleceń. Najważniejsza jest przewidywalność: użytkownik powinien wiedzieć, jakie operacje są dostępne i czy rzeczywiście zostały wykonane.

Największe wyzwanie: jedno centrum usług

Centrum usług upraszcza zarządzanie, ale staje się wspólnym punktem awarii. Gdy przestanie działać, wszystkie usługi zależne od Home Assistanta jednocześnie przestaną przetwarzać wiadomości.

Sama sieć MeshCore działa jednak dalej. Komunikacja radiowa i przetwarzanie usług w centrum to dwie różne warstwy, a dobrze zaprojektowany system zachowa jak najwięcej funkcji komunikacyjnych także wtedy, gdy centrum jest niedostępne.

Od początku warto pomyśleć o zasilaniu awaryjnym, kopiach zapasowych, automatycznym odtwarzaniu systemu i możliwości przeniesienia usług na zapasowy komputer. W bardziej rozbudowanej wersji można dodać drugie centrum, które przejmie zadania po awarii pierwszego. Nie wystarczy jednak podłączyć drugiej maszyny: potrzebne są synchronizacja danych, spójna konfiguracja i bezpieczne przełączanie, które nie dopuści do tego, by oba centra wykonały tę samą operację.

Od czego rozpocząć budowę?

Najrozsądniej zacząć od jednego centrum i jednej usługi. Połączenie MeshCore z Home Assistantem pozwala eksperymentować z odbiorem wiadomości i uruchamianiem automatyzacji. Kolejnym krokiem może być usługa, która zapisuje i wyszukuje dane, na przykład Bazar.

Potem trzeba sprawdzić, jak system zachowuje się po restarcie, przy powtórzonej wiadomości i gdy komputer jest niedostępny. Dopiero gdy podstawy działają, warto dodawać kolejne usługi i zabezpieczenia na wypadek awarii.

Ważne będą też ograniczenia samej transmisji. LoRa to nie szerokopasmowe łącze: wiadomości muszą być krótkie, a protokół usług nie może generować zbędnego ruchu. Przy większej liczbie użytkowników trzeba uwzględnić małą przepustowość, opóźnienia oraz zasady potwierdzania i ponawiania operacji. Konkretne możliwości będą zależeć od urządzeń, konfiguracji MeshCore i sposobu integracji z Home Assistantem.

Wspólna infrastruktura zamiast zbioru niezależnych eksperymentów

MeshCore zapewnia komunikację, Home Assistant koordynuje automatyzacje, moduły usług odpowiadają za konkretne zadania, a lokalne bazy danych przechowują to, co musi przetrwać restart i być dostępne bez internetu. Do takiej wspólnej infrastruktury można stopniowo dołączać kolejne usługi, zaczynając od prostego prototypu.

Na jakim jesteśmy etapie

  • Działa już: integracja MeshCore z Home Assistantem pozwala reagować na zdarzenia związane z wiadomościami i uruchamiać automatyzacje.
  • Hipoteza: jedno centrum usług może obsługiwać wiele usług, takich jak Bazar, wypożyczalnia narzędzi czy zgłoszenia, a kanały MeshCore pełnią rolę punktów dostępu.
  • Do przetestowania: zachowanie po restarcie i przy powtórzonych wiadomościach, uwierzytelnianie poleceń, ograniczenia przepustowości oraz awaria centrum usług.

Co dalej w cyklu

W części 2.2 przechodzimy do trudniejszej usługi: rozliczeń. Bazar zapisuje ogłoszenia, ale gdy w grę wchodzą punkty i salda, potrzebna jest księga transakcji i ochrona przed podwójnym wykonaniem tej samej operacji. A jeśli centrum usług w ogóle przestanie działać, zajmiemy się tym na poziomie 3, w części 3.1.

Kolejne części pojawią się pod tym tekstem, w sekcji „Zobacz też”.