Teslemetry: flat-priced tariff across the whole export window lets Tesla's own TBC defer most of the discharge to the last ~30 minutes

[springfall2008]

Describe the bug

teslemetry.py's handoff to Tesla's own Time-Based Control (TBC) engine gives it no reason to export early within a committed discharge window, and in a live capture this let a Powerwall sit almost completely idle for most of a ~2.5 hour export window before dumping most of the discharge in the last ~30 minutes — after Predbat had already correctly and continuously asserted a fully permissive device state the whole time.

Unlike every other supported inverter, Predbat never sends the Powerwall a live "stop now" command — inverter.py::adjust_force_export always writes the hardware discharge-target register as self.reserve_percent (the absolute physical minimum reserve), not the plan's live/shrinking export target. That's correct by design for inverters where Predbat's own 5-minute loop is the real-time enforcement (it flips force_export off itself the instant SoC crosses the live plan target). Tesla Powerwall has no equivalent "stop discharging now" API — teslemetry.py can only set operation_mode + backup_reserve + a synthetic TOU tariff (build_tariff / _carve_interval), and then Tesla's own onboard optimizer decides in real time how to spend the discharge budget across whatever window it was given.

_carve_interval/build_tariff prices the entire committed discharge window as a single flat ON_PEAK band. There is no time-varying incentive inside the window, so exporting at the start of the window and exporting at the end are equally "optimal" from Tesla's own cost-minimising point of view — nothing in the signal discourages its optimizer from procrastinating.

Captured timeline (relative to when Predbat committed the discharge window; all writes below returned HTTP 200 / Operation mode updated):

T+0:00   Discharge window committed (later extended once, still same day).
         Asserted to device: operation_mode=autonomous, backup_reserve=4%
         (the configured hardware minimum), grid export=battery_ok.
T+0:00 → T+2:25
         No further commands sent — correct, nothing Predbat-side had
         changed (dedup on write-on-change). Powerwall battery power
         stayed ~0 kW the entire time, aside from two ~5-minute blips
         of 1.3–1.6 kW roughly a third of the way through.
T+2:30   Powerwall begins discharging at its full ~5 kW rate for the
         first time.
T+3:00   Discharge stops abruptly as the (by-then-extended) window
         closes. SoC had only fallen from ~100% to ~69% — nowhere
         near the 4% floor Predbat had asserted (and left unchanged)
         throughout.

Predbat's own logs/config were correct and stable for the entire window — this isn't a mode-flapping or wrong-command bug like #4165, and optimization_strategy=economics / the day-of-week mapping are already correctly applied (#4600, #4610 are fixed and present). The problem is purely that a uniformly-priced window leaves Tesla's own TBC free to defer almost all of the export to the very end, so a wide, flat-priced window converts into only a fraction of its intended export.

Expected behaviour

The synthetic tariff Predbat pushes for a committed discharge window should give Tesla's own optimizer an actual incentive to act early in the window rather than at its own discretion near the end — e.g. front-load/decline the boost price across the window, or split it into several narrower priced sub-slots — so a wide export opportunity doesn't collapse into a last-minute partial discharge.

Predbat version

v8.54.2

Environment details

• Tesla Powerwall (13.5 kWh class), Teslemetry/Fleet API integration (inverter_type: TESLA, teslemetry_automatic)
• Octopus-style time-of-day export tariff with a multi-hour high-price window

Log file & apps.yaml

Not attached to keep this report anonymised — I can provide a sanitised log excerpt covering the window above on request. Happy to point at specific line numbers in teslemetry.py/execute.py/inverter.py if useful for triage.

[springfall2008]

Automated first-pass triage — a maintainer will review before any action is taken.

Classification: enhancement (I did not remove the human-applied bug label; my reasoning below). No priority set as this is effectively a design-improvement request on top of behaviour that is currently working exactly as coded.

What I verified against current main (f3ddb4c5, v8.54.2-19):

The report is accurate about the mechanism. build_tariff() (apps/predbat/teslemetry.py:1123) carves the committed discharge window as a single ON_PEAK interval via _apply_boost()/_carve_interval() (teslemetry.py:1074, teslemetry.py:1036), and _render_side() (teslemetry.py:1017) assigns one price per tier name, with _boost_price() (teslemetry.py:1117) returning a single scalar (max(0.50, 2 × max real band)). So by construction every 30-minute slot inside the window carries an identical sell price — there is no intra-window gradient, exactly as described. Nothing discourages Tesla's own TBC from treating slot 1 and slot N as equivalent, and TBC's known behaviour is to defer into the latter part of a flat band.

Two supporting observations:

• test_teslemetry_run_exports_with_aligned_tariff_boost in tests/test_teslemetry.py only asserts the boost exists and strictly dominates every real band — no test pins the intra-window shape, so nothing would catch this today. I ran the teslemetry test module against current main and it passes.
• Side note for the maintainer while this area is open: in the no-rate-data fallback branch of _rate_side() (teslemetry.py:1085) layout is None and the boost is skipped entirely, so a wide committed discharge window with no wired rate data gets no export incentive at all — not the reporter's case (they have real Octopus rates) but the same theme.

On classification: all device writes succeeded and the asserted state (mode/reserve/export rule) was correct and stable — the reporter's own capture confirms this is not a wrong-command bug like #4165, and #4600/#4610 are indeed fixed on main. The gap is that the requested behaviour (a declining/front-loaded boost price, or the window split into several narrower priced sub-bands) does not exist yet. That's an enhancement with a real functional cost on this inverter type: a large share of the planned export can silently fail to materialise, which only manifests on Tesla because every other inverter type enforces the live target through Predbat's own 5-minute loop while Powerwall has no "stop now" API — the reporter's framing of this asymmetry is correct.

The suggested fix direction looks feasible within tariff_content_v2 without new API surface: carve the window into 2–4 consecutive sub-intervals at decreasing ON_PEAK prices (all still strictly above every real band, and still mirrored on the buy side) so early export strictly dominates later export. Points a fix will need to respect: sub-band prices must survive the whole-pence rounding so the declining ordering remains strict; _render_side's matched-tier-set constraint must hold on both sides; and each window change re-pushes the whole tariff, so a wider window slightly increases command-credit spend.

No log or debug yaml is attached; I didn't request one since the behaviour is fully determined by the tariff-building code and the reporter's timeline is consistent with it.