Home Assistant na Proxmoxie od zera. Dobre praktyki, które naprawdę warto zastosować

Gdybym dzisiaj stawiał Home Assistanta od początku, nie zaczynałbym od MariaDB, wielkiego pliku configuration.yaml ani listy kilkudziesięciu „optymalizacji”. Najpierw zbudowałbym solidny fundament. W tej części pokazuję, jak podchodzę do HAOS na Proxmoxie, jakie ustawienia mają realne znaczenie i które popularne porady można spokojnie zostawić w przeszłości.

To nie będzie poradnik zbudowany na teoretycznej maszynie

Na potrzeby tej serii nie chcę tworzyć abstrakcyjnej konfiguracji typu „weź dowolny komputer z procesorem x86”. Punktem odniesienia jest sprzęt, którego rzeczywiście używam na co dzień. To niewielki FIREBAT T8 Plus z procesorem Intel N100, 16 GB pamięci RAM i dyskiem SSD 512 GB. Jeżeli dopiero wybierasz sprzęt, w kursie mam osobną lekcję o tym, na co patrzeć przy mini PC z Intel N100 pod Home Assistant i Proxmox.

Na tym komputerze działa Proxmox. Mam na nim produkcyjnego Home Assistanta OS, drugą instancję HAOS przeznaczoną do testów oraz kilka innych usług infrastrukturalnych i maszyn uruchamianych zależnie od potrzeb. Nie będę publikował topologii mojej sieci, adresów ani szczegółów konfiguracji. Nie są nam do niczego potrzebne. Interesują nas natomiast pomiary, zachowanie hosta i decyzje, które można później przełożyć na własną instalację.

I od razu ważne zastrzeżenie. To, że czegoś używam u siebie, nie oznacza automatycznie, że uznaję to za najlepszą praktykę. W tej serii każdą decyzję konfrontuję z aktualną dokumentacją Home Assistanta, dokumentacją Proxmoxa oraz doświadczeniami społeczności. Jeśli moja konfiguracja jest większa niż potrzeba, napiszę o tym. Jeśli coś dziś zrobiłbym inaczej, również to zaznaczę.

HAOS jako VM na Proxmoxie. Czy to rzeczywiście dobry pomysł?

Jeśli komputer ma służyć wyłącznie Home Assistantowi, nadal uważam instalację HAOS bezpośrednio na sprzęcie za bardzo dobre rozwiązanie. Jest prosta, ma mało ruchomych części i nie wymaga administrowania dodatkowym hypervisorem.

Jeżeli jednak chcemy wykorzystać mini-PC również do innych zadań, Proxmox zaczyna mieć dużo sensu. Właśnie dlatego używam go u siebie. Produkcyjny HA pozostaje osobną maszyną, mogę mieć obok środowisko testowe, kontroler sieci, DNS, dodatkowe usługi czy maszyny laboratoryjne i nie muszę mieszać ich bezpośrednio z systemem Home Assistanta. Jeśli zastanawiasz się jeszcze, czy sama wirtualizacja ma u Ciebie sens, zobacz lekcję Sprzęt pod Proxmox: kiedy warto planować wirtualizację.

Home Assistant oficjalnie udostępnia obraz QCOW2 przeznaczony dla KVM i Proxmoxa. Minimalne wymagania dla takiej maszyny to 2 vCPU i 2 GB RAM. Co ważne, zasoby VM możemy później zwiększyć, dlatego nie ma sensu na dzień dobry oddawać Home Assistantowi połowy serwera.

Intel N100 wygląda niepozornie. Do Home Assistanta to akurat zaleta

Intel N100 ma cztery rdzenie i cztery wątki, pracuje maksymalnie z częstotliwością 3,4 GHz, a Intel określa jego TDP na zaledwie 6 W. To nie jest procesor do dużych modeli językowych ani ciężkiego przetwarzania obrazu, ale jako serce małego serwera automatyki domowej sprawdza się bardzo dobrze.

W mojej instalacji produkcyjny HAOS ma obecnie przydzielone 4 vCPU i 8 GB RAM. To więcej, niż zaleciłbym osobie stawiającej świeżego HA. Ta maszyna nie uruchamia jednak tylko samego Core. W HAOS pracują również dodatkowe usługi, między innymi Zigbee2MQTT, broker MQTT, Node-RED, InfluxDB, Grafana, ESPHome, lokalne komponenty głosowe, monitoring i kilka innych aplikacji.

Mimo tego N100 nie jest u mnie blisko granicy swoich możliwości. Podczas normalnej pracy host Proxmox najczęściej wykorzystuje kilka procent CPU. W jednym z pomiarów bieżące wykorzystanie całego hosta wynosiło około 5,6%, a load average 0,16 / 0,27 / 0,33. To oczywiście tylko fotografia konkretnego momentu, a nie benchmark, ale dobrze pokazuje skalę obciążenia.

Mały smaczek: liczba rdzeni to nie wszystko. Sprawdź CPU Type

To jedna z tych rzeczy, o których łatwo nie pomyśleć przez kilka lat, bo Home Assistant działa poprawnie. Problem pojawia się dopiero po uruchomieniu czegoś bardziej wymagającego, na przykład lokalnego rozpoznawania mowy.

W Proxmoxie maszyna może widzieć ogólny, wirtualny model procesora zamiast wszystkich możliwości fizycznego CPU. W społeczności Home Assistanta są dobrze opisane przypadki, w których zwiększanie liczby vCPU praktycznie nie pomagało Whisperowi. Dopiero zmiana typu procesora VM na host udostępniła instrukcje AVX i radykalnie poprawiła przetwarzanie.

To szczególnie ciekawe w moim przypadku, bo Intel N100 sprzętowo obsługuje AVX2. Jeśli hypervisor nie pokaże tych instrukcji maszynie, mamy procesor posiadający konkretną funkcję, której aplikacja uruchomiona w VM nie potrafi wykorzystać.

Jest jednak wyjątek. W klastrze z różnymi procesorami ustawienie host może utrudnić live migration. Proxmox zaleca wtedy wybór kompatybilnego modelu CPU wspólnego dla węzłów. Dobra praktyka nie polega więc na mechanicznym ustawieniu jednej opcji. Trzeba wiedzieć, jaki problem rozwiązujemy.

RAM w Proxmoxie potrafi wyglądać groźnie, choć problemu nie ma

To jest mój ulubiony przykład z tej instalacji. Na wykresie produkcyjnej VM Proxmox pokazywał około 7,5 GB wykorzystanych z niespełna 8 GB przydzielonych. Na pierwszy rzut oka można dojść do prostego wniosku: Home Assistantowi kończy się RAM.

W tym samym czasie System Monitor wewnątrz Home Assistanta raportował około 2,8 GB używanej pamięci. Te wartości nie muszą być ze sobą sprzeczne, ponieważ host i system gościa patrzą na pamięć z różnych poziomów, a Linux wykorzystuje niewykorzystany RAM jako cache.

Wniosek jest ważniejszy niż same liczby. Nie zwiększam RAM-u VM tylko dlatego, że jeden wykres w Proxmoxie zrobił się niebieski prawie do końca. Patrzę na zachowanie systemu, memory pressure, OOM, swap, I/O delay oraz metryki od strony gościa.

Ballooning: nie wyłączam go odruchowo, ale nie pozwalam też zagłodzić HA

W wielu poradnikach dla Home Assistanta można znaleźć prostą radę: wyłącz ballooning. Po dokładniejszym sprawdzeniu dokumentacji Proxmoxa nie uważam tego za dobrą uniwersalną zasadę.

