HA w aplikacja na IOS także nie wstaje po uruchomieniu ponownie, więc to raczej nie chodzi o to.
Możliwe, ale nie dostarczasz żadnych wartościowych danych diagnostycznych, więc mi się pomysły już skończyły.
A nie mam szklanej kuli ani by zgadnąć konfigurację twojej sieci LAN, ani czy sobie z nią radzisz… nie wiadomo nawet, czy za każdym razem dostajesz to samo IP z DHCP
Oto przykład
- po wpisaniu w pasek adresu samego IP nigdy GUI HA się nie otworzy, bo nie jest ono na porcie 80 tylko na 8123
- adres *.local może się nie rozwiązywać w niektórych sieciach (tam gdzie nie działa poprawnie mDNS)
pomijając wszystko powyższe
- używasz Node Red jego nieodpowiedzialne użycie może być źródłem wywrotek systemu, więc na start wyłącz go na stałe.
W Node-red mam tylko i wyłącznie noda z integracja PV chyba nawet z Twojego postu na tym forum.
Adres IP mam przypisany stały dla HA.
Tak wiem że port to moje IP HA :8123
Problem nie ma nic wspólnego z siecią.
Gdyby problem występował z siecią. To po uruchomieniu HA on by się nie ładował, po czym albo zacinał albo tracił połączenie. A jak już pisałem nie raz, serwer pinguje cały czas, a HA zacina się/traci połączenie.
Nie ma innej prostej możliwości sprawdzenia nieznanej przyczyny, niż droga eliminacji…
więc po prostu wyłącz ten Node Red na stałe, użyj przeglądarki bez tłumaczenia itd. (gdy doprowadzisz do sytuacji stabilnej pracy będziesz krok po kroku uruchamiał wszystko z powrotem, aż znajdziesz ten składnik który rozwala instalację)
na skrinszotach z logów nie widać nic co mogłoby być przyczyną problemów z interfejsem, więc może cale HA się wywraca, tylko o tym nie wiesz…
ALE masz też kilka repozytoriów zainstalowanych z HACS, więc masz też albo komponenty niestandardowe (te mogą wywracać HA bo modyfikują jego działanie!!!), albo rozszerzenia lovelace (te za to mogą rozwalić interfejs), albo masz i jedno i drugie
Oprócz NR który jest bardzo niebezpieczny, bo pozwala na uruchamianie niezweryfikowanego kodu, inny znacznie mniej popularny ale z tych samych przyczyn groźny dodatek to AppDaemon (jakkolwiek z niego nie korzystasz).
Za to masz dodatek eWelink, co do którego spore wątpliwości mieli autorzy HA jakiś czas temu (zbudowany wtedy ze złamaniem wielu kluczowych zaleceń dla dodatków - testowałem go kiedyś i wiem, że ingerował w działanie HA), nie wiem czy przez ten czas cokolwiek się zmieniło, więc oprócz NR to jest drugi kandydat do zatrzymania na stałe do czasu odnalezienia problemu.
O dziwo Supervisor działa, ale nie wiadomo kiedy go sprawdziłeś - rób to w momencie gdy masz problemy = zaglądaj pod port 4357
Fajnie, że ogarniasz sieć i adresy, bo są tacy co i o tym nie mają pojęcia, a używają jakoś HA…
Póki przyczyna nie jest odnaleziona eliminujemy wszystko co potencjalnie może szkodzić, niestety w backupie masz najprawdopodobniej coś co przeszkadza w pracy, ale nie chwalisz się konfiguracją to nikt nie sprawdzi YAMLa
A ponieważ w backupie masz i tak prawdopodobnie źródło problemu, ale podejrzewam też ostatnie aktualizacje, to cofniemy się w czasie do lutego inaczej niż z backupu - metodą downgrade (bo może przyczyna leży w marcowej aktualizacji - radośnie założyłem, że robiłeś jakieś aktualizacje, bo jedyne w miarę pełne informacje o twojej instalacji pochodzą jeszcze z debiana, którego miałeś wraz z lutowymi wydaniami HA).
W terminalu (lub w CLI) oczywiście w momencie, gdy jeszcze wszystko działa
ha os update --version 11.4
oglądaj monitor i rób zdjęcia, może jednak coś istotnego tam się pojawia o czym nie wiemy?
a jak już się maszyna ładnie zrebootuje - cofniesz też wersję HA core
ha core update --version 2024.2.5
Oczywiście póki co nie aktualizuj w GUI ani systemu operacyjnego ani HA
Stwórz sensory w integracji systemmonitor i badaj zasoby maszyny.
edit
No jeszcze jedno przemknęło mi przez myśl (ale najpierw wyłącz NR, a potem łap się brzytwy) - używasz HA od niedawna, na jakimś sprzęcie polizingowym, czy w ogóle skutecznie przetestowałeś RAM przed użyciem?
Usunąłem eWelink z configuration.yaml oraz z dodatków → Sprawdziłem konfigurację, jest ok.
Dostęp do GUI odpalam na innej przeglądarce → jest ok.
Zainstalowałem od nowa HAOS przez balentaEtcher przywróciłem kopie, bez aktualizacji HA.
Skomentowałem parę linijek z yaml które niekoniecznie są mi na chwilę obecną potrzebne.
Mój yaml wyglada tak:
Moje informację o systemie:
System Information
version | core-2024.2.4 |
---|---|
installation_type | Home Assistant OS |
dev | false |
hassio | true |
docker | true |
user | root |
virtualenv | false |
python_version | 3.12.1 |
os_name | Linux |
os_version | 6.6.16-haos |
arch | x86_64 |
timezone | Europe/Warsaw |
config_dir | /config |
Home Assistant Community Store
GitHub API | ok |
---|---|
GitHub Content | ok |
GitHub Web | ok |
GitHub API Calls Remaining | 5000 |
Installed Version | 1.34.0 |
Stage | running |
Available Repositories | 1406 |
Downloaded Repositories | 8 |
HACS Data | ok |
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 12.0 |
---|---|
update_channel | stable |
supervisor_version | supervisor-2024.02.1 |
agent_version | 1.6.0 |
docker_version | 24.0.7 |
disk_total | 234.0 GB |
disk_used | 8.3 GB |
healthy | true |
supported | true |
board | generic-x86-64 |
supervisor_api | ok |
version_api | ok |
installed_addons | Cloudflared (5.1.5), Samba share (12.3.0), File editor (5.8.0), Home Assistant Google Drive Backup (0.112.1), Log Viewer (0.17.0), Node-RED (17.0.7), Mosquitto broker (6.4.0), Zigbee2MQTT (1.36.0-1), Advanced SSH & Web Terminal (17.2.0) |
Dashboards
dashboards | 3 |
---|---|
resources | 2 |
views | 5 |
mode | storage |
Recorder
oldest_recorder_run | 2 marca 2024 20:58 |
---|---|
current_recorder_run | 12 marca 2024 14:43 |
estimated_db_size | 104.51 MiB |
database_engine | sqlite |
database_version | 3.44.2 |
Sonoff
version | 3.6.0 (8dd8af9) |
---|---|
cloud_online | 0 / 1 |
local_online | 0 / 0 |
Aktualizację które na chwile obecną wiszą i były aktualizowane przed moim problemem:
Na chwilę obecną po sprawdzeniu konfiguracji i uruchomieniu ponownie system wstaje, GUI się ładuje, jedynie zauważam że ledy TV które są połączone lokalnie przez tuya local czasami są niedostępnę, po czym po chwili wracają.
No i teraz powolutku i bez pośpiechu jeśli tylko zdobędziesz pewność, że wszystko działa przywracaj po jednym wszystkie komponenty, które wyłączałeś aż znajdziesz ten problematyczny.
Nie ma sensu korzystanie z backupu, gdy jest możliwość cofania wersji HA core, ponowna instalacja systemu w ogóle nie była konieczna - jeśli uważasz, że przyczyna jest po stronie OSa (moim zdaniem raczej nie jest, ale nie wiadomo - poprzednio też instalowałeś 12.0?), to wystarczy cofnąć mu wersję do ostatniej, która działała na 100% dobrze.
Tak, za każdym razem wgrywałem tą samą wersję.
Powiedz mi jeszcze co najlepiej robić przed daną aktualizacja ? Tylko backup czy są jeszcze jakieś sposoby na ewentualne problemy po aktualizacji systemu/integracji ?
Przeczytać notatki do wydania, a w szczególności “breaking changes” (czy “backward incompatible changes” jak je nazwano ostatnio w HA core).
To jest bezwzględnie najważniejsze, bo dzięki temu nie zainstalujesz aktualizacji która “położy” twoją instalację, no i oczywiście będziesz mógł przygotować się na zmiany w konfiguracji, dzięki którym aktualizacja nie będzie niebezpieczna, a zamiast tego uzyskasz pożądany efekt.
W przypadku Dodatków są tworzone backupy cząstkowe, nie należy ich zbyt wcześnie kasować to jedyna droga powrotu do ich starszych wersji.
HA core i HAOS mają możliwość downgrade - tak jak opisałem wyżej - “podajesz z palca” wersję i taka zostanie zainstalowana.
Nie ma sensu instalować HAOS od zera, bo ma on mechanizm slotów A/B i przy trzykrotnym nieudanym bootowaniu przełączy się na drugi slot (nie widzę sensu aby wymuszać u siebie posiadanie 2 różnych wersji - z czasem to się samo utworzy, ale jeśli się ktoś by dzisiaj upierał posiadanie zapasowej starszej wersji zaraz po czystej instalacji 15.0 to z 15.0 cofamy system na 11.3 a potem aktualizujemy koniecznie ręcznie, a nie w GUI na 11.4 i ostatecznie dowolną metodą na 15.0 - zasada prosta skok o 2 wersje stabilne w dół i aktualizacja po jednej w górę, wtedy zawsze w każdym slocie będzie inna wersja).
W zasadzie wspominam o tym tylko dlatego, że czasem są zmieniane wersje sterowników kart sieciowych i w razie wykrycia problemu dotyczącego stabilności pracy karty warto cofnąć się o wersję w dół. Jest wręcz nieprawdopodobne by taka wpadka pozostałą niezauważona przez masowych użytkowników, no ale część osób instaluje HAOS na dość nietypowym sprzęcie… (ostatnio ktoś prosił deweloerów systemu o sterownik dla karty WiFi Intel Wireless-N 105, którą raczej można traktować w kategorii zabytków, ale dodano ten sterownik).
Komponenty niestandardowe i rozszerzenia lovelace (generalnie wszystko co znajdziesz w HACS) mają możliwość cofania wersji z poziomu HACS.
Używasz Reverse proxies
?
Cloudflared.(widać w installed_addons)
Nie, tak jak @MariuszAK napisał, używam Cloudflared.
Sprzęt kupiłem z drugiej ręki, który też pracował z HA właśnie na docker.
Mam pytanie odnośnie sprawdzenia tego RAM-u, po utworzeniu pendrive z testerem RAM-u wkładam go do HP i w BIOS mam ustawić aby pendrive się uruchomił jako pierwszy ?
TAK, jeśli chcesz bootować jakiś z system z pendrive, to musisz to ustawić w BIOSie lub przełączyć tymczasowo w menu bootowania (zwykle jakieś F12, ale nie piszesz co za sprzęt to nikt nie sprawdzi).
Jeśli to instalacja po kimś, to w zasadzie możesz wywalić backupy do kubła bo pewnie nie wiesz co tam jest namotane w konfiguracji.
Nic o tym nie wspominałeś, że sam tego nie konfigurowałeś…
PS
Odciąłem ten wątek jak osobny bo nie ma nic wspólnego z migracją instalacji.
Zawsze nowy problem = nowy wątek (można podlinkować w nim jakiś wcześniejszy jeśli to ma uzasadnienie), tytuł roboczy, jeśli znajdziemy przyczynę to się zmieni na jakiś bardziej pasujący.
Żadnych backupów nie było poprzedniego właściciela, był po prostu sformatowany i na czysto zainstalowany docker oraz HA.
Backupa z supervisora nie robię już na HAOS.
Co udało się mi zrobić od wczoraj, zainstalowałem najnowszy core oraz OS, na chwile oebcną nie widzę żadnych problemów. Popróbuję jeszcze z dwa dni, potem uruchomię integrację pojedynczo te które wyłączyłem do tej pory.
HP T620, do BIOS-u wiem jak wejść, bo ustawiłem żeby uruchamiał się bez urządzeń peryferyjnych oraz z automatu startował po zaniku zasilania,
Jeśli uznasz, że przyczyną może być karta sieciowa, to zrób downgrade systemu.
Jeśli dobrze pamiętam to były jakieś wątki, że HP T620 nie nadaje się pod HAOS (może to nieaktualne lub coś pomyliłem, ale po prostu przeszukaj forum)
To mnie intryguje, czyli bez czego?
Bez monitora, aktualizacja BIOS-u z pendrive wykonywałem, ale to na samym początku i po tym dopóki nie zainstalowałem HAOS cały czas działał, więc uważąm że BIOS został poprawnie zaktualizowany.
Mam jeszcze jedno pytanie ta komenda nie wchodzi mi przez SSH.
błąd Host reboot not found: 3(NXDOMAIN)
W terminalu po podłączeniu monitora normalnie działa.
Natomiast te bez problemu
Dodaj ha
przed.
To nie terminal tylko CLI, w terminalu najpierw ha
(tak fizycznie klawiatura + monitor to konsola lokalna, więc można by nazwać terminalem, ale w nazewnictwie HA to się nazywa CLI)
Panowie problem powrócił, a nic nie robiłem z HA od tamtej pory -,-
w logach mam coś takiego, co myślę że może być moim problemem.
Miałeś zanik zasilania (dasz radę to zweryfikować?), albo sprzęt nie pracuje stabilnie (co jest raczej dziwne, jeśli problem występuje na 3 różnych maszynach).
Tego rodzaju błąd masz na jednej maszynie, obu dx0d, czy wszędzie?
Jeśli na 1 konkretnej, to do sprawdzenia w pierwszej kolejności nośnik (ssd/hdd) i RAM.
Odczytu S.M.A.R.T. możesz nawet dokonać na innym sprzęcie po tymczasowym podłączeniu nośnika (dla Windows najlepsze narzędzie to CrystalDiskInfo, bo ma aktualizowaną bazę dysków), dla linuxa fajnie działa GSmartControl o ile tylko pamiętamy, że to nakładka na smartctl, a dla HA narzędzia pod tagiem smart
RAM
Hmmmm a teraz mi przyszło głowy jak o tym napisałeś… HP t620 mam podłączone przez gniazdko zigbee które mam skonfigurowane z HA przez Z2M czy problem nie może stać po tej stronie? Że jeśli HA się ponownie uruchamia gniazdko jest wtedy poza sięcią zigbee i powoduje to że HA się nie uruchamia ?