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
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)
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.
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:
| 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 |
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
| 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 | 1 |
|---|---|
| resources | 0 |
| views | 5 |
| mode | storage |
| 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 
Jeśli masz proxmox ver 7 to zaktualizuj sterowniki karty sieciowej.
Dell 5070 ma właśnie kartę Realtek
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.
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.
Dodatek ESPHome nie jest nikomu do życia potrzebny, ale
Statystycznie najczęstsze przyczyny tak poważnych problemów to zazwyczaj
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 
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)
Wrzuce kilka obserwacji z mojej strony.
