W tym artykule zrobimy sobie przerwę od zagadnień związanych z obsługą kamer. Jednak jeszcze do nich wrócimy. Zajmiemy się natomiast tematem, który często wraca w Waszych pytaniach do mnie. Dotyczą one malejącej wydajności HA szczególnie po kilku miesiącach działania z dużą ilością czujników, sensorów, dodatków itp. itd.

Powodem takiej sytuacji może być rozrastająca się baza danych, która przechowuje wszystkie informacje o zmianach stanów poszczególnych elementów systemu. Standardowo HA przechowuje wszystko w bazie danych wykorzystującej silnik SQLite, a wszystkie dane przechowywane są w pliku bazy danych home-assistant_v2.db. Silnik ten jest rozwiązaniem wygodnym bo nie wymaga specjalnej konfiguracji i może łatwo zostać uruchomiony z daną aplikacją. Jednak ma pewne ograniczenia szczególnie przy dużej ilości danych. Rozwiązań tego problemu i zarazem uzyskanie poprawy wydajności samego HA może być co najmniej kilka. Do najpopularniejszych należą:

  1. Ograniczenie danych zapisywanych w bazie - tylko do tych, które faktycznie nas interesują
  2. Wyczyszczenie danych historycznych tak aby zmniejszyć ilość danych przechowywanych co wpłynie na poprawę działania.
  3. Uruchomienie zewnętrznej bazy, która lepiej obsłuży dużą ilość rekordów. Dla dużych systemów można nawet wydzielić osobny serwer tylko na bazę danych.

Zanim przejdziemy do omówienia każdego z powyższych rozwiązań to najpierw informacja ogólna.

Mechanizmem sterującym zapisem danych do bazy dla systemu HA jest tzw. recorder. To właśnie modyfikując jego konfigurację sterujemy sposobem obsługi bazy danych. Dlatego wszystkie powyższe sposoby na poprawienie wydajności modyfikują ten moduł systemu HA.

Ograniczenie danych zapisywanych w bazie

Do sterowania zakresem danych trafiających do bazy służą nam dwa parametry modułu recorder: include oraz exclude.

Include - odpowiada za określenie jaki zakres danych ma być rejestrowany w bazie. Ważne, że jeżeli zdefiniujemy parametr include to wszystko co nie łapie się na podany zakres będzie pomijane i nie będzie zapisywane w bazie. Sposobów na określenie zakresu danych są dwa: domains (określa domenę z jakiej pochodzą informacje np: sensor) oraz entities (jest to lista konkretnych encji z jakich chcemy zbierać dane).

Exclude - odpowiada za określenie jaki zakres danych ma być pomijany przy zapisie do bazy. Zatem gdy jest zdefiniowany to zapisywane są wszystkie dane za wyjątkiem tych podanych w tym parametrze. Sposobów na określenie zakresu danych są trzy: domains (określa domenę z jakiej pochodzą informacje np: sensor) oraz entities (jest to lista konkretnych encji z jakich chcemy zbierać dane) jak również event_types (umożliwia podanie rodzaju zdarzeń z których nie chcemy zbierać danych np: call_service).

Ważne jest to, że możemy mieszać konfigurację obu parametrów ze sobą. Czyli gdy chcemy zbierać tylko domenę sensor to dodajemy ją do parametru include ale jeżeli jednocześnie nie chcemy zbierać danych z jakiegoś jednego sensora to możemy zdefiniować parametr exclude i wykluczyć konkretny sensor/encję.

Przykładowa konfiguracja w pliku configuration.yaml dla powyższych parametrów może być następująca:

recorder:
  include:
    domains:
      - sensor
      - switch
  exclude:
    entities:
      - sensor.last_boot
      - sensor.date

Wyczyszczenie danych historycznych

Odpowiednio konfigurując moduł recorder możemy również ograniczyć ilość przechowywanych danych i automatycznie czyścić dane starsze niż X dni z naszej bazy. Operacja taka działa co dobę o godzinie 04:12 lokalnego czasu. Dane przechowywane standardowo są przez 10 dni. Oczywiście jak wiele rzeczy w HA i to również możemy zmienić. Przykładowa konfiguracja zmieniająca te ustawienia może wyglądać tak:

recorder:
  purge_keep_days: 5

Oczywiście można to łączyć z konfiguracją powyższą.

Jeżeli z jakiegoś powodu chcemy wyłączyć automatyczne czyszczenie to możemy ustawić parametr auto_purge na false. Jednak jest to zdecydowanie niezalecane.

Można również proces czyszczenia wywołać ręcznie poprzez wywołanie odpowiedniej usługi. W Narzędzia deweloperskie wybieramy zakładkę Usługi i ustawiamy ją zgodnie z poniższym przykładem:

Następnie naciskamy przycisk Wywołaj usługę.

