Problem z zawieszaniem się HA

Cześć od miesiąca mam problem z HA. System mi się zawiesza coraz częściej co dzienne resety nic nie pomagają. Zawieszanie jest nie systematyczne i w logach wyskakuje mi ciągle bład Error doing job: Exception in callback _SelectorDatagramTransport._read_ready(). Proszę o pomoc w czym może być problem. Komputer na serwer to Wyse 5070 z proxmox


To jest przydzielona moc

Co to jest Shelly SHCB-1 ? Generalnie problem z Shelly, coś dodawałeś ostatnio ?

Po kodach udało mi się znaleźć że są to żarówki shelly

Shelly Colour bulb 1

Witamy na forum.
Na początek kilka uwag aby komunikacja była skuteczna i Twoje wpisy nie zniechęcały potencjalnie chcących pomóc.

Zamiast wklejać obrazki, zaznacz logi i wklej sformatowany tekst. Należy to zrobić w nasypujący sposób jak wskazał kolega @szopen (dodatkowo kilka innych uwag):

I tu coś leszcze ode mnie:

ten log wygląda tak

Logger: homeassistant
Source: components/shelly/coordinator.py:219
First occurred: 15:13:43 (150 occurrences)
Last logged: 15:50:04

Error doing job: Exception in callback _SelectorDatagramTransport._read_ready()
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 1163, in _read_ready
    self._protocol.datagram_received(data, addr)
  File "/usr/local/lib/python3.11/site-packages/aioshelly/block_device/coap.py", line 185, in datagram_received
    self.subscriptions[device_id](msg)
  File "/usr/local/lib/python3.11/site-packages/aioshelly/block_device/device.py", line 195, in _coap_message_received
    self._update_s(msg.payload, msg.coap_type)
  File "/usr/local/lib/python3.11/site-packages/aioshelly/block_device/device.py", line 247, in _update_s
    self._update_listener(self, BlockUpdateType.COAP_PERIODIC)
  File "/usr/src/homeassistant/homeassistant/components/shelly/coordinator.py", line 335, in _async_handle_update
    self.async_set_updated_data(None)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 426, in async_set_updated_data
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 182, in async_update_listeners
    update_callback()
  File "/usr/src/homeassistant/homeassistant/components/shelly/coordinator.py", line 219, in _async_device_updates_handler
    cfg_changed = block.cfgChanged
                  ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aioshelly/block_device/device.py", line 521, in __getattr__
    raise AttributeError(
AttributeError: Device SHCB-1 with firmware 20201008-085327/master@a3d98bb0 has no attribute 'cfgChanged' in block device

I jak go wiążesz ze zwisami HA?
HA zawisł o 15:13:43?
Bo jest taka sprawa:

przez poprzednie 149 wystąpień tego błędu jednak na 100% nie zawisł, więc chyba szukasz w nienajwłaściwszym miejscu

teraz coś nowego:
Ustawienia → System → Naprawy → “hamburger menu” → Informacje o systemie → (popup) Informacje o systemie → KOPIUJ
i wklej ze schowka do posta tak jak jest (ten tekst jest już prawidłowo sformatowany dla githuba lub naszego forum)

  1. dodatkowe info w jakiej sytuacji problem wystąpił pierwszy raz (np.po aktualizacji czegoś), czy próbowałeś coś z tym robić (np. przez cofnięcie wersji czegoś np. przez przywrócenie poprzedniej z backupu) itd.

  2. masz jakieś sensory zasobów HA?
    coś w guście tego
    Wyciągnięcie danych z sensorów z raspberry PI do HA - #2 przez szopen
    tylko oczywiście dostosowane do twojej instalacji
    jeśli nie to je stwórz, bo wykresiki by się przydały

Nie wiem jestem w tym nowy. Problem wygląda tak że tak co 24 godziny zawiesi system. Zanim dodałem system automatycznego resetu pokazywało mi że zajmuje mi 6,8 gb ramu na 7 i myślę czy coś mi ramu nie zasyfia przez to mogły by być zawieszenia?

Edit:

@szopen

System Information

version core-2023.12.3
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.11.6
os_name Linux
os_version 6.1.63-haos
arch x86_64
timezone Europe/Warsaw
config_dir /config
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 11.2
update_channel stable
supervisor_version supervisor-2023.11.6
agent_version 1.6.0
docker_version 24.0.7
disk_total 62.3 GB
disk_used 9.1 GB
healthy true
supported true
board ova
supervisor_api ok
version_api ok
installed_addons Spotify Connect (0.12.6), UniFi Network Application (3.0.0), Node-RED (16.0.2), Grafana (9.1.1), File editor (5.7.0)
Dashboards
dashboards 1
resources 0
views 5
mode storage
Recorder
oldest_recorder_run 6 grudnia 2023 07:58
current_recorder_run 16 grudnia 2023 15:13
estimated_db_size 32.65 MiB
database_engine sqlite
database_version 3.41.2

jedyne wykresy jakie mam to z proxmox z tygodnia


to moim skromnym zdaniem może być źródło problemu z wywrotkami systemu, ale musimy ustalić czy to faktycznie ma miejsce, czy masz tylko takie wrażenie oglądając VM od zewnątrz… (a nie od środka)

nas nie interesuje jak widać VM od zewnątrz, więc stwórz sensory z posta wyżej

Moja propozycja prostego testu - wyłącz Node Red na 3 dni, bo tak naprawdę na pierwszy rzut oka masz prawie “pustą instalację”, więc podejrzany na “pierwszy ogień” jest kod uruchomiony w NR.

Dodałem system monitorowania zasobów i na chwilę obecna pokazuje 24% zajęcia pamięci ram i miałem do zrobienia aktualizację jednej żarówki. To dam znać jak znów by się zawiesiło. Bardzo dziękuje za pomoc :grin:

Jeśli masz proxmox ver 7 to zaktualizuj sterowniki karty sieciowej.
Dell 5070 ma właśnie kartę Realtek

2 Likes

Na RPI4B z 4 GB ramu też zaobserwowałem wyciek pamięci: przez pół doby z 26% do 42%. Zaczęło się to 15-12, prawdopodobnie po aktualizacji Core do v.2023.12.3.
Przywróciłem v 2023.12.1 i będę obserwował.
Edit: Niestety to nie pomogło. Wyłączałem dodatki, integrację ale bez sukcesu. Pomogła wczorajsza aktualizacja Esphome do v.2023.12.1. A już jest nowa v.3. , ale już jej nie aktualizuję, bo znów coś się schrzani.

1 Like

Ja mam ten sam problem - codziennie wymaga resetu
(RPi5). Ponadto zauważyłem, że nawet krótkie odłączenie przewodu ETH powoduje zwis systemu i konieczność chamskiego restetu przez wyłączenie zasilania.

Jeśli będziesz korzystał z takich rozwiązań to w końcu uwalisz sobie bazę danych.

Zamiast “ruskiego resetu” (odłączenia zasilania) podłącz lokalną konsolę tj. klawiaturę + monitor i skorzystaj z poleceń w CLI.

Niestety podstawa to znalezienie faktycznej przyczyny.

Samo wylewanie żali nie wystarczy.

Może skomentuję skoro się akurat podpiąłeś tutaj.

  1. Dodatek ESPHome nie jest nikomu do życia potrzebny, ale

    • nie zaobserwowałem problemu wycieku pamięci w żadnej z jego wersji przez kilka ostatnich lat (tj. od kiedy go używam, co jeszcze nie znaczy, że nigdy taki problem nie wystąpił, ale nic mi o tym nie wiadomo, a akurat ESPHome aktualizuję mniej więcej na bieżąco, a nawet czasem testowo używam wersji beta)
    • zdiagnozowanie wycieku pamięci w dowolnym Dodatku jest stosunkowo łatwe - wystarczy w Integracji Home Assistant Supervisor włączyć sensory monitorowania zasobów tych Dodatków, które podejrzewamy o nieprawidłową pracę.
  2. Statystycznie najczęstsze przyczyny tak poważnych problemów to zazwyczaj

    • uruchomiony wadliwy kod np. w Node Red
    • wadliwy komponent niestandardowy
    • konfiguracja HA nie dostosowana do koniecznych zmian związanych z jakąś aktualizacją (breaking changes) lub po prostu błędy w konfiguracji
    • realne problemy sprzętowe - na platformach SBC częste problemy to zasilacz nie dostosowany do potrzeb danej konfiguracji (akurat dla RPi jest dostępna integracja Kontroler zasilacza Raspberry Pi) oraz problemy dotyczące karty TF (microSD), czasem problemy wynikają z przestarzałego firmware.
  3. Pozostawanie bez aktualizacji na starych wersjach nie jest rozsądne. Jeśli jakaś aktualizacja powoduje problem to pojawiają się do niej hotfixy, tym szybciej im szybciej dany problem zostanie zgłoszony jako issue we właściwym miejscu.

Jak można w CYWILIZOWANY SPOSÓB postąpić inaczej, jak RPi5 zamienia się w “cegłę” ?
Zasilacz jest oryginalny 27W. Zwis następuje wtedy,
kiedy kabel ETH zostaje odłączony i przyłączony z powrotem. Może to są problemy związane z niedopracowaniem obsługi Ethernetu,
Ostatnio w trakcie jest przenoszenie Proxmoxa na procesory ARM, i może HA na nim postawiony będzie stabilny “jak skała”. Podobno już działa na RPi5 (niedopracowane jest kilka funkcjonalności, w tym ETH, ale działa z przejściówkami USB-ETH, jest nawet działająca obsługa EFI).
Ludzie mają problemy z niezawodnością i stabilnością przy instalacjach typu “metal bare”, co nie występuje przy stosowaniu środowisk wirtualizacyjnych takich jak Proxmox lub Docker.
Być może trzeba poczekać i są to problemy “wieku dziecięcego” w przypadku tego modelu RPi5 ?

Podłączyłeś lokalną konsolę (klawka + monitor wpięty w hdmi0)?
I co jakie efekty? pochwalisz się?

Możliwe, nie mam maliny piątki i nie planuję.


DŁUGI OFF TOPIC
Kiedyś miałem 2 instalacje HA na malinach: trójce i trójce z plusem, ta pierwsza się fizycznie zjarała z powodu błędów projektowych sprzętu, wymieniłem na kolejną trójkę z plusem.
Później postanowiłem mimo wszystko iść do przodu w tym samym kierunku i kupiłem czwórkę zaraz po premierze (najwyższy wtedy model 4GB RAM), to było jakieś 5 lat temu, następnie czekałem na aktualizację firmware pół roku, aby się stała zdatna do użytku, zanim się doczekałem trafił mnie szlag - zmigrowałem na pecety i jestem od 5 lat szczęśliwym użytkownikiem obu instalacji HA na platformie x86-64 (konkretniej kupiłem wtedy 2 NUCe intela, które cenowo były porównywalne z maliną), aktualizacja firmware pojawia się kilka miesięcy później. Dzisiaj ta malina czwórka czasami robi u mnie za instalację eksperymentalną i jest to rozwiązanie akceptowalne (chociaż mi zupełnie nie pasuje konieczne “druciarstwo”), a nawet inny egzemplarz czwórki (wersja 2GB RAM) działa u znajomego jako jego główna instalacja HA (ale to rozwiązanie tymczasowe - będzie coś x64).

Chyba tak, więc tu odpowiem: zapewne trzeba poczekać od kilku tygodni do kilku miesięcy… eksperymentalne wsparcie dla maliny piątki pojawiło się niedawno w styczniu 2024 w HAOS 11.3, wersja 11.5 zawierała jakieś ważne łatki, ale zapewne warto być na najnowszej wersji systemu.

A mówię to jako były fan malin wszelakich :upside_down_face:

Pierwszą malinę kupiłem na przedsprzedaży w 2012 i to był model B 256MB, bo nie było żadnego innego - dzisiaj na to mówią jedynka, to była taka rewolucja na rynku, że zanim się doczekałem dostawy wypuszczono model B 512MB i taki dostałem za wcześniej zapłacone pieniądze.

Plusem tego sprzętu była wtedy cena i tylko cena, bo Broadcomm nigdy nie był otwarty na open-source i nawet licencje na wspomaganie sprzętowe kodeków mpeg2 i vc1 dla tej “jedynki” trzeba było kupić osobno dla konkretnego numeru seryjnego SoC. Swoją drogą BCM2835 był SoC’em pierwotnie zaprojektowanym do budżetowych linii smartfonów (np. wszystkie modele z linii Samsung Y z tamtych lat były na tym SoC i wszystkie wkrótce stały się elektrozłomem z powodu tak zamkniętej polityki Broadcomm’a).

Kwestia wsparcia open-source przez Broadcomm nie zmieniła się przez te kilkanaście lat - dalej oni są “na nie”.

Natomiast założyciele malinowej fundacji (od początku to miał być sprzęt do użytku edukacyjnego stąd fundacja non-profit) wyczuli dość szybko dobry biznes i zaczęto produkować modele dedykowane do użytku przemysłowego (linia CM) i w zasadzie od trójek w górę jest to już projekt czysto komercyjny (przy sprzedaży powyżej pół miliona sztuk rocznie), swoją drogą produkcją i sprzedażą malin nie zajmuje się już fundacja, tylko normalny komercyjny podmiot założony na te potrzeby…

Szkoda tylko, że wsparcie programowe ślimaczy się jeszcze bardziej niż kiedyś (no ale to w końcu closed-source Broadcomma, więc działające sterowniki leżą w gestii producenta SoC i tu nie pomoże wsparcie społeczności, a twórcy HAOS też są od tego uzależnieni).

PS W HAOS-generic (a właściwe w dedykowanej edycji SBC dla maliny piątki) nie powinno być żadnego problemu z wykorzystaniem wybranych modeli kart Ethernet na USB, bo pewna pula sterowników takich kart jest wkompilowywana w wydanie dla każdej platformy pracującej bare-metal.

Niestety nad kwestią wyłączenia wbudowanej karty sam musisz popracować samodzielnie = poszukać w malinowej dokumentacji, może wyłączanie karty nie będzie w ogóle potrzebne, podłącz kartę USB i sprawdź.

Green Ethernet był kiedyś przyczyną problemów w starszych wersjach malin samej karty nawet nie trzeba było deaktywować.
Niestety podobno w piątce dtparam=eee=off nie działa jak należy.

Hmm piszesz o generic, ale na malinie piątce powinieneś do instalacji HAOS użyć obrazu dedykowanego systemu dla SBC
haos_rpi5-64-<wersja>.img(.xz)
a nie generic dla aarch64
haos_generic-aarch64-<wersja>.img(.xz)

1 Like

Wrzuce kilka obserwacji z mojej strony.

  1. Mialem HA na PRI4 podlaczone kabelkiem do LAN. RPI ma problemy i “gubi polaczenie” po jakims czasie przez co system jest niedostepny. Mozna uzywac Wifi ale w moim rozwiazaniu w szafie Rack mialem skretke i chcialem aby wszystko bylo bezpiecznie po kablu.
  2. RPI4 z karta SD po jakims czasie ta karte spali (za szybkie zapisy). Próbowałem z wieloma kartami (jeszcze na wcześniejszych wersjach od 0.72 w górę)
  3. Aby uniknąć wszelkich problemów z pamięciami, ramem, instalacjami itp polecam zainstalować Home Assistanta na czystym sprzęcie bez żadnych proxmoxów i innych udziwnień.
  4. Wirtualizację proponuję robić na innych maszynach, osobno a HA trzymać osobno (wg woli - ja zauważyłem że najlepiej mieć automatyzację domu dostępną 24/h).
    Jesli masz mozliwosc proponuje zainstalowac system na czyms innym niz raspberry - oszczedzisz sobie niepotrzebnych problemow i straty czasu.
    Ja zmigrowalem na HP T620 i jestem zadowolony ale w przyszlosci wymienie na cos mniej prądożernego (np. Odroid ale wciąż się zastanawiam).