Proxmox zaleca pozostawienie Ballooning Device również wtedy, kiedy nie chcemy dynamicznie zmniejszać pamięci VM. Mechanizm dostarcza hypervisorowi dodatkowych informacji o wykorzystaniu pamięci gościa. Jeśli ustawimy maksymalną i minimalną pamięć na tę samą wartość, VM otrzyma stały przydział, ale samo urządzenie balloon nadal może pozostać aktywne.

Dlatego przy nowej, produkcyjnej VM zrobiłbym raczej:

Czego nie zrobiłbym? Nie ustawiłbym produkcyjnemu HAOS minimum 512 MB czy 1 GB tylko po to, żeby Proxmox mógł agresywnie odzyskiwać pamięć. Automatyka domu to nie jest najlepsze miejsce do walki o ostatnie kilkaset megabajtów RAM.

Dysk: VirtIO SCSI Single, IO Thread i jeden checkbox, o którym łatwo zapomnieć

Przy nowej VM wybieram SCSI z kontrolerem VirtIO SCSI Single. To nie jest tuning pod Home Assistanta. To po prostu bardzo sensowny sposób podłączenia wirtualnego dysku w Proxmoxie. Pozwala korzystać z parawirtualizowanego sterownika i IO Thread.

IO Thread włączam. Nie oczekuję dzięki temu magicznego przyspieszenia dashboardu. Chodzi o poprawne rozdzielenie obsługi I/O w warstwie wirtualizacji.

Discard, czyli usunąłem plik, ale Proxmox nadal uważa miejsce za zajęte

To jeden z bardziej praktycznych drobiazgów. Przy thin provisioning system gościa może usunąć kilka gigabajtów danych, ale storage hosta nie musi od razu wiedzieć, że odpowiadające im bloki można ponownie wykorzystać.

Włączenie Discard pozwala HAOS przekazywać polecenia TRIM/UNMAP do warstwy storage. Ma to sens wtedy, kiedy storage znajdujący się pod VM faktycznie wspiera reclaim, na przykład przy typowym thin provisioning.

Nie ustawiam natomiast bez powodu specjalnego cache dysku, writeback, niestandardowego AIO czy innych parametrów znalezionych w poradniku dotyczącym serwera bazodanowego. Domyślne ustawienia są punktem wyjścia. Tuning zaczyna się dopiero wtedy, gdy potrafię pokazać problem na pomiarach.

64 GB na HAOS? To nie jest wymaganie, tylko rozsądny zapas

Oficjalny obraz Home Assistanta startuje od mniejszego dysku i nic nie stoi na przeszkodzie, żeby później go powiększyć. Ja dla nowej instalacji dałbym 64 GB, ponieważ koszt takiej przestrzeni na współczesnym SSD jest niewielki, a daje wygodny margines na bazę, aplikacje, aktualizacje i dane dodatkowych usług.

Tutaj moja realna instalacja daje ciekawy punkt odniesienia. Produkcyjny HAOS ma obecnie około 129 GB dostępnego dysku i wykorzystuje około 47 GB. Jednocześnie sama baza Recordera SQLite ma około 709 MiB.

To ważne, bo gdy ktoś widzi kilkadziesiąt gigabajtów zajętego HAOS, łatwo odruchowo obwinić Recorder. Tymczasem przestrzeń wykorzystują również Apps i ich dane, InfluxDB, Grafana, ESPHome, multimedia, backupy i inne komponenty.

QEMU Guest Agent włączam od razu

QEMU Guest Agent tworzy dodatkowy kanał komunikacji pomiędzy Proxmoxem i systemem działającym wewnątrz VM. Oficjalna konfiguracja KVM Home Assistanta również przewiduje kanał guest agenta.

Po stronie Proxmoxa wchodzę więc w ustawienia VM i włączam QEMU Guest Agent. Nie próbuję przy tym instalować przypadkowych pakietów apt wewnątrz HAOS. Home Assistant OS jest systemem appliance. Jego środowiskiem systemowym zarządza Home Assistant, nie ja przez ręczne modyfikowanie Debiana pod spodem.