Ważna uwaga. Samo skasowanie danych nie zmniejsza wielkości pliku bazy danych jednak przy ponownym zapisie nie będzie już on przyrastał chyba, że będzie taka konieczność aby "pomieścić" nowe dane.

Aby faktycznie zmniejszyć plik, a nie tylko ilość danych możliwe jest użycie opcji repack, która ponownie zapisze wszystkie dane i tym samym zmniejszy wielkość pliku. Jednak działa to tylko dla silnika SQLite i PostgreSQL. Dodatkowo jest to proces bardzo obciążający system i nie należy go uruchamiać w trakcie normalnego działania systemu.

Powyższą usługę oczywiście można również uruchomić z jakiejś automatyzacji np.: przy pomocy Node-RED.

Uruchomienie innego rodzaju bazy

Jest wiele możliwości skorzystania z zewnętrznych baz danych. Będą działać wszystkie które wspierane są przez ORM SQLAlchemy. Do najpopularniejszych należą MySQL, MariaDB, PostgreSQL lub MS SQL Server.

ORM jest to mechanizm, który przekłada obiektową strukturę systemu na relacyjną bazę danych.

Wykorzystując wparcie tego modułu  możemy podmienić standardową bazę na jakąś bazę zewnętrzną. Wszystkie wymienione wcześniej bazy zdecydowanie lepiej radzą sobie z dużą ilością danych niż SQLite. Jednak potrzebują do działania zdecydowanie więcej zasobów. Dlatego mocno odradzam korzystanie z tej metody na systemach RPI.

Jeżeli posiadamy serwer HA uruchomiony na komputerze RPI i bardzo chcemy skorzystać z tego sposobu to bazę powinniśmy postawić na serwerze zewnętrznym.

My w zakresie tego poradnika uruchomimy bazę MariaDB (wersję z dodatków) na tym samym serwerze co HA. Jednak pamiętajcie, że możecie wybrać inny rodzaj bazy (nie ma innego w dodatkach więc instalacja musi być wykonana zgodnie z instrukcją do wybranego rodzaju bazy i systemu na którym wykonujemy instalację). Różnica w konfiguracji będzie tylko na poziomie definicji połączenia z bazą.

No więc zacznijmy od instalacji. Korzystamy z dodatków do HA więc instalacja przebiega tak samo jak każdego innego dodatku. Supervisor->Addon-store wyszukujemy MariaDB naciskamy Install. Czekamy na koniec instalacji.

Po instalacji pora na konfigurację. Przykładowa konfiguracja może wyglądać następująco:

Wszystkie opcje można pozostawić standardowe. Natomiast koniecznie należy podać hasło dla użytkownika.

Gdy mamy zapisaną konfigurację startujemy dodatek.

Jeżeli baza działa, a w logach dodatku nie ma błędów to możemy przejść do konfiguracji modułu recorder. Dodajemy parametr db_url gdzie podajemy użytkownika, hasło, serwer (dla instalacji z dodatku jest to core-mariadb; dla bazy zewnętrznej może to być IP), bazę oraz kodowanie znaków. Dla powyższej konfiguracji parametr db_url powinien wyglądać następująco:

recorder:
  db_url: mysql://homeassistant:moje_haslo@core-mariadb/homeassistant?charset=utf8

Dla innych baz danych parametr db_url może wyglądać trochę inaczej. Poniżej przykłady kilku najpopularniejszych:

MySQL	mysql://user:password@SERVER_IP/DB_NAME?charset=utf8
PostgreSQL	postgresql://user:password@SERVER_IP/DB_NAME
MS SQL Server	mssql+pyodbc://username:password@SERVER_IP/DB_NAME?charset=utf8;DRIVER={DRIVER};Port=1433;

Oczywiście konfigurację bazy zewnętrznej możemy łączyć z konfiguracją wcześniejszą dzięki temu nie dość, że wymienimy silnik bazy danych na bardziej wydajny to jeszcze zmniejszymy ilość danych. Łatwo się domyślić, że suma tych rzeczy może znacząco poprawić wydajność naszego serwera.

Pamiętajmy, że po każdej zmianie konfiguracji należy wykonać restart systemu HA. Oczywiście wcześniej sprawdzając, że nie ma w niej błędów.

To chyba wyczerpuje temat poprawy wydajności przez zmiany w bazie danych. Tradycyjnie komentarze są Wasze.

Na koniec jeszcze uwaga ogólna. Pamiętajcie, że w przypadku systemów RPI wydajność może w dużej mierze zależeć od karty SD jakiej używamy. To również jest obszar w którym możemy uzyskać dużą zmianę wydajności jeżeli użyjemy dobrych kart. Natomiast pozbycie się karty na rzecz dysku SSD wniesie nasze RPI na całkowicie nowy poziom wydajności. Przy większych instalacjach jeżeli chcemy zostać przy RPI może być to nawet konieczne.

Do następnego artykułu. Cześć.