Skip to content

fix(heltec-v3): powerOff() arms user button + LoRa-DIO1 wake mask#2595

Open
akkerkid wants to merge 1 commit into
meshcore-dev:mainfrom
akkerkid:fix/heltec-v3-hibernate-button-wake
Open

fix(heltec-v3): powerOff() arms user button + LoRa-DIO1 wake mask#2595
akkerkid wants to merge 1 commit into
meshcore-dev:mainfrom
akkerkid:fix/heltec-v3-hibernate-button-wake

Conversation

@akkerkid
Copy link
Copy Markdown

HeltecV3Board::powerOff() calls enterDeepSleep(0) which falls through to the default pin_wake_btn = -1. The wake mask thus arms only LoRa-DIO1 -- the user button is never armed despite typical long-hold-button-to-hibernate UX (the OLED prompt commonly says "Tap button to wake").

Discovery context: the identical bug shape on HeltecV4Board bit our downstream conduit firmware fork (akkerkid/meshomatic-conduit-firmware) in May 2026 and shipped to ~80 conduit units before we caught it. While porting our conduit feature work to V3 in May 2026 we found V3 carrying the same bug -- mirroring the V4 fix is one line.

Fix

variants/heltec_v3/HeltecV3Board.h:

void powerOff() override {
  enterDeepSleep(0, PIN_USER_BTN);
}

Pre-fix:

void powerOff() override {
  enterDeepSleep(0);  // falls through to pin_wake_btn = -1; only LoRa-DIO1 armed
}

Scope

  • Single-line change, no API change. enterDeepSleep's existing int pin_wake_btn = -1 default stays for any other caller that genuinely wants radio-only wake.
  • Doesn't touch any other Heltec board class. Sibling variants (V2, TrackerV2, T096, T190, E213, E290, RAK3112, ThinknodeM2/M5, StationG2, TDeck, etc.) may have the same shape but are out of scope for this PR -- happy to file follow-ups if it makes sense.
  • No compile breakage. PIN_USER_BTN is defined in variants/heltec_v3/platformio.ini via -D PIN_USER_BTN=0 build flag; the symbol is already in scope in HeltecV3Board.h. Verified locally with build.sh build-firmware Heltec_v3_repeater -- SUCCESS, 20.78s.

Happy to address review feedback. Filed with DCO sign-off.

HeltecV3Board::powerOff() called enterDeepSleep(0) with the default
pin_wake_btn = -1, so the wake mask armed only LoRa-DIO1. The user
button (PIN_USER_BTN) was never armed despite typical long-hold-button-
to-hibernate UX prompts expecting it to wake.

Mirrors the same fix landed for HeltecV4Board in May 2026 in the
downstream meshomatic-conduit-firmware fork
(akkerkid/meshomatic-conduit-firmware fix/hibernate-button-only-wake),
where this bug shipped to ~80 conduit units before discovery. V3 in
upstream carries the identical bug shape today.

One-line fix: pass PIN_USER_BTN explicitly. No API changes; the
default-arg signature stays. Affected use case: any board class user
that calls `powerOff()` expecting both LoRa packets AND the user
button to wake the device (the OLED prompt "Tap button to wake" reads
that way).

Signed-off-by: AkkerKid <akkerkid@meshomatic.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant