Jakieś fatum wczoraj zdechł mój Dell Wyse miałem na nim Proxmoxa z HA.
Niestety problem sprzętowy bo SSD Patriot też padł całkowicie a z nim wszystkie backupy oprócz grudniowego pobranego na kompa.
Nowy HA postawiłem już na OptiPlex3050 ale bez proxmoxa na HAOS i udało mi się przywrócić ten grudniowy backup. Szkoda mi trochę Thinclienta bo to tylko 20W a mój HA nie był zbyt wymagający.
Niestety straciłem też 3 urządzenia ESP, tzn. mam ich instalki w plikach bin ale bez yaml i bez API Key. Jest jakakolwiek szansa na odzyskanie klucza szyfrującego? I kolejne pytanie czy jak skonfiguruję sobie API key w secret to będzie to jeden wspólny klucz dla wszystkich urządzeń? Sadziłem, że każde urządzenie powinno mieć swój.
- Raczej nie, a w każdym razie nie znam metody znalezienia klucza (ale standardowo flash nie jest szyfrowany, więc cień szansy jest, rok temu dawało się odczytać dane uwierzyteniajace WiFi to może i klucz API da się odczytać jesli go znajdziesz).
- W secrets.yaml możesz skonfigurować jeden wspólny lub dla każdego urządzenia oddzielnie, jak stryjenka woli, ja używam wspólny, jeśli ktoś mi się włamie do sieci czy HA, to nie będzie robiło różnicy czy jest jeden klucz, czy wiele.
Ten backup nie zawierał konfiguracji dodatków? W kopii HAOS (np. automatic_backup_2026_2_2.tar) są YAML’e. Takie archiwum z kopią możesz rozpakować i dostać się do folderu esphome:
../automatic_backup_2026_2_2/homeassistant/data/esphome
Mam wszystkie urządzenia i yamle z grudnia niestety styczeń i luty przepadły czyli 3 nowe urządzenia oraz statystyki. Będę jeszcze próbował ożywić Wyse i ten dysk ssd ale nie robię sobie wielkich nadziei tak jest jak się nie poczyta, że Patrioty miały jakiś bublowaty chiński kontroler i pamięci. Jedno wiem na pewno, że bardziej podoba mi się HAOS bezpośrednio na dysku niż Proxmox muszę jeszcze sprawdzić czy uda się też bezpośrednie programowanie ESP przez USB na Proxmoxie niestety nie hulało.
A testowałeś sam SSD? Czy tylko w dellu bo nie zawsze musiał zdechnąć SSD
SSD testowany w różnych kompach i 3ech różnych adapterach USB.
Wyse się jeszcze kilka razy uruchomił na Ubuntu z USB ale teraz nie chce wstać.
Co do ESP czy da się wyłączyć restarty gdy nie ma połączenia z HA?
Staram się aby moje urządzenia działały bez konieczności komunikacji z HA ideałem dla mnie byłoby aby nadal działały też bez sieci.
Czy zatem jest opcja aby po wyłączeniu HA ESP nie restartował się?
Czy jest opcja aby po zaniku sieci pojawił się hotspot ESP ale z działającą stroną www?
I tak muszę zabawki przeprogramować przynajmniej te najważniejsze.
ESPHome – może działać bez połączenia z HA i sieci WiFi
1. Wyłączenie restartu gdy brak połączenia z HA
Domyślnie ESPHome restartuje się po ~15 minutach bez połączenia z API. Możesz to wyłączyć:
yaml
api:
reboot_timeout: 0s # 0 = wyłącza automatyczny restart
2. Wyłączenie restartu gdy brak WiFi
Analogicznie dla WiFi:
yaml
wifi:
reboot_timeout: 0s # wyłącza restart przy braku sieci
3. Hotspot (AP Fallback) z działającą stroną www
ESPHome ma wbudowany fallback AP oraz web server. Możesz mieć oba jednocześnie:
yaml
wifi:
ssid: "TwojaSSID"
password: "haslo"
reboot_timeout: 0s
ap:
ssid: "ESP-Fallback"
password: "haslo123"
captive_portal:
web_server:
port: 80
Gdy WiFi odpada → ESP tworzy własną sieć AP, a strona www nadal działa pod 192.168.4.1. Możesz sterować urządzeniem przez przeglądarkę bez HA i bez sieci domowej.
4. Pełna autonomia – działanie lokalnej logiki
Automatyzacje wbudowane w ESPHome (automation:, lambda:, script:) działają lokalnie na chipie i nie wymagają HA. Warto przenieść krytyczną logikę z HA do ESPHome.
Podsumowanie – minimalna konfiguracja “odpornej” kostki
yaml
api:
reboot_timeout: 0s
wifi:
ssid: "TwojaSSID"
password: "haslo"
reboot_timeout: 0s
ap:
ssid: "ESP-Device-Fallback"
password: "haslo123"
captive_portal:
web_server:
port: 80
Trzy linie zmieniają całkowicie zachowanie – ESP nie będzie się restartować, a po utracie sieci dostaniesz własny hotspot ze stroną sterującą.
To samo dla komponentu WiFi
Nie musisz, bo to działa na bare metal.
Natomiast metody eliminujace restart po utracie połączenia zawsze miały jedna wadę - trzeba było odłączyć zasilanie by przywrócić połączenia, natomiast jakiś czas temu przebudowano obsługę WiFi i być może to ograniczenie już nie istnieje, ale nie miałem jak na razie okazji do testów i nawet takich nie planuję, bo obecnie nie mam nic wymagającego pracy autonomicznej.
Dzięki za pomoc straciłem dwa miesiące statystyk a reszta już prawie w całości odzyskana.
Z plików .bin da się odczytać zarówno hasła do wifi ale też hasło do update co pozwala trochę pokombinować i nadpisać API key.
Była okazja wszystko posprzątać i wprowadzić trochę standardów bo każde kolejne ESP to było coś nowego zaczynałem od indywidualnych sieci WiFi, API i haseł potem powoli ewaluował secret i zawsze brakowało czasu na poprawki w starych urządzeniach. Sądziłem, że przy aktualizacji OTA przez stronę www po zalogowaniu się wpiszę dowolny plik uf2 a okazało się, że bez prawidłowego hasła OTP po komunikacie o succesie soft był nie zaktualizowany.
Na szczęście hasła dało się odzyskać i zmienić przy aktualizacji mam więc teraz wszystko w secret.
Jeszcze raz dzięki za rady czas na testy “autonomii”.
1 polubienie
Ponieważ sytuacja już opanowana WYSE odpalony na razie na starym dysku z laptopa. Urządzenia ESPHome też ogarnięte. Teraz pracuję nad NAS i automatyczną kopią z HA na OMV.
Co do hasła i klucza API.
Hasło do aktualizacji OTA znajduje się w pliku .bin w obok haseł wifi. Wystarczy otworzyć taki plik w dowolnym hex edytorze i wyszukać jako tekst swoje hasło do wifi i znajdziemy hasło do OTA.
Znając już to “stare” hasełko możemy przeprowadzić migrację do nowego hasła z secret dodając taki kawałek do yamla:
on_boot:
- lambda: |-
id(my_ota).set_auth_password("nowehaslo");
Po wgraniu usuwamy wpis i mamy nowe hasło i możliwość wgrania dowolnego softu również z nowym API key.
3 polubienia