Read the live API client count for the RGB status LED - #80
Merged
Merged
Conversation
The connected color latched a boolean that any one of the API server's client slots could clear, so a second client disconnecting left the LED white while Home Assistant was still connected and reporting the device online. The api.connected condition reads the live connection count instead. Upstream fires the disconnect trigger after removing the client, so the condition sees the true state from inside it.
There was a problem hiding this comment.
Pull request overview
Fixes incorrect RGB status LED behavior when multiple API clients are connected by switching from a latched api_ok global to ESPHome’s live api.connected condition, preventing the LED from falsely turning white when any one client disconnects.
Changes:
- Remove the
api_okglobal and re-drive the LED status script based onapi.connected. - Keep API connect/disconnect triggers solely to re-run the LED evaluation script.
- Document the multi-client API caveat and the “read live, don’t latch” rule in
OPERATIONS.md.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| templates/rgb-led-status.yaml | Replace latched API state with live api.connected and keep triggers to re-evaluate LED status. |
| OPERATIONS.md | Add operational guidance explaining why API connection state must be read live and link to the connection-cap section. |
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
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.
The status LED on a deployed proxy sat white while Home Assistant held an unbroken API connection and every entity was live.
The connected color was driven by an
api_okglobal, set inon_client_connectedand cleared inon_client_disconnected. The API server acceptsmax_connectionsclients, 5 by default, so any one of them disconnecting cleared the flag for all of them. Nothing re-evaluated while Home Assistant stayed connected, so the LED latched white until some new client happened to connect.The
api.connectedcondition readsAPIServer::is_connected(), the live connection count, so it cannot be wrong about a client that is still there. Upstream fires the disconnect trigger after removing the client, so the condition reads the true state from inside it. The two triggers stay, but only to re-run the script.Verification
esphome configpasses for every consumer of the template: both Bluetooth proxies, the HVAC compressor sensor, and the eighttest/devices whose board templates include it.The fix is flashed to the office proxy. With one log client attached alongside Home Assistant, a second client was connected and then disconnected. The disconnect fires the trigger and re-drives the LED green,
0% / 100% / 10%, because two clients remain. Before the change the same sequence set it white,70% / 70% / 70%.