Optimizer: unsere Regeln als Eingaben im Beratungsmodus, einmaliges Netzladen - #4
Merged
Merged
Conversation
The optimizer request gets the fork's settings as inputs, so its plan already respects them, in the advisory as well as in the automatic mode: - peak shaving: the peak limit as hard grid import limit, the reserve as the home battery's minimum soc - soc-based grid charging: the start soc as minimum soc, so the charging is planned ahead before the battery would fall below it; while it runs the stop soc as goal within the grid charge window (advanced setting, default 3 h) - grid charging the load management or a peak refuses right now is not offered - a loadpoint plans with at most its circuits' power, priorities 0-10 map onto the optimizer's 0-2 One hook where the request is assembled. Without circuits, peak shaving and soc-based grid charging the request is unchanged (contract test). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 774c578)
…icle Loadpoint entries of the optimizer request are typed as vehicle once a vehicle is known, the inputs now cover both. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 0925307)
Sends a recorded request with the fork's inputs to the optimizer named by OPTIMIZER_URI and checks the plan: soc never below the minimum, the grid charge goal reached, grid import within the peak limit. Skipped unless OPTIMIZER_REPLAY and OPTIMIZER_URI are set. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 8f166ad)
…t case REPLAY_SETTINGS=limit,reserve,start,stop runs the recorded request with the installation's own settings. The charge case checks the grid charge goal is reached with room above the recorded peak; the conflict case checks the hard peak limit wins over the goal when there is no room. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 720a35c)
REPLAY_GRID_PRICE and REPLAY_SOC turn a recorded request into a realistic case, and the log compares the battery minimum without and with the fork's inputs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 3173269)
Started by hand, it grid-charges the home battery once up to the chosen
soc and then switches itself off: right away, or by a time of day at the
cheapest slots before it, picked by the upstream planner from the planner
tariff (charging right away once the time passed). It survives a restart,
can be cancelled and passes the same gate as the soc-based grid charging.
With the optimizer in control it is an optimizer input: the target soc as
goal at the chosen time, or right away at the earliest step the charge
power reaches it.
API: POST /batterygridchargeonce/{soc}[/{HH:MM}], DELETE to cancel;
state batteryGridChargeOnce {target, until, active}.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit e0f2a2e)
Below "Netzladen nach Ladestand": "Einmalig bis <soc> aus dem Netz laden", right away or by a time of day at the cheapest time, with a start and a cancel button and its state (charging or waiting for the cheapest time). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit c15fb25)
"Netzlade-Ziel erreichen in", 1-24 h, default 3: how long the optimizer may take to reach the stop soc of running soc-based grid charging. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The ui merges a published object into the previous one, so a field left out kept its old value: after starting right away the ui still showed the earlier time, and a finished charge still showed as charging. The state is now published with every field, until as null for right away. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
1 participant
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.
Kann direkt auf
load-peak-features: hängt von keinem offenen evcc-PR ab.Warum
Deine custom-Instanz fragt den Optimizer jetzt im Beratungsmodus an. Er kannte aber unsere Regeln nicht. Replay mit deiner echten Anfrage (Fahrzeug 80 kWh, Batterie 16,6 kWh, 408 Viertelstunden) gegen den Optimizer auf dem Pi, bei realistischen 30 ct Bezugspreis und halbvoller Batterie:
Bei den aktuell eingestellten 10 ct Bezugspreis entlädt der Optimizer die Batterie gar nicht (Netzstrom ist kaum teurer als der Wert der gespeicherten Energie). Das ist Optimizer-Logik, kein Fehler.
Was es macht
Unsere Einstellungen als Eingaben an den Optimizer (eigene Datei, ein Anschluss beim Zusammenbau der Anfrage):
Einmaliges Netzladen auf der Batterieseite unter „Netzladen nach Ladestand“: sofort oder bis Uhrzeit zur günstigsten Zeit. Mit Abbrechen-Knopf, läuft über Neustarts weiter, endet von selbst, gleiche Prüfung wie das Netzladen (Spitze, Stromkreis, Ladeleistung).
Unverändert: Ohne Stromkreise, Peak Shaving, Netzladen nach Ladestand und einmaliges Netzladen ist die Anfrage an den Optimizer identisch (Vertragstest). Der Beratungsmodus steuert nichts.
Der Automatik-Modus (Sicherheits-Gate, Hinweise) bleibt in PR 3, der auf evcc PR 32881 wartet. Die Commits hier sind dort ebenfalls enthalten und fallen beim späteren Umsetzen weg.
Getestet
🤖 Generated with Claude Code