ESPHome nie działa z wyświetlaczem

Cześć
Instaluje sobie przykładową konfiguracje do obsługi wyświetlacza z tej strony Time & Temperature on OLED Display — ESPHome i ESPHome przestaje wykrywać układ. Przez chwilę wyświetla mi się aktualna godzina a po jakimś czasie przestaje się synchronizować z HA
Poniżej moja konfiguracja
Załączam też filmik jak się zachowuje port podczas próby manualnego zainstalowania konfiguracji. Naciśnięcie przycisku FLASH powoduje że port USB się pojawia i można normalnie wgrać konfigurację.
Podstawowa konfiguracja jaką tworzy ESPHome w HA po wgraniu działa poprawnie, dopiero po dodaniu kodu współpracy z HA i wyświetlaczem dzieje się tak jak opisałem.

esphome:
  name: wyswietlacz
  friendly_name: wyswietlacz

esp8266:
  board: nodemcuv2

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  encryption:
    key: "4ZSjZ9TCA6ZcyuCjgluV9o4rC/vgMqacvzCeP7vv3eQ="

ota:
  password: "3ddc9661251e39c7058993a15ddaa248"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Wyswietlacz Fallback Hotspot"
    password: "mVnVnKFx0t8I"

captive_portal:

time:
  - platform: homeassistant
    id: esptime
sensor:
  - platform: homeassistant
    id: inside_temperature
    entity_id: sensor.mellanvaning_temperature
    internal: true

  - platform: homeassistant
    id: outside_temperature
    entity_id: sensor.10_00080192969d_temperature
    internal: true
font:
  - file: 'slkscr.ttf'
    id: font1
    size: 8

  - file: 'BebasNeue-Regular.ttf'
    id: font2
    size: 48

  - file: 'arial.ttf'
    id: font3
    size: 14
i2c:
  sda: D1
  scl: D2
  scan: false

display:
  - platform: ssd1306_i2c
    model: "SH1106 128x64"
    reset_pin: D0
    address: 0x3C
    lambda: |-
      // Print "Mitt Smarta Hus" in top center.
      it.printf(64, 0, id(font1), TextAlign::TOP_CENTER, "Mitt Smarta Hus");

      // Print time in HH:MM format
      it.strftime(0, 60, id(font2), TextAlign::BASELINE_LEFT, "%H:%M", id(esptime).now());

      // Print inside temperature (from homeassistant sensor)
      if (id(inside_temperature).has_state()) {
        it.printf(127, 23, id(font3), TextAlign::TOP_RIGHT , "%.1f°", id(inside_temperature).state);
      }

      // Print outside temperature (from homeassistant sensor)
      if (id(outside_temperature).has_state()) {
        it.printf(127, 60, id(font3), TextAlign::BASELINE_RIGHT , "%.1f°", id(outside_temperature).state);
      }

Kod ogólnie wydaje się poprawny (szczególnie jeśli przechodzi walidację i kompilację).

Piny D1 i D2 to aliasy pasujące do wybranych modeli płytek MCU.
Zdefiniowałeś płytkę jako

a jaką masz w rzeczywistości?

Drugie pytanie to o wyświetlacz - masz dokładnie ten model który jest w tutorialku?
Na kontrolerze SSD1306 i pokrewnych jest mnóstwo różnych wyświetlaczy i wymagają różnej konfiguracji, a pin resetu możesz póki co zakomentować (zwykle nie jest potrzebny dla wyświetlaczy I2C, stosujesz go tylko jeśli są problemy)

ponadto istnieją wersje z interfejsem SPI zamiast I2C (to może być np. konfigurowane zworką, czasem lutowaną w postaci pola na PCB)

Pliki czcionek oczywiście posiadasz i są dorzucone do katalogu zawierającego YAMLe urządzeń ESPHome?
(bez tego raczej kompilacja nie powinna przejść)

W kwestii “dobrej rady na przyszłość” sugeruję założenie w esphome podkatalogu fonts na czcionki i tam ich wkopiowanie (i tak samo np. images jeśli będziesz używał grafikę), bez tego utoniesz w bałaganie powstałym w katalogu esphome, przykładowe odwołanie do pliku w podkatalogu:

font:
  - file: 'fonts/slkscr.ttf'
    id: font1
    size: 8

Jeśli chodzi o flashowanie to czy wcisnąłeś i przytrzymałeś przycisk zwierający GPIO0 do masy przy podpinaniu zasilania (lub resetowaniu MCU)?
(zwykle oznaczony BOOT lub FLASH, on służy do wprowadzenia moduły w tryb flashowania, ale trzeba go wcisnąć i przytrzymać podczas resetowania)

przycisk zwykle oznaczony RST wykonuje reset (więc można nim pstryknąć zamiast podpinać i odpinać zasilanie)

OK to widzę robisz, ale znikający i pojawiający się port może być objawem bootloopa (czyli kolejność wciskania przycisków nieprawidłowa, bo sprzęt nie powinien w ogóle próbować bootować w trybie bootloadera)

PS wrzuć jakieś ładne foty sprzętu (by się dało go zidentyfikować w miarę łatwo, tj. czytelne zdjęcia makro z dobrze widocznymi napisami również na scalakach obu stron każdej z płytek), albo napisz jaki konkretnie masz sprzęt (wyświetlacze graficzne są zwykle ekstremalnie trudne do zidentyfikowania, więc link do konkretnej oferty sklepu w którym to kupiłeś będzie OK, ale zdjęcia realnego sprzętu też bym chciał zobaczyć).

PPS przeoczyłem ten istotny fragment

Więc jednak wszystko działa, ale przez krótki czas?
bo nie bardzo kumam o co chodzi z tym czasem/aktualną godziną, bo to sugeruje, że wyświetlacz działa, a potem przestaje… (jeśli tak jest, to przyczyny bym szukał w zasilaniu).
Skoro masz dyrektywę ota: to możesz flashować “przez powietrze” tj. po WiFi, nie ma musu po kabelku, no chyba, że skompilowany wsad z obsługą wyświetlacza uwala sprzęt… (ale robi to raczej nie bez powodu - zwykle tak się zdarza, gdy konfiguracja zupełnie nie pasuje do wykorzystanego sprzętu)

Nie wiem czy powinienem tu odpowiadać czy edytować swój post. Zaryzykuje i odpowiem.
Sprzęt działa, jest to nodemcuV3 ale dla esphome ustawione V2. Wyświetlacz też jest poprawnie dodany. Układ jest na prototypowej płytce bo dopiero zacząłem poznawać ESPHome i od razu natknąłem się na problem.
Zrobiłem już jeden prosty układ włączanie i wyłączanie przekaźnika i diody za pomocą przycisku - działał jak należy.
Poniżej wklejam zdjęcie zbudowanego układu.
Problem jest dokładnie taki że po wgraniu programu do nodemcu przestaje odpowiadać wifi. Zegar, który powinien się synchronizować z HA wyświetla tak jak na fotce - czas idzie, odlicza od 1:00, układ na foto jest uruchomiony 7 minut.
Raz na kilka programowań układ załapie sieć wifi i zegar się zsynchronizuje z HA ale po około 30-40 minutach działania wszystko pada, traci łączność z wifi i pokazuje 1:00

Jak wgram standardowy startowy plik z konfiguracją nowo utworzonego urządzenia to działa, jest wifi, mogę sprawdzać logi, programować po wifi.
Nawet tak okrojony kod powoduje takie samo działanie układu

esphome:
  name: wyswietlacz
  friendly_name: wyswietlacz

esp8266:
  board: nodemcuv2

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  encryption:
    key: "4ZSjZ9TCA6ZcyuCjgluV9o4rC/vgMqacvzCeP7vv3eQ="

ota:
  password: "3ddc9661251e39c7058993a15ddaa248"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Wyswietlacz Fallback Hotspot"
    password: "mVnVnKFx0t8I"

captive_portal:


font:
  - file: 'slkscr.ttf'
    id: font1
    size: 8

i2c:
  sda: D1
  scl: D2
  scan: false

display:
  - platform: ssd1306_i2c
    model: "SH1106 128x64"
    address: 0x3C
    lambda: |-
      // Print "Mitt Smarta Hus" in top center.
      it.printf(64, 0, id(font1), TextAlign::TOP_CENTER, "Test wyswietlacza");

Mnie to intryguje po co te pulldowny na szynie I2C, jeśli już to powinny być pullupy, ale przy takiej długości przewodów można je zaniedbać, bo ESP8266 na większości pinów dysponuje wewnętrznymi pullupami.
Pozbądź się więc rezystorów i sprawdź czy działa stabilnie.


PS

To nie miejsce na dyskusję na ten temat, ale…

Co do zasady - edytowanie postów do których istnieją odpowiedzi zaburza naturalny tok dyskusji, więc jest to dopuszczalne tylko w naprawdę uzasadnionych wypadkach, jeden z moderatorów tu usilnie walczy o zawieranie wszystkiego w jednym poście (o ile jeszcze nie ma do niego odpowiedzi) - jako edycje i absolutnie zabrania posta pod postem, nawet gdy zawierają odpowiedzi do innych osób, czy są one na różne tematy.

O o ile właściwie z tym wszystkim się zgadzam (można stosować cytaty wybiórcze by adresować odpowiedzi do konkretnych osób lub wywołanie przez @nick), to nie z tym ostatnim - zgarnianie różnych tematów do jednego wora uniemożliwia moderację post-factum wątków w których jeden temat rozwidlił się na 2 lub więcej tematów wartych osobnych wątków (więc pozostaje mi olewać takie wielotematyczne wątki i kwitnie w nich syf i burdel, albo ciąć jak siekierą i się nie przejmować, że to może zniszczyć tok dyskusji np. na podstawowy temat wątku …).

Może pomysł na wyprodukowanie na tym engine płaskiego forum a’la elektroda (podczas gdy Discourse jest częściowo drzewiaste) jest jakimś szczytnym pomysłem, ale nie jestem do tego przekonany.

A co najgorsze ludzie obdarzeni moderacyjnymi ostrzeżeniami zaczynają się zachowywać dziwnie i edytują wcześniejsze posty całkowicie niszcząc zrozumiałość toku dyskusji …

Te rezystory nie są połaczone z portami procesora. To pozostałość po poprzednim “projekcie” i nie łączą się one z płytką. Płytki stykowe mają fizyczne połączenie dziurek do przetłoczenia (F-J).

Ja też nie wiedziałem czy mam edytować swój poprzedni post czy odpisać. Tak jak piszesz takie edytowanie postów wprowadza ogromny bałagan i niszczy zrozumiałość dyskusji. Sam mam forum techniczne na którym jest ponad 80.000 userów i jest tam możliwość edycji swojego posta tylko przez 30 minut od napisania właśnie po to żeby nie zaburzać zrozumiałości wątku ale móc poprawić ewentualne zauważone po napisaniu błędy.

1 polubienie

Masz zaznaczone scan: false
Wykrywa Ci poprawnie adres wyświetlacza na magistrali I2C podczas rozruchu NodeMCU?

I w NodeMCU
SCL to D1
SDA to D2

U Ciebie jest odwrotnie zdefiniowane.

Faktycznie nie zauważyłem, że tam są 2 osobne płytki stykowe koło siebie.

Skanowanie można włączyć - to wydłuża czas rozruchu, ale skoro znasz adres I2C tego wyświetlacza to nie widzę powodu.

Magistrala I2C w ESP8266 jest tylko programowa (nie ma sprzętowego układu TWI), więc w zasadzie można zdefiniować dowolne typowe (nie wszystkie są typowe) piny jako I2C, jeśli ich zamiana pomoże tzn. ESPHome zawiera istotne błędy (lub masz MCU nieco usmażony po jakiś innym projekcie).

Nie miałem czasu odpowiedzieć na to

Istotnie problem dotyczy WiFi i/lub połączenia API z HA

Stosujesz połączenie API z szyfrowaniem, jeśli poprzednio miałeś inny klucz lub brak szyfrowania to może być przyczyną - sugeruję usunąć urządzenie w Integracji w HA i dodać je ponownie używając dokładnie tego klucza z konfiguracji (restart HA spowoduje, że zadziała automatyczne wyszukiwanie, ale można też dodać ręcznie).

Brak połączenia API (jeśli jest zdefiniowane i brak połączonego klienta w postaci HA) powoduje cykliczne restarty (jeśli dobrze kojarzę co 15 minut i to niezależnie od stanu WiFi)

Druga kwestia - pobierasz czas z HA, jeśli nie ma połączenia API, to sprzęt nie jest w stanie uzyskać w ten sposób informacji o bieżącym czasie. (To samo może dotyczyć sytuacji gdy masz jakieś problemy z HA.)

To akurat można opędzić inaczej

time:
  - platform: sntp
    id: esptime

Jeśli przy takiej konfiguracji zegar nie otrzyma czasu w 5-6 sekund od uruchomienia, to masz jakieś poważne problemy z siecią.


W ogóle to cały czas kombinujemy pod górkę - masz włączone debugowanie i na tej płytce wykorzystanie debugowania po UART jest jak bułka z masłem - wystarczy mieć wpięte USB do portu komputera i to wszystko, logi możesz przechwytywać dowolnym terminalem.

Jeśli używasz Windowsa, to ja sugeruję tradycyjny PuTTY
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
przykładowa konfiguracja dla COM4

a do logów z UARTA można się nawet dostać przez web-ESPHome
https://web.esphome.io/

Oczywiście niezależnie od metody łączysz się z tym portem szeregowym “co zawsze”.
Log powie nam wszystko, będzie widać przyczynę jak na dłoni.
(a sugeruję PuTTY, bo czasem trzeba “łapać” logi przez dłuższy czas rzędu godzin)


Ciąg dalszy kwestii WiFi - jeśli nie ma połączenia z siecią, to też po jakimś czasie ESP będzie się restartować - to na wypadek zawieszenia się karty sieciowej (można to wyłączyć w konfiguracji, ale zacznijmy od tego, że ten projekt musi działać niezawodnie, bo jest stosunkowo prosty).

Jeszcze kwestia anteny WiFi - generalnie te anteny PCB nie są jakieś wybitne, a dodatkowo płytka stykowa zawiera “pod pokładem” mnóstwo żelastwa, które tłumi sygnał RF, więc zasadniczo zaleca się by antena WiFi wystawała poza płytkę stykową na ile się tylko da - warto przełożyć płytkę prototypową “tył na przód” tzn. by złącze USB wypadało gdzieś w środku płytki stykowej, a antena wystawała na ile to możliwe - piny D0 i A0 umieść w otworach przy samej krawędzi.

Oto przykład - moduł wprawdzie inny ale to tylko demonstracja jak upchnąć na płytce stykowej by antena wystawała na wolną przestrzeń (obrysowałem ją, bo w tym module akurat antena jest od przeciwnej strony PCB, ale co charakterystyczne - jest to obszar bez elementów i ścieżek):

Sugeruję też poprzekładać inne elementy na pojedynczą płytkę by używać jak najmniej zworek między płytkami - rezystancja styku potrafi czasem zakłócać działanie układu.

Aż się boje odpowiadać… chyba powinienem zedytować pierwszy post żeby odpowiedzieć…

Jest ewidentnie problem z połączeniem z HA po zmianie platformy pobierania czasu na sntp czas wyświetla się poprawnie, wifi działa i jest ok.

Dodanie jakiejkolwiek linii - platform: homeassistant powoduje złą pracę układu.
np:

sensor:
  - platform: homeassistant
    id: inside_temperature
    entity_id: sensor.th2_u_eli_w_biurze_temperature
    internal: true