Sieć: VirtIO, bridge i stały adres bez ręcznego wpisywania IP

Na Proxmoxie zaczynam od VirtIO jako modelu wirtualnej karty sieciowej. Proxmox rekomenduje VirtIO ze względu na niski narzut. Home Assistant w swojej ogólnej dokumentacji wirtualizacji wspomina także E1000 i E1000E jako rozwiązania kompatybilne, dlatego nie traktuję modelu karty jak religii.

Jeżeli VirtIO działa poprawnie, zostawiam VirtIO. Gdybym miał nietypowe problemy z discovery czy multicastem, model wirtualnego NIC jest jedną z rzeczy, które sprawdziłbym diagnostycznie.

Sam Home Assistant powinien mieć przewidywalny adres IP. W domu preferuję rezerwację DHCP zamiast ręcznego adresu statycznego. Mam wtedy plan adresacji w jednym miejscu i mogę zmieniać parametry sieci centralnie.

Warto zachować także MAC wirtualnej karty. Home Assistant zwraca uwagę, że zmiana typu adaptera może zmienić nazwę interfejsu wewnątrz VM. Stały MAC powoduje natomiast, że istniejąca rezerwacja DHCP nadal może przydzielić ten sam adres.

Po restarcie Proxmoxa dom ma wrócić bez mojego udziału

W ustawieniach produkcyjnej VM włączam Start at boot. To brzmi banalnie, dopóki pierwszy raz nie zabraknie prądu podczas urlopu.

Po ponownym uruchomieniu hosta Home Assistant ma wystartować sam. Jeśli później wydzielę do osobnych LXC broker MQTT, Zigbee2MQTT czy bazę danych, wtedy dochodzi jeszcze Startup Order i opóźnienia pomiędzy usługami. Nie konfiguruję jednak zależności, których na razie nie mam.

FIREBAT ma jeszcze jedną bardzo przydatną opcję

W BIOS-ie T8 Plus można ustawić zachowanie po powrocie zasilania. Opcja State After G3 ustawiona na S0 State powoduje automatyczne uruchomienie komputera po ponownym pojawieniu się napięcia.

W serwerze automatyki domowej jest to znacznie bardziej użyteczne niż domyślne pozostanie komputera wyłączonego. Jeśli zasilanie zniknie na chwilę i wróci, chcę odzyskać kolejno hosta, HAOS i automatykę domu bez wciskania przycisku Power.

Zigbee przez USB w VM? Tak, to normalne rozwiązanie

W mojej produkcyjnej instalacji działa Zigbee2MQTT z brokerem Mosquitto i koordynatorem Sonoff USB. I nie, nie uważam, że z powodu Proxmoxa trzeba teraz wyrzucić dongla i kupić koordynator Ethernet.

Home Assistant w oficjalnej instrukcji KVM pokazuje nawet przykład przekazywania do VM Sonoff Zigbee 3.0 USB Dongle. USB passthrough jest więc jak najbardziej poprawną architekturą.

Ale sposób przypięcia USB ma znaczenie

Proxmox potrafi przypisać urządzenie USB między innymi według identyfikatora producenta i produktu albo według fizycznego portu hosta. To dużo lepsze podejście niż budowanie konfiguracji zależnej od przypadkowego numeru urządzenia, który może zmienić się po restarcie czy przepięciu.

Jeśli mam jedno urządzenie danego typu, vendor/product ID jest wygodny. Jeżeli podłączę dwa identyczne dongle mające ten sam identyfikator, lepsze może być związanie urządzenia z konkretnym fizycznym portem.

Jest też koszt takiej decyzji. Fizyczny dongle należy do konkretnego hosta. Nie wykonam pełnej live migration HAOS na inny serwer i nie oczekuję, że radio magicznie pojedzie razem z VM.

I tutaj koordynator Ethernet lub PoE zaczyna mieć realną zaletę. Uniezależnia warstwę radiową od fizycznego serwera. To jednak decyzja architektoniczna, a nie obowiązkowy upgrade dla każdego posiadacza działającego Sonoffa.

