Utrata danych w panelu energia

PioSko · 2 Sierpień 2023 07:25

Od kilku dni mam problem z utratą danych historycznych w panelu energia (i zapewne wszystkich innych też, ale te nie są istotne). Nagle wszystko co było wcześniej znika. Znika także z dysku, bo backup po takim zniknięciu ma ok 147, podczas gdy poprzednie miały w okolicach 475.

Oczywiście odtworzyłem z backupu i dane się pojawiły, ale kilka godzin później znów znikają…
Pomyślałem, że może coś się porobiło z danymi już w tym backupie, więc cofnąłem się do jeszcze poprzedniego - działało 12 godzin, dane zniknęły.

Ktoś może mi coś podpowiedzieć?
Instalacja na RASP, standardowa baza z HA na karcie w RASP.

artpc · 2 Sierpień 2023 23:20

1.Jakieś konkretne urządzenia które gubią dane ?
2. Masz ustawione purge DB na jakiś określony czas ?
3. Urządzenia przestały wysyłać dane ?
4. Jakąś aktualizacja coś zmieniła ?

PioSko · 3 Sierpień 2023 07:35

Wszystkie
Nic nie ustawiałem
Nie
Nie

Ale chyba mam więcej już wiedzy.
Generalnie tracę dane codziennie o 4 z minutami, czyli usuwa mi je wbudowany serwis HA. W wyniku jego działania tworzy pusty plik home_assistant_v2.db oraz powstaje drugi (duży, więc pewnie pełny) home_assistanr_v2.db.corrupt.data_i_godzina.

Zakładam więc, że plik z danymi jest w jakiś sposób uszkodzony i automat czyszczący nie radząc sobie z nim zrzuca go do backupu i tworzy od nowa czysty plik. Ja go przywracam z kopii i o 4 z minutami się powtarza.

No i powstaje pytanie:

jak naprawić uszkodzony plik?
lub: Jak skopiować z niego dane zanim automat go usunie?
Jak wyłączyć automat do czasu poradzenia sobie z uszkodzeniem?

Edit: na pytanie 3 znalazłem odpowiedź.

artpc · 3 Sierpień 2023 08:00

HA Recorder

auto_purge boolean (optional, default: true)

Automatically purge the database every night at 04:12 local time. Purging keeps the database from growing indefinitely, which takes up disk space and can make Home Assistant slow. If you disable auto_purge it is recommended that you create an automation to call the recorder.purge periodically.

https://www.home-assistant.io/integrations/recorder/
Wygląda na to że jest z automatu czyszczona jest Baza o wskazanej godzinie 4:12
Jeżeli chcesz to zmienić czas przechowywania danych musisz dodać konfiguracje dla Recordera w pliku configuration.yaml

Tu przykład z mojej konfiguracji

recorder:
  db_url: !secret mariadb_url
  purge_keep_days: 20
  exclude:
    domains:
      - automation
      - weblink
      - updater
      - media_player
      - switch
      - climate
      - camera
      - zone
      - input_boolean
      - input_number
      - input_select
      - input_text
      - light
      - media_player
      - sun
      - timer
      - weather

Zastanów się nad przejściem na inną bazę np. MariaDB

PioSko · 3 Sierpień 2023 08:20

To chyba niepełna odpowiedz.

Tak, ma to ewidentny związek z czyszczeniem bazy o 4:12
Ale system powinien wtedy czyścić bazę z zapisów starszych niż 10 dni i tak to przez lata robił (zostawiając magicznie zapisy dot. panelu energia, tu był dostęp do wszystkich danych), teraz po prostu wrzuca pusty plik z danymi a poprzedni wyrzuca do “corrupt”. Zatem - coś się popsuło i nie jest to kwestia ustawień.

Tak, rozważam przeniesienie się na mariadb, tyle, że ja mam instalację na RASP a wrzucanie bazy danych na kartę SD nie ma sensu. Kupiłem sobie właśnie zewnętrzny dysk SSD który będę chciał podpiąć pod RASP, tyle, że nigdzie nie znalazłem informacji jak uruchomić mariaDB na zewnętrznym dysku. No i pozostaje pytanie o dane historyczne, czyli te o które walczę. Czy po podłączeniu zewnętrznej bazy mogę jakoś przerzucić dotychczasowe informacje?

artpc · 3 Sierpień 2023 08:28

Jak cos się popsuło z niczego to obstawiam błędy zapisu, czyżby karta SD kończyła żywot ?
Szczerz teraz nie pamiętam czy dane są przenoszone automatycznie przy zmianie Bazy czy trzeba sobie je ręcznie przenieść.

