Historia, Logbook i statystyki w Home Assistant: analiza danych

Historia, Logbook i statystyki — czym się różnią i po co je znasz

Trzy narzędzia, jedno źródło danych. Historia, Logbook i statystyki w Home Assistant czerpią z tej samej bazy rekordera, ale pokazują zupełnie inne rzeczy. Kto tego nie rozróżnia, ten szuka wykresu tam, gdzie powinien zajrzeć do listy zdarzeń. Brzmi prosto? W praktyce wielu użytkowników miesza te funkcje i dziwi się, że nie widzi tego, czego szuka.

Historia to surowe dane w czasie. Każda zmiana stanu encji ląduje w bazie i możesz ją obejrzeć na wykresie lub pobrać jako liczby. Logbook to zapis zdarzeń w formie tekstowej: kto, co i kiedy zmienił. Statystyki to natomiast agregacja, czyli wartości uśrednione lub zsumowane w dłuższych okresach, przydatne choćby do rozliczeń energii.

Krótka historia domyślnie trzyma dane przez ograniczoną liczbę dni, a statystyki długoterminowe przechowują zagregowane wartości znacznie dłużej. To nie czarna magia, tylko kwestia tego, co rekorder zapisuje na bieżąco, a co wylicza w tle.

Po co ci ta wiedza? Bo od niej zależy, gdzie szukasz odpowiedzi. Chcesz sprawdzić, o której włączyło się światło wczoraj wieczorem? Historia. Chcesz wiedzieć, która automatyzacja to zrobiła? Logbook. Chcesz policzyć zużycie prądu w skali miesiąca? Statystyki. Wybór złego narzędzia to najczęstszy powód frustracji przy analizie danych.

Historia w Home Assistant: konfiguracja, baza danych i retencja

Bez włączonej historii Home Assistant zapisuje tylko bieżące stany encji. Widzisz, że lampa jest teraz zapalona. Nie zobaczysz, że paliła się cztery godziny dziennie przez cały tydzień. A właśnie takie dane pozwalają wyciągać wnioski i budować sensowne automatyzacje.

Domyślnie rekorder działa od razu po instalacji. Zapisuje zmiany stanów do lokalnej bazy SQLite, którą znajdziesz w pliku home-assistant_v2.db. Brzmi prosto. Problem pojawia się, gdy baza rośnie w gigabajty i zaczyna mielić dysk, zwłaszcza na Raspberry Pi z kartą SD.

Konfigurację historii ustawiasz w pliku configuration.yaml. Najważniejsze opcje to zakres zapisywanych encji oraz czas retencji, czyli jak długo dane pozostają w bazie. Domyślny okres to 10 dni. Możesz go wydłużyć, ale każdy dzień to większy plik.

• recorder decyduje, które encje trafiają do bazy, a które są pomijane dla oszczędności miejsca.
• purge_keep_days określa, po ilu dniach stare wpisy są usuwane z bazy danych.
• history wybiera encje widoczne na wykresach i w panelu historii.
• logbook filtruje zdarzenia pokazywane w dzienniku, żeby nie zalać go szumem.
• exclude i include pozwalają precyzyjnie wyciąć encje, których nie chcesz śledzić.

Wyobraź sobie sytuację, w której masz trzydzieści czujników temperatury raportujących co kilka sekund. Zostawiasz wszystko na domyślnych ustawieniach i po miesiącu baza puchnie do kilku gigabajtów. Panel historii otwiera się wolno, a karta SD dostaje zadyszki. Wykluczenie części encji rozwiązuje problem szybciej niż wymiana sprzętu.

Moim zdaniem lepiej od razu wykluczyć hałaśliwe encje niż później ratować zapchany dysk, ponieważ dane z czujników raportujących co sekundę i tak nie wnoszą nic do analizy dziennej. Warto skupić się na tym, co faktycznie chcesz obserwować.

Pamiętaj też o kopii zapasowej bazy przed zmianą retencji. Skrócenie okresu usuwa starsze wpisy nieodwracalnie. A co jeśli okaże się, że potrzebujesz danych z zeszłego kwartału? Lepiej mieć backup niż żałować.