Już wcześniej próbowałem, usuwałem i tworzyłem nowe urządzenia nazywając je w różny sposób i za każdym razem ten sam błąd działania.
Spróbuje jeszcze raz to zrobić ale nie spodziewam się sukcesu.
Czy gdzieś jeszcze w samym HA się konfiguruje jakieś połączenie z ESPHome? Gdzieś jeszcze powinienem zajrzeć?

Z tym podglądaniem portu przez Putty czy stronę to nie da się :slight_smile: Jak układ źle działa nie mam portu, pojawia się i znika więc nie można z nim nawiązać połączenia.

@zaktom dziękuje za zwrócenie uwagi na pomyłkę pinów. Nie powinno to mieć znaczenia przy uruchamianiu ale zmieniłem tak jak na opisie z oficjalnego rysunku płytki

To jest typowy objaw bootloopa, czyli firmware które przygotowałeś ma jakąś kluczową wadę, jeśli dysponujesz backupem IDE ESPHome to sugeruję downgrade do 2023.2.4 bo w marcowych wersjach weszły zmiany, które w specyficznych warunkach mogą prowadzić do budowy wadliwych obrazów.

Ponadto warto konfigurację zawsze porównać z aktualną dokumentacją (stare tutoriale budowy gotowych urządzeń mogą zawierać jakieś przestarzale opcje).

Ja stawiam na problem dotyczący klucza API - usuń wszelkie urządzenia ESPHome z Integracji w HA, sprawdź czy nie masz czegoś w Ignorowanych lub wyłączonych i usuń wszystko (te 2 ostatnie przypadki mogą wymagać restartu HA), zrestartuj HA.

Nowo wykryte urządzenia dodaj ponownie do Integracji podając poprawny klucz API dla każdego z nich (ten z YAMLa, nie zmieniaj go przerabiając YAMLe, generalnie jeśli zmieniasz intensywnie encje eksponowane przez urządzenia, to sugeruję takie urządzenie usunąć i dodać ponownie do integracji).

Opcjonalnie można w ogóle się pozbyć kluczy API, jeśli nie otwierasz swojej sieci do internetu.

A co do importu encji z HA, to oczywiście encja o id sensor.th2_u_eli_w_biurze_temperature musi istnieć w HA, z którym się łączysz.

1 polubienie

Bardzo dziękuje za podpowiedzi i podsunięcie dobrych praktyk jak choćby tych żeby fonty i obrazki trzymać w wydzielonych folderach.
Właściwie nie wiem co się wydarzyło z moim układem ale zaczął działać poprawnie :slight_smile: . Wyświetlacz działa, łączy się z wifi - co prawda bardzo długo się łączy ale w końcu dochodzi do stabilnego połączenia.
Jedyne co zmieniłem to ustawienie z - platform: homeassistant na

time:
  - platform: sntp
    id: esptime

Między czasie dodałem obsługę czujnika dallas, czujnika DHT i za każdym razem jest dobrze. Szkoda tylko że nie wiem co się zadziało że układ działa sprawnie.

No cóż tamte bootloopy nie są już raczej do zdiagnozowania.

YAML, który wkleiłeś na początku (zauważyłem to dopiero po głębszej analizie) wprawdzie zawierał sensory z HA, co do których mam pełne przekonanie, że takich nie posiadałeś i nie posiadasz: sensor.mellanvaning_temperature (a co do tego drugiego nie mam pewności, bo jego nazwa nie mówi zupełnie nic) - możesz sprawdzić czy dodanie takiego “lewego” sensora powoduje bootloopy (moim zdaniem nie powinno, ale to jest do sprawdzenia, może powodować natomiast niestabilną pracę i ewentualnie restarty co jakiś czas, a bodajże po 8 “niezdrowych” restartach sprzęt wchodzi w tryb awaryjny).

Przykłądowy log z trybu awaryjnego po sieci (to akurat ESP-01 i nie ma go podpiętego po serialu)

INFO Reading configuration /config/esphome/esp01-ikea-vindriktning-b05480.yaml...
INFO Starting log output from esp01-ikea-vindriktning-b05480.local using esphome API
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer
WARNING Can't connect to ESPHome API for esp01-ikea-vindriktning-b05480.local: Connection isn't established yet (ConnectionState.CLOSED)
INFO Trying to reconnect to esp01-ikea-vindriktning-b05480.local in the background
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer
WARNING esp01-ikea-vindriktning-b05480.local: Connection error occurred: [Errno 104] Connection reset by peer

aby wyjść z trybu awaryjnego można odłączyć zasilanie od ESP

Obecnie procedura Adopcji wymusza użycie klucza API, nawet jeśli wsad jest skompilowany bez klucza.


Do pełnej diagnozy byłyby potrzebne jeszcze pełne informacje o środowisku w którym kompilujesz wsad (w tym przede wszystkim wersja IDE ESPHome, które miało 2 aktualizacje w ostatnich dniach, powiązane z dużymi zmianami, więc teoretycznie mogą wpływać na problemy w kompilacji) oraz logi z tych kompilacji przy których powstały wsady, które uwalały ESP do bootloopa.

Zmiana platformy źródła czasu nie ma prawa mieć żadnego znaczenia (o ile urządzenie masz prawidłowo zintegrowane z HA) - wciąż mam testowe urządzenie, które używa obu platform czasu (w celu porównania ich niezawodności) i działają oba (aktualizuję je na bieżąco ze stabilnymi wydaniami ESPHome).

1 polubienie

Nie miało znaczenia czy były to encje, których nie mam w HA czy takie, które posiadam. Sprzęt zachowywał się tak samo
Teraz już jest dobrze, nie wiem co się wydarzyło. Aktualizowałem co prawda HA w tym czasie ale to nie powinno mieć znaczenia. Dziękuje za pomoc. Pozdrawiam

W dużym skrócie (już o tym pisałem) - po 8 restarcie ESP (z jakiejś wewnętrznej przyczyny czasem nieznanej, ale brak połączenia z API czy problemy z dostępem do sieci są takimi przykładowymi przyczynami) firmware ESPHome wchodzi w tryb awaryjny, to może sprawiać wrażenie awarii (więc świeżo po OTA warto poczekać na logi - zwykle pojawia się w nich informacja jeśli takie restarty wystąpiły).
Odcięcie zasilania na chwilę załatwia (tymczasowo) taki problem (generalnie trzeba znaleźć przyczynę restartów).

Przyczyną bootloopów (których typowym objawem jest znikający i pojawiający się port szeregowy) zazwyczaj jest wadliwie skompilowane firmware, ale problemy z zasilaniem też bywają ich przyczyną (szczególnie jeśli zasilasz z ESP jakieś peryferia) - “pusty” wsad (tzn. taki który prawie nic nie robi) może umożliwić modułowi stabilną pracę bo pobiera wtedy stosunkową niską moc, jeśli dokompilujesz coś “prockożernego” to pobór mocy wzrośnie… (w tym wypadku doszła też moc pobierana przez sam wyświetlacz, który w uśpieniu bierze mniej).

Ale generalnie moduły zawierające AMS1117 3.3 i zasilane z USB (z jakiegoś sensownego zasilacza) powinny pracować stosunkowo stabilnie (NodeMCU v2 i zbliżone klony mają ten stabilizator na PCB).

Ostatnie aktualizacje ESPHome mogły mieć wpływ na to czy skompilowane firmware jest prawidłowe. Ponieważ takie rzeczy się zdarzają w intensywnie rozwijanych projektach open-source to backupy Dodatku (IDE) ESPHome trzymam nawet do kilku miesięcy wstecz (aby w razie wykrycia problemu, który wcześniej nie występował móc się “cofnąć w czasie”).

Ostatnio musiałem z tym dość intensywnie walczyć w odniesieniu do platformy RPi pico (wczesne marcowe aktualizacje popsuły sporo, a ostatnia jak dotąd nie naprawiła wszystkiego). Jest to wprawdzie platforma w fazie eksperymentalnej, ale działała już wcześniej w dość rozsądnym zakresie.

1 polubienie