Raspberry Pi 3B+ i ESPHome - PRZESTROGA

Witam wszystkich.
Jeżeli ktoś rozpoczyna przygodę z ESPHome w polaczeniu z serwerem Home Assistanta postawionym na Raspberry Pi 3B+ to sugeruje by nie wgrywać bezpośrednio do modułu esp8266, lecz najpierw skompilować plik binarny i zgrać go na dysk.
image
dlaczego tak? Bo z mojego doświadczenia wynika ze przy zastosowaniu pasywnych radiatorów na malince w trakcie kompilacji pliku binarnego dochodzi do “zagotowania” sprzętu i dopiero twardy reset po schłodzeniu umożliwia dalsza prace na nim.

Co za tym idzie jeśli sprzęt się zagotuje w trakcie fleszowania modułu esp8266, na jakiejkolwiek platformie to go “uceglimy”.

Wygenerowany plik bin wgrywamy za pośrednictwem https://web.esphome.io/ i lokalnego komputera.

W moim przypadku musiałem zastosować “aktywne chłodzenie suszarką” malinki by zdołała wygenerować plik *.bin

2 polubienia

Tak przy okazji - używasz w swoich projektach dyrektywy?

  compile_process_limit: 1
1 polubienie

@Marcin_Domański tak jak pisze @szopen, wystarczy dodać tę opcję i RPi3 daje rady, poniżej moja ekstremalna temperatura procesora, kompilowanie plików ESPHome i wgrywanie OTA jest widoczne na wykresie po godz. 17.

image

1 polubienie

Ogólnie to mam jeszcze takie spostrzeżenie, że RPi model 3B był dość mocno niedorobiony - mój egzemplarz po prostu się sfajczył, a sam się wtedy poparzyłem przy okazji próbując diagnozować problem (swoją drogą i tak już po fakcie). Problem tam dotyczy toru zasilania - zastosowanego VRM oraz generalnie rozwiązania z zasilaniem z gniazda microUSB-B i bliskości tych elementów.

Konstrukcję RPi poprawiono w modelu 3B+, ale niestety pozostawiono gniazdo microUSB-B, które nie jest dostosowane do wysokich prądów (zupełnie nie rozumiem czemu nigdy nie zastosowano zwyczajnego współosiowego gniazda DC, skoro dyrektywa unijna dotyczyła standaryzacji sprzętu powszechnego użytku, a SBC się nie kwalifikują do tej grupy, a w dodatku wielkie korporacje jak Apple i w wielu mniejszych producentów i tak centralnie olały dyrektywę :P).
Obawiam się, że “wyrobiona”, czy wadliwa wtyczka micro może być przyczyną awarii również nowszych modeli (jest wprawdzie opcja zasilania przez złącze GPIO lub wręcz przez podlutowanie się do PCB, ale chyba mało kto korzysta z takiego rozwiązania).

Rozwijając temat - po awarii 3B byłem ciekaw zachowania nowszych modeli i mimo stosowania w ramach eksperymentów wyłącznie pasywnego chłodzenia (a nawet chwilowo zupełnego braku radiatora na 4B, bo kupiłem jako “golasa”, chłodzenie osobno, a Chińczyk we wczesnych czasach RPi4 “omyłkowo” wysłał mi chłodzenie w wersji dla RPi 3 zamiast RPi4) nie udało mi się nigdy doprowadzić do ich zawieszenia wskutek zwiększenia temperatury CPU przy naprawdę dużym obciążeniu procka (throttlowanie moim zdaniem jest skuteczne, choć być może zakłóca proces flashowania, tu taki mały hint - ponieważ ESP nie daje się uceglić, a ESPHome przy ponownej kompilacji niezmienionego projektu tylko linkuje obiekty do binarki zamiast kompilować całość od nowa, można spróbować ponownej kompilacji i flashowania UART kilka minut po ostygnięciu sprzętu).

PS w czasach walki z Covid19 (akurat zmigrowałem już wtedy HA z RPi na x86-64) stworzyłem malutki “pododdział” malinek (+ jednego jetsona - ten wymagał jednak minimalnego chłodzenia aktywnego) pracujących w projekcie Fold For Covid i wszystkie maliny pracowały z pasywnym chłodzeniem by mi nie hałasować (a Boinc obciążał im procki na tyle, że czasami i terminal był mało responsywny).

PPS Hint numer 2:
Zamiast flashowania OTA z poziomu IDE ESPHome można korzystać z flashowania OTA “ręcznie” o ile w projekcie użyjemy dyrektywy

web_server:

oczywiście to nie dotyczy pierwszego flashowania ESP.

1 polubienie

ODP: Nie mam jeszcze swoich projektów :slight_smile:

Stawiam pierwsze kroki… korzystałem narazie z gotowych repozytoriów, zacząłem od projektu radiowego odczytu licznika wody za pośrednictwem modułu CC1101. Próbując poskładać klocki do kupy, jednak trzeba trochę podstrugać - by spasować je z swoim HA. Ale wcześniej trzeba nauczyć się trzymać nóż w ręku.

@szopen @macek: dziękuje za wędkę, przed dalszymi pracami zagłębie się w dokumentacje projektu ESPHome

Napisałem - PRZESTROGA - dla takich zielonych jak ja, by nie “uceglili” sobie sprzętu na dzień dobry. Wskazane przez was ścieżki do dobre praktyki o których warto pamiętać przy podejmowaniu nowych projektów.

ESP nie dają się tak łatwo uceglić :stuck_out_tongue: “uwalony programowo” MCU można bez problemu ożywić flaszując ponownie przez UART.

Natomiast bez większego trudu można “upiec” ESP (i każdy inny MCU 3,3V) stosując bezpośrednie połączenia z zewnętrzną logiką 5V.

Wystarczy dopisać tą linijkę w sekcji esphome:

esphome:
  ...
  compile_process_limit: 1

wielokropek symbolizuje tu inne linijki spotykane w tej sekcji.
1 to jeden rdzeń
RPi3 ma 4 rdzenie
możesz poszukać kompromisu między wydajnością kompilacji (maksimum rdzeni), a przegrzewaniem (jeden to minimum, może uda się uzyskać stabilną pracę podczas kompilacji na większej ilości rdzeni np. 2 lub 3?).

Czasami układy flash stosowane na tanich modułach ESP są kiepskiej jakości (i spotkałem się wiele razy z problemem konieczności zaprogramowania modułu więcej niż 1 raz tym samym wsadem aby działał poprawnie), czasami problemem jest… niedobór zasilania.
Sytuacja zapisu pamięci flash powoduje radykalne zwiększenie poboru prądu przez moduł ESP, a właściwie jego pamięć flash (więc możliwe, że masz po prostu za słaby zasilacz w RPi, bo skoro do niego podpinałęś moduł, to zasilacz musi obsłużyć i RPi i wszystkie jego “normalne przyległości” jak np. ssd czy inne dongle USB).
To zasadniczo wynika z wewnętrznej budowy pamięci flash.

1 polubienie

Jak znajdę schemat podłączenia i metodę by go “ożywić” to napisze w tym wątku :slight_smile:
Na przykładzie: ATB-USBAsp ATNela i NodeMcu v3


Czyli:
Programator → NodeMcu
VCC → 3v3
GND → G
Tx → Rx
Rx → Tx
Pamiętając by programator przestawić na 3.3 V na VCC (akurat ten robi to automatycznie)

Nie wiem, nie znam, nie widziałem jeszcze takiego by automatycznie dobierał napięcie zasilania (bo skąd ma wiedzieć jakie jest potrzebne).

Jakkolwiek zawsze można zasilić moduł we właściwy mu sposób i nie podpinać zasilania między przetwornikiem USB-UART a modułem (jedynie linie GND muszą być połączone!).

Natomiast kwestia “ożywiania” jest taka - dla modułów zawierających własny UART nie potrzeba żadnego zewnętrznego UARTu, kluczowe może być natomiast spięcie GPIO0 z masą (GND) przy włączaniu zasilania modułu ESP.
Często jest to wymagane przy pierwszym flashowaniu “pustego” modułu.
To w szczególności jest konieczne, jeśli w ESPHome użyjesz innej definicji modułu niż faktycznie używasz.

ALE! Jeśli dobrze kojarzę NodeMcu v3 ma układ automatycznego flashowania, ale płytka musi być zdefiniowana jako

esp8266:
  board: nodemcuv2

Tia i jeszcze jedno można sądzić - że v2 nie pasuje do sprzętu, ale nazwa definicji płytki zwykle pochodzi o najpopularniejszej odmiany o tych samych kluczowych flakach, a tymczasem ta definicja pasuje też dla NodeMCU v1.0 (ale uwaga nie do v0.9)


Tak zupełnie z innej beczki - u siebie (platforma x86-64) w ramach oszczędności czasu przy aktualizacjach robię 2 kompilacje ESPHome jednocześnie (to 4-wątkowy. 4-rdzeniowy celeronek)
ESPHome_kompilacja_x2_2022-12-20_15-58

@Marcin_Domański chyba za bardzo dorozumiał instrukcję :wink:

Chodzi bardziej o to że programator ustawia poziomy ttl na podstawie napięcia procka.

1 polubienie

Niestety nie pomogło…
Przy pierwszej próbie padł serwer HA (zrestartował się)
Przy drugiej użyłem suszarki jako “aktywnego trybu chłodzenia malinki”

obciążenie procka i temperatura jaką osiągnął sprzęt:

Dziwne, masz radiator, który się styka z prockiem?
Testy robiłem parę lat temu, i throttling zwalniał proca wielokrotnie, ale bez wywrotek.
Monitorujesz też obciążenie RAM i swapa? (oprócz procka)
Jeśli tak, to wrzuć to na jednym wykresie, może RAMu brakło?
W końcu RPi3 ma tylko 1GB (gdybym nadal był na takim sprzęcie to przed kompilacją zatrzymałbym wszystkie inne Dodatki).

Metoda na sztuczne powiększenie swapa w HAOS jest w tamtym wątku

o ile oczywiście masz system na ssd, bo kartę TF to zajeździsz swapowaniem.

Obrazek na potrzeby tego wątku - 2 równoczesne kompilacje (zaktualizowałem sporo sprzętu, gdy w jednym oknie się kończyło zaczynałem następne w drugim)


4GB RAM, więc 20%=~800MB

@Marcin_Domański dopiero teraz zwróciłem uwagę na temperatury na twoim obrazku - moim zdaniem procek w twoim RPi nawet nie throttluje (BCM2837B0​ zrzuca zegar o połowę dopiero w okolicy 75 °C), przyczyną nie jest przegrzewanie, myślę że to brak RAMu.

Masz racje RAMu mam tylko 1GB, tylko dlaczego jeśli nie włączę suszarki to się resetuje, a przy włączonej nie. To mi nie pasuje. Radiatory oczywiście mam.

UPDATE1:
Powyłączałem wszystkie zbędne na czas kompilacji dodatki (NodeRED, ) - zużycie pamięci spadło do 68% i uciągnął, kompiluje bez suszarki.

Szczerze mówiąc nie widzę powiązania z suszarką, tu byś musiał dorzucić taki sensor, by było wiadomo czy procek istotnie throttluje

  - platform: command_line
    name: CPU Speed
    command: "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq"
    unit_of_measurement: "GHz"
    value_template: "{{ value | multiply(0.000001) }}"
    scan_interval: 5

powyższy jest wyciągnięty z konfiguracji dla RPi4, ale jeśli mnie pamięć nie myli powinien też działać na RPi3
(zmiana zegara jest kilkustopniowa, więc tego nie obserwując nie mamy danych, moje eksperymenty sprzed paru lat dotyczyły chłodzenia, a nie braku RAM) przy około 75 °C CPU zrzuca zegary do minimum, ale być może jest to kwestia zejścia z maksymalnego zegara do wartości pośredniej, co przedłuża proces kompilacji na tyle, że następuje np. reakcja Supervisora.

Natomiast w kwestii braku RAMu - system się wywraca w momencie gdy oprócz RAMu zostanie w całości wykorzystany swap.
Generalnie system nie powinien się wywrócić - Supervisor powinien zabić procesy powodujące zagrożenie dla systemu, więc zapewne zabija ESPHome, ale powiązania z suszarką nie widzę.


Taka wrzutka nie na temat, ale może warto wiedzieć


na obrazku 4-rdzeniowy celeronek, po lewej stronie procek bez obciążenia (działa tylko HA “z przyległościami”) po prawej dodatkowo wrzucone obliczenia które zajmują równo połowę procka (2 rdzenie).
Na pierwszym wykresie widać, że celeronek w ramach oszczędności energii zrzuca zegary prawie o połowę, jego obciążenie widać na drugim wykresie, przy okazji też na drugim widać że jedna z aktualizacji zainstalowanych 19.12.2022 wieczorem zwiększyła obciążenie procka o kilka procent.
W tej instalacji mam 8GB RAMu (sporo za dużo, bo jak widać w użyciu jest koło 1,5GB, ale w dalszych planach są Dodatki które mogą go potrzebować).
Ostatni wykres to temperatury, NUC ma tzw. pół-pasywne chłodzenie, tj. przy braku obciążenia jest pasywne, a wiatrak rusza (w tych warunkach z niesłyszalną prędkością) dopiero po osiągnięciu jakiejś temperatury (nie pamiętam jakiej, BIOS ma predefiniowane krzywe chłodzenia i jest wybrany profil cichy), tu widać, że się uruchomił i nieco przewiał obudowę, bo mimo wzrostu temperatury procka spadła temperatura ssd - ostatnia linia na wykresie temperatur to temperatura otoczenia (i była niezmienna a ssd nieco ostygł, ale jak widać nieznacznie, bo wzrost temperatury procka ostatecznie wyrównał warunki).

To tak w kwestii jakbyś planował przesiadkę na platformę x86-64 (bo niestety na RPi RAMu nie dołożysz, a RPi3B+ wciąż można wykorzystać do wielu innych sensownych zastosowań, niestety ilość wodotrysków w HA powoduje jego stosunkowo wysoką zasobożerność i 1GB zaczyna być za małą ilością pamięci na nieco bardziej rozbudowane instalacje).

I zapewne masz rację, z ciekawości odpaliłem HA na jakimś szufladowym Rpi3B+ i on bez próby kompilacji ledwo dycha.

Home Assistant Supervisor

System operacyjny hosta Home Assistant OS 9.4
Kanał aktualizacji stable
Wersja Supervisora supervisor-2022.11.2
Wersja agenta 1.4.1
Wersja Dockera 20.10.19
Pojemność dysku 57.8 GB
Pojemność użyta 17.6 GB
Zdrowy true
Wspierany true
Układ rpi3-64
API Supervisora ok
Wersja API ok
Zainstalowane dodatki File editor (5.4.2), Mosquitto broker (6.1.3), Node-RED (14.0.0), Samba share (10.0.0), SSH & Web Terminal (13.0.0), ESPHome (2022.11.5)

Wyżej podlinkowałem wątek, w którym jest opisane jak zwiększyć sobie swap w HAOS (bo używanie sprzętu z 1GB RAMu wciąż jest możliwe, ale niestety twórcy systemu nie przewidzieli, że w pewnych zastosowaniach może zabraknąć tyle swapa co przewidzieli), HAOS na starszych modelach RPi nie bez powodu nie jest wspierany (jeszcze 2 lata temu było możliwe odpalenie HAOS bez zasobożernych dodatków na RPi zero i “jedynce”, które miały po 512MB…).

No mnie właśnie czeka przesiadka na HAOS, bo ja nadal mam HA na Raspbianie :slight_smile:

Na RPiOS powiększenie swapa to bułka z masłem

Są użytkownicy forum którzy przechodzili z debianowych instalacji na HAOS.
Bez zmiany sprzętu przejście na HAOS nie ma sensu (jeśli mówimy o RPi3 lub słabszych sprzętowo modelach).

1 polubienie

Dzięki za podpowiedz, wkońcu znalazłem chwile by ze 100MB zwiększyć SWAPa do 2GB :slight_smile: Nie wiem czy to ma większy sens dla Malinki z 1GB RAMu, ale działa dysk SSd na przejściówce USB daje rade i to nawet bardzo dobrze bo przy włączonych wszystkich dodatkach (Node_RED, Z2M) stabilnie skompilował plik binarny i nie doprowadziło to do resetu malinki. Dzięki @szopen za wskazówkę rozwiązującą omawiany problem.

skąd pobierasz dane : raspberry Temp ? jaka to encja …jak jej nie widzę w swoim HA

mój HA na rPi 4 - w ustawienia / sprzęt / Raspberry Pi 4 …widzę tylko “procesor” i “pamięć” … zresztą tych sensorów też nie wiem gdzie znaleźć jeśli bym chciał je mieć na swojej karcie lovelace