ESPHome rozszerzenie Home Assistanta o DIY oparte na ESP

[szopen]

Tym razem kilka słów o ESPHome https://esphome.io/index.html
który w HA zainstalujemy jako plugin dodając repozytorium:
https://github.com/esphome/hassio
edit1 (listopad 2019): obecnie już ten krok nie jest potrzebny (chyba, że chcemy korzystać z wersji beta lub developerskiej), standardowa wersja ESPHome jest dostępna w Supervisor-> Sklep z dodatkami, w grupie Home Assistant Community Add-ons
edit2 (marzec 2022): wszystko wraca do korzeni, obecnie poprawne repozytorium to:

Kod:

https://github.com/esphome/home-assistant-addon

Ten wątek powstał przez wydzielenie tego tematu z wątku dedykowanego Home Assistant:
http://forum.jdtech.pl/Watek-home-assist...egracji-id

Opis jak to szybko ogarnąć:
https://esphome.io/guides/getting_started_hassio.html
w każdym razie - instalacja bez sprzętu nie ma sensu (więc warunki początkowe to działający HA oraz posiadanie jakiegoś sprzętu, który damy radę sflaszować na firmware ESPHome).

Nie ukrywam to dość świeże wrażenia, bo dopiero niedawno zmusiłem się do lekkiego ruszenia tego tematu, pragnąc uzyskać coś możliwego dla ESP32, konkretnie zamarzyła mi się zdalna bramka BLE (szczegóły po co i dlaczego póki co odpuszczam), więc nadszedł czas aby temat nieco ogarnąć.

Z założenia nie chciałem rozgrzebywać gotowych urządzeń mających ESP na pokładzie (bo nie wiem jeszcze jakie ostatecznie będą miały zastosowanie i czy np. nie zostaną na fabrycznym sofcie), ale się okazało, że jednak miałem w szufladzie płytkę prototypową NodeMCU ESP8266 moduł dokładnie taki jak widać w dokumentacji:
https://esphome.io/devices/nodemcu_esp8266.html
(a właściwie to jego chiński klon obrandowany Amica(!) a dostępny od ręki również w PL choćby w znanych sklepach dla hobbystów, jakkolwiek przynajmniej 2x drożej niż w ChRL) spora lista podobnych płytek prototypowych
http://docs.platformio.org/en/latest/pla...tml#boards
pełna baza płytek rozwojowych dotycząca także innych platform (m.in. ATmel czy STM) https://platformio.org/boards
Główny problem tego sprzętu to brak wbudowanego BT (więc w ten sposób nie osiągnę celu), no ale chciałem się wdrożyć - jak się okazuje to rozwiązanie jest ultra-proste w obsłudze… (i to znacznie bardziej niż się spodziewałem, a właśnie potencjalny poziom trudności mnie wstępnie odstraszał, ale jak się okazuje dokumentacja jest bardzo przystępna).

Doskonały opis pinoutów różnych płytek ESP8266 (mam w szufladzie też klony płytek Ai-Thinker ESP-01S, ale nadają się raczej tylko do ultraprostych projektów)
https://randomnerdtutorials.com/esp8266-...nce-gpios/
chociaż ultra-podstawowy opis można znaleźć nawet na wiki https://en.wikipedia.org/wiki/ESP8266

Do rzeczy - na dobry początek wpiąłem moduł za pomocą kabelka USB do RPi (wbudowany port USB microusb w module załatwia 2 kwestie za 1 zamachem - zasilanie i programowanie "po kabelku", wiadomo, przerabiając jakieś gotowe urządzenia poziom trudności nieco rośnie - trzeba mieć w zanadrzu jakiś konwerter USB->UART np. CP2102 - taki akurat mam fabrycznie zamontowany na płytce w opisanym module, ważne by pracował z napięciem 3,3V by nie spalić procka, albo np. FT232RL, czy CH340G - na 100% każdy kto zdecydował się na grzebanie w sprzęcie tego rodzaju ma coś takiego w szufladzie), potem instalacja (to kilka minut przypuszczalnie znaczenie ma też szybkość łącza do internetu, ale generalnie jeśli ktoś ma już hass.io na RPi, to wie że trzeba poczekać cierpliwie), uruchomienie pluginu ESPHome, kompilacja kodu (nawet takiego, który nie robi nic, no dobra to by było za proste - postanowiłem zmierzyć napięcie zasilania procka akurat w 8266 jest to banalne, ale wyklucza użycie wejścia analogowego) i flashowanie

kroki od kompilacji przez flaszowanie (oprócz pierwszego można to robić później już jako OTA) po uruchomienie układu trwają na RPi3B+ około minuty

Kod:

esphome:
  name: nodemcu8266_test
  platform: ESP8266
  board: nodemcuv2

wifi:
  ssid: "SSID_sieci"
  password: "klucz_do_sieci"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "tu_8266_nie_mam_sieci"
    password: "klucz_do_fallback_AP"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

sensor:
  - platform: adc
    pin: VCC
    name: "VCC Voltage"

---

No to teraz niech to robi coś użytecznego, przegrzebałem szuflady i znalazłem parę rzeczy, które można wykorzystać do budowy własnych wynalazków.

Na pierwszy ogień poleciało DHT11
https://esphome.io/components/sensor/dht.html
moja konfiguracja jest minimalnie inna (mimo, że użyłem gotowca z rezystorami) - jak się okazuje autodetekcja układu nie działa w przypadku mojego egzemplarza (bądź modelu DHT11 i trzeba go jawnie podać), może to kwestia zasilania 3,3V, które sobie "bezczelnie" podebrałem z płytki 8266

W drugim kroku do układu dorzuciłem ultradźwiękowy czujnik odległości HC-SR04 (chytry plan zakłada wykorzystanie go do szacowania poziomu paliwa w zbiorniku dla pieca na pellet, obawiam się że może być z tym słabo w kwestii trwałości, ale te czujniki są tanie jak barszcz, czas pokaże… a najpierw muszę zrobić jakąś sensowną konstrukcję do pracy w piwnicy)
https://esphome.io/components/sensor/ultrasonic.html
oczywiście nie obyło się bez trudności - przegapiłem w dokumentacji napięcie zasilania 5V i usiłowałem zasilić go z 3,3V (akurat tylko 3,3V podebrałem sobie na cały breadboard, na którym to złożyłem w kilka minut, ale można też z płytki zabrać 5V z pinu Vin), co ciekawe objawy były dość dziwne do zdiagnozowania - wskazywał odległość rzędu kilku cm (a tego typu rozwiązanie daje w miarę dokładne wyniki w zakresie od 20cm, w/g botland chodzi o 2cm, do koło 2-3m, przy czym w typowej konfiguracji jest timeout bodajże przy odległości 2m), po odłączeniu pinu zwracającego sygnał echa dostawałem timeout (czyli niby wszystko w porządku, a jednak nie )
Planowałem cel edukacyjny, a będzie chyba realne zastosowanie (do budowy takiego czujnika zabierałem się chyba z pół roku, pewnie mozna by to ogarnąć na prostszym sprzęcie, ale WiFi + możliwość dorzucenia do kompletu jeszcze kilku czujników chyba zrobi robotę…).

poniższy kod zawiera tylko sekcję poświęconą sensorom, ale oczywiście musi być kompletny (resztę mamy przecież już gotową)

Kod:

sensor:
  - platform: adc
    pin: VCC
    name: "Napięcie VCC"
  - platform: dht
    model: DHT11
    pin: D7
    temperature:
      name: "Biurko Temperatura"
    humidity:
      name: "Biurko Wilgotność względna"
    update_interval: 60s
  - platform: ultrasonic
    trigger_pin: D1
    echo_pin: D2
    name: "Sensor ultradźwiękowy"

no i na bis w ramach ułatwienia sobie życia dołożyłem tez sekcję umożliwiająca reboot (mimo połączenia WiFi to zaledwie maksymalnie koło 15sek. przy konfiguracji ze statycznym IP ten czas spada do paru sekund) lub zatrzymanie systemu na tym prototypie (w sumie nie wiem po co, bo to konstrukcja odporna na zaniki zasilania, ale może się przyda w dalszych eksperymentach? bo to naprawdę tryb deep-sleep, ale bez możliwości wybudzenia, przynajmniej podobno, ale skoro tak twierdzi developer…).

