HA 2022.2.x - problemy

Takie pytanie do tych co zaktualizowali. Jak wam to dziala? Ja musiałem wczoraj przywrócić kopię 2021.12.10. Po jednym dniu sceny oświetlenia i odpalanie świateł z pilota to masakra, opóźnienia rzędu 30 sekund do minuty. Mam jedną scenę która odpala mi żarówki tuya (na integracji local), trzy paski wled i trzy lampki philipsa - to na HA 2021 działa to błyskawicznie a na 2022 w ciagu ok 40 sekund odpalało mi losowe urządzenia. w innych pokojach gdzie wyłaczniki wireless miały po prostu odpalać usługę turn on/turn off lights tak samo opóżnienia do kilkudziesięciu sekund

HA mam postawione na proxmoxie - HA OS 7.2 / supervisor 2022.01.01

Czy logach HA masz taki wpis:

Logger: tuya_iot
Source: /usr/local/lib/python3.9/site-packages/tuya_iot/openmq.py:166

error while get mqtt config

Ma Home Assistant 2022.2.3 i działa

Nie powiem, bo jak pisałem mam już przywróconą z backupu poprzednią wersję. Aczkolwiek to nie kwestia samej Tuii bo jak pisałem wcześniej opóźnienia dotknęly lamp Philips Zigbee oraz wLed’a

Monitorujesz zasoby sprzętu na którym pracuje HA? Objawy które opisałeś są typowe dla kończącego się RAMu.

Jak patrze na wykresy proxmoxa to z przydzielonych 3gb zużycie w zasadzie stałe między 2.5 do 2.7 giga, a sam sprzęt ma 4GB i vm z ha jest jedyna odpalona

Czyli cały czas ponad 80%?(!)
a sprawdzasz użycie swap?

W czwartek jeszcze raz zaktualizuje do nowej wersji i sprawdzę. W tym momencie na wersji 2021 jak patrze na glances to jest spoko - 55% użycia pamięci i 4% swapu. Ale jeśli to nie pamięć…

Screenshot w wiekszej rozdzielczości

To cofniesz znowu wersję (sam cofałem z 2022.2.0 do 2021.12.10, ale nie z takich powodów), od paru dni mam 2022.2.3 i jest OK.
Aktualizacja do 2022.2.x z wcześniejszych dużych wersji konwertuje bazę danych i to może sporo potrwać i zająć zasoby, ale jeśli restart systemu po kilku godzinach od aktualizacji nie pomoże to faktycznie jest jakiś problem.

W kwestii monitorowania zasobów to trzeba je monitorować (czyli gromadzić dane), a nie zajrzeć np. w glances raz na jakiś czas - tylko analiza wykresów cokolwiek powie o tym co się faktycznie dzieje.

Czyli jak rozumiem odpalić integracje system monitor ustawić konkretne typy argumentów w configuration.yaml i niech automatycznie agreguje sobie dane?

Tak, systemmonitor jest raczej najodpowiedniejszy (nie używa intensywnie zasobów jak kontener Glances)

przykładowy fragment “wyrwany żywcem” z mojej konfiguracji (może wymagać lekkiego dostosowania, system mam zainstalowany natywnie, a nie w VM)

sensor:
  - platform: systemmonitor
    resources:
      - type: disk_use_percent
        arg: /home
      - type: disk_use
        arg: /home
      - type: disk_free
        arg: /home
      - type: swap_use_percent
      - type: swap_use
      - type: swap_free
      - type: memory_use_percent
      - type: memory_free
      - type: memory_use
      - type: processor_use
      - type: load_1m
      - type: load_15m
      - type: last_boot
      - type: ipv4_address
        arg: enp1s0
      - type: ipv6_address
        arg: enp1s0

dodatkowo używam do tego command_line, ale tu już są to rzeczy wybitnie dopasowane do sprzętu

sensor:
  - platform: command_line
    name: ACPI Temperature
    command: "cat /sys/class/thermal/thermal_zone0/temp"
    unit_of_measurement: "°C"
    value_template: '{{ value | multiply(0.001) | round(1) }}'
  - platform: command_line
    name: CPU Temperature
    command: "cat /sys/class/thermal/thermal_zone1/temp"
    unit_of_measurement: "°C"
    value_template: '{{ value | multiply(0.001) | round(1) }}'

PS Przypomniałeś mi, że miałem zająć się podzieleniem wątku związanego z tym tematem.

PPS W przypadku platform x86-64 i równocześnie niezbyt wypasionego sprzętu jeśli tylko jest to możliwe jestem zwolennikiem instalacji bare-metal zamiast wirtualizacji (nie tracimy cennych zasobów na dodatkowy system hosta, a sens wirtualizacji przy jednej VM jest zerowy)

PPS W przypadku platform x86-64 i równocześnie niezbyt wypasionego sprzętu jeśli tylko jest to możliwe jestem zwolennikiem instalacji bare-metal zamiast wirtualizacji (nie tracimy cennych zasobów na dodatkowy system hosta, a sens wirtualizacji przy jednej VM jest zerowy)

Tylko jak rozwiązać szybkie backupy? w Przypadku proxmoxa mam automat ustawiony który codziennie w nocy robi mi pełen backup VM z HA na synology więc w przypadku jakiegoś problemu w 5 minut przywracam pełną kopie z poprzedniego dnia bez żadnych kombinacji. A jak bym miał HA postawiony 1:1 bezpośrednio na swoim T620 to sie trochę chyba sprawa komplikuje? (Pisze z punktu widzenia zielonki który w linuxie grzebie tylko tyle ile trzeba i gdzie znajdzie gotowego manuala który prowadzi krok po kroku)

PS. przy okazji dzięki za linka bare-metal, poczytam

Tak, w HA nie ma czegoś takiego jak migawki systemu, po prostu są backupy konfiguracji (a w razie wtopy system trzeba postawić od zera, co nie jest w sumie trudne - backup przywraca do życia to co nas interesuje czyli HA).

Mi wystarczają cykliczne backupy do gdrive (bardzo fajny addon jest do tego) - po prostu nie mam NASa pracującego 24/7, ale z całą pewnością istnieją rozwiązania, które dadzą się zaadaptować do twojej konfiguracji np.:

plus artykulik

inne rozwiązanie

kolejne

i jeszcze inny artykulik

Wow :slight_smile: Dziękuje będę miał czym zabijać czas na urlopie niedługo. Póki co, jutro zrobię ponownie aktualizacje do 2022.2.3 i zobaczymy czy problem wraca czy nie.

Dodam coś od siebie, nie tylko do kopii zapasowych, wieloplatformowy:

https://syncthing.net/

1 polubienie

U mnie także stwierdzam dziwne problemy przy upgrade z wersji 2021.12.10 na 2022.2.5
Instalacja także na proxmox ale mam dużo addon-ów i dla bezpieczeństwa mam limit 12 gb ram. Na co dzień ta wartość raczej nie przekracza 6-7 gb.
Po instalacji w logach miałem błędy ingress, których nie miałem nigdy wcześniej, do tego jakieś dziwne zachowanie dashboardu - z pięciu widoków (zakładek) jedna skopiowała się do drugiej i każda zmiana w jednej przenosiła się z automatu do drugiej - jakby się sklonowały - nie dało się tego zmienić w żaden sposób :exploding_head: Masakra jakaś. Jeszcze nie wróciłem do starej wersji. Będę walczył wieczorem.

W razie problemów z GUI podstawową czynnością jest… wyczyszczenie cache przeglądarki.
Aktualizacja do 2022.02.x oprócz konwersji bazy danych zmienia nieco obsługę GUI, więc wyczyszczenie cache przy tej aktualizacji jest bardzo wskazane.


