mirror of
https://github.com/esphome/esphome.git
synced 2026-07-10 17:05:36 +00:00
J. Nick Koston
af8fd1d060
Addresses copilot review on #15636. 1. Fix cleanup_connection_() race with queued listener events. While an OTA session was active, a second incoming connection would fire esphome_socket_event_callback → esphome_wake_ota_component_any_context, which sets pending_enable_loop_ on the (still-active) OTA component. enable_pending_loops_() only scans the inactive section, so that flag goes invisible. When cleanup_connection_() then called disable_loop(), the component dropped to LOOP_DONE with a stale pending flag and nothing to re-trigger the scan — the queued client sat forever until some unrelated socket activity woke the main loop. Fix: don't call disable_loop() from cleanup_connection_(). loop() has the idempotent idle check at its top; one more dispatch after cleanup is cheap and guarantees we re-read server_->ready() and either accept the queued client or disable cleanly. 2. Tighten the multi-port error message. Merging is fine — the constraint is single-port. Reworded: "Only a single port is supported for 'ota' 'platform: esphome'. Got ports [...]. Consolidate onto a single port; configs sharing a port are merged automatically." 3. Comment drift: three call sites and the fast-select extern declaration still referred to enable_loop_soon_any_context() and implied the hook wakes the main loop. Updated to reflect the current mechanism (sets pending-enable flags only; callers have already woken the main loop). Also clarified that esphome_wake_ota_component_any_context fires on every RCVPLUS event across all monitored sockets, so false wakes are expected and OTA::loop() disables itself again when idle. 4. Added tests/component_tests/ota/test_esphome_ota.py covering ota_esphome_final_validate: single instance accepted, same-port configs merge, different-port configs rejected with cv.Invalid, non-esphome platforms unaffected.
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 |