przepiąłem swojego HA do Msql.
Wrzuciłem do Record na chwilę obecną chyba wszystko aby potem zastanowić się co jest mi potrzebne, obecnie wygląda to tak:
recorder:
purge_keep_days: 365
include:
domains:
- alarm_control_panel
- automation
- binary_sensor
- camera
- climate
- counter
- cover
- device_tracker
- energy
- fan
- history
- integration
- input_boolean
- input_select
- light
- lock
- media_player
- person
- remote
- scene
- script
- sensor
- statistics
- sun
- timer
- weather
- switch
- updater
- zone
exclude:
# domains:
# - automation
# - updater
entity_globs:
- sensor.date_*
- weather.*
Baza urosła mi przez 7 dni ~1.3 GB.
events - 493 MB ( ponad 2.8 mln rekordów)
states 840 MB ( ponad 2.8 mln rekordów)
Reszta to mała ilość.
I tak zastanawiam się:
co tak naprawdę potrzebne jest aby rejestrować?
Da się zamiast globalnie ustawić dla konkretnych encji ustawić czas przechowywania?
Zależy mi głównie na:
Statystykach zużycia prądu, rejestracji wilgotności, temperatury, itp.
Nie chciałbym utracić statusów czy dany przełącznik jest włączony czy wyłączony ale nie potrzebuję przechowywać tego więcej niż 24h.
Czy naprawdę potrzeba mi aż tyle events?
Czy da się bezpiecznie to usunąć?
Czy nie jest jakoś tak, że HA zlicza obecne zużycie dodaje poprzednie i nowy wpis więc stary można by usunąć?
Poczytaj wnikliwie oficjalnego bloga od wydania sierpniowego
aż do aktualnych wpisów - do celu długoterminowych statystyk wprowadzono nowe rozwiązanie (long-term-statistics) na obrazku poniżej recorder ma “fabryczne” ustawienia (czyli zapewne 10 dni)
tylko jest to wciąż słabo udokumentowane (dlatego link poniżej jest do dokumentacji developerskiej):
W międzyczasie zmień te 365dni na jakieś 7 może 10 (w przeciwnym razie baza danych w końcu spuchnie do rozmiaru nie do przyjęcia), centralki AIS mają podobno recorder ustawiony na 2 doby edit: 5 dób.
PS do wklejania kodu nie używaj cytowania, tylko przed i po wklejonym bloku (tekstu=kodu) dodaj linijki z trzema odwrotnymi apostrofami (tak jak to się robi np. na githubie w komentarzach czy issue) - chodzi o 3 znaki spod “klawisza tyldy” czyli ```
Zobacz jak poprawiłem twojego posta.
Właśnie między innymi takie dodatki, po wyciągnięciu z pudełka, jak zapisy do różnych baz danych i sporo więcej. Po dwóch latach rozwoju HA + rozwiązania AIS daje fajną mieszankę.
Ok, przebrnąłem przez lekturę (recorder, statystyki długoterminowe i poboczne tematy związane z bazami danych) i tak mi to zryło beret, że szukam potwierdzenia.
Recorder zapisuje wszystko i trzyma tyle ile ustawiono default’owo lub ręcznie , potem czyści starsze niż … i tak dalej ?
Recorder wrzuca część uśrednionych danych (te które spełniają kryteria) do statystyk długoterminowych i je tam sobie trzyma … ? Czy te trzymane dłużej to te, które w “Statystykach” mają tą “zjeżdżalnię” i czy usunięcie encji spowoduje jednorazową akcję wyczyszczenia jej długoterminowych statystych po czym historia się zacznie budować na nowo ?
Wyłączenie zapisu encji w recorderze spowoduje brak zapisu statystyk długoterminowych ? A jak w takim przypadku: zapis “krótki” chciałbym ale długich nie ?
W kartach wykorzystujących wykres mogę używać zakresu najdalszej daty dla prezentowanych wartości encji → max recordera chyba, że encja posiada statystyki długoterminowe ?
tak (fizyczne czyszczenie bazy=przepakowanie jest w 2 niedzielę miesiąca, czyli dzisiaj)
tak, nie (zjeżdżalnia to klasa stanu total_increasing bodajże), nie (jeśli dobrze zrozumiałem, jeśli utworzysz od nowa encję o tym samym identyfikatorze, to będzie kontynuowany zapis długoterminowy, no chyba że go usuniesz z poziomu Narzędzi deweloperskich przed ponownym utworzeniem identycznej encji, pewnie warto jeszcze przepakować bazę przed taki ruchem, albo odczekać do kolejnej 2 niedzieli a raczej poniedziałku)
tak (o ile dobrze rozumiem działanie tego ficzeru), jeśli chcesz tylko “krótkie” to wywal z encji np. klasę stanu
karty to już zupełnie inna historia, jeśli chcesz użyć statystyk długoterminowych na wykresie to albo karta type: history-graph, albo jakaś niestandardowa dedykowana do statystyk
PS opcjonalnie można bazę danych sobie obrobić ręcznie (jeśli ktoś to ma w małym palcu, ja raz w ten sposób naprawiałem bazę i raczej nigdy nie planuję tego robić drugi raz)
Dzięki wielkie, w zasadzie Twoje odpowiedzi na pierwsze 3 pkt, stanowiły odpowiedź na nieprecyzyjnie zadany 4 Pozostaje w takim razie zapytać czy warto migrować na DBMaria czy też trzymać się Bazy HA (zakładając tymczasowy brak jakiegoś szczególnego powodu) ? A jeśli tak to na tym samym dysku czy postarać się o nowy tylko na bazę ?
a raczej poniedziałku)
Pozostaje w takim razie zapytać czy warto migrować na DBMaria czy też trzymać się Bazy HA (zakładając tymczasowy brak jakiegoś szczególnego powodu) ? A jeśli tak to na tym samym dysku czy postarać się o nowy tylko na bazę ?