evcc master 12.10. übernehmen (Automatik-Modus)

[SolarPower2024]

Worum es geht

evcc master bis ed7828c (55 Commits seit 0.317.1) übernehmen. Ausnahme von der Release-Regel, freigegeben am 12.10.: der Automatik-Modus des Optimizers (evcc PR 32881) ist gemergt, aber in keinem Release.

Was evcc mitbringt (für den Fork wichtig)

• Optimizer: Automatik-Modus (Aus / nur Batterie / Batterie und Ladepunkte), Lauf alle 5 min im Automatikbetrieb (evcc PR 32881), dazu evcc PR 34644, 34678, 34689, 34738
• Phasen: 3p-Mindestladen endet nach einer Abschaltverzögerung, wenn 1p nicht reicht; 1p-Projektion aus dem gemessenen Strom (evcc PR 34752, 34755)
• Stromkreis: gebrochener Mindeststrom (evcc PR 34750)
• Marstek lädt im Haltemodus (evcc PR 34497), Entladen ins Netz nur bei fähigen Batterien (evcc PR 34685), Temperatur-Entität für Heizgeräte am HA-Charger (evcc PR 34614)

Konflikte und wie gelöst

• core/loadpoint.go setLimit: evccs requestedPower übernommen, unser lmCircuit() bleibt
• core/loadpoint.go pvScalePhases: evccs neue disable-Logik übernommen; unsere Hooks bleiben (min1pCurrentOr für die 1p-Schwelle, phaseScaleDelay(1) statt der Abschaltverzögerung). Ohne eigene Verzögerung verhält es sich wie evcc
• core/loadpoint/config.go: applyPhaseSwitch vor evccs cmp.Or(err, limitErr)
• i18n/de.json: evcc-Text („PV & Speicher“), eigener Key peakshaving bleibt

Ohne Konflikt angepasst: optimizerUpdateAsync nimmt jetzt force bool statt minAge. lmOptimizeLater und die eigenen Aufrufe (Reserve-Lauf, Schnee) folgen.

Upstream zuerst

• Automatik-Modus: ersetzt keinen Fork-Code direkt. Unsere Optimizer-Eingaben (Peak-Grenze, Reserve, SoC-Netzladen) bleiben. Der Umbau von PR 3 (Vorschau) auf den echten Modus folgt als eigener PR
• Batterie-Vermessung: Fehlalarm, watch.json geschärft

Entscheidung nötig / bekannt

Der Automatik-Modus ist standardmäßig aus, der Fork verhält sich dann wie bisher. Eingeschaltet gilt bis zum Umbau von PR 3:

• bei aktivem Peak Shaving (Reserve) setzt der Fork die Batterie weiter auf normal, er hat Vorrang vor dem Optimizer
• SoC-Netzladen und einmaliges Netzladen des Forks greifen nicht, evcc prüft Automatik vor dem Netzladen
• Batterieprofile mit Entlade-Sperre melden einen Fehler (evcc sperrt das in Automatik)
  → Automatik bis zum PR-3-Umbau nicht einschalten.

Code-Review (Opus, Aufwand mittel)

Behoben in eigenen Commits:

• Reicht 1p nicht, schaltet evcc ab statt umzuschalten; dafür gilt jetzt die Abschaltverzögerung, nicht unsere 1p-Verzögerung (phaseScaleDelay1p)
• batterySupported rechnet einen anstehenden Wechsel auf 1p mit dem 1p-Minimum (projectPhaseSwitch1p), neuer Hook mit Vertragstest
• Netzladeziele des Forks folgen den Stunden-Slots des gehosteten Optimizers nach 48 h (lmPlan.coarse)
• watch.json: weitere Schreibweisen

Offen bis PR 88 (geparkt): mit eingeschalteter evcc-Automatik greifen Fork-Netzladen und Stromkreisschutz beim Optimizer-Laden nicht, Peak-Shaving-Reserve übersteuert den Optimizer, Profile mit Entlade-Sperre scheitern. Automatik nicht einschalten, bis PR 88 gemergt ist.

Tests

• wsltest: 85 Pakete ok, inklusive core, core/lm, core/peak, core/loadpoint, core/circuit, server, tariff, util, charger, cmd. vehicle/toyota hat nur Integrationstests und wird ohne Tag nicht gebaut, deshalb meldet das Skript FAIL – das Paket ist unverändert
• TestForkHooksInPlace grün
• Optimizer-Szenarien gegen den Optimizer auf .107 grün
• nach den Review-Fixes: core, core/lm, core/peak, core/loadpoint, server, cmd ok; Optimizer-Szenarien 64/64
• Frontend: vue-tsc, vitest 248/248, i18n, Lint der 33 geänderten Dateien grün

Für das Add-on

CHANGELOG: „evcc-Stand vom 12.10. (nach 0.317.1): Optimizer-Automatik (vorerst nicht einschalten), Phasenumschaltung beendet 3p-Mindestladen schneller, wenn 1p nicht reicht, Marstek lädt im Haltemodus.“

🤖 Generated with Claude Code