Snapshot przed aktualizacją? Tak, ale warto wiedzieć, co zmieniło się w HAOS

W starszych dyskusjach można znaleźć ostrzeżenia, że snapshot pracującej VM z SQLite może pozostawić bazę w niespójnym stanie. To kiedyś było realne ryzyko.

W Home Assistant OS 11 wprowadzono bardzo ciekawą zmianę przygotowaną właśnie z myślą o środowiskach KVM i Proxmox. Gdy hypervisor wykonuje filesystem freeze podczas snapshotu, informacja jest przekazywana do Home Assistanta. Recorder może wtedy przygotować SQLite lub MariaDB podobnie jak podczas natywnego backupu.

Innymi słowy, współczesny HAOS znacznie lepiej współpracuje ze snapshotami VM niż stare wersje.

Snapshot nadal nie jest backupem. Jeśli umrze SSD z VM i snapshotem, stracę oba. Snapshot odpowiada na pytanie „jak szybko cofnąć ostatnią zmianę?”, a backup odpowiada na pytanie „jak odzyskać system, gdy sprzęt albo dane naprawdę znikną?”.

Home Assistant sam jest dziś znacznie lepszy w backupach niż kilka lat temu

To kolejna rzecz, która zmienia stare best practices. Home Assistant potrafi wykonywać automatyczne backupy, zarządzać retencją i wysyłać kopie do skonfigurowanych lokalizacji. Przy aktualizacji może też utworzyć świeży backup przed rozpoczęciem operacji.

Od wersji 2025.5 ustawienie backupu przed aktualizacją można ustawić jako domyślne. Home Assistant potrafi również poczekać z restartem, jeśli backup właśnie trwa. To niby drobiazgi, ale właśnie z takich drobiazgów powstaje system, którego nie trzeba pilnować przy każdej aktualizacji.

U siebie używam dodatkowego fizycznego miejsca na backupy oraz kopii poza hostem w Google Drive. Do tego mam możliwość wykonania niezależnego backupu całej VM w Proxmoxie. Jeżeli chcesz przejść temat od harmonogramu po test restore, zobacz lekcję Backup i restore: automatyczne kopie zapasowe bez których nie ruszasz dalej.

Jedno nie wyklucza drugiego. Koszt utrzymywania obu warstw jest niewielki, a scenariusze awarii są różne.

Backup bez klucza może okazać się bezużyteczny

To jeden z najbardziej praktycznych wniosków z historii użytkowników Home Assistanta. Można mieć perfekcyjnie działający automatyczny backup do chmury i dopiero po awarii odkryć, że klucz potrzebny do odszyfrowania kopii został na komputerze, który już nie istnieje.

Dlatego Emergency Kit przechowuję poza Home Assistantem. Nie w katalogu HA, nie tylko na tym samym serwerze i nie w miejscu, do którego dostanę się wyłącznie wtedy, gdy działa infrastruktura, którą właśnie próbuję odzyskać.

Jest jeszcze trzeci backup, o którym prawie nikt nie pamięta

Możemy mieć backup Home Assistanta. Możemy mieć backup wszystkich VM i LXC. A potem może umrzeć systemowy dysk hosta Proxmox.

Oczywiście da się zainstalować świeżego Proxmoxa i odtworzyć maszyny. Problem w tym, że backup VM nie jest automatycznie backupem całej konfiguracji hosta. Sieć, storage, ustawienia hosta czy część konfiguracji infrastruktury trzeba będzie odtworzyć.

Kluczową częścią konfiguracji PVE jest pmxcfs. Proxmox opisuje procedurę recovery wykorzystującą między innymi plik /var/lib/pve-cluster/config.db. Nie oznacza to, że codziennie wykonuję obraz całego systemu Proxmox. Oznacza, że w planie disaster recovery uwzględniam również hosta, a nie tylko to, co działa na nim jako VM.

