ESP8266 WiFiClient odbiór danych z serwera – callback, ESPAsyncTCP, polling

Pytanie

Esp8266, odbiór danych od serwera przez WiFiClient w callback

Odpowiedź Sztucznej Inteligencji

Bezpośrednia odpowiedź na pytanie

• Standardowy WiFiClient w rdzeniu Arduino-ESP8266 nie ma wbudowanych callbacków dla zdarzenia dane dostępne.
• Aby reagować „callbackowo”, masz dwie praktyczne ścieżki:
  1. Symulacja callbacku w loop() lub timerze (polling nieblokujący).
  2. Zastosowanie biblioteki ESPAsyncTCP (lub wyższego poziomu ESPAsyncWebServer/WebSocket/MQTT), która udostępnia natywne zdarzenia onData().

Kluczowe punkty
• WiFiClient = synchroniczny; callback wymaga warstwy pośredniej.
• Podejście z pollingiem działa wszędzie, ale blokada pętli jest niedozwolona.
• ESPAsyncTCP daje prawdziwą asynchroniczność i czyste callbacki.

Szczegółowa analiza problemu

1. Dlaczego nie ma natywnych callbacków?

WiFiClient korzysta z górnej warstwy LWIP; w API Arduino wystawiono tylko funkcje blokujące (read, write, available), co upraszcza użycie, ale wymaga aktywnego sprawdzania stanu gniazda.

2. „Pseudo-callback” w pętli głównej

Tworzymy maszynę stanów; w każdej iteracji sprawdzamy:

void loop() {
  if (client.connected() && client.available()) {
      handleIncoming();       // <- nasz „callback”
  }
  otherTasks();               // czujniki, UI…
}
void handleIncoming() {
  static String buf;
  while (client.available()) {
      char c = client.read();
      buf += c;
  }
  if (buf.endsWith("\n")) {   // np. kompletna linia
      processLine(buf);       // właściwy callback
      buf = "";
  }
}

• Brak blokowania — żadnych while(client.connected()), delay() ani długich printów.
• W długich pętlach zawsze yield(); lub delay(0); aby nie wywołać resetu WDT.

3. Timer (Ticker) = zerowy narzut na pętlę

Ticker rxTicker;
void setup() {
   rxTicker.attach_ms(50, []() { if (client.available()) handleIncoming(); });
}

• Ticker korzysta z systemowego timera i działa w tle; wciąż nie wolno wykonywać długich operacji w jego ISR — tylko szybkie skanowanie i ewentualnie ustawienie flagi do obróbki w loop().

4. Prawdziwie asynchronicznie – ESPAsyncTCP

#include <ESPAsyncTCP.h>
AsyncClient *async = nullptr;
void setup() {
  async = new AsyncClient;
  async->onConnect([](void*, AsyncClient*c){
      c->onData([](void*, AsyncClient*, void* data, size_t len){
          processData((char*)data, len);   // natywny callback
      }, nullptr);
      c->write("GET / HTTP/1.1\r\nHost: ex.com\r\n\r\n");
  }, nullptr);
  async->connect("93.184.216.34", 80);
}

• Biblioteka wykorzystuje wewnętrzny core-timer i zadania LWIP → brak blokowania, brak pracy w ISR.
• Trzeba doinstalować ESPAsyncTCP (kompatybilna z core ≥ 2.7.4; dla core 3.x dostępny fork z gałęzi tekwiz).

5. MQTT/WebSocket – gdy komunikacja jest ciągła

Jeżeli serwer może publikować do brokera MQTT, najprościej użyć PubSubClient (polling, ale ma callback) lub AsyncMQTT. Analogicznie WebSocket (AsyncWebSocketClient).

6. Zarządzanie buforem i pamięcią

• ESP8266 ma ~40 kB RAM-u dla użytkownika; unikaj wielkich String – lepiej użyć statycznego bufora char[512].
• Dane przychodzą fragmentami (TCP segmentation, MSS ~1460 B), buforuj do detektora końca wiadomości (CRLF, Content-Length, JSON brace count).

7. Watch-dog & stabilność

Długa obróbka w callbacku? Użyj kolejki i obróbki w loop(); w samym callbacku tylko kopiuj dane.

Aktualne informacje i trendy

• Core Arduino-ESP8266 3.1.2 (2024-02) nadal nie dodał callbacków do WiFiClient.
• Forki AsyncTCP dla ESP8266 są aktualizowane; główna gałąź me-no-dev jest zamrożona, aktywne rozwidlenie: https://github.com/tekwiz/ESPAsyncTCP.
• Na nowych projektach coraz częściej migruje się do ESP32-C3/S3, gdzie IDF oferuje FreeRTOS + event-loop (callback natywny).

Wspierające wyjaśnienia i detale

• client.setTimeout(ms) tylko skraca blokujące funkcje; nie robi ich nieblokującymi.
• TLS: jeśli musisz łączyć się z HTTPS, użyj WiFiClientSecure lub BearSSL::WiFiClientSecure (pamiętaj o ładunku certyfikatu w PEM i limicie ~2 kB).
• Jeśli używasz HTTP-chunked, detektor końca to 0\r\n\r\n.

Aspekty etyczne i prawne

• Szyfruj dane (TLS) – transmisja plain-text może naruszać RODO/GDPR, jeśli przesyłasz dane osobowe.
• Sprawdź licencje bibliotek (ESPAsyncTCP – LGPL-2.1); przy dystrybucji gotowego firmware należy udostępnić kod źródłowy zmian.
• Dbaj o aktualne certyfikaty – wygasły cert uznawany jest za podatność CVE-2023-34460 w starszych BearSSL.

Praktyczne wskazówki

1. Włącz Serial.setDebugOutput(true); podczas testów – zobaczysz logi LWIP.
2. Stosuj WiFi.setSleep(false) w czasie transmisji strumieniowej, aby uniknąć mikro-przerw.
3. Na długie połączenia TCP ustaw client.keepAlive(maxIdle, interval, probe);.
4. Testuj automatyczny reconnect: sprawdzaj WiFi.status(), a nie tylko client.connected().

Ewentualne zastrzeżenia

• ESPAsyncTCP nie współpracuje z delay() > 15 ms w loop() – zakłóca time-slice.
• Biblioteka nie wspiera IPv6; jeśli serwer wymusza IPv6, trzeba użyć LWIP-RAW lub przejść na ESP32.

Sugestie dalszych badań

• Wypróbuj FreeRTOS na ESP8266 (ESP8266-RTOS-SDK); task TCP + kolejka zdarzeń.
• Przetestuj async-mqtt-client – pełen MQTT 3.1.1 z natywnymi callbackami.
• Sprawdź bibliotekę ArduinoNimBLE na ESP32 jako referencję event-loop.

Krótkie podsumowanie

Standardowy WiFiClient nie zapewnia callbacków – musisz:

1. Polling w loop()/Ticker → prostsze, przenośne.
2. ESPAsyncTCP/AsyncWebServer/MQTT → prawdziwa asynchroniczność, czystszy kod, większa responsywność.

Wybór zależy od złożoności projektu. Dla prototypu – polling; dla produkcyjnego, wielozadaniowego systemu – ESPAsyncTCP albo migracja na ESP32 z natywnym event-loop.