PV: track energy metrics and apply forecast scaling to optimizer

[andig]

Summary

Three related changes around PV energy and the solar forecast scale factor:

1. Per-PV metrics.Collector (core/site.go)

   • Adds pvCollectors map[string]*metrics.Collector keyed by meter ref, group pv
   • Created alongside the existing in-memory pvEnergy accumulator in Boot()
   • Fed in updatePvMeters via AddEnergy(&mm[i].Energy if >0, nil, mm[i].Power) mirroring the grid/battery patterns
   • Each PV meter now surfaces in the History UI as its own series, so individual modules can be tracked / replaced without losing prior history.

2. Reusable solarScale() helper (core/site_tariffs.go)

   • Extracts the existing produced/forecasted ratio calc out of solarDetails so the optimizer can call it without re-running the side effects (AddImportEnergy, settings persist).
   • Identical thresholds (fcst > 0, produced+fcst > 0.5 kWh) — no behavior change in the published solarDetails.Scale.

3. Optimizer applies the scale (core/site_optimizer.go)

   • Previously fed the raw solar forecast into the optimizer regardless of how reliable it had been.
   • Now multiplies the pruned solar rates by solarScale() when available, so the optimizer reflects consistent under-/over-production rather than the bare forecast.

4. Re-expose the adjusted-forecast toggle in the UI (assets/js/views/Forecast.vue)

   • The && false guard was added in Forecast UI: real data adjust (-100 %) #29165 (forecast metrics could go inconsistent on restart).
   • The underlying issue was addressed by resetSolarForecastMetrics, so the experimental toggle is unblocked.

Test plan

• go build ./... clean
• gofmt -l clean on touched Go files
• go vet ./core/... clean
• go test ./core/... -count=1
• npm run lint (eslint, vue-tsc, i18n) clean
• Manual: configure multiple PV meters, observe per-meter rows in meters table under group pv
• Manual: run for >0.5 kWh of accumulated forecast+produced, confirm solar.scale is published and Forecast view exposes the adjust toggle in experimental mode
• Manual: confirm optimizer logs reflect scaled solar input (DEBUG solar forecast: ... scale ...)

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

Hey - I've left some high level feedback:

• In updatePvMeters, the error log persist pv %d energy only includes the index; consider including the PV meter name (name) to make diagnosing persistence issues easier.
• solarScale is now called both from solarDetails and the optimizer, which will duplicate the solar forecast: ... DEBUG logs each cycle; consider either centralizing the call or making logging conditional to avoid noisy duplicate entries.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `updatePvMeters`, the error log `persist pv %d energy` only includes the index; consider including the PV meter name (`name`) to make diagnosing persistence issues easier.
- `solarScale` is now called both from `solarDetails` and the optimizer, which will duplicate the `solar forecast: ...` DEBUG logs each cycle; consider either centralizing the call or making logging conditional to avoid noisy duplicate entries.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[andig]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Merge conflicts are resolved. I merged the remote PR branch and master, kept the branch pushable, and pushed the result in 2f38765.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 192.168.1.1
  • Triggering command: /tmp/go-build1799151314/b1500/service.test /tmp/go-build1799151314/b1500/service.test -test.testlogfile=/tmp/go-build1799151314/b1500/testlog.txt -test.paniconexit0 -test.timeout=10m0s -j ACCEPT mpile ux-amd64/pkg/tool/linux_amd64/vet -errorsas shservice mpile ux-amd64/pkg/too-buildtags -o off/v5@v5.0.2/ba-errorsas off/v5@v5.0.2/er-ifaceassert 0.1-go1.26.0.lin-nilfunc -p hub.com/golang/g-w mpile 0.1-go1.26.0.linsecurity (packet block)
• 224.0.0.251
  • Triggering command: REDACTED, pid is -1 (packet block)
• 239.12.255.254
  • Triggering command: REDACTED, pid is -1 (packet block)
• api.awattar.at
  • Triggering command: /tmp/go-build1799151314/b1451/tariff.test /tmp/go-build1799151314/b1451/tariff.test -test.testlogfile=/tmp/go-build1799151314/b1451/testlog.txt -test.paniconexit0 -test.timeout=10m0s /tmp/go-build1799151314/b1389/_pkg_.a ecode_amd64.s ncode_amd64.s ux-amd64/pkg/tool/linux_amd64/vet -errorsas se/go-jose/v4/js-atomic mpile qy2w7f007j8N -o r/shoutrrr@v0.14-errorsas tainer/heap/heap.go ux-amd64/pkg/tool/linux_amd64/compile (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[naltatis]

@premultiply is PV production import (implemented here) or export? Looking at the other PR discussions I think we might need to swap here. Can you formulate a rule/rules that we can use in documentation? or even better a simple markdown table for all device types we have (battery charge = import, ...).

[andig]

@naltatis see #29788 (comment): production is export.
@premultiply this gets confusing though since all PV inverter power values would be positive in that case which would get mapped to the metrics import column unless we deliberately switch the sign?

[premultiply]

Definition: energy direction is from device to energy grid.

Meter type	Import	Export	Positive Power
grid	buy / A+ / 1.8.0	sell / A- / 2.8.0	Import
battery	charging(+self-consumption)	discharging	Export
pv	self-consumption	production	Export
ext	consumption	(production)	Import
aux	consumption	(production)	Import
charge	charging(+self-consumption)	(V2X)	Import

Current "legacy" energy mapping is marked in bold. This is also our internal positive power direction (most important / "main usage").

[naltatis]

@premultiply just to be clear: self-consumption == self-consumption of the device (like standby power), right?

[premultiply]

Yes. This may or may not included in the measurement of the device. Depends on the device and internal setup itself.
But we do not care about self-consumption in detail. Just the be precise that it may be included here.

[VolkerK62]

So battery and pv will have the opposite sign as "normal" (e.g. in log)?

[andig]

I've added designator for positive power in table above- still doesn't feel consistent.

[andig]

Table represented as diagram. We're still not clear regarding the metrics table how we want to use import/export and how that aligns with the current device power signs:

---
Energy flow
---
flowchart
    loadpoint(Loadpoint)
    site((Site))
    grid(Grid)
    pv(PV)
    battery(Battery)

    grid -- Consumption
    (+ import/energy) --> site
    site -- Feed-in
    (- export/return energy) --> grid

    pv -- Production
    (+ export/energy) --> site

    site -- Charge
    (- import/return energy) --> battery
    battery -- Discharge
    (+ export/energy) --> site

    site  -- Consumption
    (+ import/energy) --> loadpoint

Loading

[florian240483]

Just a thought:
Energy and current flow basically follows Kirchhoff's current law. One possible convention for energy flow could be: Define Site as a node; all incoming connections are counted as positive, all outgoing connections as negative.

[andig]

Long story short: we're dumping the import/export concept and settle on energy/return energy.