Dysk może ostrzegać przed awarią. Pod warunkiem, że zobaczysz ostrzeżenie

Proxmox ma narzędzia SMART do monitorowania lokalnych dysków. smartd może okresowo sprawdzać nośniki i zgłaszać problemy. Sam fakt, że mechanizm istnieje, nie wystarczy jednak, jeśli wszystkie komunikaty trafiają do lokalnej skrzynki roota, której nikt nigdy nie otwiera.

Współczesny Proxmox ma system powiadomień obsługujący między innymi SMTP, Gotify i webhooki. Dobra praktyka nie brzmi więc „sprawdzaj SMART raz na pół roku”. Brzmi: skonfiguruj system tak, żeby sam powiedział Ci o problemie z dyskiem, backupem czy innym krytycznym zdarzeniu.

W małym serwerze z jednym SSD to szczególnie ważne. Dysk jest jednocześnie małym, tanim i bardzo istotnym pojedynczym punktem awarii.

Drugi HAOS do testów to jedna z rzeczy, które naprawdę lubię w Proxmoxie

Na tym samym N100 mam również osobną instancję Home Assistanta przeznaczoną do testowania. To jedna z zalet wirtualizacji, którą łatwo niedocenić. Mogę sprawdzić nową konfigurację, integrację czy większą zmianę bez robienia eksperymentu na systemie sterującym domem.

Nie oznacza to jednak, że bezmyślnie klonuję produkcję i uruchamiam jej identyczną kopię w tej samej sieci. Klon może mieć ten sam hostname, konfigurację sieci, tokeny, integracje oraz automatyzacje próbujące sterować tymi samymi urządzeniami.

Testowy HA powinien mieć własną tożsamość sieciową, a jeśli korzystam z kopii konfiguracji produkcyjnej, bardzo uważam na automatyzacje i integracje mające realny wpływ na dom.

A co z bezpieczeństwem samego Proxmoxa?

Ten temat rozwinę osobno, ale kilka rzeczy traktuję jako fundament. Interfejs zarządzający Proxmoxa i SSH nie powinny być po prostu wystawione do Internetu. Dostęp administracyjny trzymam w zaufanej sieci albo przez VPN. Jeżeli chcesz uporządkować bezpieczeństwo od podstaw, zacznij od lekcji Bezpieczeństwo Home Assistant: co jest realnym zagrożeniem, a co straszeniem.

Włączam 2FA dla panelu administracyjnego. Do SSH preferuję klucze zamiast logowania hasłem. Jeżeli wyłączam logowanie hasłem, robię to dopiero po sprawdzeniu, że dostęp kluczem rzeczywiście działa.

Nie traktuję natomiast zmiany portu SSH z 22 na losowy numer jako ważnego zabezpieczenia. Może ograniczyć automatyczny szum w logach, ale nie zastępuje firewalla, VPN, kluczy SSH i właściwego ograniczenia dostępu.

Podobnie z Fail2Ban. To przydatna dodatkowa warstwa w określonych scenariuszach, ale jeśli interfejs zarządzający w ogóle nie jest dostępny z Internetu, nie zaczynam budowy bezpieczeństwa od instalowania kolejnego demona. Jeśli później chcesz pójść krok dalej i wydzielić IoT od komputerów domowych, warto przeczytać lekcję Sieć i VLAN dla urządzeń IoT.

Czego celowo nie robię po postawieniu świeżego HAOS

I tutaj dochodzimy do rzeczy, od której zaczęła się cała seria. Po pierwszym poprawnym uruchomieniu Home Assistanta bardzo łatwo otworzyć stary poradnik i zacząć „poprawiać” nową instalację.

Najpierw uruchamiam system. Potem go obserwuję.

Czy SQLite nadal nadaje się do poważnej instalacji? U mnie nadal działa

Nie chcę jeszcze rozwijać tego tematu, bo będzie mu poświęcona cała kolejna część, ale moja instalacja daje tutaj bardzo ciekawy przykład.

Produkcyjny Home Assistant korzysta nadal z SQLite jako bazy Recordera. W chwili wykonywania pomiaru baza miała około 709 MiB. Jednocześnie w systemie działa sporo integracji i Apps, między innymi Zigbee2MQTT, MQTT, Node-RED, InfluxDB2, Grafana, ESPHome, Music Assistant, monitoring i komponenty Voice.

Mam również InfluxDB, ale to bardzo ważne, nie jest on zamiennikiem bazy Recordera. Home Assistant nadal zapisuje swoją historię do SQLite. InfluxDB działa równolegle jako dodatkowa baza danych czasowych, którą mogę wykorzystać między innymi do długoterminowych analiz w Grafanie.

Nie wyciągam z tego wniosku, że SQLite wystarczy każdemu. Wyciągam znacznie bezpieczniejszy wniosek:

Co więcej, aktualna dokumentacja Home Assistanta nazywa SQLite domyślnym i rekomendowanym silnikiem bazy danych Recordera. Jeśli temat bazy interesuje Cię już teraz, pełne rozwinięcie jest w lekcji o Recorderze, SQLite, MariaDB i PostgreSQL.

Moja checklista przed dodaniem pierwszej żarówki

Gdybym jutro dostał pustego mini-PC i miał zbudować nową instalację od początku, zanim zacząłbym dodawać Zigbee, ESPHome czy pierwszą automatyzację, chciałbym mieć odhaczone następujące rzeczy.

Najważniejsza dobra praktyka nie jest żadnym ustawieniem

Im dłużej używam Home Assistanta, tym mniej podoba mi się podejście polegające na zbieraniu „obowiązkowych tweaków”. MariaDB, InfluxDB, Grafana, osobny MQTT, osobny Zigbee2MQTT, VLAN-y, dodatkowy reverse proxy, kilka systemów monitoringu i dziesiątki zmian w konfiguracji mogą być świetnymi rozwiązaniami.

Ale tylko wtedy, kiedy wiemy, po co je dodajemy.

Jeżeli SQLite działa, nie wymieniam go dlatego, że ktoś w 2018 roku miał problemy z kartą SD.

Jeżeli 2 vCPU wystarczają, nie daję ośmiu.

Jeżeli Zigbee przez USB działa stabilnie, nie wymieniam koordynatora tylko dlatego, że Ethernet jest dziś modniejszy.

Jeżeli natomiast backup istnieje tylko na tym samym SSD co Home Assistant, nie mówię sobie, że „kiedyś to poprawię”. To jest rzecz, którą poprawiam od razu.

W części 2: SQLite, MariaDB, Recorder i InfluxDB bez mitów

Kolejna część będzie dotyczyła rzeczy, od której zaczęło się pytanie inspirujące tę serię. Czy w 2026 roku nadal warto po instalacji Home Assistanta od razu przechodzić na MariaDB?

Sprawdzimy dokładnie, co zapisuje Recorder, dlaczego domyślnie przechowuje szczegółową historię tylko przez określony czas, czym są statystyki długoterminowe, co naprawdę powiększa bazę i kiedy MariaDB daje korzyść, a kiedy dokłada tylko kolejny element wymagający administracji.

Pokażę też mój rzeczywisty przypadek: SQLite pracujący równolegle z InfluxDB i Grafaną, bez przenoszenia Recordera do zewnętrznej bazy. Zobaczymy, dlaczego InfluxDB nie zastępuje SQLite, co warto archiwizować przez lata i jak nie doprowadzić do sytuacji, w której backup Home Assistanta waży kilkadziesiąt gigabajtów.

Bo dobra praktyka nie polega na tym, żeby zastosować najbardziej rozbudowane rozwiązanie. Polega na tym, żeby zastosować rozwiązanie właściwe dla problemu, który rzeczywiście mamy.