Przez lata też wiele się zmieniło w konfiguracji Bazy danych.

szopen · 3 Sierpień 2023 09:15

Tak, masz rację to HA usuwa dane (a właściwie cała bazę - home_assistanr_v2.db.corrupt.data_i_godzina to plik uszkodzony, z którego HA nie korzysta), robi to celowo, bo plik bazy danych masz uszkodzony.

Licząc się z utratą części danych możesz spróbować backupu wcześniejszego niż ten, z którego przywracasz bazę (prawdopodobnie przywracasz uszkodzoną).

Raz w życiu naprawiałem bazę sqlite parę lat temu przy pomocy sqlite-tools, niestety szczegółów nie jestem w stanie podać, ale korzystałem z jakieś ściągawki znalezionej w internecie
(poniżej tylko przykład, niestety nie zapisałem sobie linka na przyszłość, ale jestem prawie pewien, że podpowiedź znalazłem na stackoverflow, opisy z linka brzmią dość wiarygodnie, tj. robiłem to w jakiś w miarę podobny sposób, ale poszukaj jednak samodzielnie alternatywnych rozwiązań)

Zajęło mi to jakieś 3 dni, a naprawiona baza i tak nie zawierała wszystkiego (dlatego sugeruję użyć wcześniejszy backup w którym masz bazę jeszcze nieuszkodzoną).
Potem zmigrowałem z RPi na x64

Ale powiem tak - od paru lat uszkodzić sqlite w HA jest raczej trudno - HAOS przy starcie systemu naprawia pliki, a baza jest też automatycznie naprawiana bodajże przy starcie HA.

Swoją drogą moje 2 instalacje przeżyły setki zaników zasilania, a oprócz tego jednego razu nie miałem problemów (teraz jedna z instalacji ma UPSa, a w drugiej nie doświadczam tak częstych zaników zasilania - naprawiono instalację w bloku).

Ale na RPi może po prostu karta skończyła żywot (RPi3 i RPi4 wspierają możliwość pracy na ssd podpiętym przez USB i to zarówno jako jedynym nośniku, jak i z bootowaniem HAOS z karty, a dyskiem tylko na dane).

PS Doświadczyłem też parę razy sytuacji odpięcia dysku w obudowie USB od RPI w trakcie pracy i w zasadzie to przeważyło szalę na korzyść x64.

PioSko · 5 Sierpień 2023 14:47

Czy jest jakiś prosty sposób by zmigrować dane z natywnej bazy HA do MariaDB?

artpc · 6 Sierpień 2023 17:59

Chyba prostego nie ma, raczej hardcore
https://community.home-assistant.io/t/migrating-home-assistant-database-from-sqlite-to-mariadb-only-if-you-are-very-familiar-with-database-administration/96895

Tomasz_Max · 12 Marzec 2025 09:26

Podepnę się pod ten temat, bo jest bardzo podobny do mojej sytuacji. Wczoraj, po tym porannym “czyszczeniu” wyparowały mi wszystkie dane historyczne (HA postawiony na terminalu we wrześniu 2024.), a w logu znalazłem to:

Rejestrator: homeassistant.components.recorder.util
Źródło: components/recorder/util.py:307
integracja: Recorder (dokumentacja, Problemy)
Pierwsze zdarzenie: 04:12:05 (1 zdarzenia)
Ostatnio zalogowany: 04:12:05

The system will rename the corrupt database file //config/home-assistant_v2.db to //config/home-assistant_v2.db.corrupt.2025-03-11T03:12:05.069168+00:00 in order to allow startup to proceed

Nie wykonała się również kopia zapasowa, prawdopodobnie z tego właśnie powodu.
Przywróciłem kopię z dnia poprzedniego, oczywiście tracąc dane z wczoraj. Zaktualizowałem do 2025.3.1., nie znalazłem nigdzie ostrzeżeń o błędach na dysku (SSD). Dzisiaj sytuacja się powtórzyła, acz backup już się wykonał.
Patrząc na wielkość plików kopii zapasowych - ta uszkodzona baza zajmuje 740 MB, zaś pusta to tylko 80 MB. Może ten rozrost (nie jestem pewien, kiedy mocno zaczęło rosnąć, ale stawiam na wdrożenie Solarmana) jest przyczyną? Jak duże mogę być te bazy?
Nie wiem, czy jestem gotowy na walkę o odzyskanie poprzedniej bazy, zwłaszcza że dwóch ostatnich dni i tak nie przywrócę, ale chciałbym uchronić się przed powtórką. Co sugerujecie?

szopen · 12 Marzec 2025 09:58

U mnie w porywach bywało sporo ponad 4GB, po optymalizacjach z ostatnich miesięcy schudła do około 3GB (dane historyczne są mocno przetrzebione).
Jaki masz zakres gęstych danych recordera?
(wiem, że są hardkorzy, którzy ustawiają sobie nierozsądny zakres gęstych danych i u nich baza potrafi być wielokrotnie większa niż moja).

Natomiast inna kwestia, bo tym się nie pochwaliłeś - ile masz wolnego miejsca na dysku czy tam udziale dedykowanym dla HA?

Tu jak rozumiem przyznajesz się do własnoręcznego grzebania w bazie, może gdzieś popełniłeś jakiś kluczowy błąd…

Przywróć backup sprzed ręcznych modyfikacji (dla mnie sens walki się zaczyna powyżej utraty 2 tygodni, może miesiąca danych).

hmm a masz zainstalowane hdd-tools lub scrutiny ewentualnie wersję beta samba-nas ?

Tomasz_Max · 12 Marzec 2025 10:13

Nie, nawiązuję tutaj do początku wątku, że system coś robi nad ranem, a na pewno robi automatyczną kopię. Nic nie grzebałem.

Ok, spróbuję jeszcze raz i spróbuję z którymś narzędziem, które lepsze dla średnio zaawansowanego?

Jednocześnie, dziękuję za tak szybką i rozbudowaną odpowiedź.

szopen · 12 Marzec 2025 10:23

W takim razie w kluczowym momencie mogla nastąpić utrata zasilania (baza jest odporna na wiele zdarzeń, ale bez przesady, chociaż moje instalacje przeżyły setki utrat zasilania a tylko jedno miało jakieś realnie poważne skutki, to jednak bezwzględnie nie wolno odcinać zasilania bez wcześniejszego zamknięcia systemu), to jest instalacja na malinie?

Taka informacja zapobiega zadawaniu dziesiątek zbędnych pytań
Jak podzielić się informacjami o swojej instalacji Home Assistant na forum lub githubie

System coś robi po nocy, to fakt, generalnie kiedyś była zasada, że optymalizacja bazy jest wykonywana bodajże koło 4 rano w 2 niedzielę miesiąca, ale nie wiem czy to obowiązuje nadal.
Oprócz tego są wykonywane backupy, natomiast obróbka historycznych danych statystycznych jest ostatnio wykonywana znacznie częściej, więc nie umiem nawet powiedzieć co się kiedy dzieje.

Tomasz_Max · 12 Marzec 2025 11:28

Najmocniej przepraszam, WYSE 5070:

System Information

version	core-2025.3.2
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.13.2
os_name	Linux
os_version	6.6.73-haos
arch	x86_64
timezone	Europe/Warsaw
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	1642
Downloaded Repositories	3

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

GIOŚ

can_reach_server	ok

Home Assistant Supervisor

host_os	Home Assistant OS 14.2
update_channel	stable
supervisor_version	supervisor-2025.03.2
agent_version	1.6.0
docker_version	27.2.0
disk_total	229.2 GB
disk_used	17.7 GB
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	Matter Server (7.0.0), Get HACS (1.3.1), File editor (5.8.0), Volvo2Mqtt (1.10.5), Mosquitto broker (6.5.0), Terminal & SSH (9.16.0), Meross Local Broker Addon (0.0.1-alpha50), ESPHome Device Builder (2025.2.2)

Dashboards

dashboards	6
resources	4
views	13
mode	storage

Network Configuration

