feat(octopus): octopus_intelligent_dynamic - confirm Intelligent slots only well inside a dispatch

[springfall2008]

Follow-up to #5229 and #5245.

Problem

#5229 checks Octopus Intelligent slots against whether the car is actually charging, and cancels them if it isn't. Two things stopped it working in practice.

1. It never ran on real installs. It was gated on switch.predbat_metric_dynamic_load_adjust, which defaults Off. predbat_config.json saves every setting, defaults included, so almost every install has false stored, and changing the default would only reach new installs. A live test on a Wallbox showed exactly this: the car was in a dispatch at 0 W, and not one car ... decision line was ever logged.
2. It judged dispatches on a 5-minute grid. Octopus schedules them to the minute. The dispatch in that test was two entries, 15:55–16:00 and 16:00:00–16:01:22, about 6.5 minutes in all. "In a slot" was checked against minutes_now, rounded down to 5 minutes. So a dispatch ending at 12:37 still looked in progress until 12:40, and the car stopping because it ended counted as "not charging". There was also no allowance for the car and charger waking up at the start.

Change

• New switch.predbat_octopus_intelligent_dynamic (expert mode, default On) gates slot confirmation. It still only runs for an Intelligent car with evidence: a real car_charging_now entity, or the house load with the car inside the CT clamp. So existing installs with a sensor get it without changing a setting.
  • metric_dynamic_load_adjust is now only the load estimate.
  • The trust switch's Off mode needs the new switch. With it Off, a warning says so.
• "In a slot" uses the exact clock (now_utc_real plus skew), in the check and the 15-second poll alike, so the two still agree. Zeroing slots and building rates keep minutes_now.
• Back-to-back slots count as one dispatch, so a long dispatch split into half hours has no start band at each join.
• Start band for the sensor: a "not charging" reading counts from 3 minutes into the dispatch, then the 2-minute grace applies, so the earliest cancel is start + 5.
  • An in-progress dispatch's start can be advanced to now each cycle, so the earliest start seen is kept, keyed on the dispatch's end.
  • "Charging" still counts anywhere in the dispatch.
• Load window: a load reading is the 5-minute average up to minutes_now, and only counts when that whole window lies inside the dispatch. The grace is one more window, timed on the 5-minute grid rather than the exact clock, because load only arrives on cycles. So two low windows in a row cancel: start + 10 for a dispatch starting on the grid.
• No end band: a dispatch is simply over at its real end.
• Docs: a new "Checking Intelligent dispatches against the car" section under Octopus-led charging covers why the check exists, setup (including a charging-power sensor), how it decides (a timing table), what happens when a slot is cancelled, a worked example, and troubleshooting. The switch bullets link to it.

Live regression

A second live test on main showed a cancellation being dropped although car_charging_now never changed:

• 16:42: the car was cancelled against the planned 16:30–17:00 entry.
• 16:43: Octopus replaced that entry with a started one, 16:40:39–17:00.
• Main judged this on minutes_now, rounded down to 16:40:00, which is before 16:40:39. So the car appeared to have left the slot, and it resumed.

Test 33b reproduces this: it passes here, and fails with the rounded clock. Here it's fixed twice over: by the exact clock, and by the dispatch start remembered against the unchanged 17:00 end.

Behaviour changes

• On by default: Intelligent users with a real car_charging_now sensor now get slot confirmation without changing a setting.
• Load-based confirmation is on by default too: Intelligent users whose car is inside the CT clamp and who have no sensor now get it, where before they needed dynamic load.
• Dynamic load no longer affects car slots: users who had it on only for the load estimate see no change there.
• The load method is quicker: start + 10 on the grid, down from a flat 10 minutes of low load, and it now ignores load from before the dispatch started.

Tests

test_dynamic_load_car_not_charging (51 scenarios). _reset() now leaves dynamic load off, so every scenario shows the feature working without it. New cases:

• the start band: no cancel before start + 3, a cancel at start + 5, and "charging" counting inside the band;
• back-to-back slots;
• a start that drifts forward;
• the 6.5-minute dispatch from the live log, cancelled at 16:00:15 and over at 16:01:22;
• a 12:23–12:37 dispatch that's over at 12:37:10, in both the poll and the check;
• a load window straddling an off-grid start, and grace timed on the grid;
• dynamic load off still working, and the new switch off (with the trust switch Off) doing nothing;
• the switch-off warning.

Deliberately broken versions of the start band, the merging, the remembered start, the exact clock, the load window, the load timing and the switch gate each make it fail. ./run_all --quick: all passed. pre-commit: clean.

🤖 Generated with Claude Code

[springfall2008]

Minor: for a cancelled car the merged dispatch is computed and the slot list sorted twice in this cycle - once inside dynamic_load_car_target (line 510) and again here via dynamic_load_car_in_slot - and dynamic_load_car_dispatch re-sorts the slots per car every 15 seconds in the poll. dynamic_load_car_in_slot (line 459) now has exactly one caller, this line. Reusing the dispatch tuple the target call already produced (or dropping the wrapper) removes the duplicate sort/merge.

[springfall2008]

Reply from Claude Code, working with @springfall2008.

Fixed in 2989f8e. dynamic_load_car_in_slot() is removed, and its one caller uses dynamic_load_car_dispatch() directly. That call only runs when a car's state changes, to choose the log wording, so the extra merge doesn't happen on ordinary cycles. I left the poll's per-car sort as it is: it sorts a handful of one car's slots every 15 seconds, which isn't worth caching state for.

[springfall2008]

Reply from Claude Code, working with @springfall2008.

Fixed in 2989f8e: dynamic_load_car_in_slot() is gone, and its one caller now calls dynamic_load_car_dispatch(car_n, minute) is not None directly. That call only runs when a car's cancellation state changes, to choose the log wording, so the extra sort happens rarely. The poll's per-car sort is over a car's own few slots every 15 seconds, so I've left it as is.