feat(octopus): gate IOG dispatch-slot trust on a real car_charging_now sensor (#4482, #4516)

[chalfontchubby]

(Written by Claude, working with @chalfontchubby.)

Supersedes #4885, which was closed on two objections. Both are addressed here — the first with measurements rather than argument.

This is a defensive change. It trades away some upside to remove a downside: distrusting a slot that would have materialised costs a cheap window you could have used, but trusting one that doesn't costs real money — either an irreversible decision (an early force-export) made around a window that vanishes, or an import billed at full peak. Anyone who prefers the upside stays on the default, which trusts everything exactly as today.

The objections, answered

"It takes 5-10 minutes based on a sensor to figure out if the car is really charging."

Measured on a live system (Sigenergy + Hypervolt + VW ID.3), from the Predbat log:

Stage	Measured
car_charging_now changes → Predbat writes to the inverter	17-40s
Register write → inverter physically stops discharging	36-65s
Total, from a locally-reported charging state	under 2 minutes

The 5-minute figure assumes the scheduled run_time_loop cycle. It doesn't apply: a watched entity sets update_pending, and update_time_loop polls that every 15 seconds and replans out of cycle. I had this wrong myself until I measured it.

A trigger routed via the Octopus app (a boost) adds ~1:35-1:56 of cloud round-trip, but that's upstream of Predbat either way.

"It might not detect it, or falsely detect say a kettle as the car."

Agreed — so started now requires a real car_charging_now sensor for that car: a charger/car-reported signal, never inferred from a load signature, so there's no kettle ambiguity. Without one it falls back to none, decided per car, with a startup warning.

What it does

Two independent gates a future out-of-window slot must both clear. They answer different questions and can be used together or separately:

• switch.predbat_octopus_intelligent_limit_future_slots (default Off) — does the car still need this slot? Requires octopus_intelligent_consider_full; warns at startup if enabled without it.

• select.predbat_trust_future_dynamic_iog_slots (default planned) — will Octopus honour it?

  • planned — trust every dynamic slot. Today's behaviour.
  • started — trust a slot once car_charging_now corroborates it (a "trusted streak" - see Notes for review below). Falls back to none for a car with no such sensor.
  • none — trust nothing outside the fixed window.

  There's deliberately no separate completed level waiting on Octopus's own metered record alone: that record only appears once a slot has already ended (and can lag by up to an hour), so it could never arrive in time to influence a planning decision about the slot it confirms. started still accepts it as one form of evidence where available - it's just not a selectable level on its own.

The fixed 23:30-05:30 window is never gated — it's cheap by tariff structure, not by dispatch.

Both defaults preserve current behaviour. A fresh install or upgrade sees no plan change until someone opts in, per your condition last round.

On Predbat.com the gateway auto-wires car_charging_now from the charger's own OCPP session state, so started works there too. Gateway users with gateway_evc_control don't get that sensor (it's omitted to avoid a feedback loop) and fall back to none for that car — but if Predbat is driving the charger then Octopus isn't dispatching it, so there are no dynamic slots to gate anyway.

Related issues

Several open issues describe this same exposure from different angles. Flagging them together since some may be answerable by this, and others are explicitly out of scope:

• IOG future planned dispatches treated as cheap home rate before EV charging earns the slot #4516 — future planned dispatches treated as cheap before the EV has earned it. This is what trust_future_dynamic_iog_slots answers directly.
• Use actual EV SoC to limit provisional Intelligent Octopus slots used in the Predbat plan #4482 — use real EV SoC to limit provisional slots. Mitigated, not implemented — see below.
• Best way to limit Octopus IOG? #5065 — "Best way to limit Octopus IOG?", with real billing evidence of peak-rate charges in slots the car didn't use. started is the intended answer; worth the reporter trying it.
• IOG slots not ignored with car unplugged #5012 — IOG slots not ignored with car unplugged. Related but distinct: that's about slots already granted when the car is unplugged, which ignore_unplugged covers at fetch time. none/started would also stop the house battery relying on them, so it may help in practice.
• IOG Dispatch Trust: CT Visibility Detection + Load-Confirmed Charging #4917 — proposes CT-visibility detection plus load-confirmed charging as a richer version of started, for installs with no car_charging_now. Note that issue assumes trust_future_dynamic_iog_slots already exists on main — it didn't until now, so its premise is finally true. The load-confirmed half is deliberately not done here: inferring charging from load is exactly the kettle risk, which is why this requires a real sensor instead.
• Monitor both IOG loss modes: withdrawn slots causing later full-rate import, and imports billed at peak #5080 — proposes measuring both loss modes (withdrawn slot causing later full-rate import; import billed at peak) via Octopus's own measurements API. Not built. That would turn the cost case here from anecdote into a number, and would validate whichever trust level a user picks.

On #4482

limit_future_slots addresses #4482's failure mode — the house battery no longer defers charging into slots outside what the car still needs — but it is not the implementation that issue asks for. It reuses the car_charging_slots cap rather than computing remaining EV energy from car_charging_soc/battery_size/limit directly, and so depends on consider_full, which #4482 explicitly notes isn't sufficient on its own. So this mitigates it rather than closing it, and I've left the issue open for the reporter to judge.

The structure is a single predicate per slot, so the stronger version builds on this rather than replacing it — #4482's own SoC calculation would swap out how the expected-slot set is derived. Time-bounded trust ("trust a slot starting within the next hour or so") would be another clause on the same decision. Out of scope here.

Notes for review

• car_charging_now confirms a whole 30-minute settlement slot as a "trusted streak", not a single reading. get_arg() re-samples live state on each replan rather than consuming the edge that woke it, so a short pulse can be missed entirely rather than merely seen late. A streak rolls forward until an explicit "not charging" reading, which also tolerates a charger toggling at a settlement boundary — observed live as a readiness sensor flipping Charging→Ready→Charging within two minutes, negotiation noise rather than a real stop. A start guard stops a reading in a slot's closing minutes confirming the next slot; a 4-slot cap bounds how far a streak rolls without fresh evidence, so a missed negative edge degrades to untrusted rather than silently behaving as planned. Both constants are judgement calls, not measured — happy to tune.
• Rejecting a slot actively restores rate_max_base rather than just declining to discount it, because on a real Intelligent tariff fetch_octopus_rates() can deliver the discounted rate straight from the feed. exclude_dynamic_io_slots() handles that feed-side case, consuming the same trust decisions so the two can't disagree. Both touch only future minutes — an elapsed minute records what the tariff actually charged, and rewriting it would inflate today_cost() without changing a plan that never looks behind minutes_now.
• feat(octopus): log a diagnostic IOG dispatch timeline (#4516 Stage 1) #4948 has since landed the dispatch-timeline diagnostic fix(octopus): don't rely on unconfirmed or unneeded IOG dispatch slots (#4482, #4516) #4885 also carried, so only the trust logic is new.

Closes #4516. Addresses #4482.

Tests: 26 new/reworked cases across test_rate_add_io_slots.py, test_fetch_config_options.py and a new test_car_charging_now_confirmed_slots.py. Full quick suite and pre-commit green.

[Copilot]

🟡 Changes recommended

Two critical and three moderate findings remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds opt-in safeguards for trusting future Octopus Intelligent dispatch slots, including charging-sensor confirmation and configurable need/trust gates.

Changes:

• Adds configurable dynamic-slot trust and EV-need gates.
• Tracks per-car car_charging_now confirmation streaks.
• Updates rate handling, configuration, documentation, runtime state, and tests.

File summaries

File	Reviewed changes and findings
docs/car-charging.md	Documents the new controls. Nit (3 votes): clarify that none keeps completed dispatches at the normal rate.
apps/predbat/unit_test.py	Registers the new test suite. No final comments.
apps/predbat/tests/test_rate_add_io_slots.py	Adds rate-gating tests. Nit (1 vote): add coverage for the feed-side exclusion path.
apps/predbat/tests/test_fetch_config_options.py	Adds configuration tests. No final comments.
apps/predbat/tests/test_car_charging_now_confirmed_slots.py	Tests charging confirmation streaks. Moderate (1 vote): isolate or fully restore shared fixture state.
apps/predbat/predbat.py	Initializes new runtime state. No final comments.
apps/predbat/octopus.py	Implements trust-gated rate handling. Critical (1 vote): untrusted overlaps can block later trusted slots. Moderate (1 vote): cap-rejected slots can lose valid feed discounts. Nit (1 vote): feed-side exclusion lacks regression coverage.
apps/predbat/fetch.py	Adds sensor detection and configuration handling. Critical (1 vote): confirmation changes may not update the change signature or force replanning. Moderate (1 vote): zero-car configurations can record a spurious error.
apps/predbat/const.py	Defines confirmation timing constants. No final comments.
apps/predbat/config.py	Adds expert configuration options. No final comments.

Review details

Suppressed comments (5)

apps/predbat/fetch.py:2539

• The raw-config check treats any scalar value as a configured sensor, including the valid fixed sensor_type: string|boolean values such as car_charging_now: "yes". With started, that constant produces trusted streaks without any charger/car sensor and can make provisional slots cheap; require a non-empty entity-id string (and the same check for list entries) before returning True.

        configured = self.args.get("car_charging_now", None)
        if configured is None:
            return False
        if not isinstance(configured, list):
            # A scalar (un-indexed) value applies to every car, not just car 0: resolve_arg() only
            # indexes when the configured value is itself a list (userinterface.py - "isinstance(
            # value, list) and index is not None"), so a single sensor resolves identically for
            # every car_n. Returning car_n == 0 here would wrongly degrade car 1+ to "completed" on
            # a single-sensor multi-car install whose sensor does in fact cover them.
            return True
        return car_n < len(configured) and configured[car_n] not in (None, "")

apps/predbat/fetch.py:3262

• num_cars explicitly supports zero (config.py:2684), but this loop forces a fictitious car 0 and records had_errors=True whenever a car-less install selects started. Since rate_add_io_slots() never processes any car when num_cars == 0, this creates a spurious error on an otherwise valid configuration; iterate only over range(self.num_cars).

            for car_n in range(max(self.num_cars, 1)):
                if not self.has_car_charging_now_sensor(car_n):

apps/predbat/octopus.py:3574

• This strips the feed-side discount from a future slot rejected only because octopus_slot_max was already reached. rate_add_io_slots() intentionally does not add cap-rejected minutes to trusted_dynamic_minutes when needed and trusted are both true (lines 3476-3517), so this loop cannot distinguish that case from an untrusted/withdrawn slot and restores rate_max_base anyway. That contradicts the documented cap-only exemption and makes the stricter trust modes overrule a genuine dispatch solely because Predbat's local budget was full; preserve cap-only minutes separately (or otherwise carry that reason through before stripping feed adjustments).

        for minute in list(self.io_adjusted.keys()):
            if minute < self.minutes_now:
                continue
            if self.io_adjusted[minute] and not self.minute_in_iog_fixed_window(minute) and minute not in self.trusted_dynamic_minutes:
                rates[minute] = self.rate_max_base

apps/predbat/octopus.py:3542

• The new feed-side exclusion path is not exercised by the added tests: test_rate_add_io_slots.py calls rate_add_io_slots() directly and manually sets io_adjusted, but no test calls exclude_dynamic_io_slots() or the full fetch pipeline. This leaves the safety-critical case where a future io_adjusted minute is restored and its marker cleared, while past, fixed-window, and trusted minutes remain untouched, unverified. Add a focused regression test.

    def exclude_dynamic_io_slots(self, rates):

apps/predbat/tests/test_car_charging_now_confirmed_slots.py:317

• This test restores only a few fields, but each get_car_charging_planned() call overwrites the shared fixture's car_charging_planned, plan arrays, battery size/limit/rate, charging slots, exclusivity, and related state. The final call rebuilds those values from old_args rather than restoring values set by the preceding test; unit_test.py reuses one PredBat instance for the registry, so later tests can inherit this mutation. Snapshot and restore all mutated fields or use an isolated fixture.

    my_predbat.get_car_charging_planned()

• Files reviewed: 10/10 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[springfall2008]

completed — require Octopus's own metered record.

Not sure this makes sense as completed is strictly after the slot finishes?

[chalfontchubby]

(Written by Claude, working with @chalfontchubby.)

You're right, and it's worse than a wording problem - completed couldn't do anything useful. The record only appears after the slot has ended, planning never looks behind minutes_now, so the trust arrived too late to affect any decision about the slot it confirmed. #4917 measured that record lagging a slot's end by 0-60 minutes as well, since Octopus batch-refreshes it rather than updating live. For planning purposes it was none with a misleading name.

Dropped it. The ladder is now:

• none - trust no daytime dispatch
• started - trust a slot car_charging_now corroborates, or one Octopus has already recorded as completed
• planned - trust everything (default, unchanged)

started still accepts the completed record where it exists - it's strictly stronger evidence than a live sensor reading, and costs nothing to honour on an elapsed slot. It just isn't something worth waiting for, which is what the old level did.

One consequence worth flagging: started without a car_charging_now sensor now falls back to none rather than completed. That's a bigger behaviour change for that case than before, but it's the honest one - falling back to a level that never confirms anything in time would have been the same outcome dressed up as something milder. The startup warning says none now.

Docs updated, including a note on why there's no completed-only level so this doesn't get proposed again. Tests 31/32/35/36/40 reworked onto started; full quick suite and pre-commit green.

[Speshman]

I found a concrete order-dependent failure, although the original 30-minute planned -> add_now example does not reproduce as stated.

At the default 30-minute interval, car_charging_now_confirmed_slots makes the earlier planned entry trusted for the same block, so it applies the low rate before add_now is reached. Completed records are also appended before planned records, so the reverse _confirmed=False -> True order is not currently emitted by fetch_sensor_data_cars().

Partial overlap does expose the problem with the supported plan_interval_minutes: 15 configuration:

• now: 14:00, confirmed block {840}
• planned slot first: 14:15-14:30
• add_now slot second: 14:00-14:30
• low/max rates: 4p/10p

The planned slot claims minutes 855-869 in saved_slots, but because its range contains no minute % 30 == 0, it never adds block 840 to slots_added_set. The later add_now slot prices 840-854 at 4p, then skips 855-869 because they are already saved. Observed output is therefore 4p for 14:00-14:15 and 10p for 14:15-14:30; reversing the input order gives 4p for the full block.

A direct unconfirmed-then-confirmed duplicate also reproduces the original gate-ordering issue, though current fetch ordering prevents that input.

So the exact rationale should be narrowed, but saved_slots still appears to represent visited minutes rather than successfully accepted/applied minutes. A regression covering the 15-minute partial-overlap case would demonstrate the fix.

---

Analysis and reproduction performed with OpenCode using OpenAI GPT-5.6 Sol.

[chalfontchubby]

Can you get your AI to explain a bit more gently please - It could be written a bit more human friendly if I'm trying to consider it myself.

[Speshman]

@chalfontchubby Sorry, the previous explanation was much too dense. Here is the plain-English version.

I could not make this go wrong with the normal 30-minute setting. I only reproduced it when plan_interval_minutes is set to the supported 15-minute value, so this is an edge case and may be an older issue rather than something introduced by this PR.

The example is:

1. Predbat sees a short 14:15-14:30 slot first. It marks those 15 minutes as already dealt with.
2. However, the code only applies the slot rate on a 00 or 30-minute boundary. This short slot contains neither boundary, so it does not actually make those minutes cheap.
3. Predbat then sees the sensor-confirmed 14:00-14:30 slot. It correctly makes 14:00-14:15 cheap, but skips 14:15-14:30 because those minutes were marked as already dealt with by the first slot.

The final result is therefore:

• 14:00-14:15: cheap, which is correct
• 14:15-14:30: peak rate, which is incorrect because the whole half-hour was confirmed

If the same two slots are processed in the opposite order, the full half-hour is cheap. That is what shows the result depends on ordering.

The likely fix is simply to mark minutes as dealt with only after a slot has actually been accepted and applied, or to allow a later accepted slot to replace an earlier skipped one. A small regression test using the times above should demonstrate whether the fix works.

I hope that is clearer. I can also provide the test setup as code if that would be useful.

---

Analysis and reproduction performed with OpenCode using OpenAI GPT-5.6 Sol.

[chalfontchubby]

Fix pushed - not able to mark the review as resolved because it wasn't raised as such.

Can I ask we focus on trying to get something merged and then iterate to fix problems in new tickets rather than have this one descend into another round of bots raising corner cases - we've lost 3 PR already that got mired down.

[Copilot]

🟡 Changes recommended

Unresolved moderate correctness and test-isolation findings remain, along with a documented configuration mismatch.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (3)

apps/predbat/fetch.py:2698

• When a fresh positive reading arrives after the previous streak anchor has exceeded the rollover cap, the code first re-anchors car_charging_now_streak_last_read to the current slot, but this branch still uses the stale streak_anchor and immediately clears that newly created anchor. The current block is confirmed, but subsequent blocks can never roll over from it until another fresh read; preserve the fresh anchor and only clear the streak when the cap is exceeded without a guard-passing positive reading.

                else:
                    # Cap exceeded with no fresh evidence - lapse the streak, but leave slots already
                    # confirmed while it was valid alone.
                    self.car_charging_now_streak_last_read[car_n] = None

apps/predbat/fetch.py:1255

• This reconciliation path is the only code that removes a feed-side io_adjusted discount when the trust gate rejects a dynamic slot, but the added rate tests call rate_add_io_slots() directly and never exercise exclude_dynamic_io_slots(). Add coverage for a future io_adjusted minute with none/started trust (including preservation of fixed-window and trusted minutes); otherwise the real-tariff path can regress while all current tests remain green.

            # #4516: undo any dynamic (out-of-window) IOG dispatch discount that arrived via the
            # rate feed itself (self.io_adjusted) rather than rate_add_io_slots()'s own overlay -
            # see exclude_dynamic_io_slots()'s docstring for why both sources need handling.
            import_rates = self.exclude_dynamic_io_slots(import_rates)

apps/predbat/fetch.py:2680

• The new streak logic treats every non-matching car_charging_now value as False, so a transient HA unknown/unavailable state clears the anchor here. get_car_charging_now_tristate() already distinguishes those states from an explicit negative; preserving the streak for None is needed to match the documented “explicit not charging” termination and avoid losing confirmation after a sensor/restart glitch.

            elif not charging_now:
                # Clearing the anchor too skips the backfill, so nothing is confirmed on the strength
                # of a streak this read just ended.
                streak_anchor = None
                self.car_charging_now_streak_last_read[car_n] = None

• Files reviewed: 11/11 changed files
• Comments generated: 3
• Review effort level: Lite

[chalfontchubby]

(Posted by Rik; working with Claude.)

Following up on Copilot's 2026-09-17 18:28 review — its 3 findings there are now all fixed in 707962d, on top of the midnight-rollover fix already pushed in ba63fd9:

fetch.py:2680 - an "unknown"/"unavailable" sensor reading was ending an active streak. get_car_charging_now_tristate() already existed to distinguish "confirmed not charging" from "no evidence either way," but the streak logic wasn't using it - any non-matching value, including a transient HA unknown around a restart, was treated the same as a genuine stop. Now only a real tristate False ends the streak; None falls through untouched, so a brief sensor hiccup no longer drops confirmation for a car that may have kept charging the whole time.

fetch.py:2698 - a fresh confirming read could be wiped in the same cycle it arrived. When the previous cycle's anchor had already gone past the rollover cap, and this cycle's own reading re-anchored the streak, the cap-exceeded branch was still comparing against that stale old anchor and immediately clearing the anchor this cycle just set - silently discarding the fresh confirmation. The lapse branch now only fires when this cycle's own reading didn't already re-anchor.

fetch.py:1255 - exclude_dynamic_io_slots() had no test coverage. It's the function that strips a feed-side io_adjusted discount on a real Intelligent tariff - the path that matters most, since it's live discounted data straight from Octopus rather than anything rate_add_io_slots() itself added. Added direct tests for the strip, preserve, and fixed-window-exempt cases.

All three are covered by new regression tests (test_car_charging_now_confirmed_slots.py Test 7b/12, test_rate_add_io_slots.py Tests 42-44), confirmed to fail against the unpatched code and pass with the fix. ./run_all --quick and ./run_pre_commit both green.

[Speshman]

As the reporter of #4482, the safety direction in this PR matches the live behaviour I captured. Future out-of-window slots with no confirmed charging can disappear and have their source rates revert, so avoiding reliance on them until the Zappi reports real charging is a useful mitigation.

My original issue proposed using the real EV SoC directly, but I would support merging this narrower protection first and iterating separately. It preserves the fixed 23:30-05:30 window and offers a safer opt-in policy without changing existing defaults.

I have no request to broaden this PR further. It appears ready for an update onto current main and maintainer review.

---

Prepared with assistance from GPT-5.6 Sol.

[Copilot]

Copilot review overview

🟡 Changes recommended

Unresolved moderate findings remain in DST handling, sensor validation, overlapping-slot handling, and shared test-state isolation.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• Use calendar-day differences when rebasing across DST · New
• Isolate or restore shared PredBat state between tests · New

Resolved since last review (3)

• This test runs against the single shared my_predbat fixture, but the final…
• car_charging_now_confirmed_slots stores starts as minutes relative to the current midnight_utc,…
• The PR description lists completed as one of the selectable trust levels, but this config exposes…

Previously missed (1)

In code that hasn't changed since last review

Require actual HA entity references for charging sensors

apps/​predbat/​fetch.py:2593

has_car_charging_now_sensor() treats every scalar value (and any non-empty list entry) as a real sensor. However, car_charging_now is allowed to be a static off value in apps/predbat/config/apps.yaml:357-361 and the schema permits boolean/string states (apps/predbat/config.py:2687). With car_charging_now: off, started will not warn or fall back to none, and can still trust _confirmed completed records, contrary to the documented real-sensor requirement. Restrict this check to actual HA entity references for both scalar and list forms.

[Copilot]

Copilot review overview

🟡 Changes recommended

Unresolved slot-overlap and rate-handling issues can produce incorrect planning and tariff decisions.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Allow accepted overlapping slots to override rejected entries · New

Resolved since last review (2)

• Isolate or restore shared PredBat state between tests
• Use calendar-day differences when rebasing across DST

[chalfontchubby]

(Written by Claude, posted by @chalfontchubby.)

Pushed f8c71d8c, addressing the high-severity finding and four more bugs found while fixing it.

On the reported finding. It is real and now fixed, but the mechanism in the review comment is not quite the one that bites. car_charging_now_confirmed_slot_starts is keyed on slot_start, so it is shared by every entry covering a block - the live car_charging_now entry and a planned entry therefore reach the same verdict and cannot disagree. The only per-entry input to trusted is _confirmed, so the reachable case is an unconfirmed planned entry visited before a completed dispatch record for the same block. Same bug, narrower trigger. Test 46 reproduces it.

Four further bugs, each found by a cold review pass and each with a test confirmed to fail without its fix:

1. Car order decided the outcome. rate_add_io_slots() runs once per car into one shared rates dict and its reject path drops the io_adjusted marker as well as rewriting the rate. The guard against undoing another car's dispatch read trusted_dynamic_minutes, which that same loop builds as it goes - so a rejecting car running first saw it empty, popped the marker, and nothing anywhere restores one. The rate was restored by the accepting car; the marker was not, dropping the block out of plan.py's IOG skew and prediction.py's PV10 hedge. Test 49 runs both orders and compares.

2. A rejection was read back as the tariff price. assumed_price read the working rates dict, which this function mutates. Safe on main (nothing ever wrote rate_max_base into rates), but this PR's restore path made it reachable: car 0's rejection became car 1's "tariff price". Now reads rate_import_no_io, the snapshot taken before the per-car loop. Test 48.

3. The cap stripped the tariff's own discount. trusted_dynamic_minutes was only recorded when the octopus_slot_max cap granted the discount, so exclude_dynamic_io_slots() stripped the very minutes the #4483 cap-only exemption had just protected. The cap budgets what Predbat plans - it is documented per-car while the rates dict is install-wide - not what it believes the price to be. Test 39 previously asserted that bookkeeping directly with no io_adjusted markers at all, so it passed under either behaviour; rewritten to assert the user-visible outcome.

4. An end_minutes clamp used forecast_minutes where its three siblings use forecast_minutes + minutes_now. forecast_minutes is a duration, so it truncated roughly minutes_now of the horizon and a dispatch landing in that tail lost its discount. Pre-existing on main, but this PR added the consumer that makes it bite.

Structural change. Three of these came from the same root: two places computing one decision and drifting apart. car_trusted_dispatch_blocks() is now the single per-car answer to "which blocks does this car have a genuine dispatch for", used by both the cross-car shield and the loop's own gates. An intermediate version of the shield re-derived a looser variant - dropping the needed gate at "planned", and skipping the per-car degrade to "none" for a car with no real car_charging_now sensor - which shielded blocks the loop itself rejects and would have kept a rescindable slot cheap. That is the #4516 failure this PR exists to prevent, so Test 50 pins shield breadth in both directions.

Process note, since it is relevant to how much weight to put on this. Four of the five bugs above were introduced or missed by me, including two inside the fix for the bug you reported. I stopped self-reviewing and ran independent cold reviews instead, iterating until one came back with "no correctness bug introduced by this branch's own work". That last pass also brute-forced the two block derivations against each other across plan_interval_minutes ∈ {1,5,10,15,20,30,60} and found zero divergence. I would still rather you or Copilot looked than take that as settled.

Out of scope, flagged not fixed: assumed_price is keyed on the entry's start_minutes rather than the current minute, so with octopus_slot_low_rate: false and two overlapping entries at different tariff prices the result depends on list order. Pre-existing on main and unrelated to trust gating - happy to raise it separately.

Full quick suite and pre-commit green. run_shuffle --hunt --quick clean so far for order dependence.

[chalfontchubby]

(Written by Claude, posted by @chalfontchubby.)

Correction to my previous comment. I justified the trusted_dynamic_minutes change partly with "the cap is documented per-car while the rates dict is install-wide". That premise is wrong, and I should not have leaned on it.

octopus_slot_max defaults from has_six_hour_cap(), which matches on the tariff code - a property of the account, not of a vehicle. The "per-car" line in docs/car-charging.md was documenting current behaviour rather than intent, and that behaviour turns out to be a latent bug: the cap is derived per account but enforced per car, because slots_per_day is a local in rate_add_io_slots() and that function runs once per car. Raised separately as #5215, with a docs correction; not touched in this PR.

The conclusion in f8c71d8c still holds, for the reason that was actually load-bearing. The cap must not strip a discount the tariff feed itself delivered, because io_adjusted records what Octopus will bill - a fact, not a prediction. That is true whether the allowance is per-account or per-car: Predbat's own budget for planning cheap charging says nothing about what the meter is charged. The per-car detail was supporting colour in my write-up, not the argument.

Flagging it because the commit message carries the same wrong premise, and I would rather correct it here than leave it to be read as established.

[Copilot]

Copilot review overview

🟡 Changes recommended

Two moderate issues remain in fetch.py and octopus.py and should be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Avoid startup errors when num_cars is zero · New

Resolved since last review (1)

• Allow accepted overlapping slots to override rejected entries

[chalfontchubby]

(Written by Claude, posted by @chalfontchubby.)

Fixed in c18f8e8a. The finding is correct.

The warning loop used range(max(self.num_cars, 1)), so an install with num_cars: 0 - explicitly allowed ("zero": True in the schema) - was warned that car 0 lacked a car_charging_now sensor and given had_errors=True. The block is gated only on trust_future_dynamic_iog_slots == "started", never on car count, so it is reachable.

Root cause is that the max(..., 1) idiom was copied from the wrong context. Its two other uses in fetch.py size per-car lists (car_charging_rate, car_charging_manual_soc), where a spare slot avoids an IndexError on a later unconditional indexed read - fetch.py:390 reads car_charging_rate[0] gated on car_charging_hold rather than on num_cars. Sizing a list and iterating to emit user-facing warnings are not the same problem, and I conflated them.

Only the warning is affected. The actual per-car degrade to "none" lives in rate_add_io_slots(), which calls has_car_charging_now_sensor() itself every cycle, so the trust gate is unchanged.

Test 21 covers it and was confirmed to fail against the old loop on both assertions. A cold review pass also checked the other IOG/trust call sites for the same assumption at num_cars == 0 (resolve_protected_dispatch_minutes, car_trusted_dispatch_blocks, get_car_charging_planned, add_now_to_octopus_slot, load_octopus_slots) and found them all either bounded by range(self.num_cars) or guarded - no sibling instances to fix.

[springfall2008]

I've opened #5229 as an alternative approach. Review welcome, @chalfontchubby.

It comes from reviewing this PR. Here, trust is gated only through the rates. car_charging_slots is left as it is, so "Hold for car" still holds the battery during a slot the plan no longer trusts. At none with car_charging_from_battery on, the planner sees the car's load priced at peak and discharges the house battery into the car during a genuine dispatch.

#5229 works the other way round. Dispatches are trusted by default, and the evidence that counts is the car not charging. It builds on the existing dynamic load feature, with no new settings:

• When it fires: while a car is inside one of its slots and car_charging_now reports it isn't charging (for 2 minutes), its future slots are cancelled. That releases the hold and the predicted car load. The dispatch's cheap rate is withheld too: Predbat's own discount, and any discount the rate feed already delivered.
  • Without a sensor, low load stands in, if the car is inside the CT clamp (10 minutes).
• Recovery: it clears as soon as the car starts charging again or the slot ends. A 15-second poll replans straight away instead of waiting for the 5-minute cycle.

Your latency measurements were what made a 2-minute sensor wait credible, so thank you for those.

What #5229 doesn't cover: it only reacts once a slot has started. A dispatch withdrawn before it starts, after the plan has already acted on it (e.g. an early force-export), isn't prevented there. limit_future_slots also answers a different question (does the car still need the slot), so it could stand on its own.

[chalfontchubby]

(Written by Claude, working with @chalfontchubby.)

Closing in favour of #5229, which now covers this.

switch.predbat_octopus_intelligent_trust_slots Off does what trust_future_dynamic_iog_slots was for: an Intelligent car's slots start untrusted — 0 kWh and no cheap daytime rate — and are trusted only once the car is seen charging inside a slot, with each dispatch confirmed separately. It also works without dynamic load enabled, and it fixes something this PR got wrong: #5110 distrusted the rates but left car_charging_slots alone, so "Hold for car" still held the battery through a slot the plan no longer trusted.

One concern I'd like to carry over to #5229 rather than lose here. Under the switch, a car inside the CT clamp can be confirmed as charging by load signature alone. The asymmetry matters: a false "charging" reading now trusts a phantom slot, which is the failure mode the switch exists to prevent — the opposite direction from the original kettle objection, and a worse one. Worth considering whether confirmation should require a real car_charging_now entity even where the load test is available. I'll raise it on #5229.

Leaving #4516 open — #5229 addresses it but that's @springfall2008's call, not mine. #4482 is untouched by either PR.