mirror of
https://github.com/esphome/esphome.git
synced 2026-08-31 18:16:03 +00:00
J. Nick Koston
a0ac226e6c
Restructures Application::loop() into two independent phases to stop the scheduler from silently pulling the component loop cadence forward. Before: Application::loop() bounded its sleep by min(loop_interval_ - elapsed, next_schedule_in()) with a delay_time/2 floor. Any scheduler item due sooner than loop_interval_/2 dragged the whole component phase with it. On a typical ESP32 config with default loop_interval_=16ms, combined scheduler activity from api / esp32_ble / esp32_ble_tracker / debug was keeping every component's loop() running at ~128 Hz instead of the documented ~62 Hz. This has become more visible recently as more components convert to PollingComponent (which uses set_interval internally) and more in-tree code uses set_interval / set_timeout directly. Adding or removing any scheduled item silently changed every other component's loop cadence. App.set_loop_interval() for power savings was also silently defeated. After: - Phase A (every tick): drain wake notifications, run scheduler.call(), feed WDT - Phase B (gated by loop_interval_ or HighFrequencyLoopRequester): iterate registered components and update last_loop_ Sleep = min(time-until-next-component-phase, next_schedule_in()). When a scheduler event wakes us early, Phase A services it and the component phase stays gated independently. loop_interval_ is now a true minimum interval between component phases. The delay_time/2 floor is removed. Any legitimate need to wake faster than loop_interval_ has proper mechanisms: - HighFrequencyLoopRequester for sustained fast-loop needs - Application::wake_loop_threadsafe() from any context (new in 2026.4.0) for one-shot wake-on-event Also guards against set_interval(0) misuse — it asks the main loop to spin forever, which was never the intended API. Warns at creation time pointing authors at HighFrequencyLoopRequester. set_timeout(0)/defer() is unaffected; zero-delay one-shots remain legitimate. Runtime stats: process_pending_stats is now called on every tick (not just when the component phase runs) so log_interval_ isn't quantized to the component-phase cadence. Added an inline fast-path gate in runtime_stats.h that early-outs unless now >= next_log_time_, keeping Application::loop() slim; the log_stats_ work stays out-of-line. Ordering constraints preserved: - defer() callbacks still FIFO before components same-tick (Phase A runs before Phase B) - Scheduled items still execute before components when both due - Scheduled callbacks still run on main thread only - loop_component_start_time_ is still set fresh at each component's loop - WDT is still fed at least once per tick
74 lines
2.9 KiB
Python
74 lines
2.9 KiB
Python
"""Test that loop_interval_ no longer clamps scheduler cadence.
|
|
|
|
Regression test for the decoupling of Application::loop() component-phase
|
|
cadence from scheduler wake timing.
|
|
|
|
Setup:
|
|
- App.set_loop_interval(500) — raised for power-savings style cadence
|
|
- Scheduler interval at 50ms — should fire at 50ms regardless of loop_interval_
|
|
- Component loop (LoopTestComponent) — should run at 500ms cadence
|
|
|
|
Before the decoupling fix the old `std::max(next_schedule, delay_time / 2)`
|
|
floor clamped the sleep to ~250ms, so the 50ms scheduler only fired ~8 times
|
|
per 2s (vs the ~40 expected). After the fix the scheduler fires close to its
|
|
requested cadence while the component phase stays gated at loop_interval_.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
import asyncio
|
|
import re
|
|
|
|
import pytest
|
|
|
|
from .types import APIClientConnectedFactory, RunCompiledFunction
|
|
|
|
|
|
@pytest.mark.asyncio
|
|
async def test_loop_interval_decoupling(
|
|
yaml_config: str,
|
|
run_compiled: RunCompiledFunction,
|
|
api_client_connected: APIClientConnectedFactory,
|
|
) -> None:
|
|
"""Raised loop_interval_ must not clamp scheduler item cadence."""
|
|
loop = asyncio.get_running_loop()
|
|
measurement_done: asyncio.Future[tuple[int, int]] = loop.create_future()
|
|
|
|
def on_log_line(line: str) -> None:
|
|
match = re.search(r"MEASUREMENT_DONE loop_delta=(\d+) sched_delta=(\d+)", line)
|
|
if match and not measurement_done.done():
|
|
measurement_done.set_result((int(match.group(1)), int(match.group(2))))
|
|
|
|
async with (
|
|
run_compiled(yaml_config, line_callback=on_log_line),
|
|
api_client_connected() as client,
|
|
):
|
|
device_info = await client.device_info()
|
|
assert device_info is not None
|
|
assert device_info.name == "loop-interval-decouple"
|
|
|
|
try:
|
|
loop_delta, sched_delta = await asyncio.wait_for(
|
|
measurement_done, timeout=10.0
|
|
)
|
|
except TimeoutError:
|
|
pytest.fail("MEASUREMENT_DONE marker never appeared")
|
|
|
|
# Observation window = 2s, loop_interval_ = 500ms.
|
|
# Component phase should fire ~4 times in 2s. The upper bound must be
|
|
# less than 8: the pre-decoupling behavior clamped to ~250ms cadence
|
|
# giving ~8 loops/2s, so allowing 8 would let the old behavior pass.
|
|
assert 2 <= loop_delta <= 6, (
|
|
f"Component loop should fire ~4 times in 2s at loop_interval=500ms, "
|
|
f"got {loop_delta}"
|
|
)
|
|
|
|
# Scheduler interval = 50ms → ~40 fires in 2s. Before the decoupling
|
|
# fix this clamped to ~8 fires. Assert >= 20 to catch the old clamped
|
|
# behavior with comfortable jitter headroom for slow CI hosts.
|
|
assert sched_delta >= 20, (
|
|
f"50ms scheduler interval should fire ~40 times in 2s but only "
|
|
f"fired {sched_delta}. This indicates loop_interval_ is still "
|
|
f"clamping scheduler cadence."
|
|
)
|