Meldung "charger out of sync: expected enabled, got disabled" bei voller EV Batterie

[MarkusGH]

System mit PMCC (Ansteuerung über eebus)
evcc 0.86

evcc neu gestartet, modus pv
Ladeleistung ist verfügbar, EV ist eingesteckt, EV Batterie ist voll (EV kann nicht laden)

Es kommt in jedem Zyklus die Meldung "charger out of sync: expected enabled, got disabled"

In der Folge wird per eebus versucht das Laden durch Schreiben der Ladestrombeschränkung zu starten (write EV:LoadControl LoadControlLimitListData). Das hat natürlich keinen Effekt, weil der PMCC schon freigeschaltet ist, aber das Fahrzeug schlicht nicht laden kann.

Ich würde erwarten, dass die Situation erkannt wird und die Warnung nicht ausgegeben wird.
Das ständige Schreiben der Ladestrombeschränkung zum PMCC ist zwar in der Situation unnötig aber unschädlich.

[andig]

Ob das Auto voll ist oder nicht spiel aus Sicht evcc keine Rolle. Die Wallbox wird bei Überschuss zur Ladung freigegeben.

Das ständige Schreiben der Ladestrombeschränkung zum PMCC ist zwar in der Situation unnötig aber unschädlich.

Hast Du einen Vorschlag, woran der PMCC (=der nichts vom Rest von evcc weiß!) die Situation erkennen soll? Wenn der PMCC den Ladestand des Autos (ISO?)? Falls nein sehe ich keine Weg.

Und wie erwähnt- wir haben keinen Maintainer für EEBus.

[MarkusGH]

Die eebus Thematik ist mir bekannt, das Problem liegt aber meiner Meinung nach nicht in dem Bereich.
Der PMCC tut ja was er soll - er gibt den Ladestrom frei.
Dass das Auto gar nicht laden kann ist eine andere Sache.

Der Ladepunkt meldet ständig "charger status: B" und evcc quittiert dies mit der Warnung und dem Versuch das Laden zu starten.

Hat die Logik in loadpoint.go überhaupt die Möglichkeit zwischen den Zuständen "Fahrzeug angeschlossen und lädt nicht weil Laden nicht freigegeben" und "Fahrzeug angeschlossen und lädt nicht obwohl Laden freigegeben" zu unterscheiden?

[andig]

Der Ladepunkt meldet ständig "charger status: B" und evcc quittiert dies mit der Warnung und dem Versuch das Laden zu starten.

Das kann nicht sein. Status B ist völlig ok.

Hat die Logik in loadpoint.go überhaupt die Möglichkeit zwischen den Zuständen "Fahrzeug angeschlossen und lädt nicht weil Laden nicht freigegeben" und "Fahrzeug angeschlossen und lädt nicht obwohl Laden freigegeben" zu unterscheiden?

Nein und das ist auch irrelevant. Nicht laden ist B und B ist fein.

Dein Problem ist dass der Charger behauptet nicht freigegeben zu sein und das stimmt nicht weil die Ermittlungslogik dafür falsch ist. Der Fehler ist im Enabled().

Siehe auch #2858 (comment)

[MarkusGH]

Dein Problem ist dass der Charger behauptet nicht freigegeben zu sein und das stimmt nicht weil die Ermittlungslogik dafür falsch ist. Der Fehler ist im Enabled().

Stimmt - habe nachgesehen.
Das hast sogar Du selber in commit 8474881 kaputtgemacht :-)

Vor dem Commit wurde c.expectedEnableState auf true gesetzt wenn genug Strom fließt.
Nach dem Commit c.expectedEnableState zusätlich auf false gesetzt wenn nicht genug Strom fließt.

Die Variable c.expectedEnableState ist deswegen auch notwendig und kann nicht entfernt werden.

[andig]

Ich seh da keinen Fehler- das wurde ja nur geschrieben, aber nicht gelesen? Wenn Du's sieht mach gerne einen PR!

[andig]

Bzw. frag mich grad wie man das sauber lösen kann. Bei der Statusabfrage noch interne Variablen zu setzen ist jedenfalls keine sehr transparente Lösung.

[MarkusGH]

Was macht dataUpdateHandler?

[andig]

Updated den Ladepunkt gem. Fähigkeiten des Fahrzeugs. GetData ist eigentlich obsolet (ist ein anderes Thema).

Ich tendiere dazu, das ganze Hin-und-her zu lassen und Enable() falls es ohne Fehler läuft als internen Status zu nehmen und bei Enabled() dann genau den zurück zu geben. Es gibt m.E. überhaupt keinen Grund, Enabled() wieder ein Rätselraten zu starten?

Wenn Du schmerzfrei bist könnten wir das zusammen ausprobieren; testen kann ich allerdings nix...

[MarkusGH]

Warte mal - wenn ich rausfinde wie ich mit VS Code einen Pull Request mache sende ich einen Vorschlag

[MarkusGH]

Und da isser auch schon: #2942

[MarkusGH]

Es gibt m.E. überhaupt keinen Grund, Enabled() wieder ein Rätselraten zu starten?

Doch - denn der Charger hat ja durchaus auch ein Eigenleben, das EV kann ausgesteckt werden oder aber es können Kommunikationsprobleme auftreten. Dann wäre es schon gut wenn evcc die Abweichung des tatsächlichen Enabled State vom zuletzt gesetzten erkennen kann.

[MarkusGH]

@andig: So - in #2956 ist jetzt ein PR der auch funktioniert.

[andig]

Ist drin. Trotzdem nochmal zur Erklärung:

Doch - denn der Charger hat ja durchaus auch ein Eigenleben, das EV kann ausgesteckt werden oder aber es können Kommunikationsprobleme auftreten. Dann wäre es schon gut wenn evcc die Abweichung des tatsächlichen Enabled State vom zuletzt gesetzten erkennen kann.

Das stimmt schon, ist aber ohnehin nicht der Fall. Aus Sicht evcc heisst Enable() einfach "Ladung freigegeben falls jemand laden möchte". Bei EEBus aktuell also Overload Protection deaktiviert. Den Zustand stellen wir genau in dem Moment ein wo Enable() aufgerufen wird.

Der einzige Fehlerzustand den wir m.E. erkennen können ist wenn in Enabled() eine Ladung stattfindet obwohl Enable(false) gesetzt war. Den umgegehrten Zustand- Auto lädt nicht obwohl freigegeben- erkennen wir ohnehin nicht.

Vor dem Hintergrund könnte die ganze komplexe Logik m.E. verschwinden. Falls Du schmerzfrei bist und ich etwas Zeit finde, könnte ich mal versuchen das aufzuräumen.

[MarkusGH]

Momentan würde ich es gerne drin lassen.
Was macht evcc wenn ich im laufenden Betrieb bei Enabled = True den Charger resette?
Was macht evcc wenn ich im laufenden Betrieb bei Enabled = False den Charger resette?
Wird in den Fällen der Sollzustand per Schreiben der Overload Protection an den Charger gesendet?

[premultiply]

Ja, evcc wird bei nächster Gelegenheit den internen Zustand wieder mit dem Charger zu synchronisieren.
Wenn Das nicht zueinander passt kommt die Meldung "charger out of sync: expected XXXabled, got XXXabled".

[MarkusGH]

Das ist das was jetzt passiert.
Aber was passiert wenn die eebus Logik in den FällenFall treuherzig den letzten Zustand der von evcc geschrieben wurde zurückgibt? Dann gibt es kein "Out of Sync" und keine Synchronisierung.
@DerAndereAndi: Was hältst Du davon - die aktuelle Implementierung dürfte von Dir stammen? Mein letztes Commit sollte die diesbezügliche Logik 1:1 übernehmen.

[andig]

Aber was passiert wenn die eebus Logik in den FällenFall treuherzig den letzten Zustand der von evcc geschrieben wurde zurückgibt? Dann gibt es kein "Out of Sync" und keine Synchronisierung.

Das habe ich oben versucht zu erklären. "Die Logik" gibt schon heute den Stand von evcc zurück, plus/minus aktiver Ladevorgang am Auto. Sie macht das nur auf sehr komplizierte und nicht offensichtliche Weise.

[MarkusGH]

@andig:

Das habe ich oben versucht zu erklären. "Die Logik" gibt schon heute den Stand von evcc zurück, plus/minus aktiver Ladevorgang am Auto. Sie macht das nur auf sehr komplizierte und nicht offensichtliche Weise.

Ich sehe da wegen "plus/minus aktiver Ladevorgang" nur noch wenig Optimierungspotenzial aber mach doch einen PR mit einem Vorschlag, ich schau es mir gerne gelegentlich an.

[DerAndereAndi]

@MarkusGH Ihr müsste bedenken dass es keinen Schalter enable im EEBUS Protokoll gibt. Man kann da nicht einfach zu jeder Zeit (!) sagen "sperren" oder "freischalten".

Das Sperren oder Freischalten ist erst nach einem initialen u.U. mehrere Sekunden dauernden Datenaustausch mit der Wallbox möglich, indem die erlaubten Stromstärken gesetzt werden. In dieser Zeit kann man nur zurückmelden dass eine Freigabe erfolgt ist und jede Sperrung wird nicht funktionieren.

Entweder man baut einen irgendwie gearteten (scheinbar kompliziert und nicht offensichtlich) Workaround wie ich es gemacht habe, der wird nie perfekt, oder man baut die Logik um dass solche Dinge gar nicht erforderlich sind. Diskussionen dazu gab es in der Vergangenheit mehrfach.

Mehr kann ich nicht helfen.