evcc-io
GetMaxPhaseCurrent: do not return offered current when not charging
Mit https://github.com/evcc-io/evcc/commit/4afd2d238b37846616f589da974384a4150b0590 haben wir sichergestellt, dass an den Circuit nicht offeredCurrent übergeben wird, wenn noch gar nicht geladen wird. Dieser PR zieht diese Änderung nach für die Funktion lp.GetMaxPhaseCurrent. .lp.setLimit habe ich angepasst, so dass auch dort lp.GetMaxPhaseCurrent verwendet wird, anstatt die Implementierung zu duplizieren.
Ohne diese Änderung passt unter Anderem der circuit Strom nicht zum aktuellen Ladestrom, der an validateCurrent übergeben wird, siehe #21303 Beispiel: Start einer Ladung mit 16 A bei 16 A:
- Der aktuelle circut Strom springt dann schon auf z.B. 16 Ampere, obwohl noch nicht geladen wird
- der Aufruf von validateCurrent lautet aber validateCurrent(0, 16)
- in validateCurrent wird davon ausgegangen, dass der circuit schon mit 16A belastet wird.
-
die Erhöhung von 0 auf 16 wird nicht freigegeben, obwohl noch nicht geladen wird.
fixes #21293 #21303
Ich kanns noch nicht ganz nachvollziehen. Da die Änderung etwas subtil ist sollte es einen Test dafür geben?
Ich kanns noch nicht ganz nachvollziehen.
lp.GetMaxPhaseCurrent ist dafür da, den aktuellen Ladestrom zu erhalten. Hat der loadpoint ein Charge Meter mit currents, gibt die Funktion den höchsten gemessenen Phasenstrom zurück. Wenn es kein current meter gibt die Funktion im Moment immer offeredCurrent zurück.
Es gilt aber logischerweise: wenn nicht geladen wird, gibt's auch keinen aktuellen Ladestrom. Das wurde in https://github.com/evcc-io/evcc/commit/4afd2d238b37846616f589da974384a4150b0590 an anderer Stelle schon behoben, hier aber noch nicht.
Die Funktion wird im circuit verwendet, um die aktuelle Auslastung zu ermitteln. Nun nehmen wir einen loadpoint an, an dem Ladestrom freigegeben wurde, der ihn aber gar nicht verwendet. Dennoch wird aktuell angenommen, dass der circuit ausgelastet ist. Dazu kommt der Konflikt mit der Änderung https://github.com/evcc-io/evcc/commit/4afd2d238b37846616f589da974384a4150b0590, mit dem sich der loadpoint dann abhängig von interval und der Reaktionszeit von charger und Auto selbst blockieren kann:
- Circuit limit ist 16 A
- Loadpoint will schnell laden, offeredCurrent wird auf 16 A erhöht
- site.Update ruft im nächsten Zyklus zunächst circuit.Update auf, dort wird c.current auf offeredCurrent, also 16 A gesetzt
- site.Update ruft nun loadpoint.Update auf. Wenn der loadpoint noch nicht lädt, wird dort an validateCurrent 0 A aktueller und 16 A gewünschter Ladestrom übergeben. Da c.current aber schon 16 A ist, wird der Strom nicht freigegeben und der loadpoint wieder auf 0 A offeredCurrent gesetzt
- Und es geht wieder von vorne los
Da die Änderung etwas subtil ist sollte es einen Test dafür geben?
Ich schau mal wo ich den unterbringe :)
Muss mir nochmal was anschauen bzgl. des zeitlichen Verlaufs, Update loadpoint status und circuit update.
Also, der charger status muss logischerweise up-to-date sein, bevor versucht wird, die currents und powers für den circuit upzudaten. Ich habe das update deshalb in die Funktion lp.UpdateChargePowerAndCurrents() vorgezogen (und die Funktion umbenannt in lp.UpdateChargerStatusAndPowerAndCurrents), so minimalinvasiv wie möglich. Ob das die schönste Lösung ist, schwer zu sagen.
Das gleiche Loadmanagement Problem wie mit den currents ohne meter gibts übrigens schon immer mit powers ohne Meter, siehe https://github.com/evcc-io/evcc/discussions/19473#discussioncomment-12417916. Vermutlich hiermit auch gelöst.
Ich denke die Implementierung ist grundsätzlich logisch. Bzgl. der Implementierungsdetails des nun vorgezogenen Charger Status Updates bin ich mir nicht sicher, weil Power und Currents dort per backoff aktualisiert werden, der neue Status aber nicht.