Kod:

switch:
  - platform: restart
    name: "Biurko Test Restart"
  - platform: shutdown
    name: "Biurko Test Shutdown"

w interfejsie HA wygląda to teraz tak:
   

---

A teraz sprawca całego zamieszania - LYWSD02, czyli zegarek z wyświetlaczem e-papier + czujnikami temperatury i wilgotności
https://esphome.io/components/sensor/xia...wsd02.html
Jak się okazało w miejscu montażu nie sięga BT wbudowany w RPi… (którym ogarniam sobie kwiatki z czujnikiem miflora, co ciekawe z nimi nie było problemu związanego z zasięgiem?),
ale na bis: HA póki co nie ma bezpośredniej biblioteki do obsługi czujników tego zegarka (a dodatkowo nie ukrywam - jestem "za cienki w uszach" by sobie samemu to naskrobać, mimo że w sieci jest już co nieco na ten temat… ale to i tak by sprawy nie załatwiło przez brak zasięgu), a…

ESPHome dla ESP32 załatwia ten temat niemal od ręki, bo ten moduł ma wbudowany BT można więc za jego pomocą stworzyć sobie bramkę dla urządzeń BLE
https://esphome.io/components/esp32_ble_tracker.html
https://esphome.io/components/binary_sen...sence.html
(a ponieważ kupiłem za około 20zł moduł ESP32-CAM - cos takiego:
https://randomnerdtutorials.com/esp32-ca...duino-ide/
i czekam na jego przybycie, to sobie chyba jakoś nim to ogarnę, kamera przecież nie jest obowiązkowa szczególnie, że to raczej zabawka), konstrukcja jest dość nietypowa jak na ESP32 (ze względu na dodatkowe 4MB pamięci PSRAM specjalnie dla obróbki obrazu, oprócz wbudowanych w ESP32 320kB), ale jeśli się nie uda, no cóż majątku w tym nie utopiłem - można po prostu sprzęt wykorzystać jako dodatkową kamerę (o raczej kiepskich możliwościach, ale np. do podglądu w mniej istotnym miejscu?)
https://randomnerdtutorials.com/esp32-ca...assistant/
najwyżej pomyślę o ESP32 w bardziej typowym wykonaniu, a wybór płytek jest również spory:
http://docs.platformio.org/en/latest/pla...tml#boards

Oprócz tego ESPhome zawiera też biblioteki obsługujące np. takie rzeczy zawierające BLE jak:
Okrągły termometr LCD z czujnikiem wilgotności LYWSDCGQ
https://esphome.io/components/sensor/xia...sdcgq.html
czy czujniki MiFlora HHCCJCY01
https://esphome.io/components/sensor/xia...jcy01.html

[szopen]

W międzyczasie dotarł do mnie dość miniaturowy wyświetlacz e-ink (znów e-papier ) Waveshare E-Paper 1,54' w wersji czarno-białej (póki co tylko do takiej jest wsparcie w ESPHome, Arduino ma już wsparcie także dla wersji biało-żółto-czarnej i biało-czerwono-czarnej, więc i tu się pewnie z czasem pojawi) z interfejsem 4-Wire SPI, jest to kwadratowy wyświetlacz o rozdzielczości 200x200pix wielkościowo mniej więcej połowa wyświetlacza opisanego w linku:
https://esphome.io/components/display/wa...paper.html
po 2 dniach "walki" uzyskałem końcową konfigurację, która póki co mnie zadowala
(1 dzień to były testy jak się zachowuje sam wyświetlacz i co umożliwia środowisko ESPHome i zabawa w kotka i myszkę co zrobić, aby sobie nie uwalić działającego kodu , drugi dzień przygotowanie layoutu już "na czysto" i nawet wstępnie mnie on zadowala, choć pozostawiłem sobie dwie naprzemiennie wyświetlane strony, więc jeszcze coś tam można upchnąć gdyby była potrzeba; sam układ elektryczny można jeszcze zoptymalizować, teraz użyłem wszystkich przewodów wyświetlacza, a w finalnym układzie będzie uproszczenie, bo coś czuję, że mi linii GPIO braknie - właściwie to już brakło choć nie musiało)

Polecam na początek przeanalizować taki nieskomplikowany przykład użycia wyświetlacza OLED (bazującego na SSD1306 lub SH1106 - takie wyświetlacze swoją drogą są dość taniutkie) a zwracam na to uwagę, bo projekt ESPHome jest dość ciekawy dla początkujących użytkowników HA i umożliwia wymianę danych w obie strony bez uruchamiania dodatkowego brokera MQTT, a w tym przykładzie jest to ładnie opisane:
https://esphome.io/cookbook/display_time_temp_oled.html

Generalnie do pracy z wyświetlaczami trzeba poczytać przed próbami użycia, bo silnik renderujący żywcem opiera się na funkcjach z języka C++ i składnia jest dość radykalnie inna od pozostałych komponentów ESPHome czy HA, gdzie przeważa YAML (ale i tak trzeba pilnować wcięć, bo nawet jedna zbędna spacja nawet przed komentarzem może rozwalić kod na tyle, że kompilacja nie będzie możliwa)
https://esphome.io/components/display/index.html

Parę uwag:
- wpadłem na genialny pomysł aby podpiąć linię Reset wyświetlacza do GPIO0 ESP8266, bo nie chciało mi się szukać rezystora do pullup'u (to finalnie będzie jedno z uproszczeń), a tymczasem zapomniałem, że GPIO0 jest zarezerwowanym pinem, gdy się korzysta z bajeru z pomiarem napięcia na procku, a tymczasem to dopiero co opisałem w poprzednim poście … i pół dnia poszłooo, już myślałem że doszedł uszkodzony wyświetlacz (akurat folia ochronna jest na nim uszkodzona jak po uderzeniu, a opakowanie było wręcz śmieszne… uszkodzenie widać na zdjęciu w dolnej linijce między 1 a 3, bo tej folii póki co nie usuwam - poczeka do ostatecznego montażu w obudowie)
- współrzędne pikseli są numerowane (przynajmniej w przypadku mojego wyświetlacza, ale reguła wygląda na bardziej ogólną) od 0 do 199, a nie od 1 do 200 (dla rozdzielczości 200pix)
- na polskie literki prawdopodobnie nie ma co liczyć (nakombinowałem się ze znalezieniem jakiejś fajnej czcionki z PL znakami, ale odpuściłem znalezienie rozwiązania, bo wiele znaków się i tak nie renderuje jak należy, dlatego użyłem "PM1" zamiast zapisanych symbolicznie "mikrogramów na metr sześcienny"), fonty to zwyczajne *.ttf trzeba je wrzucić do katalogu ESPHome (lub lepiej do podkatalogu by nie utknąć w bałaganie i podawać do ścieżkę względną z nazwą katalogu)
- jeśli chodzi o renderowanie grafiki, to przećwiczyłem *.png z alfakanałem - chciałem mieć ikonki MDI, czyli zgodne wyglądem z HA, pobierając je z https://materialdesignicons.com/ właśnie takie dostaniemy - nie działają, alfakanał jest ignorowany (może można to zrobić prościej, ale nie wiem jak, może nie dokopałem się w dokumentacji?) obszedłem to obrabiając grafikę by się pozbyć alfakanału, przy okazji zredukowałem ilość kolorów do 2 (nie jestem przekonany, czy był to dobry pomysł, ale chciałem zoptymalizować ich rozmiar, a zależy mi tez na czytelności, nie wiem czy się wyświetlą szarości)
- w ramach testów wyszło na to, że obsługiwane są pliki *.bmp, *.gif i *.png (więcej formatów nie próbowałem) byleby bez alfakanału, teoretycznie renderer obsługuje skalowanie, ale skoro już obrabiałem grafikę, to przygotowałem sobie ikony w finalnym rozmiarze 48x48pix (co daje możliwość wyświetlenia 4 linii z wiodąca ikoną), ale oczywiście nie ma musu - testowałem też mniejsze wymiary, ale te były idealne na moje potrzeby (mniejsze niż 24x24pix raczej nie mają sensu); uwaga odnośnie katalogów identyczna jak dla czcionek

