feat(octopus): log a diagnostic IOG dispatch timeline (#4516 Stage 1)

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Why this instead of #4885

You pushed back on #4885 and I think the objection holds: distrusting IOG slots has a concrete cost — you end up discharging the house battery into the car, and it takes 5-10 minutes of sensor evidence to know whether the car is really charging — while the benefit rests on slots being rescinded often enough to matter. I went looking for evidence of that in my own billing and couldn't find an instance, and @Speshman's example on #4483 turned out to be a different case (provisional daytime slots the car doesn't need, not slots Octopus withdrew).

So rather than argue the premise, this makes it measurable. No behaviour change at all — no rate is altered, no plan decision reads this. It is a log line.

The reason this is needed is that the data does not currently exist. Predbat merges and retains completed dispatches for 5 days, but planned dispatches are replaced wholesale on every poll, so a slot that disappears leaves no trace. Nothing logs the planned set either. The absence of evidence here is an absence of instrumentation, not of the phenomenon — and that cuts both ways: if the timeline shows slots are stable, #4885 should be closed on the strength of it.

What it does

Once per 30-minute boundary, per car, one character per 30-minute block across [-4h, +24h]:

Octopus: Dispatch timeline car 0 @ 14:30 [-4h..+24h]: ....CCcc..SS..pp....PP..................................

. nothing known, P planned (provisional), S started, C completed. Most-confirmed status wins where the lists disagree.

Lowercase means Predbat's own plan charges in that block. That distinction is the point of the second commit: a slot that vanishes having never been planned against costs nothing, while one Predbat committed an import to is a plan that will not happen. A plain P/S/C render cannot tell those apart.

Stacked in a monospace viewer, consecutive lines make dispatch lifecycles read as diagonal stripes — a specific dispatch drifts one column per line as now advances. So:

• a stripe that runs through into C is a slot that was delivered
• a stripe of p that stops before reaching the now column is a slot Predbat planned around and lost

That second pattern is the thing worth finding, and it is exactly the failure I suspect but cannot currently prove: I had one late-day shortfall I believe followed a cheap import slot moving, and no way to confirm it.

Notes

• The timeline is built in fetch, before the planner runs, so the charge windows are the previous cycle's plan — one 5-minute cycle stale against 30-minute blocks. That is deliberate and commented: what Predbat believed while the slot was still live is the more useful record, and the error is well inside a block.
• Windows with a zero charge limit are not counted as charging.
• Logged only on 30-minute boundaries so log volume stays sane; dispatch decisions are 30-minute-granular anyway.
• The first commit is my own work from August (IOG future planned dispatches treated as cheap home rate before EV charging earns the slot #4516 Stage 1), cherry-picked onto current main. One conflict from a method added adjacently since, resolved by keeping both.

Testing

test_dispatch_timeline covers the render, precedence, boundaries, multi-block slots, and the new lowercase annotation including the zero-limit and no-slot cases. The existing tests did not set plan state, so they would have inherited ambient charge windows in a full-suite run — they now set it explicitly and save/restore around the whole test. Full quick suite and pre-commit clean.

What I'd suggest happens next

Land this, run it for a few weeks on a couple of IOG systems, and let the stripes settle whether #4885 has a case. If slots turn out to be stable, I'll close #4885 myself.

[Speshman]

Thanks for separating the instrumentation from the behavioural change. This looks like a useful and low-risk way to gather evidence.

Two details may affect what can be concluded from the timeline:

1. Logging only on 30-minute boundaries could miss a provisional slot that appears after one boundary, influences Predbat’s plan, and disappears before the next. Would it be practical to log whenever the canonical timeline changes, while retaining the half-hour entry as a heartbeat?
2. Lowercase currently shows that a dispatch overlaps Predbat’s charge plan, but not necessarily that the dispatch caused that plan. Predbat might have charged in that block anyway because of the fixed off-peak window or another rate source. Describing lowercase as “overlaps planned house-battery charging” rather than “relied upon” may avoid overstating what the evidence proves.

Neither point argues against landing the observability work; they would just make it less likely to miss the original issue or draw a stronger conclusion than the data supports.

Drafted with assistance from OpenAI GPT-5.6 Sol.

[chalfontchubby]

I a slot only lives for a short period and disappears before the next log heartbeat it won't have had much time to do damage to the soc. non-uniform time, logging on every issue, would be possible, but limited in utility.
This is indicative- pinning down whether a slot is responsible for what is problematic

I think patch stands as is. Agile mentality mezns ship it if it ads value, don't redo repeatedly and find you never get merged. We can add more later if we need it.

[Copilot]

🟡 Changes recommended

Real started dispatches are discarded, preventing S or s from appearing.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds diagnostic logging for Octopus Intelligent dispatch lifecycles without changing planning behavior.

Changes:

• Renders planned, started, and completed dispatch timelines.
• Marks blocks overlapping Predbat charge plans in lowercase.
• Adds and registers timeline unit tests.

File summaries

File	Description
apps/predbat/octopus.py	Builds dispatch timelines.
apps/predbat/fetch.py	Reads started dispatches and logs timelines.
apps/predbat/tests/test_dispatch_timeline.py	Tests timeline rendering.
apps/predbat/unit_test.py	Registers the new tests.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Balanced

---

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

[chalfontchubby]

Reconsidered point 1 after checking the code more closely — it's cheaper than I gave it credit for. completed/planned/started were already being re-read from HA every 5-minute cycle; only the log line itself was gated to the 30-minute boundary. So a heartbeat-only log genuinely can miss a provisional slot that appears and disappears entirely within one half-hour window, which is exactly the "stripe that never reaches now" pattern this diagnostic exists to catch — regardless of how little time it had to affect SoC, which was the wrong axis to argue on.

Implemented in 45dd2576: the 30-min heartbeat still always logs unmarked, and a change from the last-logged timeline for that car now also logs immediately, marked with a trailing ' *' so the two kinds of line can be told apart (or grepped separately) without disturbing the fixed-width alignment the diagonal-stripe reading depends on — the marker is a suffix, not a prefix.

Point 2 stands as discussed — the lowercase mark is indicative of overlap, not proof of causation, and I think that's already clear enough in context without a wording change.

Posted by Claude on behalf of @chalfontchubby.

[Copilot]

🟢 Approval recommended

The diagnostic-only implementation is consistent with its stated scope, handles real started-dispatch data, preserves shared test state, and has focused coverage.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[chalfontchubby]

@Speshman
If you filter the predbat log by all with a string "Timeline" now you should see an illustration of how slots come and go. Might be useful if confusing.