Składnik online_image w ESPHome pobiera obraz spod adresu URL i wyświetla go na ekranie, na przykład zdjęcie z kamery, okładkę albumu albo mapę pogody. 22 i 23 października 2026 do gałęzi rozwojowej (2026.11.0-dev) trafiły trzy powiązane zmiany autorstwa Clyde'a Stubbsa. Razem zmniejszają ilość pamięci potrzebnej do pobrania pliku JPEG, a ekran może teraz pokazać, ile danych już dotarło. Powinny pojawić się w ESPHome 2026.11.

Mniej pamięci na ten sam obraz

Do tej pory online_image najpierw pobierał cały plik do bufora, a dopiero potem zaczynał dekodowanie. JPEG o rozmiarze 200 KB potrzebował 200 KB ciągłej pamięci RAM, nie licząc bufora na zdekodowany obraz, a samo dekodowanie szło w jednym długim wywołaniu. Na ESP32 z niewielką ilością wolnej pamięci może to przesądzić o tym, czy duży obraz w ogóle się wczyta.

Po zmianie #21342 plik JPEG, dla którego serwer podaje nagłówek Content-Length, jest dekodowany na bieżąco. Bufor pobierania musi pomieścić tylko nagłówki obrazu, a dekoder pracuje krótkimi krokami, najwyżej 20 ms na jeden obieg pętli głównej, więc reszta urządzenia działa normalnie. Jeśli nagłówki nie mieszczą się w buforze, dziennik podpowiada, żeby zwiększyć buffer_size. Plik JPEG bez Content-Length nadal jest najpierw pobierany w całości.

Nowa biblioteka JPEG

Podstawy przygotowała zmiana #21341. ESPHome korzysta teraz z własnego rozwidlenia biblioteki JPEGDEC (esphome-libs/JPEGDEC). Według opisu zmiany oryginalny projekt nie miał nowego wydania od wersji 1.8.4, a poprawki od innych osób czekają tam bez odpowiedzi. Rozwidlenie dekoduje obraz po jednym rzędzie bloków, potrafi poczekać na kolejne dane zamiast dekodować śmieci i poprawia błędy przy niepełnych odczytach oraz obrazach w odcieniach szarości. Włącza też przyspieszoną konwersję kolorów SIMD na ESP32-S3 w kompilacjach ESP-IDF, z której JPEGDEC korzystał dotąd tylko z Arduino. Na ESP32-S3 dekodowanie pełnego obrazu przyspiesza o 12-19%, a kompilacja biblioteki z -O2 dokłada kolejne 3-5%. Poprawki trafiły też jako propozycje do oryginalnego projektu.

Postęp pobierania na ekranie

Trzecia zmiana, #21355, dodaje dwa wyzwalacze:

  • on_download_started uruchamia się, gdy serwer przyjmie żądanie, ale nie przy odpowiedzi 304 ani przy błędzie HTTP.
  • on_download_progress podaje progress w procentach i bytes_read. Uruchamia się z wartością 0 na starcie, najwyżej co 100 ms w trakcie pobierania i jeszcze raz po ostatnich bajtach, więc pasek postępu zawsze dojdzie do 100%. Bez Content-Length wartość progress to NAN.

Autor sprawdził wyzwalacze na LilyGo T-Display S3 Pro, gdzie przy sześciu pobraniach sterowały paskiem postępu w LVGL. Cały zestaw zmian przeszedł też testy na wyświetlaczu z ESP32-S3 i testy jednostkowe. Dekodowanie w trakcie pobierania dotyczy tylko JPEG, a nie innych formatów obrazów.