A tak wygląda już po konfiguracji (na zdjęciu pierwszy layout - czyli 1 strona, na drugiej mam zegar z datą, czyli nic ciekawego), 3 pierwsze wskazania to lokalne czujniki (opisałem je wcześniej), a czwarte to poziom pyłu PM1 odczytywany z najbliższej miejscu ostatecznej instalacji stacji badania jakości powietrza Airly ("państwowej" tj. sponsorowanej przez gminę).
   

No OK wyświetlanie czasu jednak też jest ciekawe
https://esphome.io/components/time.html#strftime
ja sobie podbieram czas z HA
https://esphome.io/components/time.html#...ime-source
ale można też choćby z… modułu GPS, albo z internetu przez powszechnie stosowany SNTP

---

Tak przy okazji - pod poniższym linkiem jest sporo przykładów gotowych projektów, na których można się oprzeć budując prosty samodzielny projekt (można oprzeć się na samym ESPHome bez Home Asistant'a, bo ESPHome może też pracować stand alone, ale dużo ciekawiej jednak mieć to spięte z HA)
https://esphome.io/cookbook/
i podgląd z ikonkami:
https://esphome.io/index.html#cookbook

Przy czym dość ciekawym projektem z tam przedstawionych może być też port expander
https://esphome.io/cookbook/arduino_port_extender.html
(choć wymaga użycia standardowego IDE dla Arduino, by zaprogramować płytkę, bo spod ESPHome się nie da tego zrobić co jest chyba zrozumiałe)
Oczywiście to dodatkowa komplikacja w konfiguracji, ale może być warta zachodu jeśli pragniemy użyć większej ilości sprzętu podpiętego do pojedynczego modułu ESP.
A wspomniałem o nim, bo po podłączeniu do ESP8266 2 czujników (DHT używa 1 GPIO, a ultradźwięki 2GPIO) i wyświetlacza (6 GPIO ale da się zredukować do 4) osiągnąłem już niemal kraniec możliwości ESP8266 (który ma w tym wykonaniu jakiego używam ma dostępne 9 GPIO (z czego 1 ma opcję wejścia analogowego, a 3 to są naprawdę GPO bo mogą być tylko wyjściami - akurat OK dla wyświetlacza, więc właściwie mamy tylko 5 wejść cyfrowych lub 6 jeśli nie użyjemy analog-in).

Edit: okazuje się, że tańszym i wygodniejszym rozwiązaniem może być… użycie po prostu ESP32, albo gotowych ekstenderów SX1509, PCF8574 lub PCF8575, choć nie wiem czy w takim wypadku realnie będzie taniej (jakkolwiek jeszcze krzyżyka nie stawiam na pomyśle użycia ekstendera, bo jakieś płytki na układach Atmela mi zalegają szufladę po upadłym projekcie, niestety to wersje 5V, ale podobno niektóre działają poza specyfikacja i na 3,3V)

[szopen]

A teraz z coś innej beczki - kupiłem od chińczyka kilka modułów ESP8266 o nieznanej specyfikacji, konkretniej ESP-01(S?) oparty o konstrukcję referencyjną zaprojektowaną pierwotnie bodajże przez producenta chipsetu, czyli Espressif Systems, a produkowaną przez producentów posiadających nazwy oraz jako zupełne noname, więcej tam:
http://forum.jdtech.pl/Watek-jak-rozpozn...low-esp-01

Czemu o tym piszę? bo to bardzo popularny i równocześnie taniutki moduł, a ESPHome (doskonały plugin dla HA) zawiera preset dla ESP-01, ale w wersji 512kB flash (a nie miałem jakoś zdrowia do sprawdzenia co zawierają wszystkie inne gotowe presety)
   
gdzie nagłówek kodu wygląda jakoś tak:

Kod:

esphome:
  name: nasza_nazwa_modulu
  platform: ESP8266
  board: esp01

wystarczy zmienić go na taki dla modułu z 1MB flasha

Kod:

esphome:
  name: nasza_nazwa_modulu
  platform: ESP8266
  board: esp01_1m

i już możemy kompilować bardziej skomplikowane projekty, które nie zmieściłyby się w 512kB w szczególności to może być istotne w kwestii dostępności OTA (oczywiście sprzęt MUSI mieć zamontowany flash tej wielkości!).

Na dobry początek polecam pomiar napięcia zasilania (opisany gdzieś wyżej) oraz wskaźnik siły sygnału WiFi
https://esphome.io/components/sensor/wifi_signal.html
warto wiedzieć czy dany moduł nie jest na granicy zasięgu, szczególnie że antena w postaci ścieżki na płytce nie ma świetnych parametrów (pod tym względem wygrywają moduły wyposażone w gniazdo U.FL mające możliwośc podłączenia anteny zewnętrznej, choć wiele z nich, a właściwie wszystkie wyposażone w zintegrowaną antenę, wymaga przelutowania zwory SMT).

Inny przydatny podczas uruchamiania sensor "wbudowany" to uptime, czyli czas nieprzerwanej pracy modułu
https://esphome.io/components/sensor/uptime.html

---

a na bis ciekawostka (choć "siedzący w temacie" pewnie wiedzą o tym od dawna, ale parę razy już zapomniałem o tym wspomnieć )- Home Assistant w pierwszej dziesiątce szybko rosnących otwartoźródłowych projektów na githubie
https://octoverse.github.com/#top-and-trending-projects

i jest to jedyny tak duży projekt bez wsparcia ogromnych korporacji
https://www.home-assistant.io/blog/#were...-the-world

Jakkolwiek tematy związane z HA mają własny wątek:
http://forum.jdtech.pl/Watek-home-assist...egracji-id

[szopen]

No i stało się - zjarałem moduł NodeMCU v2… i to dzięki temu, że parę dni temu przyszedł mi ESP32-CAM prosto z ChRL ;P i zacząłem eksperymenty (zamarzyła mi się równoczesna praca jako zdalna bramka BT i równocześnie kamerka, bo moduł ma 4MB PSRAM, a szkoda, by się marnowało, ale jak dotąd takie kombo mi się nie udało…).
Więc taka przestroga dla innych - o ile fajnie jest sobie podebrać zasilanie z innego modułu, to tym razem przesadziłem - stabilizator 3,3V w NodeMcu wytrzymał zasilanie łącznie 4 modułów ESP8266, ale po podpięciu do tego kramiku jeszcze ESP-CAM poszedł z dymem, ale nie wykluczam zwarcia… (na breadboard miałem już naprawdę gęsto, ale przeciążenie jest bardziej prawdopodobne, bo nieco wcześniej niż poszedł dym straciłem wskazania z DHT11).

Aby było weselej moduł ESP-CAM nie raczy pracować przy zasilaniu 3,3V i ostatecznie pozostaje zasilanie 5V
(moduł kupiony jako "Geekcreit ESP32-CAM"
https://www.banggood.com/Geekcreit-ESP32...94679.html
w rzeczywistości jest to najprawdopodobniej moduł "AI Thinker ESP32-CAM"
https://docs.platformio.org/en/latest/bo...32cam.html )
ale przez ten dym na biurku odechciało mi się dalszej walki, chyba po prostu dokupię najprostszy moduł ESP32 i z niego będzie bramka + czujniki, a ESP32-CAM pozostanie jako dodatkowa kamerka nie robiąca jednak szału poza ceną… (a mam akurat jedną atrapę, to można wrzucić do środka o ile sprzęt nie będzie się np. przegrzewał przy ciągłej pracy, bo ten cały kramik podlegał testom stabilności przed wrzuceniem na stałe do obudów…).

[szopen]

No cóż - w międzyczasie dotarł do mnie moduł ESP32 (taki całkiem "zwykły" bez PSRAM jak moduły z kamerką), uruchomiłem "minibramkę BLE" i działa (przy okazji "na pokładzie" jest niezbyt dokładny czujnik Hall'a, jeszcze nie mam pomysłu na wykorzystanie, choć coś mi świta inna ciekawostka to możliwość budowy klawiatury dotykowej - tego wciąż nie testowałem, ale może odgraniczę "sprzęt użytkowy" od zabawek do testów by się nie skończyło na kolejnym uwalonym module, co zatrzymało mnie w martwym punkcie w momencie gdy mam sporo wolnego…).

Na obrazku integracja z zegarem Xiaomi BLE z czujnikami temperatury i wilgotności
oraz wskazania dostępne z użytego modułu (ESP32 to konkretnie u mnie moduł "TTGO T7 mini" - jest on prawdopodobnie klonem modułu Wemos D1 mini, przynajmniej pod względem układu wyprowadzeń, ale o tym nie wiedziałem i skorzystałem z ogólnego szablonu dla ESP32, swoją drogą jest nieco inny - ma przyłącze akumulatora i dodatkowy przełącznik, krótki czas pracy od uruchomienia na obrazku wynika z zasilania z PB - akurat się rozładował nieco wcześniej i podmieniłem na inny, ale moduł planuję wbudować do urządzenia i tak posiadającego już stałe zasilanie)
   

Czekam też na nowe moduły ESP8266 (by przywrócić do życia niemal gotowy projekt… do którego NodeMCU v2 jest w zupełności wystarczający), zamówiłem też konwertery poziomów 3,3V<->5V by nie katować sprzętu jeśli nie ma takiej potrzeby (automatykę domową to raczej należałoby przygotowywać na lata bezawaryjnej pracy), oraz na parę innych gadżetów np. diody WS2812B - trafiłem przypadkiem na bardzo fajny projekt DIY bazujący na nich
https://forbot.pl/forum/topic/16878-lamp...01s-sloik/
widzę tam jeszcze możliwość podpięcia np. lokalnego przycisku sterującego (a gdyby użyć ESP32 to możliwości jeszcze rosną choć mam w planie użyć do tego możliwie najprostszą konstrukcję, czyli ESP-01(s?) które kosztują w ChRL bez żadnej łaski koło 4zł/szt. w PL jest niestety ~3-4x drożej, ale nawet na amazonii można znaleźć wielopaki w których te moduły nie są droższe niż 6zł/szt.)

choć jako soft wykorzystam pewnie WLED
https://github.com/Aircoookie/WLED
który się integruje z HA
https://www.home-assistant.io/integrations/wled/

ewentualnie natywną obsługę w ESPHome (czyli poniekąd integracja z HA na dzień dobry), a do wyboru 2 biblioteki
fastled
https://esphome.io/components/light/fastled.html
i neopixel
https://esphome.io/components/light/neopixelbus.html

[szopen]

Jak mówiłem, tak zrobiłem, wprawdzie "poleciałem łatwizną", tj. użyłem ESPHome, WLED zostawiam sobie na późniejsze eksperymenty (na wypadek sytuacji, gdyby konstrukcja miała być używana bez HA większa elastyczność konfiguracji jest wskazana - np. gdyby konstrukcja była na prezent dla kogoś, to nie można wymagać "inteligentengo domu" do sterowania lampką).
edit: WLED też pociągnąłem "metodą na lenia", temat jednak jest wystarczająco odrębny od HA (może bezproblemowo stanowić samodzielne rozwiązanie), więc poświęciłem mu osobny wątek:
http://forum.jdtech.pl/Watek-wled-dla-le...oddzielnie

Ponieważ trafiłem na problem z wykorzystaniem zalecanego wszędzie GPIO02, przypuszczalnie był to problem związany z obciążeniem go poziomem podciągniętym do masy (przez wejście pierwszego układu WS2812B) w trakcie bootowania, więc użyłem dostępnego w ESP-01 portu GPIO03 (normalnie to jest bodajże RXD0 portu szeregowego, nie ma to kluczowego znaczenia, jak się okazuje - gdy zajrzymy w dokumentację biblioteki Neopixelbus, która używa tego portu w metodzie z wykorzystaniem DMA… gdzie nie ma możliwości wyboru portu wyjściowego lecz jest na sztywno użyty GPIO03 ), wciąż to prowizorka, bo tymczasowo użyłem zasilania przekraczającego 4V (a ESP-01 z układem Puya nie powinien być zasilany napięciem powyżej 3,6V, więc tak nie będzie w ostatecznym wykonaniu) - czekam na resztę sprzętu, jak dotąd dotarł tylko pasek z adresowalnymi LEDami, a moduły ESP-01 wykorzystałem te wspomniane wcześniej (z trójpaku).

Pełna konfiguracja dla biblioteki FastLED wygląda u mnie tak (hasła i SSID mojej sieci są w osobnym pliku secret.yaml, stąd takie odwołania w konfiguracji), oczywiście to wersja robocza z wrzuconymi przykładowymi efektami (na potrzeby projektu nastrojowych lampek są raczej zbędne, choć można dopracować parametry, by nie były "męczącą wioską"):

Kod:

esphome:
  name: azdel826603
  platform: ESP8266
  board: esp01_1m

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

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

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

light:
  - platform: fastled_clockless
    chipset: WS2812B
    pin: GPIO03
    num_leds: 30
    rgb_order: GRB
    name: "FastLED WS2812B Light"
    default_transition_length: 0.5s
    color_correct: [100%, 100%, 100%]
    effects:
      - addressable_rainbow:
          name: Tęcza
      - addressable_rainbow:
          name: Tęcza z wartościami użytkownika
          speed: 10
          width: 15
      - addressable_color_wipe:
          name: Efekt kolorowa roletka
      - addressable_color_wipe:
          name: Efekt roletka biały
          colors:
            - red: 100%
              green: 100%
              blue: 100%
              num_leds: 3
            - red: 0%
              green: 0%
              blue: 0%
              num_leds: 5
          add_led_interval: 300ms
          reverse: False
      - addressable_color_wipe:
          name: Efekt kolorowa roletka na choinkę
          colors:
            - red: 100%
              green: 0%
              blue: 0%
              num_leds: 5
            - red: 0%
              green: 100%
              blue: 0%
              num_leds: 5
          add_led_interval: 100ms
          reverse: False
      - addressable_scan:
          name: Efekt skanowania
      - addressable_scan:
          name: Efekt skanowania 1 LED  z wartościami użytkownika
          move_interval: 100ms
          scan_width: 1
      - addressable_scan:
          name: Efekt skanowania 3 LED  z wartościami użytkownika
          move_interval: 100ms
          scan_width: 3
      - addressable_twinkle:
          name: Efekt rozbłyski
      - addressable_twinkle:
          name: Efekt rozbłyski z wartościami użytkownika
          twinkle_probability: 5%
          progress_interval: 4ms
      - addressable_random_twinkle:
          name: Efekt losowe rozbłyski
      - addressable_random_twinkle:
          name: Efekt losowe rozbłyski z wartościami użytkownika
          twinkle_probability: 5%
          progress_interval: 32ms
      - addressable_fireworks:
          name: Efekt fajerwerków
      - addressable_fireworks:
          name: Efekt fajerwerków z wartościami użytkownika
          update_interval: 32ms
          spark_probability: 10%
          use_random_color: false
          fade_out_rate: 120
      - addressable_flicker:
          name: Efekt migotania
      - addressable_flicker:
          name: Efekt migotania  z wartościami użytkownika
          update_interval: 32ms
          intensity: 35%

sensor:
  - platform: adc
    pin: VCC
    name: "Napięcie VCC 3"
  - platform: wifi_signal
    name: "Siła sygnału WiFi 3"
    update_interval: 60s
  - platform: uptime
    name: Uptime ESP01-3

dla biblioteki Neopixelbus (przewidując potencjalny problem z bootowaniem gdy użyję pinu GPIO02) użyłem od razu metody DMA (dla ESP8266 używającej GPIO03), poniżej tylko fragment definiujący użycie biblioteki Neopixelbus, cała reszta może być identyczna z poprzednim przykładem (i u mnie jest identyczna choć to oddzielne "urządzenie" - sflaszowałem 2 oddzielne moduły by móc porównać pracę z wykorzystaniem obu bibliotek, więc oczywiście poniżej pomijam fragmenty konfiguracji, które muszą się różnić - choćby nazwa modułu, powyżej i tak jest mocno robocza)

Kod:

light:
  - platform: neopixelbus
    variant: WS2812
    method: ESP8266_DMA
    num_leds: 30
    type: GRB
    name: "NeoPixel WS2812B Light"
    default_transition_length: 0.5s
    color_correct: [100%, 100%, 100%]

Różnic w działaniu nie widać, a skoro nie widać…
no ale jest jeszcze kwestia optymalizacji kodu - podobno neopixel pod tym względem lepiej wypada (ale to dane sprzed kilku lat, a w tym czasie obie biblioteki ewoluowały, jakkolwiek na pewno jest pisany metodą "bliżej sprzętu" w sensie MCU) może to mieć znaczenie dla bardziej rozbudowanych konstrukcji (gdzie będzie istotna ilość miejsca zajmowanego we flashu czy wykorzystanie RAMu).

Co do efektów świecenia, to niestety nie jestem zadowolony (jako światło efektowe jest całkiem OK), ale kolor "fabrycznie biały" jest raczej nie do zaakceptowania (spodziewałem się tego po diodach RGB, więc w bardziej użytkowym projekcie należałoby zastosować jeszcze dodatkowo diody/paski ciepło-białe) wprawdzie udało mi się uzyskać coś zbliżonego do 2700K przy ustawieniu jak z obrazka
   
ale to dość daleko od środka koła (gdzie jest domyślna biel), natomiast ograniczenie jasności wybranych kanałów niestety dość mocno psuje światło efektowe (choć można zredukować ilość niebieskiego i troszeczkę zielonego, ale dobranie sensownych wartości wymaga dość długich eksperymentów).

Można teoretycznie zastosować układy wyposażone w 4 LEDy (RGBW), np. niektóre konstrukcje na SK6812 ale nie wnikałem aż tak głęboko, bo projekt z założenia miał być tani, a i tak z tego co wiem zwykle stosowane są zimno-białe LEDy, a konstrukcji RGBTW tego typu jeszcze nie widziałem.

Przykładowe zdjęcia taśmy LED podczas wyświetlania niektórych efektów (specjalnie na ciemnym niemal czarnym tle, by zdjęcia nie miały "wypranych kolorów") po lewej efekt "bożonarodzeniowy", a po prawej fragment "tęczy" (ta fotka akurat miała prezentować przykład lutowania 2 odcinków taśmy, co jest widoczne między 3 a 4 "diodą" od lewej - tam gdzie jest ostro, więc się nie skupiałem na widoczności efektu świetlnego), oczywiście oba efekty są ruchome.
       

[jerzs]

Chciałem CI podziękować za Twój zapał bo to tylko właśnie dzięki niemu zająłem sie home assistatntem - kupiłem malinę 4 jakiś jeden czujnik z xiaomi i to działa - przeogromny potencjał! Ponad to również przez Twój entuzjazm kupiłem swój pierwszy ESP32 - WROOM ale okazało sie że nie wiem jak go zaprogramować w ESPHOME bo po drodze to chyba trzeba go zaprogramować w różne bootloaderi itp. Posiedziałem nad tym z parę godzin i widzę że wszyscy w necie już to wiedza i skupiają sie jedynie na samym programowaniu yaml ESPHome Czy mógłbyś opisać jakiegoś tutka jak dla zwykłego Kowalskiego jak przejść przez wszystkie etapy flashowania ?? Tego wydaje mi sie naprawdę nigdzie nie ma....

Pozdrawiam - świetna robota!

[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)

[jerzs]

OMG!!!!!!!! Jesteś prawdziwym geniuszem! będe musiał sobie to wydrukować i powiesić na ścianie :-)
Tak na szybko bo drobiazgowe czytanie i dłubanie w sprzęcie to dopiero niestety po południu - płytka to ESP-WROOM-32, a po rewersie napisane jest ESP 32 DEVKIT V1, ale następne Wemosy i 8266 juz płyną do mnie zza wielkiej wody :-)

///mod: zedytowałem atrybuty, większą czcionkę zostawmy sobie na to co jest naprawdę ważne

[jerzs]

mój moduł to ESP-WROOM-32 DEVKIT V1
Tak na poważnie to czytam czytam juz dokładniej Twój opis i jestem całkiem zdziwiony bo nigdzie do tej pory nie czytałem o tym żeby flashować ESP z poziomu maliny, a dokładniej to HA! w sumie to pominąwszy zużywanie wspomnianej karty to kapitalny pomysł!!
Nie myślałeś o tym żeby wogóle przejsć na inny napęd np jakis mały dysk SSD? takie 64GB są w śmiesznych cenach a zajechać je już nie jest tak szybko jak microSD...

[szopen]

jerzs napisał(a):płytka to ESP-WROOM-32

Naprawdę?
moduł ESP-WROOM-32 wygląda tak (zdjęcie zapożyczone z ali):
   

o czym pisałem wyżej jest on bazą do budowy wielu modeli gotowych modułów
swoją drogą dobra podstawowa dokumentacja dla wszystkich modułów na nim bazujących:
https://randomnerdtutorials.com/getting-...ith-esp32/

więc sytuację ratuje to

jerzs napisał(a):po rewersie napisane jest ESP 32 DEVKIT V1

czyli stawiam na to (wygodniej oglądać wyniki wyszukiwania w grafice):
https://www.google.com/search?q=esp32+dev+kit
https://www.google.com/search?q=esp32+dev+kit&tbm=isch
ewentualnie (choć raczej odrzucam taką możliwość)
https://www.google.com/search?q=ESP32-DevKitC
https://www.google.com/search?q=ESP32-DevKitC&tbm=isch

https://startingelectronics.org/articles...M-testing/

czyli zgaduję, że jako gotowiec powinieneś wybrać "Espressif ESP32 DeV Module", ewentualnie jakiś inny który bardziej pasuje? (może to po prostu "DOIT ESP 32 DEVKIT V1" ???)

jerzs napisał(a):nigdzie do tej pory nie czytałem o tym żeby flashować ESP z poziomu maliny

no cóż taka jest podstawowa idea ESPHome, by zainstalować go jako plugin do HA
(można wprawdzie oddzielnie, ale integracja z HA jest bardzo wygodna)
a kompilację i "pierwsze flashowanie" robimy z tego komputera na którym mamy zainstalowane ESPHome
dlatego z góry założyłem, że jest to właśnie ta malina na której masz HA i ESPHome w postaci plugina

---

jerzs napisał(a):Nie myślałeś o tym żeby wogóle przejsć na inny napęd np jakis mały dysk SSD? takie 64GB są w śmiesznych cenach

Myślałem
Ale, myślałem też o innych rozwiązaniach - docelowo planuję migrację HA z maliny na intel NUC bo likwiduje to m.in. problem "pajęczarstwa" czy kiepskiej jakości wentylatorów i mam nadzieję, że umożliwi instalację wszystkiego bezpośrednio na ssd lub od biedy hdd, o ile to nie zabije wydajności
(ale eksperymentalnie mam też HA od paru dni na Odroidzie MC1 solo, i też fajne rozwiązanie, swoją drogą tam testuję rozwiązanie z oddzielnym nośnikiem na system - karta TF i oddzielnym roboczym - prowizorycznie jest to pendrive, ale docelowo może być właśnie jakiś niedrogi ssd, a równie dobrze można do tego celu użyć HC1 lub HC2 które stanowią równocześnie obudowę hdd/ssd)

[jerzs]

mój ESP to ten z załącznika, na razie jeszcze nie wiem czy jest dobry czy taki sobie :-) Przez krótką chwile myślałem o takim intelu o którym piszesz ale mi przeszło ze względu na jego pobór pradu - 65W i to w sytuacji kiedy moja malina 4B ma podobnie taktowany procesor . W tech chwili kręci sie na niej hassio, unifi i kodi które przez 24h streamuje piosenki z showcasta. Utylizacja pamięci i procesora oscyluje między 5 a 10%. Nawet jej nie wentyluję wiatrakiem bo nie dobijam do temperatury 50 stopni. Ale jeszcze zobaczymy co będzie potem kiedy dopakuję do hassio te dziesiątki ESP które mam zamiar zbudować :-) Pajęczarstwa też NIESTETY nie zlikwiduję bo zigbee i tak jest na USB.
Ale dysk ssd zastosuję obowiązkowo ze względów bezpieczeństwa i komfortu - https://www.tomshardware.com/news/raspbe...39811.html

No a skoro nie mam jeszcze dysku i kompilacje mogą zamordować moja kartę SD to rozglądnę się za flashowaniem wprost z PC

[szopen]

jerzs napisał(a):mój ESP to ten z załącznika, na razie jeszcze nie wiem czy jest dobry czy taki sobie :-)

to jest "DOIT ESP 32 DEVKIT V1", czyli zgadłem (albo jego klon, wersja 30-pinowa, czyli ma jedno GPIO mniej niż 36-pinowa) ten mały kwadratowy czarny scalak to właśnie UART na USB (nie widać nadruku na nim, ale pewnie CP2102), więc zasilanie i pierwsze programowanie masz mocno ułatwione (ma tez przyciski)
niestety nie mam podobnego modułu, więc musisz się opierać na dokumentacji
https://docs.platformio.org/en/latest/bo...-devkit-v1
(poniżej dodatkowo od innego projektu wykorzystującego taki moduł, ale też zawiera niektóre najistotniejsze kwestie)
https://docs.zerynth.com/latest/official...index.html
prawdopodobnie przycisk EN to jest Reset, a BOOT to Flash (do przytrzymania podczas resetu, oczywiście tylko w sytuacji flashowania przez USB/UART).

Ponieważ to SoC ESP32 to już mówię, że jest dobry (w ESP8266 trafiałem już na ograniczenia sprzętowe przy bardziej rozbudowanej zabawie)
z drugiej strony wszystkie niemal wszystkie moduły na ESP32 "to to samo" (różnią się głównie podłączonymi peryferiami, co oczywiście może rzutować na zastosowania, ale ogólne zasady są te same).

---

jerzs napisał(a):Przez krótką chwile myślałem o takim intelu o którym piszesz ale mi przeszło ze względu na jego pobór pradu - 65W i to w sytuacji kiedy moja malina 4B ma podobnie taktowany procesor

No cóż 2 popularne błędy w 1 zdaniu:
- moc znamionowa zasilacza to nie pobór mocy (tzn. dla zasilaczy to jest pobór mocy przy maksymalnym obciążeniu, ale przeciętny NUC zżera jakieś 10W, jeśli się dorobię to obiecuję, że zmierzę realny pobór mocy, prawdę mówiąc miałem na myśli nie jakiegoś króla wydajności tylko raczej energooszczędny NUC6CAYH mający na pokładzie 4-rdzeniowego 64-bitowego celeronka o TDP 10W), swoją drogą wspomniane 65W to jest zdaje się maksymalna obciążalność (a rzeczywisty pobór mocy to odwrotność sprawności pomnożona przez obciążenie na wyjściu, więc w ekstremalnym wypadku może przekroczyć te 65W tylko nie wiem co miałbym do niego podpiąć, aby tyle uzyskać, nawet chyba nie bardzo się da, bo ma za mało portów USB3, właściwie to chyba kwestia zasilacza jest taka - do każdego modelu jest taki sam zasilacz, więc również do tych które mają mocniejsze CPU)
- porównanie zegara procesora przy odmiennych architekturach (nie twierdzę, że akurat celeronek to jest król wydajności )

