Mały serwer może zapewniać niezawodne sterowanie Home Assistantem w całym domu, jeśli ścieżka wrażliwa na opóźnienia pozostaje prosta, a zadania wykonywane w tle nie przeciążają tych samych zasobów procesora, pamięci, pamięci masowej ani sieci. Celem nie jest maksymalizacja funkcji panelu ani przechowywanie jak największej ilości historii, lecz zachowanie przewidywalnego czasu od odczytu czujnika do wykonania działania w najbardziej intensywnych, ale typowych warunkach domowych.
Zacznij od jednej reprezentatywnej lokalnej automatyzacji i zmierz jej działanie, gdy system jest bezczynny. Następnie dodawaj kolejno aktywność Rejestratora, panele, kopie zapasowe, zadania związane z kamerami lub multimediami oraz inne kontenery. Dostosuj obciążenie, które zmienia opóźnienie sterowania, zamiast stosować ogólne ustawienia „wydajności” do każdego komponentu.
Chroń ścieżkę sterowania w czasie rzeczywistym, zanim zoptymalizujesz historię
Prześledź jedną krytyczną automatyzację od wyzwalacza do działania: zdarzenie urządzenia, aktualizacja stanu Home Assistanta, ocena automatyzacji, wywołanie usługi i odpowiedź urządzenia. Ta ścieżka powinna w miarę możliwości pozostawać lokalna i nie powinna zależeć od zapytania do historii w panelu ani od usługi w chmurze niezwiązanej z fizycznym działaniem.
Jeśli oświetlenie reagujące na ruch działa szybko, a wykresy historii wolno, traktuj te problemy osobno. Jeśli oba elementy zwalniają podczas intensywnych zapisów lub pracy innego kontenera, bardziej prawdopodobną przyczyną jest współdzielony host albo ścieżka pamięci masowej.
Omówienie w ZimaSpace dotyczące utrzymywania lokalnej ścieżki od czujnika do działania stanowi właściwy punkt odniesienia: niezawodne sterowanie całym domem potwierdza się na ścieżce, która musi działać także wtedy, gdy opcjonalne usługi znikną.
Ogranicz pracę Rejestratora, która nie przynosi korzyści domownikom
Rejestrator może generować stały strumień zapisów do bazy danych przez szybko zmieniające się encje, rozbudowane atrybuty i zdarzenia, do których nikt później nie zagląda. Większa ilość danych nie oznacza automatycznie bardziej użytecznej historii.
W jednym z niedawnych przypadków dotyczących Rejestratora Home Assistanta ograniczono przyrost bazy danych z około 160 MB dziennie do mniej niż 50 MB, wykluczając głośne encje i zawężając przechowywaną historię. Najważniejsza lekcja nie polega na tym, że każda instalacja powinna skopiować te wykluczenia, lecz na tym, że ilość zapisów powinna odpowiadać informacjom faktycznie wykorzystywanym przez domowników.
Zidentyfikuj czujniki o wysokiej częstotliwości zmian, duże atrybuty, encje diagnostyczne oraz integracje powodujące niepotrzebne zmiany stanów. Usuń tylko dane, których nie potrzebujesz do automatyzacji, historii, statystyk ani rozwiązywania problemów, a następnie porównaj przyrost bazy danych i opóźnienie sterowania, zanim wprowadzisz kolejną zmianę.
Nie pozwól, aby opóźnienia bazy danych stały się problemem współdzielonego hosta
Małe hosty Home Assistanta często mają wystarczająco dużo procesora, ale większość czasu spędzają na oczekiwaniu na pamięć masową. Zapisy do bazy danych, zapytania do historii, kopie zapasowe, aktualizacje i inne kontenery mogą współdzielić jeden dysk SSD lub urządzenie flash, powodując kolejkowanie niewidoczne na przeciętnym wykresie użycia procesora.
Niezależny poradnik dotyczący baz danych Home Assistanta wskazuje, że zmiana silnika bazy danych nie jest uniwersalnym lekarstwem na problemy z wydajnością. Najpierw zmierz czas obsługi pamięci masowej i zachowanie bazy danych, a dopiero potem zdecyduj, czy rzeczywisty problem rozwiąże szybsza pamięć masowa, mniejsza liczba rejestrowanych encji czy inna topologia bazy danych.
Przechowuj stan aplikacji na niezawodnej pamięci masowej o niskich opóźnieniach. Duże pliki multimedialne, archiwa nagrań z kamer i kopie zapasowe umieszczaj gdzie indziej, jeśli generują długotrwały ruch sekwencyjny konkurujący z bazą danych.
Planuj intensywne zadania w tle poza szczytem sterowania
Kopie zapasowe, konserwacja bazy danych, indeksowanie nagrań z kamer, skanowanie multimediów, aktualizacje pakietów i lokalne zadania AI mogą powodować krótkie okresy presji na procesor, pamięć masową lub pamięć operacyjną, których nie widać na zrzucie ekranu wykonanym w stanie bezczynności. Zanim kupisz mocniejszy sprzęt, przenieś elastyczne zadania wsadowe na spokojniejszą porę.
Nie zakładaj, że północ zawsze jest spokojna. Duża liczba czujników, harmonogramy ogrzewania, zadania związane z energią lub konserwacja Rejestratora mogą już działać w nocy. Zanim dodasz kolejne zaplanowane zadanie do tego samego przedziału czasowego, porównaj rzeczywistą oś czasu zdarzeń i wykorzystania zasobów.
Jeśli jedno zadanie w tle powoduje opóźnienia automatyzacji tylko podczas działania, ogranicz je albo przełóż na inny termin. Jeśli ścieżka sterowania pozostaje powolna po zakończeniu zadania, kontynuuj diagnozę, sprawdzając zasób, który nie powrócił do normalnego stanu.
Utrzymuj współhostowane usługi w ramach zmierzonego budżetu
Home Assistant często działa obok MQTT, Zigbee2MQTT, Pi-hole, Node-RED, oprogramowania do obsługi kamer, serwerów multimediów lub narzędzi do tworzenia kopii zapasowych. Te usługi nie są „darmowe” tylko dlatego, że host przez większość czasu jest bezczynny.
Uruchom zwykłą lokalną automatyzację, gdy działa najcięższe spodziewane obciążenie towarzyszące. Obserwuj jednocześnie nasycenie procesora, dostępną pamięć, użycie pamięci wymiany, opóźnienia pamięci masowej i zachowanie sieci. Pierwszy zasób, którego presja pokrywa się z opóźnieniem sterowania, jest komponentem wymagającym dostrojenia.
Na bardzo małym serwerze oddzielenie jednej ciężkiej usługi może być rozsądniejsze niż modernizacja każdego komponentu. Aktualny poradnik ZimaSpace dotyczący doboru sprzętu do domowego laboratorium zaleca przejście na mocniejszy sprzęt dopiero wtedy, gdy rzeczywiste obciążenie kontenerów, multimediów, indeksowania lub maszyn wirtualnych regularnie wymaga dodatkowego zapasu zasobów.
Gdy host jest współdzielony, monitoruj presję na zasoby, a nie procenty bezczynności. Model presji w systemie Linux rozróżnia dostępną moc obliczeniową od pracy, która faktycznie oczekuje, a właśnie to rozróżnienie ma znaczenie, gdy Home Assistant musi zachować responsywność obok usług wsadowych.
Zakończ dostrajanie, gdy minie okres największego obciążenia
| Zaobserwowany objaw | Najbardziej użyteczny kolejny test | Unikaj |
|---|---|---|
| Historia działa wolno, sterowanie urządzeniami jest szybkie | Ścieżka Rejestratora/bazy danych | Wymiany procesora w pierwszej kolejności |
| Sterowanie zwalnia tylko podczas tworzenia kopii zapasowej | Konkurencja o pamięć masową/procesor | Zmiany logiki automatyzacji |
| Opóźnia się tylko jedna integracja | Ścieżka integracji/urządzenia/sieci | Globalnych zmian w Rejestratorze |
| Host korzysta z pamięci wymiany podczas normalnego szczytu | Zestaw roboczy pamięci | Dodawania kolejnych paneli do testów |
| Wszystko działa poprawnie przy normalnym nakładaniu się obciążeń | Zakończ | Optymalizacji pod kątem wyników testów porównawczych |
Dobrze dostrojony mały serwer Home Assistanta to nie maszyna z najniższym procentem użycia procesora w stanie bezczynności. To maszyna, na której najważniejsze automatyzacje zachowują przewidywalność, gdy Rejestrator, panele, kopie zapasowe i zwykłe usługi towarzyszące wykonują swoją codzienną pracę.
Wsparcie i wskazówki
Więcej do przeczytania

Czy podczas tworzenia kopii zapasowej Home Assistant Live należy zatrzymać usługę?
Wbudowane kopie zapasowe Home Assistant mogą działać na żywo; zwykłe kopie systemu plików powinny zatrzymać Home Assistant lub wstrzymać jego działanie, chyba że baza...

Dlaczego serwer Home Assistant nagrzewa się lub hałasuje w czasie bezczynności?
Zanim zmienisz ustawienia chłodzenia lub limity procesora, skoreluj skoki obciążenia wentylatora lub temperatury w Home Assistant z działaniem Rejestratora, kopiami zapasowymi, integracjami i współdzielonymi...

Kiedy lepiej zbudować Home Assistant od nowa zamiast go naprawiać?
Najpierw napraw najmniejszą uszkodzoną warstwę Home Assistant, następnie przywróć znany dobry stan, a odbudowę wykonuj tylko wtedy, gdy nie można ufać trwałej konfiguracji.

