Water heater was the only entity type that directly called
encode_message_to_buffer() instead of fill_and_encode_entity_state().
This meant device_id was never set on WaterHeaterStateResponse,
causing entities with device_id to show as unknown in Home Assistant.
Expand the device_id integration test to cover all entity types:
cover, fan, lock, number, select, text, valve, water_heater,
alarm_control_panel, date, time, datetime, and event.
Closes https://github.com/esphome/esphome/issues/14206
Replace the heap-allocated tx_buffer_ (new char[]) with a compile-time
sized inline array using ESPHOME_LOGGER_TX_BUFFER_SIZE define. This
eliminates a heap allocation during Logger construction, saving ~513
bytes of heap on memory-constrained devices like BK72xx.
Changes:
- Add ESPHOME_LOGGER_TX_BUFFER_SIZE define set from Python config
- Change tx_buffer_ from char* to char[ESPHOME_LOGGER_TX_BUFFER_SIZE+1]
- Remove tx_buffer_size_ member field
- Update constructor to no longer take tx_buffer_size parameter
- Update all references to use the compile-time constant
The Beken/RTL SDKs ship lwIP defaults tuned for a general-purpose WiFi
SoC: TCP_SND_BUF=10*MSS (14.6KB), MEM_SIZE=32KB, 12 TCP + 22 UDP
sockets. These waste significant RAM on memory-constrained chips.
ESPAsyncWebServer allocates malloc(tcp_sndbuf()) per response chunk,
and at 14.6KB this causes OOM on BK7231N.
This tunes lwIP to match ESP32/ESP8266 ranges:
- TCP_SND_BUF/TCP_WND: 4*MSS (was 10*MSS)
- MEM_SIZE: 12KB BK72XX / 16KB RTL,LN (was 32KB)
- Socket counts: dynamic from component registrations
- All derived pool sizes adjusted accordingly
Also splits socket consumer tracking into TCP/UDP, adds
get_socket_counts() API, and updates ESP32 to use it.
Closes https://github.com/esphome/esphome/issues/14095
Tracks heap usage per component during both construction and setup() phases.
Logs deltas inline as components are registered and set up, then prints a
sorted summary after setup() completes. Storage is freed after the summary.
This is a diagnostic tool - not intended for production use. It was used to
discover the logger's unused UART event queue allocation (#14168).
Reverts the frame header synchronization added in #14135 and #14136
in favor of a simpler fix: increasing MAX_LINE_LENGTH so that the
existing footer-based resynchronization can recover after losing sync.
Both components already check for frame footers at every byte position,
which naturally resyncs the parser. The problem was that the buffers
were sized exactly to fit the largest frame, so a desynced parser's
footer could land at the overflow boundary and get discarded. Increasing
the buffer by 4 bytes (footer size) ensures the footer always lands
inside the buffer.
- ld2450: 41 -> 45 (zone query response = 40 bytes + 1 null + 4 footer)
- ld2410: 46 -> 50 (engineering data frame = 45 bytes + 1 null + 4 footer)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
The batch UART read change in #13818 exposed a latent bug where the
UART parser could start accumulating bytes mid-frame after module
restart, causing an infinite cycle of "Max command length exceeded"
warnings that prevented initialization.
Add header validation for the first 4 bytes of each frame, ensuring
the parser only accumulates data starting from a valid DATA_FRAME_HEADER
(AA FF 03 00) or CMD_FRAME_HEADER (FD FC FB FA). Non-matching bytes are
discarded until a valid frame start is found.
Fixes#14131
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Change progmem_array codegen from `static const` to `static constexpr`.
This ensures the compiler evaluates the array at compile time with no
runtime initialization, and is the correct qualifier for constant data
known at compile time.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
