⏳ Filtrowanie zapisu zdarzeń

Filtrowanie zapisu zdarzeń do bazy

:hourglass_flowing_sand:

W wersji 2021.6.6b1, którą dzisiaj wydajemy na BETA, dodaliśmy poprawki i jedną całkiem nową rzecz - filtrowanie zapisu zdarzeń.

Niektóre integracje potrafią rejestrować z bardzo dużą częstotliwością i generować ogromne ilości danych, dlatego wymagamy zdefiniowania filtra zapisu do bazy.

Filtr pozwala na określenie, co ma być zapisywane w bazie oraz czego nie chcemy zapisywać. Dostarczamy przykładową konfigurację filtra, w którym są zdefiniowane wszystkie możliwe atrybuty.
Dla większości użytkowników ten przykładowy domyślny filtr będzie OK.

Poniżej wyjaśniamy co oznaczają parametry filtra:

:warning: Używamy nazewnictwa zgodnego z Home Assistant. Ten sam filtr występuje w wielu miejscach w systemie nie tylko w rekorderze ale też w historii i dzienniku. Uproszczenie tego mechanizmu będzie dodane w przyszłości, obecnie było by zbyt ciężkie w utrzymaniu.

  1. domains - lista domen, które chcemy rejestrować w bazie.

  2. entity_globs - lista obiektów pasujących do podanego wzorca (np. sensor.weather_*) które chcemy rejestrować w bazie.

  3. entities - lista identyfikatorów encji, które chcemy rejestrować w bazie.

  4. domains - lista domen, które nie chcemy rejestrować w bazie.

  5. entity_globs -lista obiektów pasujących do podanego wzorca (np. sensor.weather_*) które nie chcemy rejestrować w bazie.

  6. entities - lista identyfikatorów encji, które nie chcemy rejestrować w bazie.

  7. event_types - lista typów zdarzeń które nie chcemy rejestrować w bazie.

PS
dzisiaj pojawi się też opis tego mechanizmu w dokumentacji konfiguracji zapisu zdarzeń do baz danych

1 polubienie

@jolka taka mała uwaga: jeżeli został przedstawiony przykładowy rysunek z konfiguracją to dalszy opis i przykłady powinne uwzględniać i odwoływać się do tej konfiguracji, wtedy lepiej jest zrozumieć o co biega.

W dokumentacji nie widzę informacji - co zrobić w przypadku gdy już mamy filtry wpisane w pliku konfiguracji HA?
Domyślam się , że swoje filtry przed aktualizacją powinienem usunąć. Proszę @jolka o potwierdzenie…

1 polubienie

Hej :slight_smile:
Spoko, to jeszcze świeża sprawa - sami tą konfigurację testujemy na kilku bramkach, żeby sprawdzić, czy czegoś nam nie brakuje po tym przefiltrowaniu. Istotne jest to, że filtr jest obowiązkowy, tą konfigurację można modyfikować, zmieniać pozycje, dodawać, usuwać itd. ale nie da się jej całkowicie usunąć.
Czyli nie da się nieświadomie doprowadzić do takiej sytuacji, że wszystko jest rejestrowane i nowa integracja zabija nam bazę, chociaż tego w ogóle nie chcieliśmy. Każdy będzie mógł widzieć ten filtr w aplikacji (po aktualizacji do najbliższej wersji stabilnej, chyba 30 czerwca). A jeżeli ktoś usunie filtr to wtedy wrócą wartości domyślne. Tak będziemy “bronić” użytkowników przed dziwnymi integracjami.

1 polubienie

Słuszna uwaga - z tego, co zrozumiałam to koncepcja jest taka, że w ogóle ma nie być potrzeby definiowania czegokolwiek w yaml. Teraz to wszystko można zdefiniować z interfejsu aplikacji.

Oczywiście można nadpisywać tą konfiguracją w yaml, ale po co :wink:
Podczas wydania wrzucimy info, co i jak mają zrobić ci, którzy już mają swoje konfiguracje w yaml, ale w dokumentacji nie będziemy już chyba mieszać i po prostu yaml będzie odchodził powoli w zapomnienie :wink:
Ale oczywiście nie będzie to miało wpływu na możliwość dalszego konfigurowania w yaml- jak ktoś lubi i umie w yaml to śmiało śmiało :wink: nie będziemy tego blokować, po prostu chcemy ułatwić życie użytkownikom :slight_smile:

1 polubienie

Konfiguruję swoją DEV3 i chciałbym wykorzystać dostępny dysk wewnętrzny dla celów bazy danych.
czy po skonfigurowaniu PostgreSQL (local) mogę zmienić systemowe ustawienie 10 dni historii?

Jeśli to nie stwarza problemów to chciałbym osiągnąć min. 30dni danych podstawowej listy wybranych sensorów oraz zdarzeń automatyzacji.
Jaki rodzaj silnika wybrać dla wewnętrznego dysku?
Jaki rozwiązanie polecacie przy DEV3 z wolnym 100GB?