ESPHome rozszerzenie Home Assistanta o DIY oparte na ESP

[szopen]

Model i producenta modułu ESP musisz podać (od biedy może być link do sklepu, choć wolimy tu linki do dokumentacji producenta modułu), bo nie mam tyle pary, aby pisać jakiś ogólny manual.
(jeśli jakimś cudem mam identyczny to może spróbuję krok po kroku, ale tworzenie takiego tutoriala zajmuje zdecydowanie za dużo czasu)
Ogólna instrukcja dla WROOM 32:
https://randomnerdtutorials.com/esp32-pi...nce-gpios/
ale ja nie mam go w ręce, więc nie wiem jak wygląda ten twój, ale jeśli to faktycznie "goły" moduł do montażu powierzchniowego to poleciałeś hardcore jak na początek:
https://en.wikipedia.org/wiki/ESP32
(jakkolwiek podejrzewam, że masz całkiem inny moduł w który WROOM-32 jest po prostu wlutowany).

W telegraficznym skrócie
0a. Zawsze trzeba przeczytać dokumentację modułu (a często warto mieć ją pod ręką )
0b. Definiując nowy moduł musisz podać jego prawidłowy model (a jeśli nie ma presetu wybrać jakiś zbliżony lub ogólny szablon)
0c. ESPHome nie wymaga żadnych kombinacji z bootloaderem, jedyna istotna kwestia to wybór właściwego modelu w trakcie konfiguracji, reszta dzieje się "automagicznie".
0d. Pisząc "uruchomienie ESPHome" mam na myśli Supervisor->Dashboard->ESPHome->Start (i wtedy "kontrolka" zmienia się z szarej na zieloną), ewentualnie jeśli ESPHome już pracuje można użyć Restart bądź sekwencji Stop, a potem Start.
Nie mam na myśli natomiast na myśli otwarcia interfejsu ESPHome (z sidebaru czy w inny sposób, tj. przez przez otwarcie WebUI np. z Dashboardu)
0e. Częste kompilacje intensywnie zużywają kartę TF (microSD), więc należy sobie zorganizować cykliczne tworzenie snapshotów, gdzieś poza kartą TF (ja używam do tego pluginu https://github.com/sabeechen/hassio-google-drive-backup ), bo prędzej czy później karta padnie i będzie trzeba postawić sobie system z backupu (lepiej mieć roboczą partycję na ssd, ale tutoriala o tym raczej nie napiszę, bo ja radzę sobie z takimi rzeczami w raczej nietypowe sposoby, czytaj: raczej nie warte naśladowania, np. za pomocą clonezilla czy gparted, a oficjalne metody muszą się prędzej czy później pojawić)
0f. Nie jestem żadnym "guru" z tej dziedziny, więc mogę się mylić w wielu kwestiach (to jest też powód, dla którego nie chwalę się niektórymi rozwiązaniami, o których wiem, że są złe i powinienem je zmienić, ale nie mam chęci lub czasu).
0g. Kluczowe jest drążenie oficjalnej dokumentacji https://esphome.io/
np. pliki konfiguracyjne mogą zwierać dyrektywy w rodzaju include - tu akurat hasła i SSID od sieci są wyrzucone do pliku /config/esphome/secrets.yaml (sam plik jest tworzony zgodnie z zasadami panującymi w HA) przy jednym module to wydaje się nieistotne, ale gdy się robi ich więcej warto mieć już gotowe takie rozwiązanie, ssid dla "ratunkowego AP" ustawiam w każdym module inny na wypadek konieczności ich rozróżnienia (tu akurat powiązanie z nalepkami identyfikującymi moje eksperymentalne moduły)

Kod:

wifi:
  ssid:  !secret wifi_ssid
  password: !secret wifi_pass

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "esp01_01_nie_mam_wifi"
    password: !secret wifi_rcvr

i przykładowa zawartość pliku secrets.yaml (czyli wartości haseł są fikcyjne ;P zostawiłem też "fabryczne" komentarze, by mieć w razie W dokumentację pod ręką)

Kod:

# Use this file to store secrets like usernames and passwords.
# Learn more at https://home-assistant.io/docs/configuration/secrets/

wifi_ssid: ssid_wifi
wifi_pass: haslo_do_tego_wifi
wifi_rcvr: haslo_do_hotspota
ota_pass: haslo_ota

1. Za pierwszym razem (w celu pierwszego flashowania) moduł musi być podpięty przez USB do RPi, a dopiero potem można uruchomić ESPHome (w menu Supervisor, dawniej hassio, jeśli było już uruchomione to restart lub stop + po chwili start, oczywiście nie można mieć wtedy niezapisanego pliku w edycji) to jest warunek konieczny by ESPHome rozpoznało użyty UART.
Dla modułu bez USB to samo (UART podpięty przed uruchomieniem ESPHome) - trzeba podpiąć zewnętrzny UART na tych samych zasadach, a port szeregowy z modułem Rx do Tx modułu, Tx do Rx, a GND z GND (oraz oczywiście zasilanie podłączone do modułu, większość mostków USB-UART umożliwia też zasilanie układu, jeśli są zworki to należy wybrać 3,3V, jeśli nie ma wyboru trzeba się pomodlić )

Warto zajrzeć do Supervisor->System->Hardware przed (by zapamiętać sytuację) i po podłączeniu modułu (lub UARTu) do RPi by wiedzieć gdzie faktycznie szukać modułu (np. gdy po podpięciu pojawi się dodatkowo choć to tylko przykład /dev/ttyUSB2 to potem po ponownym uruchomieniu ESPHome trzeba wybrać rzeczony /dev/ttyUSB2 jako port do flashowania, zamiast domyślnego OTA, w tym menu mamy wylistowane wszystkie porty szeregowe, więc trzeba wiedzieć który jest właściwy, UWAGA po restarcie systemu numeracja portów może się zmienić, szczególnie jeśli mamy równocześnie podpięte kilka urządzeń korzystających z portów szeregowych na takim samym chipsecie, ale nie stanowi to problemu, bo USB jest hotplug, więc zawsze można odpiąć moduł by sprawdzić co znika i podpiąć ponownie sprawdzając pod jaką nazwą się pojawi, jakkolwiek po takim rozłączeniu musimy zrestartować ESPHome by mógł sobie od nowa przypisać aktywne porty, no chyba że nie zamierzamy flashować przez port szeregowy - malina czy inny SBC może stanowić przecież też tymczasowe źródło zasilania dla modułu z którym łączymy się już po WiFi)

2. Oprócz tego przy pierwszym flashowaniu moduł ESP musi być wprowadzony ręcznie w tryb flashowania. Niektóre mają przyciski, więc zwykle wtedy kombinacja polega na wciśnięciu przycisku Flash następnie krótko Reset i można puścić Flash po kilku sekundach - zazwyczaj można się połapać po kontrolkach LED kiedy jest ten właściwy moment, czasem te przyciski są opisane inaczej, ale po kontrolkach można się połapać który jest do czego, dla modułów bez przycisków tryb flashowania to GPIO0 zwarte do masy podczas resetu (zasada ta sama co powyżej), a GPIO2 w stanie wysokim (zazwyczaj nie wymaga żadnych połączeń byleby nie był podciągnięty do masy), czasem inne piny muszą być w specyficznym stanie (dokumentacja modułu wita - przykładowy ESP-01 tego wymaga, a ESP-01s już nie, tzn. wymaga ale na płytce ma już właściwe pullupy, które starszej wersji modułu musimy sobie sami zorganizować), najprostsze moduły (bez USB ani przycisków) najłatwiej zresetować przez chwilowe odłączenie im zasilania.
https://github.com/espressif/esptool/wik...-Selection

3. Czasem "pierwsze flashowanie" trzeba wykonać kilka razy, na dobry początek warto wrzucić sobie jakąś ultra prostą konfigurację do modułu, jakieś przykłady podawałem wyżej (UWAGA konfiguracja musi być w pełni kompletna!)
http://forum.jdtech.pl/Watek-home-assist...4#pid48124

tu przykładowo taki minimalny kompletny kod dla TTGO T7 (oczywiście musi być dopasowany do realiów) tu jest użyty uniwersalny szablon esp32dev, ale dla wielu innych płytek są gotowe definicje

Kod:

esphome:
  name: ttgo_mini_t7
  platform: ESP32
  board: esp32dev

wifi:
  ssid: "ssid_wifi"
  password: "haslo_do_tego_wifi"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Ttgo-T7 Fallback Hotspot"
    password: "haslo_do_hotspota"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

switch:
  - platform: restart
    name: "TTGO T7 Restart"

sensor:
  - platform: wifi_signal
    name: "TTGO T7 sygnał WiFi"
    update_interval: 60s
  - platform: esp32_hall
    name: "TTGO T7 sensor Hall'a"
    update_interval: 60s
  - platform: uptime
    name: "TTGO T7 Uptime"

4. Mając już działający moduł po pierwszym flashowaniu można przejść na OTA (odłączyć go od RPi i np. umieścić w docelowym miejscu, po to w tej minimalnej konfiguracji jest możliwość podglądu sygnału sieci WiFi) i kolejne kompilacje już wgrywać przez powietrze

5a. Czasem zdarza się wyprodukować firmware które "uwali" moduł - nie zawsze kompilator znajduje błędy, zawsze coś można skopać, pozostaje wtedy metoda "pierwszego flashowania" przez USB/port szeregowy, oczywiście po usunięciu wadliwego fragmentu kodu (dokumentację trzeba mieć pod ręką, wiele funkcji wzajemnie się wyklucza, więc "szyjąc na styk możliwości modułu" łatwo coś przeoczyć - parę własnych błędów opisywałem wcześniej)
5b. Bywają też sytuacje gdy flashowanie "po kabelku" jest konieczne z innych powodów (czasem jest po prostu wygodniej, gdy zmieniamy np. nazwę modułu, choć można zrobić to i przez OTA, ale 2-etapowo)