Bump the pioarduino ESP-IDF framework from v5.5.3 to v5.5.3.1 which
fixes the gatt_main.c compile error when GATTS is disabled. This allows
reverting the workaround that unconditionally enabled CONFIG_BT_GATTS_ENABLE.
Also update _format_framework_espidf_version to support dot-separated
sub-release versions (e.g., 5.5.3.1) in both the tag and asset filename.
Log a warning when a client connects with an API version older than
1.14. This alerts users that their client needs updating before the
backward-compatibility code for pre-1.14 clients is removed in 2026.7.0.
Same pattern as the decode side - the bit manipulation was
duplicated in the main loop and tail path.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
base64_find_char() safely handles any input including 0,
returning 0 via strchr fallback - no special contract needed.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fold the output copy loop into base64_decode_quad_ since both
call sites use the same truncation-checked copy logic, differing
only in count (3 vs i-1).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The base64 character-to-byte conversion and output copy loop were
duplicated in both the main decode loop and the tail/padding path.
Extract into a shared static helper to reduce flash usage (-64 bytes
on ESP32) and eliminate duplicated logic.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The base64 character-to-byte conversion was duplicated in both the
main decode loop and the tail/padding path. Extract into a shared
static helper to reduce flash usage (-64 bytes on ESP32).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When the scheduler lock is already held, atomic loads of the remove
flag don't need acquire ordering — the mutex provides all necessary
synchronization guarantees. Add is_item_removed_locked_() helper that
uses memory_order_relaxed and use it in all _locked_ call sites.
This eliminates redundant memw barriers on Xtensa, saving 12 bytes
in matches_item_locked_ (152 → 140 B) and reducing pipeline stalls
in the scheduler hot path.
Replace the std::chrono::steady_clock approach with the scheduler's
existing millis_64() rollover tracking. This avoids pulling in
gettimeofday_r, system_clock, and the ArduinoJson int64_t serializer
template, saving ~270 bytes of flash and 8 bytes of RAM on ESP8266.
Send uptime as uint32_t seconds (good for ~136 years) instead of
int64_t milliseconds.
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>
Add frame header validation to prevent the parser from getting stuck
in an overflow loop when it loses sync with the UART byte stream
(e.g. after module restart or UART noise). This is the same latent
bug fixed in ld2450 (PR #14135) and present in ld2420.
The fix validates the first 4 bytes of each frame match a known
header (DATA or CMD) before accumulating data. On header byte
mismatch, the buffer resets and checks if the mismatched byte starts
a new frame. Also adds a return after buffer overflow reset to
prevent immediately re-accumulating the overflowed byte.
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>
- Fix get_varint64_ifdef() to return unconditional guard when any 64-bit
varint field has no ifdef (None in ifdefs set)
- Wrap USE_API_VARINT64 define with #ifndef to avoid redefinition warnings
when esphome/core/defines.h also defines it (test/IDE builds)
- Clarify proto.h comment about uint32_t shift behavior at byte 4
- Add namespace to generated api_pb2_defines.h for linter compliance
USE_API_VARINT64 was only defined in api_pb2.h, but proto.cpp (where
decode() and parse_wide() live) includes proto.h directly. This caused:
1. parse_wide() not compiled in proto.cpp (guarded by #ifdef)
2. decode() used 32-bit-only parse(), returning {} for varints > 5 bytes
3. ODR violation: ProtoVarInt was 4 bytes in proto.cpp but 8 bytes in
api_pb2*.cpp translation units
For bluetooth_proxy, 48-bit BLE addresses encode as 7-byte varints.
The failed parse caused decode() to return early, leaving request_type
at its default value of 0 (BLUETOOTH_DEVICE_REQUEST_TYPE_CONNECT),
producing spurious "V1 connections removed" errors.
Fix: Generate api_pb2_defines.h with the USE_API_VARINT64 define and
include it from proto.h, ensuring all translation units see a consistent
ProtoVarInt layout.
Previously the BSD socket path read only one UDP packet per loop()
call. With multi-universe setups (e.g. 380 RGBW LEDs across 3
universes), this caused the light to re-render the entire strip
for each universe packet separately, resulting in visible tearing
and ~3x unnecessary RMT writes.
Now both socket backends drain all available packets before returning,
so multi-universe frames are applied atomically and the light only
writes once per frame. The duplicated packet processing logic is
consolidated into a shared loop with a platform-specific read_()
helper.
Tested on ESP32-IDF with 380 SK6812 RGBW LEDs (3 universes):
- Light total CPU dropped from 5820ms to 1108ms per 60s (~5x)
- Combined e131+light dropped from 6944ms to 4811ms per 60s
- Visible tearing eliminated
