fix(ws_bridge): charge the TX budget by time actually blocked, not wall clock - #310
Merged
Merged
Conversation
…ll clock TX_LOOP_BUDGET_MS was measured from loop() start, but state-push callbacks can fire while loop() itself never runs — http_request's OTA install() defers flash() onto the scheduler, which blocks the whole Application::loop() call for the duration of the download while publishing update progress about once a second. The wall-clock budget read "exhausted" for that entire window, so every progress push landed in tx_queue_ with nothing left to drain it, and Home Assistant's update progress bar stopped moving. Track milliseconds actually spent inside send_text_() instead, and reset the accumulator after a real idle gap since the last send. Congested-link behavior (the ~2s worst-case single loop() bound) is unchanged since a fresh budget still only allows the same one or two blocking sends before the next call defers to the queue.
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
TX_LOOP_BUDGET_MSwas measured frommillis()atloop()entry, but entity state pushes can fire whileWsBridgeComponent::loop()never runs at all:http_request's OTAinstall()defersflash()onto the scheduler, which blocks the entireApplication::loop()call for the whole download while publishing update progress about once a second from inside that blocking call.tx_queue_with nothing left to drain it (the component that drains the queue is the very thing not running) — Home Assistant's update progress bar stopped moving after PR fix(ws_bridge): avoid WDT panics, RX poison, and incomplete HA sync #309.send_text_()(a new thin wrapper both send sites now go through), and reset the accumulator after a real idle gap (TX_BUDGET_IDLE_RESET_MS = 500) since the last send. Congested-link protection is unchanged — a freshly reset budget still only allows about the same one or two blocking sends before the next call defers to the queue, so the worst-case singleloop()blocking bound (~2s, well under the 5s task WDT) established in fix(ws_bridge): avoid WDT panics, RX poison, and incomplete HA sync #309 is unaffected.Test plan
python -m esphome compile tests/components/ws_bridge/test.esp32-idf.yaml— succeeds (includes theupdate: platform: ws_bridge/platform: http_requestentities exercising this code path).installon a real device via HA and confirm theupdateentity's progress percentage updates continuously instead of freezing after the first push.🤖 Generated with Claude Code