update1: Nie sądziłem, że sprawy się tak szybko potoczą - dorobiłem się NUCa (a nawet dwu, bo podejrzewałem że kupiony na wyprzedaży jest niesprawny i z zamiarem zwrotu zamówiłem kolejnego "nówkę", a tymczasem prawdopodobnie włożyłem do niego niekompatybilny RAM ewentualnie przyczyną było stare firmware, bo się dziwnie zachowywał - na żadnym tv ani monitorze jakie mam w domu nie uzyskałem obrazu, a mam niestety same starocie, pomogła wizyta w robocie, a tak mi świta że intel w niektórych modelach "dał do pieca" wypuszczając je z wadliwym firmware HDMI na rynek co się objawiało brakiem obrazu w niektórych konfiguracjach, więc mogła to być kumulacja jakkolwiek problem już nie występuje, ten z wyprzedaży miał jednak pewną wkurzającą wadę - zerowy zasięg WiFi, przyczyną tego był odpięty kabel antenowy od karty WiFi - a na pokładzie jest karta 1T1R, czyli takie "biedne AC" Intel Dual Band Wireless-AC 3168), więc plany na niedaleką przyszłość to chyba migracja z RPi
Jak obiecałem tak zrobiłem - po włożeniu ssd i 4GB RAMu w jednej kości oraz tymczasowej instalacji windowsa (był potrzebny, aby szybko i na luzie ogarnąć oficjalne aktualizacje firmware) zrobiłem też szybkie testy poboru mocy - nieco niedoszacowałem strzelając w 10W, ale wiele się nie pomyliłem - w trybie wysokiej wydajności zużywa od 7,5W do maksymalnie 15W (zależnie od tego jakie podzespoły były "żyłowane"), nie sprawdziłem jedynie jak się zachowuje jako headless.

Update2: Konfiguracja mniej więcej docelowa, czyli taka do pracy jako HA:
- ssd: Crucial MX500 120GB (to idealny przykład niskobudżetowca, nie wiem czemu ludzie się nim tak jarają);
- RAM: 4GB PC3L-12800 (czyli DDR3 1600MHz w tym budżetowym modelu NUCa można zaszaleć na oczko szybsze);
- konfiguracja headless: czyli odpięty monitor, klawiatura i mysz oraz BIOS skonfigurowany do startu po pojawieniu się zasilania (jeszcze mam w planie delikatne poprawki w konfiguracji - można np. zgasić podświetlenie LED przedniego panelu - i tak nie będzie przecież w uśpieniu);
- udawanie środowiska typowego dla HA: podpięty dongle Z-wave.
Pobierana moc podczas typowej pracy między 6W, a 7W, właściwie to oscyluje wokół 6,5W (przecinek jest na swoim miejscu - to jest 10% możliwości zasilacza); w trakcie kompilacji w ESPHome 10W (najwyższy chwilowy wynik to było 12W).
Można jeszcze ewentualnie wywalić kartę WiFi intel AC-3168 (jest na slot M.2 key E rozmiar 2230) nie wiem czy się coś zaoszczędzi na poborze mocy, ale jest np. cień szansy by przy użyciu przejściówki M.2 key E-> NVMe wsadzić tam ssd (jakkolwiek gwarancji na to, że zadziała nie ma), ewentualnie można ją wymienić na jakąś bardziej wypasioną w razie konieczności (np. Intel AC-9560).
Cudo umożliwiające wpięcie ssd w slot M.2 przeznaczony dla karty sieciowej (nie testowałem czy to działa, w każdym razie nie musi w każdej konfiguracji, o czym co uczciwsi sprzedający uprzedzają…)
https://web.archive.org/web/202002180148...52172.html
Pewnie bym się nad tym zastanowił gdyby sprzęt miał stanowić też rejestrator dla kamer (wtedy bym wrzucił hdd sata i kombinował czy się nie da systemu mieć na nvme).

Update3: przyciemniając iluminację LED zszedłem poniżej 6W (przycisk power 20% jasności blue, obwódka jako kontrolka działania hdd z przedziałem 0-50%, ostatecznie pewnie zgaszę ją całkowicie). Pełny start systemu zajmuje koło 40sekund (jest to klon konfiguracji z RPi3B+ gdzie start zajmował 140s.).


Jest jeszcze jedna kwestia - do RPi ostatnio się dość mocno zraziłem - po… wielu wydaniach firmware z błędami przynajmniej dla RPi3B/3B+ oraz nieznanym terminie wprowadzania bootowania USB dla RPi4.
Osprzęt dostępny dla RPi też nie jest najwyższych lotów - do "trójek z plusem" kupiłem jedne z najdroższych radiatoro-obudów, a mimo to wentylatory nie dotrwały roku bezawaryjnej pracy, czwórka ma mechaniczne zmiany konstrukcyjne uniemożliwiające użycie wielu akcesoriów od trójki (tak swoją drogą to nie nowość, bo każda kolejna generacja wprowadzała jakieś zmiany, ale z użyciem dremela, pilnika czy wiertarki można zwykle było je sobie przerobić, a teraz już zmiany są takie, że nie sposób), a w przypadku NUCa wiem że dostanę jakiś przyzwoity zasilacz (bodajże FSP) a wentylator się nie zatrze po roku.

