[esp32_ble_tracker] Fix false reboots when event loop is blocked - #10144
Conversation
|
To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file: external_components:
- source: github://pr#10144
components: [esp32_ble_tracker]
refresh: 1h(Added by the PR bot) |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a race condition in the ESP32 BLE tracker that was causing false reboots when the event loop was blocked. The issue occurred because the scan timeout was being monitored through the scheduler, which would fire immediately when the loop unblocked, before the BLE tracker could process pending scan completion events.
Key changes:
- Replaced scheduler-based timeout monitoring with a state machine approach in the loop() method
- Added a one-loop delay before rebooting to ensure all components can process pending events
- Moved timeout logic from external scheduler callbacks into the component's main loop
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| esp32_ble_tracker.h | Added state machine enum and variables for tracking scan timeout state |
| esp32_ble_tracker.cpp | Implemented new timeout monitoring logic in loop() method and updated scan start/stop methods |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #10144 +/- ##
=======================================
Coverage 60.21% 60.21%
=======================================
Files 51 51
Lines 10375 10375
Branches 1381 1381
=======================================
Hits 6247 6247
Misses 3772 3772
Partials 356 356 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Device uptime more than 24 hours. No reboots since OTA. Many Thanks ❤️ |
|
Thanks! |
What does this implement/fix?
This PR fixes a race condition in the ESP32 BLE tracker where the device would incorrectly reboot when the event loop was blocked.
Previously, the scan timeout was monitored using the scheduler's
set_timeout()mechanism. When the event loop was blocked (e.g., due to heavy processing or network delays), the scheduler would fire immediately upon unblocking, before the ESP32 BLE tracker'sloop()method could process any pending scan completion events. This caused false positive timeouts and unnecessary reboots.The fix moves the timeout monitoring from the scheduler into the ESP32 BLE tracker's
loop()method using a state machine. When a timeout is detected, it now waits one additional loop iteration before rebooting, ensuring all components (particularlyesp32_ble) have had a chance to process pending events.Types of changes
Related issue or feature (if applicable):
Pull request in esphome-docs with documentation (if applicable):
Test Environment
Example entry for
config.yaml:Checklist:
tests/folder).If user exposed functionality or configuration variables are added/changed: