Fix 49.7-day millis() rollover zeroing day/month plots - #1229
Merged
Conversation
millis() (32-bit) was compared against getLastUpdateMillis() (64-bit, fed from millis64()). Once uptime passes 2^32 ms, the subtraction underflows and the "no meter data for 30 minutes" condition becomes permanently true, so handleClear() wipes the data storage with a null update at the top of every hour and blocks the real update behind isHappy(). Use millis64() on the left-hand side of all comparisons against getLastUpdateMillis(); same fix for the cloud connector HAN status, which reported error state after rollover. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The vite 8 / vite-plugin-svelte 7 bumps (#1209) require Node >= 20.19; build.yml already uses 22.x but pr-build-env.yml still pinned 19.x, breaking the UI build step on every PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🔧 PR Build ArtifactsVersion: All environments built successfully. Download the zip files:
|
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.
Fixes #1228
Problem
After 49.7 days of uptime,
millis()(32-bit) wraps whileAmsData::getLastUpdateMillis()(fed from 64-bitmillis64()) keeps growing past 2^32. In the comparisonthe subtraction promotes to
uint64_tand underflows to an enormous value, so the "no meter data for 30 minutes" condition becomes permanently true. From then on,handleClear()fires at minute 0 of every hour, writes a null update that zeroes the hour and stamps the storage as happy, and the real meter update is skipped behindisHappy(). The day plot flatlines to zeros within 24 hours, the month plot loses one day per midnight (or all 31 at once if a real telegram wins the boundary race and hits the "initializing" branch).Fix
Use
millis64()on the left-hand side of every comparison againstgetLastUpdateMillis():src/AmsToMqttBridge.cpp— the hourly-clear gate (the actual data-loss bug) and the HAN-port read fallback (benign, but same underflow).src/cloud/CloudConnector.cpp— HAN status calculation; after rollover it permanently reported status 3 (error) to the cloud.AmsWebServer.cppanderrorBlink()already usemillis64()for the equivalent checks and needed no change.Verification
pio run -e esp32devbuilds successfully (cloud connector included in ESP32 builds).getLastUpdateMillis()call sites.🤖 Generated with Claude Code