Cykl „MeshCore poza wiadomościami” · poziom 2 (lokalny) · część 2.2. Wszystkie opublikowane części cyklu znajdziesz na stronie cyklu.

W części 2.1 pokazaliśmy, jak lokalne centrum usług z Home Assistantem (otwartym systemem automatyki domowej) może obsługiwać społeczność przez radio MeshCore, na przykład w postaci lokalnego Bazaru. Gdy do usług dochodzą punkty, pojawia się pytanie, które wykracza poza samo przesyłanie wiadomości: gdzie przechowywać informacje o punktach, saldach i wykonanych operacjach, aby system był wiarygodny?

Wyobraźmy sobie niewielką społeczność, w której uczestnicy zamawiają drobne usługi, przekazują sobie punkty, korzystają z sąsiedzkiej wymiany albo rezerwują wspólne zasoby – wszystko przez radio, bez aplikacji w chmurze i bez stałego połączenia z internetem. Samo dostarczenie wiadomości nie oznacza jednak, że usługa została wykonana, zamówienie przyjęte, a punkty prawidłowo rozliczone.

Czy Home Assistant, który w części 2.1 odbierał wiadomości i uruchamiał automatyzacje, poradzi sobie także z rozliczeniami? Tak, choć warto od początku rozdzielić dwie funkcje: obsługę usług i prowadzenie księgi transakcji.

Jedna lokalna maszyna, kilka niezależnych elementów

W proponowanym rozwiązaniu centrum usług może działać na jednym komputerze. Nie oznacza to jednak, że wszystkie funkcje powinny być umieszczone w jednym mechanizmie.

Home Assistant może odpowiadać za obsługę wiadomości, automatyzacje i kierowanie żądań do właściwych usług. Natomiast dane wymagające szczególnej spójności, takie jak historia transakcji i salda uczestników, warto przechowywać w osobnym komponencie z własną bazą danych. Ten komponent nazywamy modułem rozliczeniowym, a jego zapisy księgą transakcji.

Nie musi to być drugi komputer. Na początkowym etapie zarówno Home Assistant, jak i niewielki moduł rozliczeniowy mogą pracować na tej samej maszynie, bez zależności od zewnętrznych serwerów.

Podział dotyczy przede wszystkim odpowiedzialności za poszczególne zadania.

Home Assistant wie, jakie polecenie przyszło i do jakiej usługi powinno trafić. Moduł rozliczeniowy odpowiada za to, czy operacja jest dozwolona, jak zmienia saldo i jaki wynik należy zwrócić. Dzięki temu rozwój automatyzacji nie musi oznaczać jednoczesnego przebudowywania mechanizmu przechowywania punktów.

Saldo to nie tylko jedna liczba

Największe znaczenie ma sposób przechowywania danych.

Jeśli system pokazuje, że uczestnik ma 25 punktów, to sama informacja o saldzie nie wyjaśnia, skąd te punkty się wzięły. Nie wiadomo, czy zostały przyznane, zarobione, otrzymane od innej osoby, czy może wynikają z korekty wcześniejszej operacji.

Dlatego lepszym rozwiązaniem jest prowadzenie historii transakcji. Każdy zapis powinien określać przynajmniej rodzaj operacji, jej wartość, uczestników, czas wykonania oraz wynik. Aktualne saldo można następnie obliczać na podstawie zapisów lub przechowywać dodatkowo jako wartość pomocniczą.

Taka historia ułatwia kontrolę poprawności rozliczeń i pozwala odtworzyć przebieg zdarzeń. W razie pomyłki można sprawdzić, co się wydarzyło, zamiast próbować odgadnąć przyczynę na podstawie samej końcowej wartości.

Z tego powodu historii stanów Home Assistanta nie należy traktować jako docelowej księgi rozliczeń. Jest ona przydatna w automatyzacji i diagnostyce, ale system punktowy potrzebuje własnych reguł zapisu, przechowywania i odtwarzania transakcji.

Co się stanie, gdy wiadomość dotrze dwa razy?

Rozważmy prosty przykład.

Uczestnik A ma 20 punktów i chce przekazać 7 punktów uczestnikowi B. Wysyła polecenie przez MeshCore. System sprawdza saldo, wykonuje operację i zapisuje zmianę. Następnie powinien odesłać potwierdzenie.

Problem pojawia się wtedy, gdy potwierdzenie nie dociera do nadawcy. Użytkownik nie wie, czy operacja została wykonana, więc wysyła polecenie ponownie.

Jeżeli system potraktuje ponowioną wiadomość jako nową transakcję, może odjąć kolejne 7 punktów. To przykład sytuacji, w której poprawnie działająca komunikacja radiowa nie wystarcza do zapewnienia poprawności rozliczeń.

Dlatego mechanizm transakcyjny powinien rozpoznawać powtórzone żądania. Każda operacja musi mieć własny identyfikator, a system powinien pamiętać, czy została już wykonana. Ponowne otrzymanie tego samego żądania powinno zwrócić poprzedni wynik, a nie ponownie zmieniać saldo.

