Skip to content

Fix LED state handling in StatusLEDModule to clarify power state condition#10205

Open
thebentern wants to merge 2 commits into
masterfrom
fix-led-status-confusion
Open

Fix LED state handling in StatusLEDModule to clarify power state condition#10205
thebentern wants to merge 2 commits into
masterfrom
fix-led-status-confusion

Conversation

@thebentern
Copy link
Copy Markdown
Contributor

Users have been confused with the new solid LED behavior for fully charged devices as it looks like things are "stuck" where prior to this, they would use the periodic blinking behavior.
Closes #10170
Closes #9912

Original regression in #9512

@github-actions github-actions Bot added needs-review Needs human review bugfix Pull request that fixes bugs labels Apr 19, 2026
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adjusts StatusLEDModule LED behavior to avoid a “stuck solid” power LED when devices are fully charged, aligning user-visible behavior with expected charging/power-state indications.

Changes:

  • Removes the special-case “solid ON” LED behavior for the charged power state.
  • Updates the heartbeat/blink condition so the charged state follows the non-charging blink pattern.
  • Fixes PMU charging LED mode selection to be based on LED_STATE_ON rather than boolean truthiness.
Comments suppressed due to low confidence (1)

src/modules/StatusLEDModule.cpp:101

  • With the updated condition (power_state != charging), the 1ms/999ms heartbeat branch can now run in the charged state too. When config.device.led_heartbeat_disabled is true, the later override forces CHARGE_LED_state back to OFF every loop, which causes this code to repeatedly pick the ON-path and return a ~1ms interval (tight loop), wasting CPU/power. Consider short-circuiting the heartbeat block when led_heartbeat_disabled is set (or ensuring my_interval is restored to a sane value when the override forces the LED off).
    if (power_state != charging && !doing_fast_blink) {
        if (CHARGE_LED_state == LED_STATE_ON) {
            CHARGE_LED_state = LED_STATE_OFF;
            my_interval = 999;
        } else {

@jp-bennett
Copy link
Copy Markdown
Collaborator

jp-bennett commented Apr 19, 2026

I actually really like the behavior to indicate fully charged via the LED. Would like to find a way to keep it in some form. Probably also need to first figure out of there's a bug.

Edit: maybe use the solid LED for charged only if we have a plugged-in detect mechanism. It's probably pretty non-ideal on a device that can't detect when power is unplugged, staying lit until the battery drops below 100%

@jp-bennett
Copy link
Copy Markdown
Collaborator

The t-beam is broken because #define LED_STATE_ON 0 // State when LED is lit
Fix incoming.

@Jckf
Copy link
Copy Markdown

Jckf commented May 19, 2026

Adding my vote for this. Many nodes are permanently USB powered, so I consider the new behavior broken.

@george-black
Copy link
Copy Markdown

I have a Heltec v4 that is constantly plugged into USB power. The white LED stays on solid in recent versions (past 2.7.19, i think) -- and I miss the blink. This node will never have a battery and never be charging, so the steady-on state of the LED loses the heartbeat feature for me.

So I support this PR! 👍

@jp-bennett
Copy link
Copy Markdown
Collaborator

Another possible solution, only do the solid LED when we know we have a battery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Pull request that fixes bugs needs-review Needs human review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants