Repository navigation
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
So the plan's saving compares honestly and the plan view shows it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e7d9d59329
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let worth = Self.saving(wire?["plan"]) | ||
| if worth != saving { saving = worth } |
There was a problem hiding this comment.
Honor pending metadata before publishing savings
When /api/mpc/plan returns meta.replanning or meta.outdated, this extracts and publishes the previous plan's saving anyway. After a mode or preference change, plan.get can advance first and stop the follow loop while this request returned the old plan, leaving the old saving displayed beneath the new plan until the next quarter-hour refresh. LoadpointsModel.load already treats these same flags as making plan-derived values unavailable; suppress the saving while either flag is set as well.
Useful? React with 👍 / 👎.
| @@ -144,6 +147,7 @@ extension SimulatedHouse { | |||
| var b = decide(price: price, mean: mean, pv: pv, base: base, ev: ev, soc: soc, mode: modeKey) | |||
| if b > 0, soc >= 0.98 { b = 0 } | |||
| if b < 0, soc <= Self.minSoc { b = 0 } | |||
There was a problem hiding this comment.
Rebalance both sides of the demo's terminal SOC
This lower bound does not ensure that the demo plan ends near its starting level: it blocks discharge below the floor, but later cheap-price or solar charging can still leave the battery far above the start. At the canonical DemoRig start (12 Oct at noon in Stockholm, SOC 0.62), the 24-hour plan finishes around 0.91, so PlanSaving.savedMinor rejects it for exceeding the 5% slack and the demo still shows no saving. The terminal handling needs to constrain or rebalance upward drift too.
Useful? React with 👍 / 👎.
…nst guessed, and the planning style as a scale (#58, #59, #60, #61) One squash for four stacked PRs, changes 2–5 of the plan pass Fredrik approved on 14 Oct 2026 (change 1 was #57): - #58: the planned battery level in the scrub, a dashed level line in the lanes and the dial's story (socPermille from srcfl/ftw#1630). - #59: one honest saving under the dial, against no battery, only when the plan ends near its start level. - #60: known against guessed: the dashed sun, hatched unpriced quarters, the style named when it is not balanced. - #61: the two levers at the foot of the plan view, the planning style as a detented scale (Fredrik's note 21), one command on release with the receipt, and only moved quarters cross-faded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plan pass, change 3 of 5: one honest number for what the plan saves. Stacked on change 2 (#58).
What changes
Under the dial, between the cheapest hours and the planned line, one mono line:
It is the box's own planner's reckoning: the plan's cost for the hours it covers against the same hours with no battery. "Till" names where those hours end, so the number has a span.
When it says nothing
The line is left out, rather than shown with a caveat, when:
It never compares against self-consumption, whose baseline drains the battery and so reads cheaper than it is. Nothing is said on Now.
Where it comes from
/api/mpc/plan, which the plan view reads already for the sky:total_cost_ore,baselines.no_battery_ore,initial_soc, and the last action'ssocand end. No Core change.The demo's plan used to end at 39 % from 62 %, so the rule hid its saving. Its day now stops giving power in the last eight hours once the battery is 2 points under where it started, so the demo shows the line and the rule still holds. That is a separate commit, e7d9d59.
Evidence
swift test: FTWShared 220 and FTWKit 368 tests green. New:PlanSavingTests(the home box's 14 Oct plan says 28 kr; a plan that ends emptier says nothing, with the 5-point edge on both sides; no saving to speak of says nothing) andtheSavingComesFromThePlannersDocument.NowFitsTests11 of 11,PlanStripTests3 of 3,PlanDialTests3 of 3.Pictures
The plan view dark and light, and at the largest text scrolled to the line, which wraps and holds its place.
🤖 Generated with Claude Code