mirror of
https://github.com/esphome/esphome.git
synced 2026-06-24 15:10:51 +00:00
5b728f19c3
A blocking operation that runs inside a deferred scheduler continuation
(e.g. after a delay in a script/automation) was reported as:
<null> took a long time for an operation (83 ms), max is 30 ms
Two problems:
* The DelayAction continuation carries no component (since #16129 dropped
Component inheritance), so the warning had nothing to name and printed
"<null>". Telling the user an anonymous delay action is blocking is not
useful; naming the component that hosts the automation is.
* The threshold was hardcoded to "30 ms" but the real default is 50 ms
(WARN_IF_BLOCKING_OVER_CS) and is adaptive per component.
DelayAction now records App.get_current_component() on the scheduler item,
so the warning names the component whose automation chain hit the delay
(falling back to "a scheduled task" when there is genuinely no current
component). This propagates across chained delays because the scheduler
restores the item's component as the current component before each callback.
For SELF_POINTER items the stored component is log-attribution only: the
key (the caller's `this`) is globally unique, so matches_item_locked_
ignores the component when matching and the is_failed() skip is bypassed.
This keeps delay cancellation (restart/parallel/stop) and always-fire
semantics unchanged.
The warning now reports the real (pre-ratchet) threshold instead of the
stale "30 ms".
Adds an integration test reproducing the deferred-block path via an
interval + delay + busy lambda and asserting the warning names a component
and reports "max is 50 ms".
Tests for ESPHome
This directory contains some tests for ESPHome.
At the moment, all the tests only work by simply executing
esphome over some YAML files that are made to test
whether the yaml gets converted to the proper C++ code.
Of course this is all just very high-level and things like unit tests would be much better. So if you have time and know how to set up a unit testing framework for python, please do give it a try.
When adding entries in test_.yaml files we usually need only
one file updated, unless conflicting code is generated for
different configurations, e.g. wifi and ethernet cannot
be tested on the same device.
Current test_.yaml file contents.
| Test name | Platform | Network | BLE |
|---|---|---|---|
| test1.yaml | ESP32 | wifi | None |
| test2.yaml | ESP32 | ethernet | esp32_ble_tracker |
| test3.yaml | ESP8266 | wifi | N/A |
| test4.yaml | ESP32 | ethernet | None |
| test5.yaml | ESP32 | wifi | ble_server |
| test6.yaml | RP2040 | wifi | N/A |
| test7.yaml | ESP32-C3 | wifi | N/A |
| test8.yaml | ESP32-S3 | wifi | None |
| test10.yaml | ESP32 | wifi | None |