Istotna jest również kolejność działań. System musi sprawdzić saldo i zapisać zmianę w sposób zapewniający spójność danych. Potwierdzenie sukcesu powinno zostać wysłane dopiero wtedy, gdy wynik operacji został trwale zapisany.

To zagadnienia, które wymagają osobnego zaprojektowania i przetestowania. Nie rozwiązuje ich samo uruchomienie bazy danych ani dodanie kolejnej automatyzacji.

Brak internetu a awaria centrum usług

Jedną z głównych zalet proponowanej architektury jest możliwość lokalnego działania. Jeżeli Home Assistant, komunikacja MeshCore i moduł rozliczeniowy działają w lokalnej infrastrukturze, połączenie z internetem nie musi być potrzebne do obsługi podstawowych operacji.

Brak internetu nie jest jednak tym samym co awaria centrum usług.

Jeżeli przestanie działać dostęp do sieci zewnętrznej, lokalne usługi mogą nadal funkcjonować. Jeżeli natomiast przestanie działać komputer prowadzący księgę, system nie będzie miał aktualnego i wiarygodnego źródła informacji o saldach.

W takiej sytuacji bezpieczniej jest czasowo wstrzymać operacje wymagające potwierdzenia salda niż dopuścić do rozliczeń, których później nie da się jednoznacznie uzgodnić.

Dlatego już na etapie projektowania warto uwzględnić zasilanie awaryjne, kopie zapasowe i możliwość odtworzenia danych. W przyszłości można również rozważyć dodatkowe mechanizmy zwiększające odporność systemu na awarie.

To nie przekreśla koncepcji jednego centrum usług. Oznacza jedynie, że trzeba świadomie określić jego rolę i granice odpowiedzialności.

Czy można rozliczać punkty bez centrum usług?

Można rozważać także bardziej rozproszone modele, w których uczestnicy lub poszczególne węzły przechowują własne informacje o saldach. Takie rozwiązanie ogranicza zależność od jednego centrum, ale znacznie komplikuje uzgadnianie danych.

Jeżeli dwa węzły jednocześnie zaakceptują wydanie tych samych punktów, system musi mieć sposób rozstrzygnięcia, która operacja była prawidłowa. Potrzebne są reguły synchronizacji i uzgadniania transakcji, a nie tylko wymiana kopii sald przez radio.

Możliwy jest również model hybrydowy: księga w centrum usług pozostaje źródłem prawdy (to jej zapis rozstrzyga, kto ma ile punktów), a uczestnicy otrzymują okresowe zestawienia lub kopie informacji. Takie kopie mogą pomagać w kontroli i odtwarzaniu historii, ale same w sobie nie powinny uprawniać do wydawania punktów bez weryfikacji.

Rozliczenia rozproszone są interesującym kierunkiem rozwoju, jednak na początek model z jednym centrum usług jest prostszy do wdrożenia, przetestowania i zrozumienia.

Od prototypu do działającego systemu

Najrozsądniej rozwijać taki projekt etapami. Najpierw należy uruchomić podstawową wymianę poleceń i odpowiedzi. Następnie dodać lokalny zapis operacji, kontrolę salda oraz zabezpieczenie przed ponownym wykonaniem tego samego żądania.

Dopiero po sprawdzeniu tych mechanizmów warto rozszerzać system o kolejne usługi i bardziej zaawansowane scenariusze awaryjne.

Nie wszystkie problemy muszą zostać rozwiązane w pierwszej wersji. Ważne, by od początku wiedzieć, które elementy już działają, które są propozycją architektury, a które wymagają dalszych prac. Celem nie jest od razu rozbudowany system finansowy, tylko lokalna infrastruktura usług, która działa bez internetu, ma przejrzyste zasady i rośnie razem z potrzebami społeczności.

Na jakim jesteśmy etapie

  • Działa już: komunikację MeshCore i automatyzacje Home Assistanta na zdarzeniach wiadomości można realizować już dziś.
  • Hipoteza: osobny moduł rozliczeniowy z księgą transakcji, działający obok Home Assistanta na jednym komputerze, utrzyma salda i historię operacji.
  • Do przetestowania: ochrona przed powtórzonymi żądaniami, odtwarzanie danych po awarii oraz zachowanie systemu, gdy centrum usług jest niedostępne.

W następnej części cyklu

Cały ten model opiera się na centrum usług, które pracuje i prowadzi księgę. W części 3.1 odejmujemy je razem z internetem i prądem z sieci. Zostają radia na bateriach i Room Servery, czyli węzły MeshCore działające jak wspólna tablica ogłoszeń. Sprawdzimy, czy da się z nich zbudować tablicę ogłoszeń i prosty rejestr ustaleń, i dlaczego rozliczenia punktów są tam znacznie trudniejsze.

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