Hej,
Dzisiaj zauważyłem pewną dziwną przypadłość. HA mam od ponad roku, ale obecnie próbując dodać kamerę czy przez Generic Camera czy Onvif, urządzenia są widoczne tylko do resetu HA. Szczerze mówiąc nie mam żadnego punktu zaczepienia.
Po resecie to normalne (tyle o ile bo sam reset jest czymś, co nie powinno wystąpić), po restarcie nie.
Zresetowanie hosta w ogóle jest od wielu lat sytuacją anormalną (na tyle, że klawisz “reset” przestał się pojawiać na obudowach komputerów z 20 lat temu), nie wolno też odcinać zasilania od komputera z jakimkolwiek zaawansowanym systemem plików, zamiast tego należy robić restart systemu lub jego zamykanie używając do tego właściwych funkcji.
Jeśli masz już uszkodzony system plików to należałoby go naprawić.
Dzięki za odpowiedź. Nieprecyzyjnie się wyraziłem. Chodzi oczywiście wyłącznie o restart HA a nie reset (tym bardziej niespodziewany) maszyny (mam bare metal dla HA).
Po prostu po restarcie znika mi dodana świeżo kamera. W opcjach naprawy nie mam niczego związanego z systemem plików.
Oczywiście mogę nie restartować HA
Oczywiście nie możesz nie restartować HA - tego wymagają choćby jego aktualizacje.
Być może encje nie mają unikalnych id i się im zmienia systemowe id po restarcie tj. jeśli miałeś encję
camera.cokolwiek
to poszukaj czy po restarcie nie utworzyła się camera.cokolwiek_2
Jeśli masz tak związane usta i nie dajesz nam żadnych danych diagnostycznych (informacji o sprzęcie z którym są problemy, konkretów z konfiguracji, pasujących do zagadnienia logów itd, zignorowałeś nawet podpowiedź jak pokazać podstawową konfigurację swojego systemu), to nikt nie jest w stanie pomóc bardziej konkretnie.
Właściwie nawet nie wiadomo gdzie sklasyfikować ten wątek (bo kto powiedział że problem leży w HA?)
Dzięki jeszcze raz. Oczywiście jestem świadomy konieczności restartów. Ironicznie wspomniałem o powstrzymywaniu się od nich.
Nie mam problemu z podzieleniem się danymi, po prostu myślałem, że Twój hint dotyczy sprawdzenia, czy system plików nie wymaga naprawy.
Wyszedłem z pytaniem o dużym poziomie ogólności, bo jak sam przyznałeś, nie wiadomo do czego przypiąć problem.
Encje sprawdzałem wcześniej, mając podobne podejrzenia. Zmieniałem im indywidualnie nazwy na wszelki wypadek. Po restarcie znikają.
Nie wiedziałem, czy problem dotyczy nowej kamery (może to po prostu HW lub komunikacja), więc dodałem wcześniej istniejącą i skonfigurowaną jako generic kamerę za pośrednictwem Onvif jako duplikat. Po restarcie została tylko pierwotna encja generic, więc to raczej nie problem poza HA.
Poniżej przedstawiam informacje o systemie:
System Information
version | core-2024.10.3 |
---|---|
installation_type | Home Assistant OS |
dev | false |
hassio | true |
docker | true |
user | root |
virtualenv | false |
python_version | 3.12.4 |
os_name | Linux |
os_version | 6.6.54-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 | 4988 |
Installed Version | 2.0.1 |
Stage | running |
Available Repositories | 1448 |
Downloaded Repositories | 30 |
Home Assistant Cloud
logged_in | false |
---|---|
can_reach_cert_server | ok |
can_reach_cloud_auth | ok |
can_reach_cloud | ok |
Home Assistant Supervisor
host_os | Home Assistant OS 13.2 |
---|---|
update_channel | stable |
supervisor_version | supervisor-2024.10.2 |
agent_version | 1.6.0 |
docker_version | 27.2.0 |
disk_total | 116.7 GB |
disk_used | 12.2 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 | Samba share (12.3.2), File editor (5.8.0), Let’s Encrypt (5.2.3), Cloudflared (5.1.22), Advanced SSH & Web Terminal (19.0.0), Home Assistant Google Drive Backup (0.112.1), Studio Code Server (5.17.2), Mosquitto broker (6.4.1), Zigbee2MQTT (1.40.2-1), eBUSd (23.2.6), AppDaemon (0.16.7), Network UPS Tools (0.13.2) |
Dashboards
dashboards | 2 |
---|---|
resources | 11 |
views | 6 |
mode | storage |
Recorder
oldest_recorder_run | 12 października 2024 05:09 |
---|---|
current_recorder_run | 22 października 2024 12:21 |
estimated_db_size | 314.52 MiB |
database_engine | sqlite |
database_version | 3.45.3 |
Rozszerzając informacje podjąłem kilka prób:
-cofnąłem się do kopii zapasowej sprzed 2 miesięcy (nic to nie zmieniło)
-zmieniłem IP jednej z obecnie działających kamer, żeby zobaczyć czy zmiany zostaną zachowane po resecie. Nie zostały. HA nie trzyma wprowadzonej zmiany w konfiguracji, przywracając pierwotną wartość.
Jak dla mnie wstępny wniosek był taki - uszkodzony system plików i/lub nośnik i może bym się przy tym upierał, gdybyś miał instalację na karcie TF na jakimś SBC, ale… masz peceta i jak sądzę ssd. W tym wypadku możesz sprawdzić co się dzieje z nośnikiem hdd-tools scrutiny (i mimo wszystko polecam to zrobić).
Natomiast ogólnie wydaje mi się, że przegapiłeś jakieś breaking change dotyczące twojej konfiguracji - problem dotyczy tylko kamer czy czegokolwiek innego też?
Może to jakieś pozostałości w konfiguracji YAML, gdy już istnieje możliwość konfigurowania danego komponentu z GUI?
Dzięki za podpowiedź. To jest pierwsze urządzenie, z którym napotkałem problem. Dość systematycznie dodaję urządzenia i nie napotkałem na kłopoty, ale są to głównie Zigbee. Jedynym wyjątkiem był videofon na Local Tuya, ale też dodał się bez problemu.
Skorzystałem z Twojej podpowiedzi dot. dysku i sytuacja ze scrutiny wygląda jak na obrazku.
Nie mam doświadczenia w interpretacji, ale jak rozumiem raczej powinienem się przejąć dwoma statusami różnymi od zielonych?
Nośnik (w sensie kości flash) raczej się nie sypie (tzn. nie widzę krytycznych błędów dotyczących nośnika), ale masz problem z zasilaniem i/lub kablem sata ewentualnie kontrolerem w tym dysku. Właściwie to może też być problem z przegrzewaniem, ale jakiś taki ucięty ten screenshot…
Co to za dysk?
Temperatura wygląda OK. Mam rezerwowy dysk na wypadek awarii, więc mogę go wymienić i sprawdzić rezultat.
Pełny zrzut:
Nie mam czasu na głęboką analizę, ale moim zdaniem kabel sata do wymiany (to nie usunie już istniejących błędów, po prostu przestaną przyrastać), sugeruję śledzenie parametrów w miarę upływającego czasu.
Jeśli to m.2 to ja rozkładam ręce - nie chwalisz się czy stosujesz jakieś przejściówki czy inne cuda (a nie mam czasu na szukanie specyfikacji tego konkretnego modelu i oficjalnej tabeli S.M.A.R.T. dla niego) - sprawdzałeś go w ogóle po zakupie?, a jak wygląda w hdd-tools (niektóre parametry smart nie są dostatecznie ustandaryzowane i zdarzają się różnice między producentami - scrutiny może akurat rozpoznawać sytuację błędnie, jakkolwiek wskazane parametry niezależnie od tego czy zostały rozpoznane poprawnie wyglądają dość krytycznie).
Natomiast nie wiązałbym tego wszystkiego z opisywanym na wstępie problemem (podejrzewam, że problemy z dyskiem wykryliśmy przy okazji, niestety istotnie dane mogą być uszkodzone i właściwie nie wiadomo za wiele - ani czy faktycznie są uszkodzone, ani w jakim stopniu, a przede wszystkim od kiedy).
Hmm no i backup sprzed 2 miesięcy nie brzmi dobrze - reakcję na nieprawidłowe zachowanie systemu należy zacząć natychmiast po wykryciu problemu. Rozumiem, że pewność dotyczącą prawidłowego działania HA miałeś 2 miesiące temu, więc tak - oczywiście możesz spróbować przywrócić instalację na innym nośniku.
To wszystko przy założeniu, że nie przeoczyłeś breaking changes dotyczących twojej instalacji.
Dziękuję za odpowiedź i oczywiście poświęcony czas.
Dysk sprawdzałem przed montażem po kupnie. Mam drugi dysk na takie okazje a także równolegle drugą maszynę z Proxmox (m.in. na wypadek konieczności nagłej przesiadki).
Backupy robię google backup daily. Najstarszy miał 2 miesiące a błąd został wykryty przedwczoraj.
Ponieważ mam również zwyczaj robienia backupów 3-2-1, więc znalazłem nieco starszy zbiór niż wspominałem. Problem tam nie występuje niezależnie od tego, że dokonałem aktualizacji do bieżącej wersji HA i otoczenia.
Problem pojawia się za to ponownie w przypadku częściowego restore z zaznaczeniem gałęzi Home Assistant.
Można więc przypuszczać, że geneza leży w uszkodzonym dysku, który uszkodził dane w niewiadomym stopniu.
Pozostaje więc wymiana dysku, ponowne postawienie HA, przywrócenie ostatniej funkcjonującej wersji i ręczne postawianie zmian, które wprowadzałem.
Jeśli masz peceta z windowsem i możliwość podpięcia tego ssd w dowolny sposób (można i przez przejściówkę USB) to świetnym projektem jest CrystalDiskInfo (co ważne nie wymaga podmontowania partycji, więc w niczym nie przeszkadza linuxowy system plików) - jego baza parametrów SMART raportowanych przez dyski różnych producentów jest wręcz imponująca (więc jest duża szansa, że w nim parametry będą miały prawidłowe nazwy, nawet jeśli w scrutiny nie zostały dobrze rozpoznane)
Jeśli chodzi o naprawę sytuacji to sugeruję użyć inny nośnik i na nim przywrócić prawidłowo działąjacy backup.
Jakimkolwiek narzędziem, które czyta SMART?
To był sprzęt z drugiej ręki? (jeśli nie, to zapewne się kwalifikuje na reklamację - biorąc pod uwagę pracę 24/7 nawet nie ma roku przebiegu, ba jeśli to był outlet z roczną gwarancją, to i tak warto zwrócić)