zacząłem się ostatnio bawić esphome i mam misję, żeby zrobić komunikację przez MQTT w sieci innej niż HA (w skrócie: na świat będzie wystawiony mosquitto broker, z którym będzie się komunikował esp32).
W domu postawiłem sobie testowo dwie oddzielne sieci. Udało mi się ”zmusić” esp32 do konunikacji przez mqtt w tej samej sieci, co HA. Pierwszy krok za mną. W yamlu zmieniam ustawienia wifi na drugą sieć (testową). Instaluje soft przez przewod, wszystko ok. Patrzę w logi (po USB), a esp32 cały czas laczy się ze starą siecią (tak jakby miał cały czas stary config). Restart HA. Bez zmian. Usuwam urządzenie z esphome i dodaje nowe. Automatycznie są ladowane konfiguracje z sieci domyślnej. Zmieniam konfig: zmieniam wifi, usuwam sekcje API, dodaje mqtt. Instaluje, wszystko ok. Restart HA. Logi po przewodzie - esp32 cały czas ma stary soft, łączy się z domyslna siecią, podłącza się do API, nie próbuje się łączyć z brokerem.
Czy ktoś się z tym spotkał? Czy pomijam jakiś krok i nie czyszczę buildow gdzieś po drodze (clean build stosowałem - bez zmian)?
Nie bardzo kumam jak to robisz (jest za wiele możliwości), ale jeśli przez ESP Web Tools, to musisz użyć przycisku RESET DATA (bo standardowe flashowanie nie usuwa partycji z konfiguracją sieci).
Ewentualnie możesz sobie skompilować firmware w trybie Manual Download → Legacy
i użyć do flashowania tego
Robię wszystko przez addona w HA (przez chrome’a). Teraz właśnie udało mi się wgrać nowy soft, ale kolejny raz już nie. Nie do końca rozumiem, jak to działa.
To nie ma żadnego znaczenia - chodzi o to jak flashujesz, metod jest wiele.
esphome-flasher też jest wieloplatformowy, a dla Windowsa można mieć zwykły okienkowy .exe (bez instalowania :P) Świat nie stoi w miejscu.
Normalnie - we flashu tworzone są oddzielnie partycje
zależnie od potrzeb scenariusze mogą być różne, ale upraszczając zagadnienie jest tworzona jedna partycja na system operacyjny i program w nim uruchomiony, a oddzielna na dane które mają przetrwać update
Udało się raz poprawnie wgrać kod z poziomu addonu w HA.
Poczyściłem pliki w /config/esphome/.esphome
Skorzystałem z flashera szopena:
a. przygotowałem plik .bin w addonie esphome.
b. poszło za pierwszym razem!
c. mała poprawka, kolejny bin - wtopa;
d. clean build, save, tworzenie bin - poszło;
Teraz moje pytanie brzmi - jak powinna wyglądać “higiena pracy” podczas przygotowwywanie .bin lub instalowania przez addon (czy to przez ota, czy po USB)? Bo tutaj to wszystko wygląda jakbym pomijał jakiś krok. Nie sądzę, że to clean build robi robotę.
To o niczym nas nie informuje… wciąż nie wiadomo jak to robisz.
Clean build czyści cache, czyli wstępnie skompilowane obiekty (więc raczej nie tędy droga, bo taki cache znacznie przyspiesza kompilację - coś co się nie zmieniło jest pobierane z cache zamiast ponownej kompilacji i linkowane tylko ze zmienionymi obiektami które są kompilowane wybiórczo).
To nie “mój” flasher i korzystam z niego ekstremalnie rzadko, więc mogę się mylić w kwestii tego, że on zawsze czyści cały flash przed wgraniem nowego wsadu.
Nie mam tyle wolnego czasu by siadać do eksperymentów i to zweryfikować.
Kluczowe jest czytanie logów i ich analiza, nie tylko logów urządzenia i kompilacji, również logów flashera.
Z tego co napisałeś NIC nie wynika
Ale też nie robiłem nigdy takich założeń jak twoje, może powinieneś sobie uprościć środowisko testowe, nie dam sobie głowy uciąć, ale ESP z wsadem ESPHome jest przeznaczony raczej do pracy w wyłącznie jednej sieci, więc postaw sobie brokera w tej samej sieci co HA i ESPHome.
*z flashera proponowanego przez Ciebie. Nie przypisuję Ci zasługi jego stworzenia, a doradzenia
Przykro mi, ze Cię rozczarowuję. Ale starając się odpowiedzieć na Twoje pytania:
Broker jest postawiony na HA. Obsługuje głównie zigbee2mqtt.
Z tym flashowaniem to mnie trochę dociskasz - nie mam pojęcia jak na nie inaczej odpowiedzieć niż „przez addon w HA”. Tworzysz config w yaml, addon esphome dociąga sobie resztę. Flasher to zakładam, ze to samo co https://web.esphome.io/. „Jak?” to jest flashowane - za pewne dokumentacja Ci na to odpowie. Ja nie potrafię. Niemniej jednak bardzo dziękuję za pomoc
Umówmy się, że addon/dodatek możesz nazwać IDE (środowisko), ale ono oferuje kilka metod dalszej obsługi miedzy interpretacją YAMLa (w kod c++ i jego kompilacją), a już samym flashowaniem, przy czym nawet wsady binarne powstałe w wyniku kompilacji mogą być różne, mimo, że powstają z tego samego YAMLa.
Waląc takimi ogólnikami nigdy się nie dogadamy, jeśli nie jesteś w stanie doprecyzować to rób screenshoty i wklejaj tekst (YAML, logi, itd.), ESPHome się radykalnie zmieniło od momentu, gdy robiłem w nim pierwsze kroki, mimo to nie używam wielu współczesnych wodotrysków.
Nie twierdzę też, że zjadłem wszystkie rozumki i będę wiedział gdzie jest przyczyna twojego problemu… ale zagląda tu mnóstwo ludzi, którzy mieli styczność z ESPHome, więc jeśli dostarczysz jakiś materiał do analizy to może ktoś w to zajrzy.
Ale skoro “cały czas masz stary soft”, to logi z flashera mogą być interesujące i to zarówno takie z udanych prób jak i z nieudanych.
Jeśli byś flashował przez OTA to z założenia ani układ partycji na flashu nie zostanie zmodyfikowany, ani dane konfiguracyjne (sieci) nie powinny zostać zmienione (bo taka jest idea ich niekasowania).
Ok. Moja ignorancja wynikła z załozenia, że pomijam jakiś krok, bo identyczne zachowanie potwierdziłem na dwóch różnych płytkach (NodeMCU i ESP32-devkitc-V4). Ale jasne, napiszę wszystko od początku na przykładzie NodeMCU v3.
HomeAssistant (2022.12.8) zainstalowany w sieci domowej. Nazwijmy ją “wifi_ssid” dla uproszczenia dalszych dywagacji.
ESPHome (2022.12.7) zainstalowane na HomeAssistant (2022.12.8). Aktywne dwa urządzenia (sterowniki do terrariów w tej samej sieci, w której jest HA).
Mosquitto broker (6.1.3) zainstalowane na HA jak wyżej. Działa (korzysta z niego zigbee2mqtt od blisko roku).
Plik konfiguracji NodeMCU w załączeniu. Wymaga pewnego omówienia:
a. celowy brak sekcji API (wg dokumentacji ESPHome);
b. celowy brak OTA;
c. połączenie do sieci domowej (“wifi_ssid”).
b. Następnie w chrome wybiera się port USB ze swoim urządzeniem (w moim przypadku NodeMCU). Brak logów flashera. Jest widoczne tylko okienko procentowego postępu (najpierw jest “Preparing”, potem “Installing”).
c. Logi flashera widziałem tylko w przypadku “Fail” - masz możliwość wówczas prześledzić linia po linii. W przypadku sukcesu - co była za każdym razem w moim przypadku - nie widziałem tej możliwości (nie twierdzę, że jej nie ma, ale po prostu w gui po uploadzie brak).
Po załadowaniu softu - sprawdzenie logów przez przewód (analogicznie do zrzutu powyżej). Skrócony log (wyrzuciłem wszystkie przeskanowane sieci, chcę tylko pokazać, że potwierdziłem połączenie z wifi i brokerem);
[I][app:029]: Running through setup()...
[C][wifi:037]: Setting up WiFi...
[D][wifi:386]: Starting scan...
[D][wifi:401]: Found networks:
[I][wifi:444]: - 'wifi_ssid' (<MAC>) [redacted]▂▄▆█
[D][wifi:446]: Channel: 9
[D][wifi:447]: RSSI: -56 dB
[I][wifi:257]: WiFi Connecting to 'wifi_ssid'...
[I][wifi:518]: WiFi Connected!
[D][wifi:527]: Disabling AP...
[C][mqtt:029]: Setting up MQTT...
[I][mqtt:176]: Connecting to MQTT...
[I][mqtt:216]: MQTT Connected!
[I][app:062]: setup() finished successfully!
Restart HA.
Moquitto widzi nowe urządzenie i encję. Pierwszy sukces.
Drugi test: wystawienie brokera na świat i test w sieci “wifi_ssid”.
a. przekierowanie portów na routerze.
b. zmiana w yaml adresu brokera MQTT na adres public IP routera (jedyna zmiana w yaml).
c. powtórzenie procedur jak powyżej (install, USB, sprawdzenie logów, restart).
d. wynik: NodeMCU działa w sieci lokalnej, łączy się z brokerem przez adres zewnętrzny.
Test trzeci: zmiana sieci wifi na “wifi_ssid_2”. Jest to sieć na innym routerze, z innym WAN IP. Kompletnie “zewnętrzna” sieć.
a. Zmiany w .yaml w porównaniu do p.9.: sekcja wifi - ssid zmienione na “wifi_ssid_2”, password na “wifi_password_2”;
b. wyprzedzając - wszystkie hasła i nazwy sieci są ok. Dzień wcześniej ładowałem do innego projektu;
c. powtórzenie procedur instalacyjnych;
d. wynik: log pokazuje, że NodeMCU łączy się z “wifi_ssid”.
e. restart HA.
f. brak zmian; ponowny upload; sprawdzanie logów, brak zmian; restart NodeMCU, brak zmian;
Musiałem to odłożyć i wróciłem dopiero po kilku godzinach. Upload się udał, a NodeMCU połączył się z “wifi_ssid_2”. Restart HA. NodeMCU działa z siecią zewnętrzną i komunikuje się z brokerem.
Próba wprowadzenia zmian w kodzie - powrót na sieć “wifi_ssid”. Procedury instalacyjne, log: łączy się wciąz z “wifi_ssid_2”.
Podsumowanie:
Dopiero po użyciu flashera pod windows proces stał się bardziej przewidywalny - to znaczy, że zostanie wgrany soft, który konfigurowałem jako ostatni. Jeśli tak to można nazwać. Na cztery próby - trzy potwierdziły powyższą tezę. Jedną policzę jako błąd albo niedopatrzenie.
Czyli flashujesz przez ESPHome Web Tools, a on domyślnie nie rusza danych na drugiej partycji
(swoją drogą widzę, że oznaczyłeś wcześniejszy post jako rozwiązanie, zatem podejrzewam, że tamto rozwiązanie pomogło).
Możesz sobie ułatwić życie (lub utrudnić, zależy od paru czynników) podpinając ESP do komputera, na którym pracuje HA - wtedy masz dostępny tryb flashowania “od ręki” (jeśli to instalacja HAOS generic lub dedykowany dla SBC to będzie to prawdopodobnie najwygodniejsze, w przypadku wirtualizacji niestety nie umiem powiedzieć czy będzie to wygodne, ze względu na konieczność przekazania portu USB do VM), nie pamiętam czy NodeMCU v3 ma układ automatycznego trybu bootloadera ale chyba tak (więc nie ma potrzeby pstrykania przyciskami przy takim połączeniu).
Jak rozumiem docelowe firmware będzie zajmowało więcej flasha niż jest dostępne w trybie z włączonym OTA (bo to chyba jedyna sensowna motywacja).
Mając włączone OTA (może być z hasłem) oraz portal web (może być chroniony hasłem, jakkolwiek zużywa spore zasoby, więc nie zawsze jest pożądany) będziesz miał możliwość ręcznej aktualizacji OTA nawet jeśli sprzęt będzie pracował docelowo w zupełnie innej sieci (no będzie trzeba sobie zabrać skompilowany plik w formacie “modern”).
Kilka słów na koniec - tak krótki YAML warto wrzucić bezpośrednio do posta (zedytowałem twój post, zasady formatowania markdown, czyli takie jak na githubie w issues itp.).
Pominięcie OTA było celowo ze względu na… lekturę internetu.
Przed testami z MQTT zebrałem informację z dokumentacji oraz z rozwiazań innych znalezionych w sieci. Początkowo OTA było użyte (nawet przy połączeniu z siecią “wifi_ssid”), ale szybko się okazało, że nie chce uploadować softu (logów nie przytoczę, bo na tamten moment był to naprawdę marginalny problem). Na problem z OTA wskazywali inni, którzy bawili się z MQTT. Na ile to problem OTA, a na ile nieudolności ludzi, których rozwiązania czytałem - nie wiem. Na pewno za jakiś czas do tego będę chciał wrócić, bo ten portal web wydaje się interesujacy. Z drugiej strony ostatni raz poprzednią konfigurację zmieniałem dwa lata temu (wtedy NodeMCU korzystał z Blynka).
i korzystam z niego ekstremalnie rzadko, więc mogę się mylić w kwestii tego, że on zawsze czyści cały flash przed wgraniem nowego wsadu.