Logbook i logi zdarzeń: czytanie historii w kontekście

Logbook to najprostsze okno w przeszłość Home Assistant. Pokazuje zmiany stanów encji, ale tylko te, które system uznał za istotne. Światło włączone. Ruch wykryty. Drzwi otwarte. Prosto i szybko.

Problem zaczyna się, gdy próbujesz odtworzyć pełny obraz zdarzeń. Logbook domyślnie ukrywa część wpisów, filtruje szum i pokazuje wyłącznie wybrane domeny. I tu zaczyna się problem. To, co widzisz, nie zawsze odpowiada temu, co faktycznie się wydarzyło.

Do głębszej analizy służą surowe logi. Zawierają wszystko: błędy integracji, ostrzeżenia, komunikaty debugowania. Różnica między oboma widokami bywa ogromna.

Wyobraź sobie sytuację, w której automatyzacja oświetlenia nie działa zgodnie z planem. Logbook pokaże, że światło się nie włączyło. Logi zdarzeń ujawnią, że czujnik ruchu zgłosił stan unavailable na kilka sekund przed spodziewanym triggerem. Bez tego drugiego widoku szukasz przyczyny po omacku.

Moim zdaniem do codziennej pracy Logbook wystarcza w większości przypadków, ponieważ skupia się na tym, co istotne dla użytkownika. Logi zdarzeń zostawiam na momenty, gdy coś naprawdę się sypie i trzeba dotrzeć do źródła. Diabeł tkwi w szczegółach, a te szczegóły często siedzą właśnie w logach systemowych.

Oba widoki warto traktować jako uzupełnienie, a nie zamiennik. Logbook odpowiada na pytanie „co się stało?", logi na „dlaczego".

Statystyki i wykresy, długoterminowa analiza danych z czujników

Historia i logbook pokazują, co działo się wczoraj. Statystyki długoterminowe pokazują, co dzieje się od miesięcy. To zupełnie inna skala wniosków. Krótki log przydaje się przy debugowaniu automatyzacji. Statystyki przydają się przy podejmowaniu decyzji, które mają sens za rok.

Home Assistant przechowuje dane statystyczne oddzielnie od zwykłej historii i domyślnie nie kasuje ich tak szybko. Czujniki zużycia energii, temperatury czy wilgotności zapisują wartości w sposób zagregowany, więc można śledzić trendy bez trzymania gigabajtów surowych odczytów. Diabeł tkwi w szczegółach, bo nie każda encja trafia do statystyk automatycznie. Encje diagnostyczne albo tekstowe zwykle nie mają sensu liczbowego, więc system je pomija.

Żeby wykres był coś wart, czujnik musi mieć poprawną jednostkę miary i klasę urządzenia. Bez tego statystyki bywają bezużyteczne, mimo że historia działa bez zarzutu. To najczęstsza przyczyna zdziwienia: „przecież dane są, czemu nie ma wykresu?”. Rozwiązanie zwykle sprowadza się do dodania atrybutów w definicji encji, o czym pisałem szerzej w artykule o template sensorach.

Do analizy długoterminowej przydają się trzy narzędzia wbudowane w Home Assistant:

• Karta Statistics Graph pokazuje średnie, minimum i maksimum w wybranym okresie, bez pisania własnych zapytań.
• Karta History Graph nadaje się do krótszych zakresów, gdzie liczy się dokładny przebieg zmian, a nie trend.
• Sekcja Statistics w narzędziach deweloperskich pozwala sprawdzić, czy dana encja w ogóle jest liczona i od kiedy.
• Eksport do zewnętrznego narzędzia, np. bazy czasu szeregowego, ma sens dopiero przy setkach encji i latach danych.

Moim zdaniem karta Statistics Graph działa lepiej niż rozbudowane dashboardy z surową historią, ponieważ agreguje dane po stronie bazy i nie zamula interfejsu przy długich zakresach. Historia jest dokładniejsza, tylko że przy tysiącach punktów zwyczajnie przestaje być czytelna.

Wyobraź sobie sytuację, w której chcesz sprawdzić, czy pompa ciepła zużywa zimą więcej prądu niż rok wcześniej. Bez statystyk zostaje przeklikiwanie miesięcy po kolei. Z wykresem statystycznym porównanie dwóch sezonów zajmuje kilka sekund.

Praktyczne scenariusze analizy danych i integracja z template sensor

Surowe dane z Logbooka czy Historii to dopiero początek. Prawdziwa wartość pojawia się, gdy połączysz je z template sensor, czyli encją wyliczaną na podstawie innych encji. Zamiast przekopywać wykresy, dostajesz konkretną liczbę albo stan, który możesz pokazać na dashboardzie lub wykorzystać w automatyzacji.

Wyobraź sobie sytuację, w której chcesz wiedzieć, ile godzin w tygodniu działał piec gazowy. Historia pokaże ci surowe przełączenia stanu on/off, ale nie da gotowej sumy. Template sensor potrafi zliczyć czas działania i zwrócić jedną wartość, którą porównasz z poprzednim tygodniem. To zmienia sposób patrzenia na zużycie energii.

Typowe zastosowania wyglądają podobnie w wielu domach:

• Licznik godzin pracy pompy ciepła lub rekuperatora w skali dnia i miesiąca.
• Suma otwarć okna w sypialni, żeby wychwycić nawyk wietrzenia.
• Średnia temperatura w pokoju z ostatnich 24 godzin do wykrywania przegrzewania.
• Liczba dni, w których wilgotność w łazience przekroczyła próg zagrożenia pleśnią.
• Czas od ostatniego ruchu w garażu, przydatny do automatyzacji oświetlenia.

Moim zdaniem template sensor wygrywa z gotowymi integracjami statystycznymi, ponieważ daje pełną kontrolę nad jednostką, progiem i sposobem agregacji. Gotowe statystyki są wygodne, ale ograniczają cię do kilku sztywnych metryk. Template pozwala zbudować dokładnie to, czego potrzebujesz, choć wymaga zrozumienia składni i szablonów Jinja.

Jak to spiąć w praktyce? Najprościej oprzeć sensor na atrybucie last_changed albo na historii encji źródłowej. Szczegóły tworzenia takich encji opisałem w artykule Home Assistant template sensor jak tworzyć, gdzie znajdziesz gotowe wzorce. Diabeł tkwi w szczegółach, bo źle napisany szablon potrafi zwracać zero przez cały dzień.

A co jeśli dane z Logbooka są niekompletne? Wtedy warto najpierw sprawdzić, czy recorder nie wycina wpisów po zadanym czasie. Domyślne ustawienia potrafią usuwać starsze zdarzenia, przez co statystyki wyglądają na zaniżone.

Najczęściej zadawane pytania (FAQ)

Czym różni się Historia od Logbooka? Historia pokazuje wartości liczbowe w czasie, czyli wykresy temperatur, zużycia prądu albo wilgotności. Logbook to zapis zdarzeń: kto włączył światło, kiedy otworzyły się drzwi, o której zadziałał czujnik ruchu. Pierwsze narzędzie odpowiada na pytanie „ile", drugie na „kiedy i co się stało".

Oba moduły korzystają z tej samej bazy danych, więc jeśli Historia działa wolno, Logbook też będzie zamulał. Diabeł tkwi w szczegółach konfiguracji, nie w samych narzędziach. Poniżej zestawienie najczęstszych pytań, które przewijają się w komentarzach i na forach szerzej opisaliśmy to w artykule "Home assistant template sensor jak tworzyc".

Najwięcej problemów wynika z jednej rzeczy: ludzie wrzucają do bazy wszystko, co mają. A co jeśli się okaże, że połowa encji nigdy nie trafia na żaden wykres? Wtedy wystarczy je wykluczyć i całość przyspiesza bez wymiany sprzętu.

Moim zdaniem lepiej zacząć od filtrów i dłuższego okresu przechowywania niż od razu stawiać bazę na osobnym serwerze, ponieważ większość domowych instalacji nie generuje aż takiego ruchu, żeby dedykowany serwer był konieczny. Warto też zajrzeć do wpisu o tworzeniu własnych sensorów szablonowych, bo dobrze zrobiony sensor to połowa sukcesu w statystykach.