* AsyncHttpClientLight: time out reading a body when the server goes silent
writeToStreamDataBlock() waited for the rest of a body for as long as
connected() held. A server that stops sending part way through without
closing leaves connected() true, so the worker never finishes and the
caller, waiting in runJob(), never returns. Give up after _tcpTimeout
without data and return HTTPC_ERROR_READ_TIMEOUT, as HttpClientLight
now does (#25139).
* AsyncHttpClientLight: notice when the server closes after the last byte
AsyncTcpAdapter only saw the peer close inside read(), and callers only
read when available() > 0. A body without Content-Length that ends with
the server closing left connected() true for ever, so
writeToStreamDataBlock() never returned. connected() now peeks at the
socket, as WiFiClient::connected() does: data still buffered keeps it
connected, an orderly close after it does not.
* AsyncHttpClientLight: address review of the read timeout
- connected() only reports a peer close and no longer calls stop(): it can
be called from another task than the worker using the socket.
- writeToStreamDataBlock() closes the connection on a read timeout, as the
chunked readers do, so a stalled connection is not reused.
- readBodyToStreamString(): the identity branch used by async GET/POST now
times out after _tcpTimeout without data, and notices a close: with no
Content-Length it ends the body, with one it is a lost connection.
After the zero-size chunk the readers read one line unconditionally,
then waited for another empty line. The first read already consumed the
empty line that ends the body, so every chunked body waited for a line
that never came and failed with HTTPC_ERROR_READ_TIMEOUT after
_tcpTimeout. Read trailer lines up to the first empty one instead.
writeToStreamDataBlock() looped for as long as connected() held, waiting
for the rest of the body with no time limit. A server that stops sending
part way through a body without closing the connection - a computer that
sleeps, a cable pulled, a network that drops between the two ends - leaves
connected() true for ever, so the read never returned. Called from the main
loop, as Berry's webclient get_string() is, it left the device answering
nothing, not even its web page, until it was power-cycled.
Give up after _tcpTimeout without data, returning HTTPC_ERROR_READ_TIMEOUT,
as handleHeaderResponse() already does for the headers. A body that keeps
arriving, however slowly, is unaffected: each piece resets the clock.
The MQTT flags m1, m2, m3 and mh were stored one slot too high
(position[i-6]), so mh set the triple press flag and m1 wrote before
the start of the position array. mi (mqtt_all) could not be set at all.
Store m1..mh in position[0..3], set mqtt_all from mi and include it in
the command response, as the ESP8266 driver already does.
Fixes #25082
* Matter add Wi-Fi Network Diagnostics cluster (0x0036)
Expose BSSID, SecurityType, WiFiVersion, ChannelNumber and RSSI on the
Root endpoint so controllers (Apple Home, Home Assistant) can show which
access point and channel a device uses. BSSID and channel changes are
reported to subscribers when the device roams.
tasmota.wifi() now also reports `channel`, `security` and `phy`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Clamp RSSI
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: s-hadinger <49731213+s-hadinger@users.noreply.github.com>
Regression from ab38e799a. A GetGroup response could report a huge group
count and stall the device building the group list.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The BME280 can reset itself (e.g. supply glitch) and fall back to sleep
mode; the driver kept computing a constant bogus pressure from the reset
register value until the ESP was restarted.
- check CTRL_MEAS every read, re-run Bmx280Calibrate when not in normal mode
- use I2cValidRead24 and drop 0x800000 (reset/skipped) raw values
- after BMP_FAIL_LIMIT failed reads report null instead of stale values
* Add localized eQ3 TRV status labels
This PR adds missing translation strings for eQ3 TRV status indicators and updates the BLE driver to use localized labels instead of hardcoded text.
* Strikethrough key
* copy pins_arduino from tasmota not framework
* move specific P4 settings out of pins_arduino.h
* keep backwards compability
with the option to redefine the specific different P4 board configs
* Keep P4 SD card on SDMMC slot 0 and set hosted MCU pins in default module
Arduino core and libraries do not see my_user_config.h, so without
BOARD_SDMMC_SLOT in pins_arduino.h SD_MMC uses slot 1 which is taken
by ESP-Hosted.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Add command Ldo<x> <mV> to configure ESP32-P4 LDO3 and LDO4
LDOs are set at boot before any GPIO use. LDO settings of DSI display
descriptor, CSI camera and SD card are only used if not set by command
Ldo and are deprecated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Show clear error if pins_arduino.h for a variant is missing
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Jason2866 <obermeier.johann@googlemail.com>
Co-authored-by: Jason2866 <24528715+Jason2866@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Fix silently-dropped LVGL flush chunks on ESP32-P4 DSI panels
esp_lcd_panel_draw_bitmap()'s DMA2D path takes an internal draw
semaphore with a 0 timeout and returns ESP_ERR_INVALID_STATE (without
drawing anything) if the previous async transfer hasn't completed yet.
DSIPanel::pushColors() ignored that return value, and lv_flush_callback()
always calls lv_disp_flush_ready() regardless, so LVGL believed the
flush succeeded even when the chunk was silently dropped - leaving
stale framebuffer content on screen for that region.
Retry instead of dropping the chunk. The transfer typically completes
in well under 1ms, so poll in short bursts rather than 1ms FreeRTOS
ticks; a bounded retry count still catches a genuinely stuck transfer
and logs it instead of looping forever.
* Allow LVGL DSI draw buffers to use PSRAM on ESP32-P4
lv_pixel_buf/lv_pixel_buf2 previously preferred MALLOC_CAP_INTERNAL,
costing ~120KB of scarce internal SRAM on boards where PSRAM is
otherwise nearly idle (e.g. a 1024x600 DSI panel at 60 flushlines).
Prefer MALLOC_CAP_SPIRAM instead, falling back to internal RAM if
PSRAM is unavailable - safe now that the previous commit fixes the
DMA2D transfer race that PSRAM's slower read speed was exposing.
Also switch the flush-timing debug log from millis() to micros() and
drop its DMA-path exclusion: at a ~60KB/transfer chunk size the whole
operation completes in a few hundred microseconds, so millisecond
resolution just read back 0 or 1 and the DMA path - the one we
actually needed data from - was never logged at all.
* Remove defaulting to PSRAM for now
---------
Co-authored-by: s-hadinger <49731213+s-hadinger@users.noreply.github.com>
Theo Arends
s-hadinger
Adam Matthews
Zhaoqi Xu
SteWers
Jason2866
SoWizard
LesNewellandClaude Opus 5.5
bovirus
XJ
