Dzień dobry
SQLite memory przechowuje - jak wiadomo - dobę zdarzeń. A czy w sumie to bramce zrobi jakąś różnice w wydajności jakby to było - powiedzmy - 2-3 dni?
Pozdrowienia 
W wydajności niewiele się zmieni , ale bardziej chodzi o zajętość pamięci - u mnie rozmiar bazy za jeden dzień ma ok 2GB 
A, rozumiem. To mam już ogląd i rząd wielkości. Dzięki.
Tego nie wie nikt, bo nikt nie wie ile masz integracji / encji, co one robią i ile generują danych.
Dlatego nie da się prosto powiedzieć ile dni to jest OK.
PS
Pracujemy nad ulepszeniem w tym temacie, wg sugestii @Cezary.K
Dodamy w kolejnej wersji w aplikacji możliwość zdefiniowania filtrów - jakie rzeczy rejestrować a jakich nie rejestrować.
domyślnie (chyba bo jeszcze to piszemy) będziemy rejestrować tylko zmiany encji typu:
sensor.*
Oczywiście jak ktoś będzie chciał dodać coś więcej do rejestrowania to świadomie będzie musiał dopisać encje do listy, to powinno rozwiązać problem z nadmierną ilością danych w bazie.
Chyba na tą chwilę zostawimy konfigurację w yaml-u ale docelowo będziemy wybierali domeny, encje w listy
Ewentualnie zrobimy to prościej bez wykluczenia bo to może niepotrzebnie skomplikować logikę, tylko z filtrem Include gdzie będzie można wpisać co ma być rejestrowane i uwzględnimy podczas zapisyu do bazy tylko określone podmioty:
4 polubienia
A może definować nie dni tylko maksymalny rozmiar bazy zdarzeń?
Dzięki za info 
Uważam za dobry pomysł aby określać co chcemy mieć w historii. Obie listy jednocześnie mogą powodować sporo zamieszania i nie będą chyba intuicyjne. Zdaję sobie sprawę, że rozwiązanie bazuje na tym co jest już w HA, lecz jako użytkownik, widział bym taką funkcjonalność z przełącznikiem np “rejestruj historię” przy dane encji np sensora.
Osobiście jako użytkownik wolę wiedzieć ile dni wstecz mam odczyty z czujników niż ile pamięci zajmują dane z czujników. Możesz zmniejszyć częstotliwość odczytów sensora i już zmieni się rozmiar bazy, ilość danych.
Innym rozwiązaniem dla zbyt dużej bazy danych, może być funkcja określenia minimalnej wolnej pamięci dla systemu.
w biurze mamy takie domeny:
{%- for d in states | groupby('domain') %}
{{ d[0] }}
{%- endfor %}
chyba zrobimy to tak, że na początek będziemy nadal rejestrowali sporo rzeczy (żebyśmy nie musieli każdemu tłumaczyć dlaczego nie zapisuje mi …), ale opiszemy w dokumentacji jak to konfigurować
domains:
- automation
- binary_sensor
- climate
- cover
- device_tracker
- light
- person
- sensor
- switch
entities:
- sun.sun
Tak zgadzam się, niestety specyfikowanie kązdego urządzenia będzie uciążliwe dla użytkownika (który wiadomo chce mieć wszystko), dlatego każdy doda pewnie domeny.
Czasami problem może spowodować jedna encja albo integracja.
Może być tak, że wszystkie sensory chciemy w bazie, ale jeden który loguje co sekundę chcemy wykluczyć
W ten sposób będzie pełna kontrola i każdy będzie mógł określić co chce zapisywać do bazy.
Kiedyś pewnie tak będzie.
3 polubienia