Fix BLE deep-sleep restore using minutes math instead of hours#69
Fix BLE deep-sleep restore using minutes math instead of hours#69bharvey88 wants to merge 1 commit into
Conversation
TEMP-1B_BLE.yaml packages Battery.yaml, whose "Sleep Duration" number is in hours (unit_of_measurement "h", initial 12, deep_sleep default 12h). Its on_boot restore lambda multiplied the stored value by 60 * 1000 (minutes to ms), so after every reboot the device slept 60x too short, waking roughly every 12 minutes instead of 12 hours and draining the battery. Change the expression to * 60 * 60 * 1000 (hours to ms), matching the correct math already used in TEMP-1B.yaml, TEMP-1B_Minimal.yaml, and Battery.yaml's own on_value handler. The non-battery variants keep * 60 * 1000 because NonBattery.yaml's Sleep Duration is in minutes. Sibling of the same bug found in AIR-1 during the 26.7.23.1 release (ApolloAutomation/AIR-1#119). Bumps version to 26.7.24.1. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Version: 26.7.24.1
What does this implement/fix?
TEMP-1B_BLE.yamlpackagesBattery.yaml, whose "Sleep Duration" number is in hours (unit_of_measurement: "h",initial_value: 12, and thedeep_sleepdefault is12h). Theon_bootdeep-sleep restore lambda multiplied the stored value by60 * 1000(minutes to ms) instead of60 * 60 * 1000(hours to ms).The result: after every reboot the device restored a sleep duration 60x too short, waking roughly every 12 minutes instead of every 12 hours and draining the battery.
The fix changes the expression to
* 60 * 60 * 1000, matching the correct math already used inTEMP-1B.yaml,TEMP-1B_Minimal.yaml, andBattery.yaml's ownon_valuehandler. The non-battery variants (TEMP-1.yaml,TEMP-1_BLE.yaml,TEMP-1_Minimal.yaml) correctly keep* 60 * 1000becauseNonBattery.yaml's Sleep Duration is in minutes.TEMP-1B_BLE_R2.yamlincludesTEMP-1B_BLE.yaml, so it inherits the fix.This is a sibling of the same hours-vs-minutes bug found in AIR-1 during the 26.7.23.1 release (ApolloAutomation/AIR-1#119).
Validated with
esphome configon TEMP-1B_BLE.yaml, TEMP-1B.yaml, and TEMP-1B_BLE_R2.yaml: all report "Configuration is valid!".Types of changes
Checklist / Checklijst:
If user-visible functionality or configuration variables are added/modified:
🤖 Generated with Claude Code