Dispatch starvation when Daikin quota tight (post-Phase A)

[albinati]

Symptom

On 2026-05-10 morning (~09:00 BST), action_schedule had 0 Daikin actions queued for the day despite the LP planning a tank lift to 65°C at 13:30 UTC + evening reheats. Plan ran fine; dispatch's budget guard pruned everything.

Root cause

src/scheduler/lp_dispatch.py:710-715:

reserve = int(getattr(config, "DAIKIN_RESERVE_FOR_HEARTBEAT", 30))
headroom = max(0, quota_remaining("daikin") - reserve)

Phase A (#308) removed Daikin calls from the heartbeat. The 24h rolling quota window still contained yesterday's pre-Phase-A burn (145/180 used). At plan-fire time, quota_remaining=31, headroom=31-30=1 → most LP-planned action pairs got pruned by _apply_write_budget.

The window will clear naturally by ~22:42 UTC (24h after Phase A deploy), so dispatch will recover today / tomorrow without intervention.

Why this is a real concern

Once steady-state, expected Daikin usage:

• Brief reads (08:00, 22:00 BST): ~4-10/day
• LP plan dispatches (multiple MPC fires): ~30-60/day
• Slot reconciles (cache-hit mostly): ~5-10/day
• Token refresh (lazy): ~3/day
• Total: ~50-80/day out of 180 budget

The 30-call reserve is sized for old heartbeat-era. With heartbeat now using 0/day, it's still meaningful safety buffer for slot-boundary reconciles + briefs + token refresh, but worth re-tuning once we observe ~14 days of steady-state usage.

Proposed actions

Not urgent — wait for self-recovery first.

• Observe Daikin call patterns for 7 days post-Phase-A. Capture per-kind histogram from api_call_log.
• Right-size DAIKIN_RESERVE_FOR_HEARTBEAT based on observed steady-state non-dispatch usage. Likely 10-15 instead of 30.
• Consider renaming the var (it's no longer about heartbeat). Maybe DAIKIN_RESERVE_FOR_OPS.
• Add a panic-mode dispatch fallback: when headroom < threshold, write only NEGATIVE / PEAK pairs (skip CHEAP / SOLAR_PREHEAT) so critical safety actions always make it through.
• Brief warning line when today's plan was pruned ("Daikin dispatch dropped N/M pairs due to quota — \ cost upside lost").

Related

• PnL bug: realised_cost_gbp uses household LOAD not grid IMPORT — inflates costs ~3-4× #306 (PnL real-money fields)
• feat(brief+heartbeat): Phase A data quality — Fox/meter audit, skill line, dedup, Daikin-quota-friendly heartbeat (#306) #308 (Phase A heartbeat / Daikin API decoupling)
• [Epic] Daikin observation strategy: max info per call, 2h-aligned, ready for active control #267 (epic for active-mode prereqs)

[albinati]

Partial fix landed in #315 (deployed 2026-05-10 10:11 UTC, prod SHA 2384c50):

• ✅ _apply_write_budget ALREADY prioritises NEGATIVE / PEAK pairs over CHEAP / SOLAR_PREHEAT (existing code; verified by trace).
• ✅ Brief now surfaces drops via new _budget_guard_summary_line() — reads action_log rows tagged budget_guard_drop and shows: ⚠️ Daikin quota: dropped N low-value pair(s) (… kinds …); critical NEGATIVE/PEAK preserved (min headroom=X).
• ✅ Dispatch persists drops to action_log so the brief can read them without grepping journalctl.

Still open (the actual tuning work this issue is about):

• Observe Daikin call patterns for 7 days post-Phase-A.
• Right-size DAIKIN_RESERVE_FOR_HEARTBEAT based on observed steady-state non-dispatch usage.
• Consider renaming the env var (no longer about heartbeat).

The issue stays open for the tuning step. Visibility gap is now closed.

[albinati]

Status as of 2026-05-20: Phase A (#308) removed the per-heartbeat Daikin API call (~10 % of daily quota recovered). v12 added no new Daikin-quota-impacting paths. The remaining starvation modes are: (a) 200/day cap exhausted by manual MCP-driven writes during commissioning + (b) write-budget guard dropping low-value pairs when headroom is tight (#289). Keeping open for further work on (a) per-user notification when quota crosses 50 % / 75 % / 90 % thresholds.

[albinati]

Tracked by #380 (Tier 3 — park, re-evaluate on a signal). See epic body for the specific trigger that should make this worth picking up.

[albinati]

Indirect mitigation 2026-05-22 by PR #401 (PR J PV diverter):

Diverter writes are idempotent (skip_if_matches=True) and rate-limited by the state machine (3-tick activate + 5-tick deactivate + 8-tick lockout = ~2 writes/day in steady state for the diverter itself). This means the heartbeat side of Daikin quota usage is now bounded predictably:

• Heartbeat itself: 0 calls (read-only from cache, post Phase A feat(brief+heartbeat): Phase A data quality — Fox/meter audit, skill line, dedup, Daikin-quota-friendly heartbeat (#306) #308)
• Drift checks: ~2/day (_check_tank_power_drift defensive backstop, rarely fires)
• PV diverter: ~2/day (1 activate + 1 deactivate per sunny day)
• LP scheduled actions: ~5-10/day

Total budget pressure: ~10-15 / 200 daily. The dispatch starvation symptom this issue documented should be much less likely to re-trigger.

The underlying logic (reserve calc reading 24-h rolling vs calendar-day windowed quota) is still suboptimal but no longer the operational blocker. Keeping open as a Tier-3 cleanup; can re-prioritize if the symptom recurs.