adapters	lo (disabled), enp1s0 (enabled, default, auto), hassio (disabled), docker0 (disabled), vethcff2e05 (disabled), veth11185e3 (disabled), veth7ad3fe9 (disabled), vethe9abe8b (disabled), veth1b69746 (disabled), veth3f3f105 (disabled), vetheb7e3fc (disabled), veth25a5a2c (disabled), vethabd4566 (disabled), veth2bebba0 (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp1s0 (192.168.2.201/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), vethcff2e05 (), veth11185e3 (), veth7ad3fe9 (), vethe9abe8b (), veth1b69746 (), veth3f3f105 (), vetheb7e3fc (), veth25a5a2c (), vethabd4566 (), veth2bebba0 ()
ipv6_addresses	lo (::1/128), enp1s0 (fe80::ab83:eddb:889d:6a0c/64), hassio (fe80::42:20ff:fe66:be52/64), docker0 (fe80::42:adff:feba:731f/64), vethcff2e05 (fe80::748b:5fff:fe15:2d14/64), veth11185e3 (fe80::c0f9:1cff:fe56:d56f/64), veth7ad3fe9 (fe80::3048:8dff:fef4:a93d/64), vethe9abe8b (fe80::e812:9cff:feab:744b/64), veth1b69746 (fe80::8cf9:5bff:fee0:43f6/64), veth3f3f105 (fe80::40d3:10ff:fe29:7f0c/64), vetheb7e3fc (fe80::44f0:d2ff:fe42:f4ba/64), veth25a5a2c (fe80::9811:91ff:fe9b:1829/64), vethabd4566 (fe80::d009:89ff:fedf:e2e4/64), veth2bebba0 (fe80::fcd4:2eff:fe7d:7be6/64)
announce_addresses	192.168.2.201, fe80::ab83:eddb:889d:6a0c

Recorder

oldest_recorder_run	12 marca 2025 03:12
current_recorder_run	12 marca 2025 11:03
estimated_db_size	59.12 MiB
database_engine	sqlite
database_version	3.48.0

Spałem, ale wykluczam zanik zasilania, bo system jest wpięty w wydzielony obwód z UPS w domu - inne sprzęty nie zostały wtedy zresetowane/wyłączone.

artpc · 12 Marzec 2025 18:27

Jeżeli używasz repack to spróbuj wyłączyć ta opcję, zdarzało się że repack uszkadza Bazę. Próbowałeś naprawić Bazę db.corrupt?

Tomasz_Max · 12 Marzec 2025 20:54

Chciałem poszukać tego repack, a tu się okazuje, że nie mogę zmienić katalogu w File Edytor, w ogóle nie mogę przejść do katalogów. To ja za ssh i…
Czy to jest normalne, to co mi się stało z katalogiem config?
(edit - ten zrzut)
Zrzut ekranu z 2025-03-12 22-00-17

Widziałem ten sposób naprawy, ale zastanawiam się, czy tu jest co ratować.
Przynajmniej, okazuje się, że przy HA nie można się nudzić…

szopen · 12 Marzec 2025 21:05

To proste - defaultowa konfiguracja uniemożliwia grzebanie poza katalogiem
/homeassistant (mapowanym na /config, a skoro masz pojęcie o linuxie to config jest symlinkiem do homeassistant), swoją drogą nie wiem po co chcesz z niego wychodzić skoro baza jest właśnie tam.

A w tym mc to jesteś pewnie wewnątrz kontenera ssh.
Z tego ogryzka screenshota nie da się stwierdzić gdzie faktycznie jesteś…

W kontekście w którym piszesz “nudzę się” od wielu lat.

Tomasz_Max · 12 Marzec 2025 21:21

Wiem, że robi się zbyta lamersko, wybacz jeśli robię jakiś dziwny błąd, ale ja wiem, że domyślnie powinienem być na miejscu. Jednak jak wchodzę w FE to mam otwarty (chyba) plik do edycji, którego zresztą nie otwierałem. Mogę go zamknąć, nawet dostaję pytanie o zapis, ale po zamknięciu nic się nie dzieje. Tam, gdzie mogłem poruszać się w drzewie plików mam takie opcje, z tym że ta strzałka w lewo nie działa (bo pewnie otwarty plik). Takie samo okno otwiera mi się w telefonie.

(edit)
Z symlinkiem moja wina, bo byłem przekonany, że katalog homeassistant mam pusty, a ja chyba trafiłem za pierwszym razem w home.

szopen · 12 Marzec 2025 21:59

Z menu Dodatków uruchom ponownie File Editor (bo chyba masz otwarty jakiś plik, którego nie powinieneś był otwierać… a już na pewno nie powinieneś próbować zapisywać pliku co do którego nie masz pewności, że można to zrobić bezpiecznie nie uszkadzając go, bazy nie powinieneś otwierać edytorem tekstu tak swoją drogą…).

Sądząc po urywku (znowu) skorzystałeś z funkcji związanych z githubem.

Sam dialog zamykania niczego nie zapisuje ani nie uszkadza.

jeśli wybierzesz YES zamykasz plik
a jeśli NO nie zamykasz pliku.
W obu wypadkach nie dochodzi do zapisu.

Tomasz_Max · 12 Marzec 2025 22:09

Jak już wcześniej pisałem, nie otwierałem żadnego pliku, ten który się wyświetlał był pusty. I to mnie najbardziej martwi, że się takie rzeczy dzieją.
Plik zamykałem za pomocą YES , widzę że będą miał niezłą opinię
Restartowałem HA i nie pomogło, a po restarcie FE pomogło… Lekcja do zapamiętania, dzięki.
Nie widzę nigdzie repack, więc jeśli jutro backup się zrobi, spróbuję w weekend naprawić bazę.