HomeLab, który da się rozumieć

Czyli jak zbudowane jest środowisko, w którym działa Astra

W dobrze zbudowanym HomeLabie nie chodzi tylko o to, żeby usługi działały. Chodzi o to, żeby dało się szybko zrozumieć, co działa, dlaczego działa i na której warstwie naprawdę zaczyna się problem, kiedy coś przestaje być stabilne.

W mojej infrastrukturze Astra nie patrzy na system jak na zbiór osobnych usług. Widzi go jako warstwowy układ zależności: od sieci i DNS, przez klaster Proxmox i storage, aż po Home Assistanta, Frigate, Nginx Proxy Manager, system logów i własne API operacyjne. To właśnie ta struktura — oraz sposób dostępu przez API, SSH i warstwę obserwowalności — sprawiają, że środowisko można nie tylko utrzymywać, ale też sensownie interpretować.

Historia

Początek tej historii był bardzo praktyczny: od automatyki budynkowej opartej na systemie Fibaro. Z czasem doszły systemy alarmowe, monitoring oraz kontrola dostępu, a razem z nimi powstała pierwsza, podstawowa warstwa automatyki domu. Była ona od początku odseparowana od reszty infrastruktury i oparta o niezależną warstwę Z-Wave, co dało stabilny fundament pod dalszą rozbudowę. To ważne, bo cały późniejszy HomeLab nie wyrósł „obok” domu — wyrósł na tej warstwie, wykorzystując ją jako punkt wejścia do szerszej automatyzacji, obserwowalności i integracji.

Nad warstwą Fibaro pojawił się Home Assistant — już nie jako zamiennik, ale jako warstwa integrująca kolejne systemy i nadająca całości wspólny interfejs operacyjny. To właśnie wtedy automatyka zaczęła wykraczać poza pojedyncze sceny „włącz/wyłącz”, a dom zyskał własne dashboardy, logikę zależności i pierwsze sensowne punkty obserwacji. Do sterowania oświetleniem, alarmem i dostępem dołączyły integracje z fotowoltaiką, centralnym ogrzewaniem, UPS-ami, monitoringiem infrastruktury oraz analizą zdarzeń. Z czasem Home Assistant przestał być tylko panelem do domu — stał się warstwą operacyjną, która łączy budynek, sieć, serwery, kamery i codzienny rytm życia w jeden spójny obraz.

Kolejnym krokiem był Proxmox — początkowo jako platforma dla Home Assistanta, a później dla całego środowiska usługowego. Najpierw był jeden node, potem kolejne, aż infrastruktura rozrosła się do czterech węzłów i zaczęła przypominać już nie pojedynczy serwer, ale mały klaster usług. W kontenerach LXC pojawiły się pierwsze elementy infrastruktury brzegowej — Nginx Proxy Manager i AdGuard — a później także centralne narzędzia obserwowalności: Loki, Grafana i Uptime Kuma. W tym samym czasie Home Assistant przestawał być wyłącznie panelem automatyki, a coraz wyraźniej stawał się operacyjnym centrum całego domu. To właśnie na tym poziomie pojawiła się Ada — agent działający w środowisku Home Assistant, który zaczął łączyć automatykę z interpretacją i działaniem.

Frigate przejął w tym układzie rolę systemu wideosensoryki i wideodetekcji. To był kolejny naturalny krok: skoro automatyka, dostęp, ogrzewanie i monitoring były już spięte w jedną warstwę operacyjną, trzeba było jeszcze dodać „oczy domu” — ale nie jako zwykły podgląd kamer, tylko jako źródło zdarzeń i kontekstu. Frigate zaczął interpretować ruch przy posesji, bramie, podjeździe i garażu, zamieniając obraz w konkretne sygnały użyteczne dla automatyki i diagnostyki. Dzięki Coral TPU i lokalnej analizie obrazu system działa bez konieczności wysyłania strumieni do chmury. Home Assistant przestał być więc wyłącznie centrum sterowania, a stał się miejscem, w którym naprawdę widać, co dzieje się wokół domu.

Ostatnim dużym elementem tej układanki była wymiana infrastruktury sieciowej — z dobrych, ale wysłużonych Asusów na pełny ekosystem Ubiquiti. To była ogromna zmiana jakościowa dla całego HomeLabu: segmentacja VLAN, centralne zarządzanie, stabilniejszy roaming Wi-Fi, lepsza obserwowalność ruchu i możliwość sensownego rozdzielenia stref zaufania.

