Przy okazji bardzo dziękuję za poruszenie tego superważnego tematu. Dzięki niemu uświadomiłem sobie, ile oczywistych śmieci zalega w mojej bazie danych.
Chciałbym stworzyć listę encji śmieciowych, które:
usunę bezpowrotnie z bazy
wyłączę ich zapis do bazy poleceniem exclude:
Aby zrobić to “po inżyniersku”, chcę prosić o poradę:
czy istnieje jakiś prosty sposób na wylistowanie do pliku zewnętrznego (np. excludes.yaml) wszystkich encji zarejestrowanych w HA z pominięciem ich wartości historyczych i bieżących?
czy mozna użyć następującej konstrukcji konfiguracyjnej w pliku configuration.yaml:
@Krzysztonek cześć… Czy działałeś już coś że swoją bazą, mógłbyś coś więcej napisać jak robiłeś, albo jaki obrałeś sposób, też chciałbym zrobić porządek z bazą… Z gory dzięki za odp pozdrawiam Piotr
W jego wyniku otrzymałem na ekran listę wszystkich kilkuset swoich encji, utworzonych w systemie od początku instalacji. Zaznaczyłem je wszystkie, skopiowałem zaznaczenie do pliku db_included.yaml, który następnie umieściłem w folderze /config.
Następnie powstały plik otworzyłem w edytorze i usunąłem z niego wszystkie zbędne dla mnie encje. Po tych porządkach zostało mi ok. 20% pierwotnej ilości linijek. Zapisałem zmiany w pliku.
W głównym pliku konfiguracyjnym configuration.yaml umieściłem poniższą sekcję:
Parametr purge_keep_days ustawiasz na dowolną liczbę (1 -365). Wskazuje ona ile dni wstecz wartości tych encji chcesz przechowywać. Ja wybrałem pełny zakres (rok), ponieważ istotne są dla mnie m.in. roczne statystyki produkcji energii z paneli PV i jej zużycia przez najbardziej energochłonne odbiorniki w moim domu.
Sprawdziłem konfigurację serwera HA:
Ponownie uruchomiłem Home Assistanta i poszedłem spać. Operacje opisane w kroku 3. standardowo wykonują się bowiem w nocy od godz. 4:12, gdy system jest najmniej obciążony pracą. Jakiś przytomny programista słusznie zauważył, że to najbezpieczniejsza pora na przepisywanie całej bazy od zera. (nie wiem czy jest możliwość zmiany tej godziny).
Następnego dnia sprawdziłem rozmiar bazy danych. Zmniejszył się o prawie 40% a cały system dostał jakby drugi oddech, pomimo tego, że sprzęt, na którym hula HA i tak jest zacny
Sekcja z kroku 3. wykonuje się codziennie o w/w godzinie, ale zauważalny efekt jest tylko przy pierwszym jej uruchomieniu, gdy z bazy wylatuje cała masa farfocli. Potem to już czysta konserwacja i zabezpieczenie przed nowymi śmieciowymi encjami.
Trzeba jednak pamiętać, że od tej pory do pliku db_included.yaml należy dopisywać ręcznie wszystkie nowe encje, które z jakiegoś powodu uznasz za istotne, a które pojawią się w systemie np., na skutek instalacji jakiegoś nowego dodatku, ponieważ domyślnie nie będą one zapisywane do bazy.
Stara, dobra, szkolna zasada brzmi: co było a nie jest, nie pisze się w rejestr. Tak jest i tym razem. Encje usunięte z bazy tracą swą historię. Ale co do logbooka, to tego nie jestem pewnien… muszę sprawdzić.
a jak bym utworzył dwa pliki db_included.yaml
np:
db_included.yaml
db2_included.yaml,
gdzie w pierwszym pliku umieścił bym encję które mają mieć bazę danych 365 dni a w drugim np 7 dni.
Pytanie czy to zadziała?
Jedyne co mi przychodzi do głowy to napisanie skryptu (Dla zaawansowanych) lub Automatyzacja HA.
HA posiada 2 usługi purge DB Recorder: Purge Entities i Recorder: Purge
Nie wiem natomiast jaki zakres czasu dostępny jest w Automatyzacji, ale można użyc Czasu i Szablon czasu. Pytaniem jest jeszcze czy obsługuje to inne bazy jak standardowa HA
@Raddii@Krzysztonek
Może jestem urodzonym pesymistą, ale moim zdaniem ustawienie standardowej bazy danych na przechowywanie przez rok wszystkiego (nawet jeśli odfiltrujemy sporo w sposób opisany w tym właśnie wątku) musi się skończyć “katastrofą” (wystarczy spojrzeć jaki okres przechowywania danych jest w AIS - projekcie bazującym na HA, hint: jest to sporo krótszy okres od domyślnych 10 dni w HA).
Z drugiej strony po to twórcy HA od dłuższego czasu walczą o udoskonalenie history_stats - wbudowanej integracji umożliwiającej długoterminowe przechowywanie danych w taki sposób by baza danych nie “puchła” ponad miarę (sugeruję pokopać po dokumentacji jak przygotować sobie encje, aby były zapisywane w ten sposób długoterminowo).
To jest obrazek ze zdalnej instalacji (są “dziury” w danych z powodu problemów w dostawach energii po tegorocznych wichurach), tam jest najzwyklejsza baza SQLite z recorderem ustawionym na 10 dni (a bywało i 5 dni na wcześniejszym sprzęcie)
Hej
I jak się spisuje baza danych ?
Masz to na standardowej bazie czy może na jakiejś dodatkowej?
I najważniejsze
Udało ci się osiągnąć taki efekt?
Też potrzebuję rocznej historii do PV i pewnie coś by się jeszcze znalazło, a reszta to wiadomo że się przyda ale nie na rok a na kilka dni
Prawie rok temu wprowadzono w standardowej bazie możliwość przechowywania długoterminowych statystyk (u siebie z braku czasu nie wdrożyłem wcześniej LTSS, a później - już wiedząc o tym co jest planowane tylko postanowiłem poczekać i wystarczyło).
O tym, że to działa świadczą screenshoty nieco wyżej.
Masz na myśli to, że w standardowej bazie danych można przechowywać dane np przez rok dzięki
purge_keep_days ?
Czy po prostu twórcy HA udostępnili jakieś narządzie dzięki któremu można przechowywać tą historie?
Na dzień dzisiejszy z którego rozwiązanie Ty korzystasz i jakiej bazy?
NIE, to nie są pełne dane, tylko podstawowe dane statystyczne
TAK, można mieć rok historii statystyk wstecz (a wręcz dużo więcej, jak widać od momentu gdy wprowadzono tę funkcjonalność w wersji produkcyjnej HA minął już niemal rok i tyle mam historii wybranych statystyk)
NIE purge_keep_days nie ma nic do rzeczy
NIE można dowolnie zwiększać wartości purge_keep_days, bo to powoduje nadmierny rozrost bazy danych i sporą utratę responsywności HA (myślę, że górną granicą rozsądku są jakieś 2 tygodnie, w projekcie AIS jest to zaledwie kilka dni i wystarcza, HA standardowo ma 10 dni)
Tak - po prostu udostępnili odpowiednie narzędzie w postaci statystyk długoterminowych.
To co pokazałem powyżej to standardowa baza sqlite i absolutnie standardowe ustawienia (a od niedawna jest ona w pełni bezobsługowa).
A możesz podzielić się przykładowym wpisem do konfiguracji dot. np temperatury?
Tak jak gdzieś napisałeś na temat dokumentacja tego rozwiązania, jeszcze raczkuje.
Czy dla tej statystyki temperatury robiłeś osobny wykres czy to jest z jakiegoś urządzenia pobierane?
Ja mam termometr na esphome, encje z tym wykresem dodają się automatycznie więc nie mogę chyba jej dopisać
W ESPHome można eksponować klasy urządzenia i stanu:
jeśli ogarniesz prawidłowego YAML’a w ESPHome to encja sama się doda do statystyk w HA.
W samym HA też można to ogarnąć nawet dla encji, które nie są gotowe na statystyki, używając edycji pliku /config/customize.yaml, przykładowy fragment “uzdatniający” sensor pochodzący z integracji, której od paru lat nikt nie uaktualnia
sensor.temp_4_in_1_19_2:
device_class: temperature
state_class: measurement
(ale dla urządzeń ESPHome zalecam zrobić to “po bożemu”, a nie “łatać dziury”, bo potem “zarządzanie śmietnikiem” robi się trudne)
Czy będzie to miało zastosowanie do bazy danych MariaDB?Tez chcę kilka sensorów z zapisem na 365dni.Czy exclude i include działaja z MariaDB?Nigdy wczwśniej nie zarządzałem baza danych sql.
Po dodaniu tego kodu nie będzie tak ,że baza będzie się czyścić co 5 dni ? A ja chcę mieć zapis produkcji i zużycia energii na rok więc mam wpisać 365.Gdy próbuje dodać np.
Ale może robię jakiś błąd w składni konfiguracji…