Negative export compensation

[TomasSandstrom]

What happened

My net provider have added a cost for export making my "nätnytta" negative.

I should be able to set Export Compensation (SEK/kWh) as a negative price.

Debug bundle

Please drag-and-drop bess-debug-2026-08-21-093531.md from your Downloads folder into the editor below before submitting.
The file contains your version, settings, recent logs, and the raw HA discovery dump that the maintainers need to reproduce the issue.

[bess-agent]

Diagnosis

Root cause: The "Export Compensation" (Nätnytta) field is UI-restricted to non-negative values only, with no backend enforcement and no downstream code that assumes a non-negative sign.

• frontend/src/components/settings/PricingFormSection.tsx:135-137 — numField('Export Compensation', form.taxReduction, ..., { min: 0, step: 0.001 }). The HTML min attribute only affects the spinner; there's no checkValidity()/reportValidity() call before save, so it's a soft, misleading restriction, not a hard block — but it does actively prevent using the spinner to reach negative values and visually signals "must be ≥ 0".
• Confirmed no backend validation anywhere in the chain: core/bess/settings.py's PriceSettings has no __post_init__ (unlike BatterySettings/HomeSettings, which do validate), backend/api_dataclasses.py:1144 (taxReduction: float | None) has no Pydantic bound, and backend/api.py's patch_settings passes the electricity_price section through with no numeric check.
• Confirmed the DP/economics chain is sign-agnostic: core/bess/price_manager.py:467 computes sell_price = base_price * export_spot_multiplier + tax_reduction as plain arithmetic; dp_battery_algorithm.py's reward math (_price_period_flows, lines 867-916) and discharge gate (_record_marginal_value, lines 953-960) both handle a negative sell_price/shadow_price correctly (export becomes a cost, discharge gate closes more), with no max(0, ...) ever applied to price terms — only to energy quantities. Negative Nordpool spot prices already exercise this same code path today.
• Notably, the ENTSO-e variant's own help text right below the same field (line 147) already says "Use negative values for deductions" — directly contradicting the min: 0 on the widget it describes. This is a pre-existing internal inconsistency, not introduced by this fix.

Evidence quoted above is independently verified against current source (not just the sub-agent's report).

Proposed fix

Remove the min: 0 constraint on the "Export Compensation" field in PricingFormSection.tsx:135-137 (Nordpool/ENTSO-e view). No backend change is required — the value already flows correctly end-to-end once the UI stops blocking it.

The Octopus "Tax Reduction" field (PricingFormSection.tsx:193-195) has the identical min: 0, but the issue is specifically about Swedish nätnytta — leaving that one alone unless asked, to keep the diff minimal.

Workaround check

This diff adds nothing — no parameter, flag, default-fallback, second construction site, or extra trigger — that routes around an ordering/timing/dependency problem. It removes an incorrect input constraint at its source; nothing downstream needs a workaround because nothing downstream was broken.

Scope assessment

Local. The fix stays entirely within the target field's existing contract: it's a one-attribute change to an existing form field, no new owner, no structural change, no schema/API/optimizer touch needed since those already tolerate negative values correctly.

Plan

1. TDD: add/adjust a frontend test asserting the Export Compensation field accepts and round-trips a negative value (and that the preview Sell price calc reflects it).
2. Remove min: 0 from that field.
3. Quality gate + code review (background).
4. Verify: run the dev server, enter a negative Export Compensation value, save, confirm it persists and the sell-price preview reflects it.
5. Draft PR against main, Refs #666.

Proceeding on go-ahead. Reply on this issue to confirm, redirect, or stop.

[johanzander]

Proceed.

[bess-agent]

Step 6/7 report — quality gate

Fix applied: removed min: 0 from the Export Compensation field (Nordpool/ENTSO-e view) in frontend/src/components/settings/PricingFormSection.tsx:135-137, matching the diagnosis and your go-ahead. Octopus's identical taxReduction field left untouched (out of scope, per the diagnosis).

RED test → GREEN: added frontend/src/components/settings/__tests__/PricingFormSection.test.tsx. Before the fix, expect(input).not.toHaveAttribute('min', '0') failed (min="0" was present). After the fix, both tests pass — negative values round-trip through onChange, and the sell-price preview reflects a negative Export Compensation correctly.

Fast suite: 2177 passed, 1 pre-existing failure — test_dismiss_persists_across_requests (backend/tests/test_dashboard_api.py) fails only when run as part of the full suite (test-order pollution), passes standalone (59/59). My diff touches only frontend files, so it cannot be the cause. Reproduced identically on two separate full-suite runs.

Slow suite: 554 passed, 0 failed.

TypeScript/lint/black/ruff/mypy: all clean.

This diff touches the frontend (per Step 7, that's a stop-and-confirm rather than an auto-continue). Reply to proceed to Step 8 (local verification) and PR, or redirect.

[johanzander]

Proceed.

[bess-agent]

Draft PR opened: #672

[johanzander]

Diagnosis of the #672 E2E + Fast-tests failures — pre-existing, not caused by this PR:

Both failures are the same class: tests not hermetic to the wall clock, and CI landing in the 00:00–01:00 UTC window:

1. E2E (inverter-schedule-control-model.spec.ts, VPP case): the mocked period group is 00:00–01:00. While the real clock is inside that window, getCurrentPeriodGroup() treats it as current, so the Current Strategy card renders a second "+35% (Remote)" and the strict getByText('+35%') resolves to 2 elements.
2. Fast (test_dismiss_persists_across_requests): test_app_startup.py loads real app.py, which leaks set_timezone("UTC") into the shared time_utils.TIMEZONE. At UTC hour 0 the endpoint computes zero missing hours → is_incomplete=False → dismissed always False.

Both pass outside the 00:00–01:00 UTC window. A rerun inside the window fails again — so hold the CI loop until 01:00 UTC, then rerun the failed jobs on #672; they'll go green. Root-cause fix is up as PR #673. I'm handling #671 (same flakes) on my side.

[johanzander]

Go ahead. Stay on Step 10: I'm rerunning #672's failed jobs at 01:00 UTC (the flake window ends then). When checks go green, proceed to Step 11 (request review) and drive it through. No action until the rerun lands.