jerzs napisał(a):Utylizacja pamięci i procesora oscyluje między 5 a 10%. Nawet jej nie wentyluję wiatrakiem bo nie dobijam do temperatury 50 stopni.

No to jest jakiś plus - moje pierwsze testy z RPi4 to była praca całkowicie bez radiatora (muszę czwórkę w końcu poskładać do kupy, bo mam już i obudowę i radiator, przypadkowo kupiłem konstrukcyjnie całkiem inny niż dla trójki, ale może to i dobrze? zobaczę za jakiś bliżej nieokreślony czas, bo na razie czwórka zalega odłogiem)
Ba, ewentualne wykorzystanie USB3 na RPi4 też już testowałem (z braku laku na 2 dość szybkich pendrive'ach w RAID0, ale oczywiście nie w kontekście HA) i jest to sensowne, mimo wszystko NUC mnie kusi…

---

No i wracając do tematu ESPHome i HA

jerzs napisał(a):No a skoro nie mam jeszcze dysku i kompilacje mogą zamordować moja kartę SD to rozglądnę się za flashowaniem wprost z PC

Będziesz wtedy moim linuksowym guru (z tego co kojarzę pod windows ten temat jest jeszcze bardziej hardkorowy, jakkolwiek nie próbowałem ESPHome jako samodzielnej instalacji), powiem tak: dla mnie "można" nie jest synonimem "trzeba"

Aby dać jakiś obraz sytuacji: mam 3 instalacje HA (każda w postaci gotowego obrazu hassio; 2x RPi3B+ i 1x Odroid MC1 solo) i w każdej ESPHome jako addon.

Karta w RPi (czy innym SBC działającym podobnie) i tak prędzej czy później skończy żywot, więc trzeba być na to przygotowanym (regularne backupy), a brak kompilacji i tak się na wiele nie zda jeśli masz w planach mnóstwo modułów produkujących masę danych, które się i tak znajdą w bazie danych (i w ten prosty sposób zużyją kartę, oczywiście można limitować ilość wpisów generowanych przez recorder, ale raczej nie po to przygotowuje się czujniki by z nich nie korzystać w jakiś bardziej zaawansowany sposób).

Z różnych przyczyn miałem już okazje korzystać z pełnego backupu i jest to upierdliwe, ale do przyjęcia (po przywróceniu backupu na świeżej instalacji HA trzeba jeszcze zreinstalować przynajmniej niektóre pluginy, a w przypadku awarii karty restore z backupu to w zasadzie jedyna sensowna droga), można ewentualnie zapobiegawczo klonować kartę raz na jakiś czas (pół roku, albo przynajmniej gdy zauważymy niepokojące zachowanie - timeouty mogą być takim "dzwonkiem alarmowym", że coś się zaczyna dziać złego) na nową. Droga jest zasadniczo jednokierunkowa - z mniejszej karty na większą lub identyczną, przy czym na "identycznych" można się przejechać - rozmiar tego samego modelu karty może się nieznacznie różnić, a klonowanie z większej na mniejszą zwykle się nie udaje, a wtedy zostaje jedynie świeża instalacja + restore backupu - tu taki hint: mając kilka kart w zapasie warto sprawdzić ich pojemności i ustalić sobie na przyszłość kolejność ich użycia - od najmniejszej do największej (i schować je do "nienaruszalnego zapasu").

Tu przy okazji takie spostrzeżenie - udało mi się zainstalować HA na karcie 4GB (wydanie na HassOS 3.9 dla Odroida XU4, a używam go na okrojonym do granic możliwości MC1 solo ), ale zdecydowanie odradzam taki rozmiar, minimalny rozmiar karty do pracy to jakieś 8GB (jakkolwiek używam realnie 32GB lub 64GB, jedynie Odroida odpalałem na jak najmniejszej, bo z przyjętych założeń tam docelowo partycja robocza ma być właśnie na malutkim ssd)

---

jerzs napisał(a):Pajęczarstwa też NIESTETY nie zlikwiduję bo zigbee i tak jest na USB.

A to ostatnie, to mnie intryguje napiszesz coś więcej?
(chętnie z linkami do dokumentacji), wprawdzie używam Zigbee ZLL, ale jedynie jako integracji z mostkiem Hue (nie używam DIY w tym wypadku, ale to chyba interesujący temat, jeśli masz rozpracowany).

[jerzs]

za swojej strony skompilowałem właśnie na mojej RPi4 podstawowy projekt i wychodzi tak:

Kod:

========================= [SUCCESS] Took 61.49 seconds =========================
INFO Successfully compiled program.

Czas nie jest jakoś przytłaczający. Mam pytanie czy udaje się komuś flashować ESP wprost z poziomu urządzenia? Pytam bo w moim ESPHome Dashboard widzi tylko OTA + USB z ZIGBEE..
   

[szopen]

jerzs napisał(a):Mam pytanie czy udaje się komuś flashować ESP wprost z poziomu urządzenia? Pytam bo w moim ESPHome Dashboard widzi tylko OTA + USB z ZIGBEE..

Musisz zatrzymać i wystartować (lub zrestartować) ESPHome po podpięciu płytki ESP (dostępne porty są sprawdzane tylko przy jego uruchamianiu).
Zdawało mi się, że o tym już pisałem, ale tu kłania się zasada "jeden temat = 1 wątek" przerzucam to do właściwszego wątku.

---

jerzs napisał(a):skompilowałem właśnie na mojej RPi4 podstawowy projekt i wychodzi tak:

Aby porównywać czasy, projekty muszą być z grubsza identyczne (mogę wrzucić cały mój kod testowy jeśli będę przy komputerze), ale z tego co widzę, to RPi4 wypada nieznacznie słabiej od wspomnianego wyżej celeronka, a ssd być może mógłby wyrównać czasy.

[jerzs]

(07-03-2020 20:41)szopen napisał(a):  Musisz zatrzymać i wystartować (lub zrestartować) ESPHome po podpięciu płytki ESP (dostępne porty są sprawdzane tylko przy jego uruchamianiu).
Zdawało mi się, że o tym już pisałem, ale tu kłania się zasada "jeden temat = 1 wątek" przerzucam to do właściwszego wątku.

Ja pierdziu - Jesteś prawdziwym geniuszem - zrestartowałem i pokazało sie USB z zapiętym na końcu ESP :-) Wielkie dzieki!
A nawet jest jeszcze lepiej - zrobiłem sobie chyba z miesiąc temu krótki pusty projekt pod MCU3 i kiedy wreszcie dostałem to ESP, podłączyłem do USB HA to HA sam mi go załadował do płytki i pokazał ze jest online :-))))))

[szopen]

Nie no bez przesady sam się nie skompiluje, ale ESPHome jest na tyle zintegrowane z HA, że przy użyciu pewnych ustawień mamy pełny plug&play (gdy urządzenie z firmware ESPHome pojawi się w sieci, to HA je wykryje).

to kluczowe ustawienie wewnątrz ESPHome to (wrzuciłem razem z "fabrycznym" komentarzem):

Kod:

# Enable Home Assistant API
api:

Jeśli przy pomocy ESPHome chcemy wykonać urządzanie "stand alone", czyli pracujące samodzielnie i bez kontaktu z HA, to ten właśnie fragmencik należy zakomentować (używając # albo po prostu wywalić z kodu), bo w przeciwnym razie będzie się restartowało (z braku komunikacji z HA).

PS nie jestem żadnym geniuszem - czytam po prostu dokumentację, czasem wiele razy zanim wszystko w głowie się ułoży

[szopen]

Trafiłem na interesujący projekt dzwonka z kamerą (nie jest to wideodomofon!) bazującego na ESPHome, HA i ESP32
https://github.com/marrobHD/ESP32Doorbell
jest on interesujący o tyle, że wykorzystuje wiele możliwości jakie daje taka kombinacja i jest to projekt w zasadzie "gotowy z pudełka", natomiast z użytkowego punktu widzenia zauważyłem tam kilka istotnych słabych punktów:
- jeden przycisk i 3 lokalizacje (już widzę potencjalną obcą osobę, która ma tego użyć ), tu użyłbym jednak 3 osobnych przycisków
- wykorzystany panel dotykowy (to generalnie słaby pomysł w przypadku sterowania dzwonkiem z powodu małej odporności na przypadkowe wyzwolenie), choć opcjonalnie można użyć normalny przycisk
- wyświetlacz OLED (mam na myśli niską trwałość, oraz wypalenie szczególnie przy wyświetlaniu statycznego obrazu, dlatego akurat pomysł na wyświetlanie tam pogody jako przerywnika nie jest zły, z drugiej strony w mieście coś rzucającego się w oczy jest bardziej narażone na wandalizm…)

Choć oczywiście rozumiem pewne ograniczenia wynikające z użycia modułu wyposażonego w kamerę (zajmuje ona bodajże 14 pinów GPIO dlatego moduły z wbudowaną kamerą mają bardzo ograniczoną ilość dostępnych GPIO) oraz nadmiarowość projektu w stadium eksperymentu

[szopen]

Co będzie w kolejnej wersji ESPHome można podejrzeć tam:
https://next.esphome.io/
jest to developerska wersja ESPHome, czyli to co po dodaniu repozytorium do "add-on store" w HA mamy jako "ESPHome (dev)"
normalnie z niej nie korzystam, bo jak sama nazwa wskazuje jest to wersja rozwojowa i niekoniecznie wszystko w niej działa jak należy, ale ostatnio szukałem dokumentacji do takiego prościutkiego wyświetlacza LED z układem TM1627.
Niestety jego producent zastosował nietypowe rozwiązanie w komunikacji, więc mimo że to stara konstrukcja, nie spodziewałem się obsługi, a tymczasem jest gotowiec i to nawet z przykładowym projektem wykorzystania go jako… zegara
https://next.esphome.io/components/display/tm1637.html

Na obrazku taki zegarek wykonany testowo bez lutowania (nie widać tego na zdjęciu, ale czerwień wyświetlacza jest typowa dla czerwonych LED, świecące segmenty sa prześwietlone, dlatego wydają się grubsze, w rzeczywistości czytelność jest nieco lepsza)
   
Intensywność świecenia można regulować od stopnia 0 (ledwo świeci) do 7, zapewne jest to realizowane przez zmianę współczynnika wypełnienia impulsów sterujących (z zasady takie wyświetlacze są sterowane z wyjść multipleksera i tu oczywiście sprzętowo tak się to odbywa), jak na mój gust w zupełności wystarcza poziom 2 przy zasilaniu 3,3V "podkradniętym" bezpośrednio z płytki nodemcu (ktoś gdzieś mierzył też zużycie prądu przez podobny wyświetlacz i jest to bodajże ~25mA 50mA przy wskazaniu 88:88 czyli zapalonych wszystkich segmentach i najwyższym stopniu świecenia jakkolwiek nie pamiętam czy dotyczyło to 5V, czy 3,3V).
edit: myliłem się - nie 25mA tylko koło 50mA, link:
http://uczymy.edu.pl/wp/blog/2016/05/14/...chomienia/
sam nie mierzyłem aż tak dokładnie, ale pseudo-przyrządem oszacowałem na <10mA (przy poziomie jasności 2 w skali 0-7), chociaż w sumie póki to nie polutowane mogę zmierzyć (ale nie będę do tego podchodził naukowo zapalając wszystkie segmenty).

Sterownik TM1637 umożliwia też odczytywanie stanu 16-klawiszowej klawiatury (ale w module, który widać powyżej nie przewidziano złącz, a biblioteka dostępna w tej chwili w ESPHome chyba nawet nie umożliwia odczytu stanu klawiszy - jest tylko biblioteką wyświetlacza).

PS zanim wersja stanie się stabilna jest jeszcze po drodze wersja beta
https://beta.esphome.io/
na dziś jest tam samo, co w obecnej stabilnej, ale gdy obecna developerska będzie prawie gotowa to i tam znajdziemy te nowości.

[szopen]

Jeszcze jeden link, który może się przydać przy wykorzystaniu modułów czy urządzeń bazujących na ESP, choć tu jest potrzebne duże wsparcie przytomnych użytkowników (bo projekt tej dokumentacji raczej jeszcze raczkuje):
https://esphome-configs.io/
powyższy projekt został zamknięty zamiast niego jest bardziej oficjalny projekt:
https://www.esphome-devices.com/

Przy okazji obecnie (koniec czerwca 2020) warto zajrzeć pod:
https://next.esphome.io/
bo pojawiła się m. in. dokumentacja nowych typów obsługiwanych wyświetlaczy:
- matrycowego (punktowego) na układzie MAX7219 - te moduły wyświetlaczy można łączyć szeregowo by zbudować coś większego
https://next.esphome.io/components/displ...digit.html
w silniku renderującym można użyć dowolną czcionkę, ale prawdopodobnie optymalna jest dedykowana do wyświetlaczy matrycowych czcionka pixelmix.ttf o rozmiarze 6pt., strona autora nie istnieje, więc można ją pobrać np. tam:
https://www.dafont.com/pixelmix.font
(można też używać wielokrotności np. 12pt. czy 36pt. ale do tego rodzaju wyświetlacza idealny jest rozmiar 6pt. a dla większych rozdzielczości można znaleźć coś innego https://www.fontsquirrel.com/fonts/list/...tion/pixel czy wykorzystać np. windowsowy terminal.ttf)
- ST7789V który jest np. montowany fabrycznie w chińskim module TTGO T-Display (jestem pod wrażeniem - to kolejny cel dla mnie po dokończeniu innych rozgrzebanych projektów, a ten szczególnie mnie cieszy, bo to kolorowy LCD, a nie szybko się wypalające OLEDy)
https://next.esphome.io/components/display/st7789v.html
- PCD8544 ("wyświetlacz od Nokii", chyba wspominałem już go kiedyś?)
https://next.esphome.io/components/display/pcd8544.html

a oprócz nich czujnik temperatury i wilgotności AHT10
https://next.esphome.io/components/sensor/aht10.html

magnetometr QMC5883L
https://next.esphome.io/components/sensor/qmc5883l.html

miernik prądu i mocy INA226
https://next.esphome.io/components/sensor/ina226.html

miernik pyłu zawieszonego HM3301
https://next.esphome.io/components/sensor/hm3301.html

i parę innych rzeczy (w tym np. termopary)

natomiast integracje Xiaomi BLE dorobiły się swojego ogólnego działu (zamiast opisów poszczególnych integracji - w nowej wersji będzie ich sporo więcej):
https://next.esphome.io/components/senso...i_ble.html

Przypomnę jeszcze, że wersja developerska jest dla tych, którzy "lubią stąpać po kruchym lodzie".

---

edit: No cóż, mimo rozgrzebanych innych projektów nie mogłem się powstrzymać - akurat TTGO T-display leżał już wcześniej w szufladzie - zamówiłem go dawno temu w ChRL przewidując, że może jednak kiedyś się przyda, niestety wyświetlanie grafiki nie działa jak dotąd poprawnie - problem z interpretacją kolorów mimo poprawnie przygotowanych plików z grafiką (czyli biblioteka do obsługi grafiki nie jest gotowa), reszta działa poprawnie (w tym kolorowe rysowanie i tekst oraz obsługa przycisków).
   
Podobnych modułów jest sporo więc przykładowy link do Ali (swój kupiłem za 4,5 $ w innym sklepie, ale tam teraz dużo gorsze ceny niż na ali, żałuję, że tylko jeden zamówiłem w tej cenie)
https://www.aliexpress.com/item/33048962331.html
Przy okazji trafiłem na dość ciekawy projekt (choć korzystający z custom component wewnątrz ESPHome, a nie z natywnej i jeszcze nie gotowej integracji w ESPHome)
https://github.com/anton-semeniak/Esphom...ay-Weather