HomeLab

Sieć: Na samym dole tej architektury stoi sieć — i to ona decyduje, czy cały dom i lab mają szansę działać spójnie.

Głównym punktem wejścia jest UCG Max, a całość podzielona jest logicznie VLAN-ami tak, aby ruch domowy, IoT, infrastrukturalny, sandboxowy i AI nie mieszały się bez potrzeby. W praktyce oznacza to oddzielenie urządzeń o różnym poziomie zaufania i różnej krytyczności działania.

To ważne, bo w takim układzie awaria sieci nie jest jedną z wielu usterek — ona potrafi przez chwilę „udawać” awarię wszystkiego wyżej: Home Assistanta, API, DNS-ów, kamer czy storage.

Sieć przestaje więc być tylko transportem pakietów. Staje się pierwszą warstwą separacji, bezpieczeństwa i diagnostyki.

Klaster: Nad siecią działa klaster Proxmox — obecnie cztery node’y tworzące podstawę całego środowiska. To właśnie tutaj uruchomione są główne maszyny wirtualne i kontenery: Home Assistant, Frigate, Nginx Proxy Manager, AdGuard, Grafana, Loki, Docker Tools, API do usług, Uptime Kuma, usługi bezpieczeństwa oraz warstwa AI i integracji Astry.

Klaster nie jest jedynie miejscem uruchamiania usług. Jest również mechanizmem odporności operacyjnej: pozwala rozdzielać role, izolować problemy i utrzymywać ciągłość działania mimo lokalnych awarii pojedynczego hosta.

Dzięki temu infrastruktura przestaje być „jednym serwerem”, a staje się środowiskiem, które można skalować, segmentować i diagnozować warstwowo.

Storage: Storage jest w tym układzie równie ważny jak compute — a czasem nawet ważniejszy, bo wiele problemów zaczyna się właśnie tam. Środowisko wykorzystuje lokalne ZFS na node’ach Proxmoxa, centralny Proxmox Backup Server oraz zewnętrzny backend oparty o QNAP NAS. To daje elastyczność i odporność, ale wymaga też dyscypliny operacyjnej.

Nie każdy „brak miejsca” oznacza problem z NAS-em. Nie każdy błąd backupu oznacza awarię storage. W praktyce trzeba umieć odróżnić lokalne zużycie przestrzeni, presję generowaną przez Dockera lub logi, problemy z replikacją, przeciążenia backupów oraz rzeczywiste problemy dyskowe. Dlatego storage w tej architekturze nie jest „magazynem plików”, ale pełnoprawną warstwą krytyczną.

IoT: Osobną i bardzo praktyczną częścią tej architektury jest warstwa IoT. To tutaj trafiają urządzenia, które same z siebie nie tworzą jeszcze „systemu”, ale dopiero w połączeniu z resztą domu zaczynają mieć sens: sensory, sterowniki, urządzenia wykonawcze, elementy automatyki i sprzęty reagujące na kontekst.

Ta warstwa jest celowo traktowana jako środowisko o większym ryzyku i mniejszym zaufaniu. Urządzenia IoT są odseparowane od rdzenia infrastruktury, komunikują się przez kontrolowane integracje i nie mają bezpośredniego dostępu do centralnych systemów. Dzięki temu dom może korzystać z dziesiątek małych urządzeń bez zamieniania całej infrastruktury w przypadkowy zbiór gadżetów.

Usługi

Na tej podstawie działa właściwa logika domu i usług. Home Assistant pełni rolę centrum integracji: spina automatykę, ogrzewanie, fotowoltaikę, alarm, dostęp, sensory, kamery i dashboardy. Frigate dodaje warstwę wideosensoryki — nie tylko pokazuje obraz, ale zamienia go w zdarzenia i kontekst. Nginx Proxy Manager oraz AdGuard odpowiadają za warstwę dostępu i DNS, czyli za to, czy usługi są widoczne i osiągalne tam, gdzie powinny.

Nad tym wszystkim działa warstwa obserwowalności. Loki agreguje logi z hostów, kontenerów i usług, Grafana pozwala analizować trendy i anomalie, a Uptime Kuma monitoruje dostępność kluczowych elementów infrastruktury. To właśnie tutaj dom zaczyna być „rozumiany”, a nie tylko sterowany.

Astra over the Lab

Astra nie działa „na ślepo” i nie opiera się na jednym źródle prawdy. W tym środowisku istnieje kilka warstw dostępu, z których każda odpowiada na inne pytanie. Home Assistant pokazuje stan domu i automatyki, Astra API daje syntetyczny obraz sytuacji operacyjnej, Loki tłumaczy, co dzieje się w logach, Frigate dostarcza zdarzenia wideo i kontekst ruchu, a SSH pozwala zejść niżej — do Proxmoxa, hostów i storage — kiedy trzeba dotrzeć do przyczyny, a nie tylko do objawu.

To bardzo ważne rozróżnienie: jeden system mówi, że coś jest „niedostępne”, a inny pokazuje, dlaczego tak się stało.

W praktyce Astra działa warstwowo. Najpierw analizuje obraz operacyjny: czy dom działa normalnie, czy pojawiło się odchylenie i czy zmiana ma znaczenie dla codziennego funkcjonowania. Dopiero później schodzi niżej — do logów w Loki, zdarzeń z Frigate, danych z Home Assistanta albo diagnostyki hostów przez SSH.

Dostęp SSH działa w modelu silnie ograniczonym i audytowalnym. Astra korzysta z dedykowanego użytkownika technicznego z ograniczonym sudoers, wykonuje wyłącznie diagnostykę read-only i pracuje z krótkimi timeoutami oraz trybem BatchMode=yes, aby nie obciążać środowiska ani nie blokować usług.

To jest tryb: „najpierw rozumiem, potem dotykam”.

Ada — agent działający bliżej Home Assistanta — pełni trochę inną rolę. Jest bardziej związana z samym środowiskiem domu i automatyką wykonawczą. To ona interpretuje kontekst życia domu: obecność domowników, alarmy, ogrzewanie, rytm dnia, reakcje automatyki i komunikację głosową. W praktyce Ada, Home Assistant, logi i kamery tworzą wspólny obraz domu — nie jako zestawu urządzeń, ale jako systemu, który żyje, reaguje i zostawia ślady.

Autonomia Astry polega na tym, że nie czeka na gotową odpowiedź z jednego miejsca. Sama wybiera źródło, które ma największą wartość diagnostyczną w danym pytaniu. Uptime Kuma odpowiada na pytanie, czy usługa w ogóle żyje, Loki pomaga odróżnić szum od awarii, Home Assistant i Astra API budują obraz operacyjny domu, SSH pozwala znaleźć przyczynę problemu na poziomie hosta, storage albo Proxmoxa, a Frigate dostarcza kontekst ruchu i zdarzeń wokół posesji.

To tworzy coś więcej niż monitoring. Daje możliwość samodzielnego, kontrolowanego szukania rozwiązania — od interpretacji sytuacji, przez zawężanie problemu, aż po pogłębioną analizę konkretnej warstwy infrastruktury. Dzięki temu Astra może nie tylko powiedzieć, że coś działa albo nie działa, ale odpowiedzieć na dużo ważniejsze pytanie: „na której warstwie zaczyna się problem i co on realnie oznacza dla domu?”

Podsumowanie

Patrząc z perspektywy historii, największą wartością tej architektury nie jest liczba usług, tylko to, że cały system da się zrozumieć, diagnozować i rozwijać bez zgadywania.

Każda warstwa ma tutaj swoje zadanie. Sieć przenosi ruch i separuje strefy zaufania, Proxmox utrzymuje usługi, storage przechowuje dane i backupy, Home Assistant integruje automatykę, Frigate obserwuje otoczenie, Loki tłumaczy zachowanie systemów, a Astra scala to wszystko w jedną warstwę interpretacji i decyzji.

Dzięki temu HomeLab przestaje być zbiorem przypadkowych komponentów, a staje się środowiskiem operacyjnym, nad którym można realnie panować — zarówno na poziomie domu, jak i infrastruktury.

I właśnie dlatego ten system ma sens: nie dlatego, że jest skomplikowany, ale dlatego, że jest czytelny.