Zwykłe zapytanie HTTPS wysłane z urządzenia z ESPHome do tej pory wstrzymywało na nim całą resztę pracy. Akcje http_request.get, http_request.post i http_request.send wykonywały zapytanie w całości za jednym razem, a główna pętla czekała, aż się skończy. Na ESP32-S3 oznaczało to od 2,5 do 3,6 sekundy bez odczytu czujników, odświeżania wyświetlacza i odpowiadania Home Assistantowi. Zmiana scalona 24 października 2026 to poprawia, ale niesie też niezgodność wstecz dotyczącą skryptów. Jest w gałęzi rozwojowej, więc powinna trafić do ESPHome 2026.11.

Jak to działa teraz

Akcja przekazuje zapytanie komponentowi http_request, który prowadzi je krok po kroku we własnej pętli. Akcje zapisane w automatyzacji po zapytaniu nadal ruszają dopiero po nadejściu odpowiedzi, więc kolejność działania się nie zmienia.

Autor zmierzył najdłuższe zatrzymanie pętli na płytce T-Display S3 Pro (ESP32-S3, ESP-IDF 5.5.6):

  • HTTPS GET: wcześniej 2397-2519 ms, teraz 296-356 ms;
  • HTTPS POST: wcześniej 1733-2726 ms, teraz 297-306 ms;
  • HTTPS z 20 KB danych: wcześniej 2222-2442 ms, teraz 688-727 ms;
  • pobieranie 70 KB w sieci lokalnej z prędkością 20 KB/s: wcześniej 3557-3580 ms, teraz 13-39 ms.

Całe zapytanie trwa tyle samo co wcześniej. Na ESP-IDF niektóre etapy nadal blokują pętlę: pierwsze połączenie z każdym serwerem (DNS i TCP, w testach około 235 ms), około 300 ms pracy procesora przy nawiązywaniu szyfrowanego połączenia TLS oraz odczyt treści odpowiedzi HTTPS, bo biblioteka TLS czeka na pełne rekordy. Niedostępny serwer nadal blokuje urządzenie aż do upływu limitu czasu. Sprawdzanie gniazda sieciowego wymaga ESP-IDF 5.5.3 lub nowszego. Na Arduino i przy kompilacji na komputer wszystko działa po staremu.

Kolejka i limity

Każdy komponent http_request wykonuje teraz jedno zapytanie naraz, w kolejności wywołania, a kolejne cztery mogą czekać w kolejce. Każde następne uruchamia wyzwalacz on_error i zapisuje w dzienniku komunikat Too many requests waiting; request dropped. Każde połączenie TLS zajmuje około 40 kB pamięci, dlatego zapytania nie mogą się gromadzić bez końca. Nowa opcja max_concurrent_requests (od 1 do 4, domyślnie 1) określa, ile zapytań może iść równocześnie.

script.stop może teraz przerwać trwające zapytanie. Ponowne uruchomienie lub głęboki sen porzuca zapytania oczekujące i trwające, ale te wysyłane z automatyzacji on_shutdown nadal wychodzą. Gdy odpowiedź w ogóle nie nadejdzie, on_response wciąż uruchamia się z kodem -1. W testowej konfiguracji dla ESP32 z ESP-IDF oprogramowanie urosło o 2,9 kB pamięci flash i 8 bajtów RAM.

Niezgodność wstecz

Skrypt zawierający jedną z tych akcji jest teraz uruchomiony przez cały czas trwania zapytania. Domyślny tryb skryptu to mode: single, więc przy drugim wywołaniu w tym czasie w dzienniku pojawi się Script 'x' is already running! (mode: single), a skrypt się nie wykona. Wcześniej skrypt zawsze kończył się od razu. Jeśli skrypt wysyłający zapytania może ruszyć ponownie w krótkim odstępie, na przykład przyciskiem albo przez często odświeżany czujnik, przed aktualizacją przełącz go na mode: queued lub mode: parallel.

Dokumentacja opisująca, jak zapytania działają obok głównej pętli, czeka jeszcze na scalenie.