The scheduler was already managing SchedulerItem lifecycle explicitly
through its object pool (recycle_item_main_loop_ / get_item_from_pool_locked_).
The unique_ptr wrapper added overhead (11 destructor call sites on the hot path)
without providing safety — if a lifecycle path was missed, the unique_ptr would
silently delete the item and cause needless heap allocations instead of pool reuse.
Replace unique_ptr<SchedulerItem, SchedulerItemDeleter> with raw SchedulerItem*
throughout. Every item is now explicitly recycled to the pool or deleted via
delete_item_(). This eliminates all 11 unique_ptr destructor calls from the hot
path and saves ~256 bytes of firmware.
Add debug leak detection under ESPHOME_DEBUG_SCHEDULER: a live-item counter
verified at the end of every call() cycle asserts that all allocated items are
accounted for in items_, to_add_, defer_queue_, or the pool. This turns silent
heap churn from missed lifecycle management into an immediate assert failure
caught by integration tests.
Also moves the retry-cancelled check before item allocation in set_timer_common_
to avoid needless alloc+delete on the cold retry path, and fixes a thread-safety
issue where recycle_item_main_loop_ (main-loop-only) was called from
set_timer_common_ which can run on non-main-loop threads.
Enable debug_scheduler: true in all 18 scheduler integration test fixtures.
Add inject_to_rx_buffer_delayed() to uart_mock which stages bytes
that aren't visible to available() until the delay elapses. This
simulates USB packet delivery latency.
The test uses a 40ms delay which is:
- Greater than the old ~2ms timeout (fails without fix)
- Less than the new 50ms fallback timeout (passes with fix)
- Add test fixture simulating USB UART (no rx_full_threshold set)
with a 20ms gap between response chunks
- Make rx_full_threshold optional in uart_mock
- Extract MODBUS_BITS_PER_CHAR and MS_PER_SEC constexprs
The Python tests were testing a Python reimplementation, not the
actual C++ code. Replace with an integration test that exercises
the real micros_to_millis() on the host platform, covering boundary
values, carry paths, and mod-8 shift edge cases (25 checks).
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
Device IDs are FNV hashes (uint32) that frequently exceed 2^28,
requiring 5 varint bytes. This test verifies the firmware correctly
decodes these values in incoming SwitchCommandRequest messages and
encodes them in state responses.
J. Nick Koston