Automatyzacja na Raspberry Pi w terenie: wnioski z integracji kamer z bramą wjazdową

Projekt: kamery, rejestr i brama

Lokalny producent zamówił system, który łączy oprogramowanie i sprzęt wokół kamer IP z rozpoznawaniem obrazu. Kamery rozpoznają pojazdy. Firma chciała, żeby brama wjazdowa otwierała się dla wybranych, znanych pojazdów i zostawała zamknięta dla pozostałych.

Moja część to łącznik między systemami. Po jednej stronie oprogramowanie do rozpoznawania, po drugiej tabele rejestracji, a pośrodku brama. Napisałem usługę, która przekazuje informacje między nimi. Prezentuje tabele rejestracji, zapisuje je w rejestrze i automatyzuje bramę dla znanych pojazdów.

Po uruchomieniu nic się nie zepsuło. Zawdzięczam to mniej sprytnemu kodowi, a bardziej przygotowaniu. Większość przygotowań odbyła się, zanim napisałem pierwszą linię.

Zacznij od dostępu do sieci

Sieć producenta chroniły firewalle klasy korporacyjnej. Każde połączenie między kamerami, łącznikiem, rejestrem i bramą trzeba było wcześniej odblokować. Porty, kierunki i adresy wymagały zatwierdzenia, a osoby, które je zatwierdzają, pracują według własnego harmonogramu.

Gdybym poczekał, aż usługa będzie gotowa, projekt utknąłby przy pierwszym teście połączenia. Dlatego zapytałem na początku:

1. Które systemy mają ze sobą rozmawiać i w którą stronę?
2. Jakich portów i protokołów używa każde połączenie?
3. Kto zatwierdza zmiany w firewallu i ile to trwa?
4. W jakim środowisku mogę testować, zanim urządzenia staną na miejscu?

Zapisz odpowiedzi jako jednostronicowy schemat z zatwierdzeniami przy każdej linii. To najtańszy dokument w projekcie, a oszczędza najdłuższe opóźnienia.

Skrypt staje się systemem, gdy działa bez nadzoru

Wiele projektów na Raspberry Pi zaczyna się od jednego skryptu, jednego urządzenia i jednego procesu, który oszczędza czas. Na biurku działa, bo terminal jest otwarty. Potem urządzenie trafia do szafy, warsztatu albo do klienta i nikt na nie nie patrzy.

Sterownik bramy należy do tej drugiej grupy. Nikt nie zrestartuje go ręcznie, gdy czeka gość. To zdecydowało o tym, jak zbudowałem usługę.

Test restartu

W małej automatyzacji najlepszym testem odbiorczym jest prosty zabieg: odłącz zasilanie, podłącz ponownie i poczekaj. Potem sprawdź:

• Czy usługa startuje bez klawiatury?
• Czy urządzenie wraca do sieci?
• Czy znajduje konfigurację i pliki?
• Czy sekrety leżą poza repozytorium?
• Czy proces podnosi się po przekroczeniu czasu odpowiedzi API?

Jeśli któraś odpowiedź brzmi „tylko gdy uruchomię to ręcznie”, projekt nie jest gotowy do samodzielnej pracy. Nie potrzebuje architektury korporacyjnej. Potrzebuje kilku dobrych nawyków.

Nawyki, które utrzymują mały system w ruchu

1. Uruchamiaj proces jako usługę. Jednostka systemd startuje proces po włączeniu, restartuje go po błędzie, pokazuje status i daje jedno miejsce do diagnozy.
2. Trzymaj konfigurację poza kodem. Ścieżki, tokeny, adresy, nazwy urządzeń i progi należą do pliku konfiguracyjnego. Sekretów nie wrzucaj do repozytorium.
3. Pisz logi dla osoby, która wróci do nich jutro. Znaczniki czasu, jasne nazwy zdarzeń i kontekst błędu liczą się bardziej niż efektowny wynik.
4. Zakładaj niedoskonałą sieć. Przekroczenia czasu, ponowienia, wydłużanie przerw między próbami i tryb offline to w terenie normalność.
5. Opisz drogę powrotu do działania. Jedna strona z nazwami usług, ścieżkami konfiguracji, komendami restartu i znanymi awariami potrafi oszczędzić godziny.

Jak wygląda użyteczny log

Wpis w logu odpowiada na trzy pytania: co się stało, z jakim obiektem i co system zrobił dalej. W tej integracji jedno zdarzenie może wyglądać tak: pojazd rozpoznany, sprawdzono rejestr, pojazd znaleziony, wysłano polecenie do bramy, brama potwierdziła.

Każdy z tych kroków dostaje osobną linię ze znacznikiem czasu i krótkim identyfikatorem zdarzenia. Gdy ktoś zapyta, dlaczego brama nie otworzyła się dla konkretnego pojazdu, śledzisz jeden identyfikator w całym łańcuchu i widzisz, gdzie się zatrzymał. Bez tego to samo pytanie kończy się zgadywaniem.

Monitoring może być lekki

Mały system nie potrzebuje pełnego stosu monitoringu. Musi szybko odpowiadać na trzy pytania:

• Czy proces działa?
• Kiedy ostatnio wykonał użyteczną pracę?
• Jeśli padł, co padło pierwsze?

Czasem wystarczą logi z ustaloną strukturą i prosty endpoint zdrowia. Czasem plik statusu, codzienny mail albo mały panel. Cel to mniej zgadywania, gdy urządzenie jest poza zasięgiem ręki.

Trzymaj rejestr w jednym miejscu

Tabele rejestracji to najwrażliwsza część układu, bo decydują, kto przejedzie przez bramę. Trzymałem je w jednym rejestrze, a łącznik z niego czytał. Nie kopiowałem list na kilka urządzeń. Jedno źródło to jedno miejsce aktualizacji, jedno miejsce kontroli i żadnej chwili, w której dwa urządzenia różnią się w tym, kto może wjechać.

Wartość biznesowa to ciągłość

Najlepsze automatyzacje po wdrożeniu są ciche. Przenoszą dane, uruchamiają akcje i łączą narzędzia, które wcześniej wymagały człowieka. Wartość widać w mniejszej liczbie przerw i mniejszej liczbie próśb o ręczne sprawdzenie.

Kruchy skrypt oszczędza czas tylko wtedy, gdy ktoś go pilnuje. Niezawodna usługa oszczędza uwagę. Tego potrzebuje brama, raport albo czujnik.

Jeśli to brzmi znajomo

Opisz krótko źródło danych, kontekst urządzenia i efekt, którego potrzebujesz, przez sekcję kontaktu na stronie głównej. Możemy najpierw zaplanować najmniejszą niezawodną wersję razem z wymaganym dostępem do sieci, a potem zdecydować, czy potrzebny jest panel, integracja albo lista kontrolna wdrożenia.