Teslemetry: Powerwall never exports — tariff pushed without optimization_strategy, so TBC stays in Balanced

[springfall2008]

Summary

teslemetry.py never sends optimization_strategy when it pushes the ToU tariff, so the Powerwall's Time-Based Control stays in Balanced mode. In Balanced, TBC discharges only to offset house load and never exports stored energy to the grid — no matter how high the synthetic ON_PEAK sell price in the boost window is.

Net effect: Predbat reports Exporting, every device command succeeds, and the battery exports nothing. Planned exports have never executed on this site.

The defect

set_tariff (teslemetry.py, ~line 1155):

return await self._apply_command(
    "tariff",
    signature,
    lambda: self._command("time_of_use_settings", {"tou_settings": {"tariff_content_v2": tariff}}),
    force=force,
)

The Fleet API tou_settings object accepts optimization_strategy: economics | balanced. We set the tariff but never set the dial that decides whether the Powerwall acts on it commercially. Whatever the customer's Tesla app happens to hold, stands.

Per Tesla's own description of Balanced: "once peak rates kick in, the Powerwall will start discharging to offset what your house is consuming." Offset load — not export. economics ("Cost Saving") is the strategy that will export for price.

Evidence

Real site, Powerwall 2 (13.5 kWh), Intelligent Octopus Go import (6.9p / 28.56p), Octopus Outgoing Fixed export (flat 12p).

1. The control path is correct. Entering an export window, all four commands landed successfully:

22:05:41  POST grid_import_export  200        -> battery_ok, grid charging off
22:05:41  POST operation           200 Code 200 -> autonomous
21:53:36  POST time_of_use_settings 200 Code 201 -> boosted tariff
          (backup reserve deduped, device already at 4%)
22:05:58  record_status Exporting target 56%-4%

2. The tariff itself is correct. Rebuilt locally with the site's real rates — the boost lands exactly on the window, on the right day-of-week:

=== SELL side ===   rates: {"SUPER_OFF_PEAK": 0.12, "ON_PEAK": 0.58}
  SUPER_OFF_PEAK   day 3-3  00:00 -> 07:25
  ON_PEAK          day 3-3  07:25 -> 09:30
  SUPER_OFF_PEAK   day 3-3  09:30 -> 00:00
=== BUY side ===    rates: {"SUPER_OFF_PEAK": 0.07, "OFF_PEAK": 0.29, "ON_PEAK": 0.58}
  ON_PEAK          day 3-3  07:25 -> 09:30

3. The Powerwall just load-follows. Through the whole 80-minute Exporting target 56%->4% window, battery_power tracked load_power to the watt and grid stayed at zero:

22:41:54  soc=53.6%  batt=  440  solar=0  load=  440  grid=    0
22:45:55  soc=53.2%  batt=  500  solar=0  load=  500  grid=    0
22:51:57  soc=52.8%  batt=  570  solar=0  load=  570  grid=    0
23:12:04  soc=51.4%  batt= 2140  solar=0  load= 2140  grid=    0
23:24:08  soc=50.4%  batt=  500  solar=0  load=  500  grid=    0

SoC drifted 53.6% -> 50.0% on house load alone, against a 4% target.

4. Charging works instantly, which rules out a broken command channel. The moment the plan flipped to Charging at 23:26, the next sample obeyed:

23:28:09  soc=50.0%  batt=-3640  load=  658  grid= 4298

5. Same story with a full battery. A second window (07:25-09:30, armed at 08:59:56) held battery_power at exactly 0 W for all 30 minutes while 5-7 kW of solar exported freely:

09:01:22  soc=100.0%  batt=0  solar=5614  load=327  grid=-5287
09:15:27  soc=100.0%  batt=0  solar=5739  load=250  grid=-5489
09:29:31  soc=100.0%  batt=0  solar=6981  load=336  grid=-6645

Suggested fix

{"tou_settings": {"optimization_strategy": "economics", "tariff_content_v2": tariff}}

Notes for whoever picks this up:

• Include the strategy in the _apply_command dedupe signature so changing it forces a re-push.
• Worth asserting on every tariff push rather than once at boot — the customer's Tesla app can set it back to Balanced at any time, and there is no read endpoint to detect that drift (site_info does not expose optimization_strategy).
• Probably belongs behind the same read-only gate as the rest of sync_tariff.

Secondary issue (separate, lower priority)

Tesla clamps buy up to sell when buy < sell at any given time. On a flat-export tariff this bites overnight: buy SUPER_OFF_PEAK 0.07 vs sell 0.12, so the Powerwall models cheap IOG import as 12p and its own charge decisions are distorted. Not the cause of the export failure, but worth a look once export works.

Caveat

optimization_strategy is not exposed on any read endpoint, so the current device value could not be read back directly. The diagnosis rests on the field never being sent plus the behavioural signature (battery == load, grid == 0) matching documented Balanced behaviour exactly. Setting economics and observing a window is the confirming test.

Environment

• Predbat v8.48.8
• Tesla Backup Gateway 2 + 1x Powerwall 2, firmware 26.18.3
• Teslemetry API, teslemetry_automatic (TESLA inverter type)
• Not a regression — this site ran Read-Only until recently, so the component's export path had never actually been exercised.

[springfall2008]

Reference for API: https://developer.tesla.com/docs/fleet-api/endpoints/energy

[springfall2008]

Update: the fix is deployed and does not work — and the root cause remedy here is not achievable

v8.49.0 is running on the affected site with set_tariff implemented exactly as suggested above. It does not fix the problem, and testing against the live Fleet API tonight shows optimization_strategy cannot be set at all on a tariff_content_v2 site. The suggested fix should be withdrawn.

Worse, the follow-up testing undermines the whole mechanism, not just this field. Details below so nobody re-treads this.

1. optimization_strategy is silently discarded

After ~30 minutes of the fixed code POSTing {"tou_settings": {"optimization_strategy": "economics", "tariff_content_v2": tariff}} — eight calls, every one returning {"Message":"Updated","Code":201} — the device had no tou_settings object at all, while the tariff from those same POSTs was present and correct.

Four request shapes tested:

Body	Result	tou_settings after
optimization_strategy only	400 Must provide either a valid TOU setting or tariffID	null
optimization_strategy + schedule	400 same message	null
optimization_strategy + schedule + tariff_content_v2	200 Code 201 Updated	null
optimization_strategy + tariff_content_v2	200 Code 201 Updated	null

The pattern: a tariff must be present or the call 400s — and when a tariff is present, everything else in the body is silently discarded. schedule is dropped the same way. There is no request shape that persists the strategy on a tariff-based site.

2. Correction to my earlier claim

I stated above that "there is no read endpoint to detect that drift". That was wrong. site_info.tou_settings.optimization_strategy is readable — DarwinsDen/Tesla-Powerwall-Manager reads exactly that path. On this site it reads null, i.e. the site has no ToU settings record at all. So drift/absence is detectable even though it is not writable.

3. Price is not the lever either

The export mechanism assumes Time-Based Control will export if the sell price is attractive. It will not, at any price.

With mode autonomous, export rule battery_ok, backup reserve 4%, battery at 72% — all verified live on the device — the ON_PEAK band was raised to £500/kWh on both buy and sell (buy >= sell maintained, so no clamp), a 4167x contrast against the 0.12 baseline sell. Confirmed applied on the device. Result over 150 seconds:

ON DEVICE sell: {"ON_PEAK": 500, "SUPER_OFF_PEAK": 0.12}
  t+025s  soc=72.7%  batt=480  load=480  grid=0
  t+075s  soc=72.7%  batt=480  load=480  grid=0
  t+150s  soc=72.3%  batt=490  load=490  grid=0

Zero export. Battery tracked the house load to the watt. Original tariff restored and verified afterwards.

4. Full negative matrix

Variable	Result
optimization_strategy: economics (4 shapes)	Unsettable
Mode autonomous + boosted tariff	No export
Mode self_consumption + battery_ok	No export
Mode time_based_control	400 UpdateDefaultRealMode: Invalid mode (not a valid value; autonomous is correct)
ON_PEAK sell 0.58 (4.8x contrast)	No export
ON_PEAK sell 500 (4167x contrast)	No export
Site-level export blockers	None found

On that last row: net_meter_mode: battery_ok, customer_preferred_export_rule: battery_ok, edit_setting_permission_to_export: true, no export power limit (min_site_meter_power_ac: -1e9), and solar exports freely at 5-7 kW. The grid connection permits export; only battery export never happens.

Every device command was verified by reading site_info back, not by trusting the HTTP 200. Note that Tesla's cloud takes 1-2 minutes to reflect operation and grid_import_export writes — reading back sooner shows stale values and is misleading.

5. Comparison with a working setup

Scott Helme's v1 / v2 posts describe a UK Powerwall setup on Teslemetry that does export battery to grid. He runs autonomous (stated explicitly in v1) with battery_ok, and his automation manipulates only the export rule — no tariff push, no strategy.

Same mode, same export rule, same country, same tariff shape (7p/28p import, flat export). He exports; this site does not. The differences that remain are the ones we cannot write:

	Working setup	This site
Operation mode	autonomous	autonomous
Export rule	battery_ok	battery_ok
tou_settings	populated (rate plan set in app)	null
optimization_strategy	whatever the app set	unset, unsettable via API

6. Where this leaves the integration

Two possibilities remain, and they have very different consequences:

1. Balanced strategy suppresses merchant export. Then export requires the user to set Time-Based Control to "Cost Saving" in the Tesla app. Predbat cannot do this via the API, so it becomes a documented prerequisite plus a detect-and-warn on site_info.tou_settings.optimization_strategy.
2. TBC never does merchant export on this firmware (PW2, 26.18.3) — it only offsets house load and spills surplus solar. Then forced export is not achievable on Powerwall through the Fleet API at all, and the tariff-boost machinery cannot deliver it regardless of tuning.

The deciding test is a user action: set the Tesla app to Cost Saving and observe whether tou_settings populates and export begins.

Either way this issue is no longer "the tariff push is missing a field" — it is "the export mechanism does not work on this hardware". Suggest retitling and reopening; happy to do that if useful.

[springfall2008]

Superseded by #4610 — root cause found and confirmed live.

_tesla_dow() maps Python's weekday to a Sunday=0 convention, but Tesla's fromDayOfWeek is Monday=0. Every ON_PEAK boost band was written one day late, so the Powerwall never saw a high sell price during the actual export window. Correcting only the day index took a Powerwall from grid=0 to grid=-5156 (full 5 kW battery export) in under a minute.

The optimization_strategy finding in this ticket still stands as an API fact — it cannot be set alongside tariff_content_v2 — but it was not the cause of the export failure. See #4610 for the fix.