W przypadku dogłębnych problemów, choć nie wydają mi się prawdopodobne (mam na myśli uszkodzenie konfiguracji lovelace) możesz przywrócić ręcznie samą konfigurację lovelace.
W standardowym archiwum (świeżego) standardowego backupu HA znajdź plik homeassistant.tar a w nim podkatalog .storage (z kropką na początku, bo to katalog ukryty) a w nim plik o nazwie… lovelace możesz go przywrócić na swoje miejsce tj. do /config/.storage/lovelace (przypominam, że .storage jest katalogiem ukrytym i to nie bez powodu, jeśli masz jakiekolwiek wątpliwości zrób gdzieś najpierw kopię bieżącego - może uszkodzonego? pliku zanim go zastąpisz).

PS skoro masz proxmoxa to jednym ruchem możesz przywrócić migawkę starego systemu.
Mimo to liczę na to, że stosujesz standardowe backupy w HA, bo tego dotyczy opis przywrócenia konfiguracji samego lovelace, swoją drogą w automatycznie tworzonym backupie przy okazji update (który to backup powinien się nazywać core_2021.12.10, o ile tylko jego tworzenia nie pominąłeś), znajdziesz ostatnią wersję pliku sprzed aktualizacji.

Tak, zgadzam się że często przyczyną dziwnych problemów jest cache przeglądarki, ale już wczoraj je wyczyściłem bez efektu. Co więcej problem występuje na trzech różnych przeglądarkach więc cache bym raczej nie obwiniał.
Ciężko jest ten problem wytłumaczyć na odległość :grinning: musiałbym na skype albo teams pokazać.
Plik tekstowy lovelace w środku - konfiguracja .yaml - na pewno jest ok, co więcej w środku widać że na drugiej zakładce powinno się wyświetlać coś innego a mimo wszystko HA tego nie robi :smirk:
HA dwie zakładki traktuje jak jedną sklonowaną - jeśli na jednej usunę jakąś kartę to automatycznie znika z drugiej :exploding_head:
Jest to dziwne i niespotykane ale nie zamierzam tracić przy tym czasu to próbowałem nowe dashboardy robić i ustawiać je jako domyslne żeby tamtego starego już nie brał pod uwagę i problem wciąż występuje. Jest to strasznie irytujące i wydaje mi się jednym sposobem przywrócić starą wersję, która działała bezproblemowo.

Zgłoś issue tam gdzie trzeba.
Wyobrażam sobie co się dzieje, ale nie mam bladego pojęcia co może być przyczyną (używasz jakieś niestadardowe rozszerzenia lovelace?)

A zwróciłeś uwagę na to, że cały YAML jest nadal w jednym pliku?
Jeśli masz gdzieś błąd to będzie on cały czas rozwalał konfigurację, przy czym z doświadczenia wiem, że błąd wyżej w tym pliku potrafi rozwalać konfigurację wszystkiego co jest niżej - tzn. wadliwa karta w pierwszym widoku danego dashboardu może rozwalać każdy następny widok i każdy następny dashboard.

Jeśli masz backup, to wywal cały pierwszy dashboard ręcznie z pliku (albo “po bożemu” z edytora dashboardów, jedyny problem, to fakt, że metodą “po bożemu” nie usuniesz “fabrycznie domyślnego”).
Po znalezieniu błędu przywróć ten wadliwy i usuń w nim tylko błąd.

PS a w ogóle przywróciłeś stary plik lovelace tak jak opisywałem wyżej i natychmiast zrestartowałeś po tym HA?

a ja u mnie odkryłem co powodowało problemy. Zauważyłem że sceny oświetlenia głupiały jak miałem wrzucone grupy świateł. I to w sumie jest ciekawostka. Mam na przykład grupę 2 kinkietów gdzie mam 4 żarówki i jak w scenie zamiast sterować encją grupy tych żarówek, steruje pojedyńczymi żarówkami wtedy chodzi ok bez żadnych opóźnień.

Jakoś to rozkminiłem, ale też problematyczny był dashboard z oświetleniem. Miałem tam też pogrupowane różne światła. Mozolnie wyrzuciłem wszyskie dashboardy, stworzyłem je od zera i teraz działa dobrze. Nie mam pojęcia gdzie tkwił problem, jesem przekonany że jeden współny plik .yaml z nowymi dashboardami to 100% tego co było wcześniej. Z tym że teraz działa OK. I bądz tu mądry :rofl: