SlotWrapper: linear interpolation for solar tariffs shifts energy between time slots

[1va13n7in]

Describe the bug

SlotWrapper splits 30-minute forecast slots into 15-minute sub-slots.
For solar tariffs, it interpolates between the current and next slot
value (tariff/slots.go lines 46-52). Price tariffs use constant values.

Solcast and similar sources provide average power per period. A 30-min
slot with 10000W means 5000 Wh. Both 15-min sub-slots should keep
10000W to preserve this.

The interpolation shifts energy from afternoon into morning and has no
benefit: the sub-slot resolution is artificial, the source data has no
information at 15-min granularity.

Removing the switch block (6 lines) fixes the issue and simplifies the
code. Solar sub-slots would use constant values like price tariffs
already do.

Steps to reproduce

1. Configure a solar tariff with a source that provides 30-minute slots
   (e.g. Solcast via Home Assistant)

2. Run: evcc tariff solar

3. Observe that 15-min sub-slot pairs have different values:
   2026-07-23 17:00:00 2026-07-23 17:15:00 12508.900
   2026-07-23 17:15:00 2026-07-23 17:30:00 12464.650

4. The source data has one value for the full 30 minutes.
   Both sub-slots should show the same value (12508.900).

5. Sum all slot values × 15min and compare with the raw forecast sum.
   They differ because the interpolation shifts energy between slots.

Expected behavior:

Both 15-min sub-slots of a 30-min source slot should have the same
value, preserving total energy per slot. This is how price tariffs
already work.

Configuration details

$ kubectl -n evcc exec deploy/evcc -- evcc dump --cfg
[main  ] INFO 2026/07/23 21:37:53 using config file: /etc/evcc.yaml
[main  ] INFO 2026/07/23 21:37:53 using sqlite database: /root/.evcc/evcc.db?_pragma=busy_timeout(5000)&_pragma=foreign_keys(1)&_pragma=auto_vacuum(INCREMENTAL)
[eebus ] INFO 2026/07/23 21:38:03 Local SKI: d5169309c37270892efc2fff7809d63f62cb8414
[ha-meter] WARN 2026/07/23 21:38:03 using deprecated 'home' parameter 'HomeAssistant', please use 'uri' instead
[ha-meter] WARN 2026/07/23 21:38:03 using deprecated 'home' parameter 'HomeAssistant', please use 'uri' instead
[ha-meter] WARN 2026/07/23 21:38:03 using deprecated 'home' parameter 'HomeAssistant', please use 'uri' instead
[main  ] INFO 2026/07/23 21:38:05 circuit victron has no meter and no loadpoint assigned

Version: `0.311.1`

Log details

From                   To                     Yield (W)
2026-07-23 17:00:00    2026-07-23 17:15:00    12508.900
2026-07-23 17:15:00    2026-07-23 17:30:00    12464.650
2026-07-23 17:30:00    2026-07-23 17:45:00    10762.500
2026-07-23 17:45:00    2026-07-23 18:00:00    10718.250

Each pair originates from a single 30-min Solcast slot but shows
different values due to interpolation. The second sub-slot is always
shifted towards the next slot's value.

What type of operating system or environment does evcc run on?

Linux

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

evcc version 0.311.1

[github-actions]

Thanks for the detailed writeup and reproduction steps — the described behaviour matches the code exactly.

Root cause / explanation: the interpolation in tariff/slots.go:45-53 is intentional, not a defect. SlotWrapper.Rates() currently models solar forecast values as instantaneous power at the slot's start timestamp, and linearly interpolates between consecutive slot-start values to fill in the 15‑minute sub-slots (see TestSolarAndCo2Interpolation in tariff/slots_test.go, which explicitly pins this behavior and references #23184).

This is exactly the tradeoff discussed in #23184 ("Solar forecast: switch from power at time to energy during period"), which is still open and lists as TODO to "figure out where we're using this (optimizer, solar forecast, solar forecast scaling...)" before making the switch. Your point that Solcast-style sources report mean power over the interval (i.e. energy) rather than power-at-a-point is valid and is essentially the argument for the change proposed in that issue — but switching the interpretation isn't confined to tariff/slots.go: it affects any consumer that currently assumes "power at timestamp" semantics for solar rates (optimizer, forecast scaling, etc.), per the issue's own TODO list. That's a broader design change than the isolated 6-line removal suggested here, so it needs to be resolved together with #23184 rather than as a standalone bug fix.

Given this is existing, intentionally-tested behavior with an open design discussion tracking the exact change requested, I'm not treating it as a bug and won't be opening a fix PR from this triage — please continue the discussion on #23184, or a maintainer can decide to pick this up there.

🤖 Generated with Claude Code

[andig]

@1va13n7in see #32114. I'm not sure if we should invest this effort (right now) or rather fix any specific solcast issue while maintaining status quo otherwise.

[andig]

Pls. let me know if you want #32116 to land short-term. My personal experience with Solcast is that (for Germany) the predictions are not too precise.

[andig]

With #32116 landed this should fix the energy distribution. Please let me know if this works.

[andig]

Follow-up, since #33105 proposes to revert the direction of #32116.

Re-reading this with the consumer side in mind, the two candidate readings of a solar Value are not equally supported by the code:

• core.solarEnergy treats it as the power sampled at Start and integrates trapezoidally between consecutive starts. Everything goes through it — the published timeseries, the today/tomorrow totals, the persisted forecast metric and the optimizer input (solarRatesToEnergy).
• Nothing computes the sum of slot values × 15min, which is the quantity the report in point 5 above compares against the raw forecast sum.

That matters for what "preserving the energy" means. #32116 preserves the sum of values per source slot but changes what solarEnergy returns for any window that is not a whole day. On hourly rates 0, 1000, 2500, 3000, 1500, 0 W the energy from hour 2 to the end goes from 5750 Wh to 6745 Wh (+17%), from hour 3 from 3000 Wh to 4117 Wh (+37%). The full-day figure telescopes back to the correct value because a day starts and ends at zero, which is why the daily totals look untouched. solarDetails.Today, the optimizer horizon and each individual 15min slot handed to the optimizer are all partial windows.

Two data points on the sources with slots longer than 15min, which are the only ones reaching this code path:

forecast.solar ships point samples, not period means, despite what its documentation says. The docs describe watts as "average for the period ... from last timestamp to the timestamp in the key", but the response contradicts that — watt_hours_period is the trapezoid of watts between consecutive timestamps, to the watt-hour:

ts                   watts   whp   trapz(prev,cur)   watts*dt
2026-08-23T07:00:00Z  1041    726       726.0         1041.0
2026-08-23T08:00:00Z  2093   1567      1567.0         2093.0
2026-08-23T09:00:00Z  2533   2313      2313.0         2533.0
2026-08-23T12:00:00Z  2362   2505      2505.0         2362.0

If watts were the period mean, watt_hours_period would be the last column. core.solarEnergy computes exactly forecast.solar's own definition, and only linear interpolation between the source points preserves that identity.

Solcast through evcc's own integration never produces 30min slots. tariff/solcast.go buckets the PT30M estimates by BeginningOfHour(period_end), so an hourly value is the mean of the two half-hours meeting at the hour start — a centred point sample, which the shaping then smears.

Which leaves the case actually reported here: a source handing evcc raw 30min period means, Solcast piped through Home Assistant. For that input solarEnergy is already wrong before any splitting — means 12500 @17:00, 10750 @17:30, 9000 @18:00 integrate to 10750 Wh across the hour where the true figure is 11625 Wh. SlotWrapper neither introduced that nor can repair it; the mean-preserving split only makes the sub-slots look consistent with a reading nothing downstream shares.

The repair for a period-mean source is to resample it to point samples on the way in, which is a two-tap centred filter over the two intervals meeting at each grid timestamp — what solcast.go does implicitly and what #33102 just did for pvnode. For a custom or Home Assistant sourced tariff that has to happen in the tariff's own jq, since evcc cannot tell a mean series from a sampled one. Changing the interpretation globally instead is #23184.

🤖 Generated with Claude Code