Repository navigation
feat(backend): model the PV forecast in-process - #1041
Merged
Merged
Conversation
Replaces the external Python CLI and its timer. `pv/forecast/` reads three more parameters from the Harmonie stored query the weather module already calls, then runs Perez-Driesse transposition, Martin & Ruiz reflection losses, King module temperature and Huld DC output. Every step is checked against pvlib reference values in `pv/forecast/testdata/`. Configuration is the array's mounting only — PV_TILT, PV_AZIMUTH, PV_KW. Position is the house pin already in `user_settings`. BREAKING CHANGE: `POST /api/pv/forecast` is removed. Hours whose radiation is missing from the FMI response are omitted rather than published as 0 W.
eetu
force-pushed
the
pv-forecast-rust-port
branch
from
September 8, 2026 19:39
6226b92 to
d653640
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the external Python CLI and its three-hourly timer with the model
itself, in
backend/src/pv/forecast/. It adds three parameters to the Harmoniestored query the weather module already calls, then runs Perez-Driesse
transposition onto the plane of the array, Martin & Ruiz reflection losses, King
module temperature and Huld DC output.
parse_timeseries_xmland thepv_forecast_pointsstorage are reused as they stand. One new dependency,solar-positioning(MIT, chrono-only).Configuration is the array's mounting only:
PV_TILT,PV_AZIMUTH,PV_KW. Position is the house pin already inuser_settings— the oneLocationFormwrites and the weather and sunrise views use. Until it is set theloop idles.
Breaking:
POST /api/pv/forecastis removed, along withscripts/refresh-pv-forecast.sh. Nothing here consumed it; the frontend onlyread.
../raspi/tasks/halo.pystill provisions a timer that POSTs to it, whichneeds retiring if that host has not yet moved to keel.
Verification
73 tests, clippy and fmt clean. Every model step is checked against pvlib
reference values committed in
pv/forecast/testdata/: splines and Perez-Driesseto 1e-9, reflection to 1e-12, and a synthetic clear-sky day through the whole
chain at 1e-4 relative — two NREL SPA implementations agree only to about 1e-5
degrees, which grazing incidence amplifies.
FMI stamps each accumulation at the end of the hour it covers, so sun position
is taken at the hour's midpoint and the point labelled with its start. A fixture
test pins the labels, since getting it wrong shifts every value by an hour
without any value-level test noticing.
scripts/compare-pv-forecast.pydiffs this against the Python implementation onlive FMI, neither touching the database:
The five reference-only hours are ones whose radiation FMI did not supply. The
Python implementation reports those as
0 W, including hours when the sun wasup; this omits them.