-
-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fehlende lp.resetPVTimer() calls? #20320
Comments
Unfortunately your report is missing a detailed log file. Without log, we don‘t have the information for diagnosing the issue described. See https://docs.evcc.io/docs/faq#wie-kann-ich-ein-logfile-zur-fehleranalyse-erstellen. |
Wir können uns das gerne anschauen- wenn es ein aussagekräftiges Logfile gibt. |
Dieses Logfile habe ich zur schnellen Reproduzierbarkeit mit simulierten Inputs erstellt. Der enable- und der disableDelay waren beide auf 60s eingestellt. Wenn das Auto innerhalb eines intervals nach Ladefreigabe die Ladung beginnt und gleichzeitig die disableThreshold-Bedingung erfüllt ist, dann wird die Ladung sofort unterbrochen. Also anders als im ersten Post vermutet fehlt wahrscheinlich nur ein lp.resetPVTimer()-Call, der aber evtl. nicht zwischen die im ersten Post erwähnten Zeilen 1427 & 1429 gehört, sondern in die evChargeStartHandler()-Funktion, das entsprechende Gegenstück in der evChargeStopHandler()-Funktion existiert nämlich bereits. Hier die beiden Funktionen, die sich aktuell im Bezug auf den pvTimer-Reset nicht symmetrisch verhalten: Lines 424 to 461 in 25d36a5
|
Ich habe noch ein bisschen experimentiert und es ist tatsächlich möglich mit halber interval-Frequenz "charger enable; charger disable"-Sequenzen zu erzeugen. Mir ist klar, dass das in der Praxis nur selten passiert (wobei es bei mir jetzt min. 3x vorgekommen ist in wenigen Tagen, da mein Wechselrichter bei Lastschwankungen gerne mal kurzzeitig in der PV-Leistung einbricht). |
Describe the bug
Ich habe jetzt ein paar Mal beobachtet, dass ein Ladevorgang sofort nach Ladestart ohne Verzögerung gestoppt wurde. Mein Verdacht ist, dass an 2 Stellen in core/loadpoint.go fehlende lp.resetPVTimer()-Aufrufe dieses Problem verursachen. Einmal zwischen den Zeilen 1395 & 1397 und einmal zwischen den Zeilen 1427 & 1429.
Hier ist der entsprechende Codeausschnitt:
evcc/core/loadpoint.go
Lines 1376 to 1443 in 02938e0
Steps to reproduce
Unmittelbar nach einem Ladestart muss die disableThreshold-Bedingung erfüllt sein.
Evtl. funktioniert der Bug auch umgekehrt, sprich wenn sofort nach einem Ladestopp die enableThreshold-Bedingung erfüllt ist und enableDelay <= disableDelay (+ interval?) ist.
Configuration details
Log details
What type of operating system or environment does evcc run on?
HomeAssistant Add-on
External automation
Nightly build
Version
0.202.1
The text was updated successfully, but these errors were encountered: