Feature Request: Capacity/Peak Tariff (Effektavgift) Support for Operators Who Retain Peak Tariffs

[tomasvonhofsten]

Summary
Request to add native support for capacity-based grid tariffs (effektavgift) to the BESS Manager optimization engine. While the Swedish government stopped the mandatory requirement for all grid operators to introduce peak tariffs by January 2027 in March 2026, there is nothing in legislation that prohibits peak tariffs, and during the interim period it is up to each grid operator whether they want to apply them. Several operators including my own (SEOM, Sollentuna) are continuing with their existing peak tariff structure, meaning this feature remains relevant for a meaningful subset of Swedish BESS Manager users. GitHubHome Assistant

Background — Swedish Effektavgift Structure
As of March 2026, 21 of Sweden's approximately 170 grid operators had introduced peak tariffs for household customers. These operators can continue applying their tariffs voluntarily. The billing model typically works as follows: github

Measurement: Average of the 3 highest hourly grid import values during Mon–Fri 07:00–19:00 each month
Exclusions: Weekends and public holidays excluded from measurement
Charge: Monthly fee per kW of average peak

My operator (SEOM, Sollentuna):

Winter rate (Nov–Mar): 145 SEK/kW/month
Summer rate (Apr–Oct): 72.5 SEK/kW/month
Peak window: Mon–Fri 07:00–19:00 (public holidays excluded)
Measurement: Top 3 hourly peaks averaged

The Problem with Current BESS Manager Behaviour
BESS Manager currently optimizes purely for energy cost (spot price + markup + grid fees per kWh). It has no awareness of capacity tariff costs. This means it can decide to:

Charge the battery from the grid during 07:00–19:00 Mon–Fri if spot prices are low — adding 5 kW of grid draw during the peak measurement window
Not discharge the battery to cover home loads during a peak demand moment — missing an opportunity to reduce the measured peak

In my case with a 15 kWh Growatt ARK battery and 5 kW max charge power, an unnecessary grid charge during peak hours could add 5 kW to my monthly peak measurement, costing an extra 725 SEK/month in winter — far exceeding any energy cost saving from buying cheap electricity.

Proposed Solution
Add capacity tariff awareness to the DP optimization engine with the following configuration parameters:
yamlpeak_tariff:
enabled: true
rate_winter: 145 # SEK/kW/month (Nov-Mar)
rate_summer: 72.5 # SEK/kW/month (Apr-Oct)
peak_window_start: "07:00"
peak_window_end: "19:00"
peak_days: [mon, tue, wed, thu, fri]
exclude_public_holidays: true
measurement_method: top3_hourly_average
current_month_peak_sensor: sensor.tibber_pulse_max_power
Optimization logic addition:
For each period inside the peak window, add a capacity cost term to the DP objective:
pythonif is_peak_window(period) and not is_holiday(period):
projected_grid_draw = home_consumption - solar_production + battery_charge_power
if projected_grid_draw > current_month_peak_kw:
capacity_cost = peak_tariff_rate / periods_in_month
effective_buy_price += capacity_cost
Additionally, during peak windows the optimizer should consider discharging the battery to cover home loads even when energy prices don't justify it, if doing so prevents a new monthly peak being set.

Current Workaround
As a workaround I've implemented a HA automation that blocks the switch.charge_from_grid entity during peak hours and excludes public holidays using the HA Holiday calendar. This prevents the worst case but doesn't give BESS Manager the intelligence to actively use the battery to suppress peak demand:
yamlalias: "BESS - Peak window grid charge guard"
trigger:

• platform: time_pattern
  minutes: "/15"
  condition:
• condition: time
  after: "07:00:00"
  before: "19:00:00"
  weekday: [mon, tue, wed, thu, fri]
• condition: template
  value_template: >
  {% set holidays = ["New Year's Day", "Epiphany", "Good Friday",
  "Easter Sunday", "Easter Monday", "May Day", "Ascension Day",
  "Whit Sunday", "National Day", "Midsummer Eve", "Midsummer Day",
  "All Saints' Day", "Christmas Eve", "Christmas Day", "Boxing Day",
  "New Year's Eve"] %}
  {{ state_attr('calendar.sweden', 'message') not in holidays }}
• condition: state
  entity_id: switch.qdl3da90yp_charge_from_grid
  state: "on"
  action:
• service: switch.turn_off
  target:
  entity_id: switch.qdl3da90yp_charge_from_grid
  This is reactive rather than intelligent — BESS doesn't factor capacity cost into its planning horizon.

Tibber Pulse Integration Opportunity
For users with Tibber Pulse, sensor.tibber_pulse_monthly_peak_hour_consumption provides the current month's highest measured peak. This could feed directly into the optimizer to understand how close the current hour is to setting a new monthly peak — enabling more nuanced decisions.

Impact
With winter effektavgift rates of 145 SEK/kW/month, a single unnecessary 5 kW grid charge during peak hours costs 725 SEK — equivalent to many months of energy cost savings from BESS optimization. For users on capacity tariffs, this feature is arguably more financially impactful than spot price optimization.
Happy to test any implementation and provide feedback from a real SE3 installation with Growatt ARK 15 kWh + MOD 10KTL3-XH + Tibber Pulse.

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

BESS Manager's DP optimizer has no concept of capacity/peak tariffs. Its entire cost model lives in _compute_reward in core/bess/dp_battery_algorithm.py and reduces to a single expression: total_cost = grid_imported * current_buy_price - grid_exported * current_sell_price + battery_wear_cost. There is no term for the monthly peak charge that Swedish effektavgift operators levy. As a result, the optimizer treats a 5 kW grid charge at 07:30 on a Monday identically to the same charge at 03:00 — it cannot prefer off-peak windows or actively suppress a new peak measurement, making it blind to the financially dominant cost for users on capacity tariffs.

Evidence

• core/bess/dp_battery_algorithm.py:258–259 — per-period prices are already array-indexed; this is the natural injection point:

  current_buy_price = buy_price[period]
  current_sell_price = sell_price[period]

• core/bess/dp_battery_algorithm.py:362–367 — the complete cost model, confirming no capacity term exists today:

  total_cost = (
      grid_imported * current_buy_price
      - grid_exported * current_sell_price
      + battery_wear_cost
  )
  return -total_cost, new_cost_basis

• core/bess/settings.py:224–254 — TemperatureDeratingSettings is the established pattern for optional nested config blocks (enabled: bool = False, own from_ha_config, reads from battery.temperature_derating); a new PeakTariffSettings should follow this exactly.
• backend/settings_store.py:23–30 — the OWNED_SECTIONS tuple that must include any new top-level section persisted to /data/bess_settings.json.

Proposed fix

No changes to the DP algorithm itself are needed. The existing buy_price: list[float] parameter already supports per-period prices. The implementation has four parts:

1. core/bess/settings.py — add a PeakTariffSettings dataclass mirroring TemperatureDeratingSettings, with fields: enabled, rate_winter (SEK/kW/month, Nov–Mar), rate_summer (SEK/kW/month, Apr–Oct), peak_window_start/end (default 7/19), peak_days (default Mon–Fri), exclude_public_holidays, and current_month_peak_sensor (optional HA entity ID for Tibber Pulse or similar).

2. backend/settings_store.py — add "peak_tariff" to OWNED_SECTIONS.

3. core/bess/battery_system_manager.py — in _run_optimization — before calling optimize_battery_schedule, build a capacity_adjusted_buy_prices list. For each period in the optimization horizon: if the period falls within the configured peak window (weekday, correct hours, not a holiday) and peak tariff is enabled, compute a marginal capacity cost adder using the amortization formula:

   marginal_kw_cost = max(0, projected_grid_kw - current_month_peak_kw) * rate_per_kw
   adder = marginal_kw_cost / (remaining_peak_windows_this_month * dt_hours)
   buy_price[period] += adder
   

   The current month's peak is read once at optimization start — either from the Tibber sensor (current_month_peak_sensor) via the existing HAApiController sensor-read path, or from a self-maintained rolling list.

4. core/bess/models.py (optional) — add a capacity_tariff_savings field to EconomicSummary so the dashboard can report capacity cost avoidance alongside energy savings.

Risks / open questions

Key architectural challenge — monthly cost in a 24h window: Effektavgift is non-convex and monthly-scoped: the marginal cost of 1 kW extra grid import depends on whether it would set a new top-3 peak. The DP only sees ~24–48 hours ahead. The proposed amortization heuristic (divide monthly rate over remaining peak windows) is the standard commercial BESS approach and is directionally correct, but it slightly overestimates cost early in the month and slightly underestimates it near month-end. This is acceptable given the optimizer already operates on price forecasts.

State dependency: The optimizer needs to know the current month's running top-3 average at the start of each run. If Tibber Pulse is not available, an alternative is computing it from HistoricalDataStore grid-import data — but this adds implementation complexity. The sensor-based path (Tibber or equivalent) is simpler and should be the primary path, with a graceful fallback to zero (i.e., assume worst-case: any grid import during peak hours could set a new peak).

Holiday exclusion: The proposed exclude_public_holidays flag requires a holiday data source. The simplest HA-native approach is to read a binary_sensor.workday entity (a very common HA integration), which already handles public holidays per locale. A static per-year list is a simpler fallback.

top3_hourly_average vs other methods: The measurement method varies by operator. The implementation should make this configurable but only implement top3_hourly_average initially — other operators can be added later.

Testing: The amortization formula and peak-window classification logic should be unit-tested with fixed inputs. End-to-end behaviour (does the optimizer actually avoid charging during peak windows?) should be tested with a mock HA scenario using the existing debug-export → mock-HA framework.

---

Reply @claude-bot fix to implement and open a draft PR.