Easee: wait for pause/resume to be acknowledged

[GrimmiMeloni]

Fix #8398

I felt the need to address the parallel pause/resume situation described in #7366 (reply in thread).

I have taken the initial change which @naltatis implemented in #7597 to capture the ticks when sending pause/resume commands to the Easee cloud.
I have now added enforcement into Enable() to check if a reply for a previous pause or resume command is still outstanding. If so, Enable() returns an error, so that the operation will be retried on the next interval.
I decided to wait for a max of 30s, otherwise I consider the outstanding reply lost. This is a compromise to ensure we don't get stuck forever waiting, in case Easee decides to ignore/drop requests completely.

Did my best to do proper locking in case replies come in in parallel. I'd appreciate reviewer(s) to double check this, though.

@andig I have NOT tested this yet (car is charged up right now). Can you help me mark this as WIP, or is it sufficient to leave the PR in draft state until tested?

[andig]

Das Problem welches dieser PR löst ist doch nur, dass wir nicht mehrfach enabled/disable schicken würden sondern immer auf den letzten Aufruf warten.
Das Verhalten ist aber jetzt inkonsistent- wir antworten mit Fehler falls nicht verarbeitet. Das müsste man dann konsequenterweise auch beim Initialaufruf passieren. Auch müsste die Logik für fehlende TickIDs analog der im MaxCurrent sein.

Zurück zur Ausgangsfrage: was wollen wir hier konkret erreichen? Eine kompliziertere Logik müsste folgende Fälle berücksichtigen:

• HTTP 200: ok
• HTTP 202: falls kein Tick Fehler, falls Tick retry
• retry: schauen ob es zwischendurch ein ok gab

Lohnt der Aufwand? Alternativ: wir unterstellen sequenzielle Abarbeitung und kümmern uns nur drum die fehlenden Tick auszusteuern

[GrimmiMeloni]

Guter Hinweis mit den fehlenden Tick IDs. Bisher habe ich das nur beim /settings Endpoint gesehen, aber das heißt ja nichts. Baue ich noch ein.

@andig kannst du kurz erläutern welchen Initialaufruf du meinst? Geht es um den /settings Aufruf direkt vorher in

evcc/charger/easee.go

Line 392 in df6bec8

resp, err := c.Post(uri, request.JSONContent, request.MarshalJSON(data))

?

[andig]

Ich meinte, dass alle Aufrufe gleich funktionieren sollten: Prüfung auf tick-id, Prüfung auf 200 vs 202. Annahme: auch das Backend ist immer das Gleiche...

Mir ist aber generell nicht klar, wie wir mit der asynchronen Ausführung umgehen wollen: entweder active wait auf die tick-id, oder error return? Vllt. sollten wir erstmal den Ansatz klären?

[GrimmiMeloni]

Zurück zur Ausgangsfrage: was wollen wir hier konkret erreichen? Eine kompliziertere Logik müsste folgende Fälle berücksichtigen:

• HTTP 200: ok
• HTTP 202: falls kein Tick Fehler, falls Tick retry
• retry: schauen ob es zwischendurch ein ok gab

Lohnt der Aufwand? Alternativ: wir unterstellen sequenzielle Abarbeitung und kümmern uns nur drum die fehlenden Tick auszusteuern

Sequentielle Abarbeitung können wir nicht unterstellen. Dafür habe ich hier zuviele Situationen in den letzten Monaten gesehen, wo Easee durcheinander kommt, wenn Kommandos (fast) zeitgleich gesendet werden. Auch die Laufzeiten in der Easee API schwanken, ich habe schon über 1s gesehen.

Ich würde gerne auch nochmal den Begriff "retry" hier etwas genauer definieren wollen. Mein Verständnis der Arbeitsweise von evcc ist, daß pro Intervall ein Sollzustand errechnet wird. Der Loadpoint versucht diesen Zustand auf den Charger zu übertragen in dem er entsprechende APIs aufruft.
Basierend auf diesem (vielleicht falschen?) Verständnis habe ich mich bewusst gegen einen "retry"-Mechanismus bzw. ein active-wait entschieden. Es müßte nach meinem Verständnis ausreichen den Fehler zu werfen, und der Loadpoint wird dann im nächsten Intervall erneut versuchen den Sollzustand herzustellen.

Noch kurz zu diesem Detail:

• HTTP 202: falls kein Tick Fehler, falls Tick retry

Der Teil "falls Tick retry" kann nicht eintreten. Wenn ein Tick noch gespeichert ist, wird der Request gar nicht gesendet. Die Sequenz ist wie folgt:

• Initial kein Tick gespeichert
• pause oder resume Request wird gesendet, Tick kommt zurück und wird gespeichert
• Ab jetzt werden keine weiteren pause und resume Requests mehr gesendet, weil ein Tick gespeichert ist (oder noch keine 30s seit dem speichern des Ticks vergangen sind)
• Antwort kommt für den Tick, gespeicherter Tick wird gelöscht, alles wieder von vorn

Das es keine Überschneidungen gibt ist primär nur für pause / resume Aufrufe entscheidend. Dies liegt daran, daß für diese Aufrufe die Reihenfolge der Verarbeitung entscheidend ist. Mal angenommen bei den Settings werden die Amps in falscher Reihenfolge gesetzt, dann ist dies kein Problem, weil evcc die Abweichung von soll und ist Wert bei den Amps erkennt, und dann im nächsten Interval automatisch gerade zieht.

Bzgl. des generellen Ansatz hab ich oben kurz mein Verständnis zur Arbeitsweise erklärt. Wenn dies korrekt ist, würde ich bei dem Error return Ansatz bleiben. Das erscheint mir dann als pragmatisch.

[andig]

Basierend auf diesem (vielleicht falschen?) Verständnis habe ich mich bewusst gegen einen "retry"-Mechanismus bzw. ein active-wait entschieden. Es müßte nach meinem Verständnis ausreichen den Fehler zu werfen, und der Loadpoint wird dann im nächsten Intervall erneut versuchen den Sollzustand herzustellen.

Das ist schon so, trägt aber nur so weit:

• MaxCurrent kann nur gesetzt werden und merkt sich den Zustand intern (ok, hier geht es weil wir den Strom per Roundtrip bekommen)
• 1p3p muss- wenn über Circuit geschaltet- erst den Charger disablen, sonst wirkt 1p3p nicht. Hier bräuchte es also ein active wait.

/cc @naltatis wofür brauchten wir den Circuitkram eigentlich? Raus damit???

[GrimmiMeloni]

• 1p3p muss- wenn über Circuit geschaltet- erst den Charger disablen, sonst wirkt 1p3p nicht.

Vorsicht, das ist genau umgekehrt. Bei einzelner Easee WB (wie hier bei mir zu Hause) wird über den Circuit geschaltet, und dabei ist kein disable/enable erforderlich. Das habe ich mit einem lokalen Build von #7723 bereits geprüft.

Hier bräuchte es also ein active wait.

Ok, ich gebe mal mein Verständnis wieder. Das ist der Sonderfall der sich aus dem "Charger Level Phase Switch" ergibt. Zumindest in Kombination mit #7723, weil dann der Loadpoint nicht mehr schaltet, sondern die WB es übernehmen sollte - was sie aber laut @naltatis nicht tut. Und das Argument für den Active Wait Ansatz wäre dann Uniformität, damit wir nicht beide Ansätze (return Err, Active wait) einbauen und uns für einen Weg entscheiden. Soweit richtig?

[andig]

Es ist ganz einfach: für current und phases hat evcc ein eigenes Bild vom Chargerzustand. Wenn das nicht zur Realität passt wird es mit Glück erkannt, aber eben nicht garantiert. Mit dem Zustand müssen sich die Charger halt arrangieren, wie auch immer wir das lösen.

Beispiel: sofortladen mit 16A. Wir MaxCurrent verschluckt wird halt geladen wie es gerade ist. Schlägt 1p->3p fehl, denkt evcc 3p lädt sber immer weiter mit 1p.

[naltatis]

@naltatis wofür brauchten wir den Circuitkram eigentlich? Raus damit???

Was genau meinst du damit? Die Fallunterscheidung? Der von Easee gewünschte Weg für die Phasenumschaltung ist die Regelung über den Circuit (L2=0,L3=0). Bei Circuits mit einem Charger ist das für uns kein Problem. Daher machen wir das auch genau so. Hängen an einem Charger mehrere Boxen könnten wir die nur gesammelt phasenumschalten. Das beißt sich aber mit dem Datenmodell/UI/Regelung/Funktionen von evcc. Daher der Workaround über das Phase-Setting direkt am Charger.

Easee empfielt die Settings (außer dynamicChargerCurrent) nicht unnötig oft zu schreiben. Daher macht es schon Sinn dass die direkte Steuerung am Charger nur unsere 2. Wahl ist wenn die erste nicht geht. Die beiden Codepfade bringen aber natürlich Komplexität mit.

[GrimmiMeloni]

@andig OK, dann lass uns doch mal konkreter über eine active wait Implementierung sprechen. Mein Vorschlag wäre einen Channel im Easee Adapter anzulegen. Nach Kommunikation mit der Easee API und Result Code 202 wird auf eine Antwort über den Channel gewartet. Falls nach 5s immer noch keine Antwort da ist, schlägt ein Timeout zu und wir geben einen Error zurück.
In ProductUpdate and CommandReponse würden die Werte aus der Response in den Channel geschrieben. Auf der Empfängerseite würden dann erwartete und erhaltene TickId abgeglichen. Zusätzlich würde auch der Wert von WasAccepted geprüft um den Fall zu behandeln das Easee das Kommende aktiv abgewiesen hat. Wenn alles passt geht es im Hauptthread wieder weiter, so also wäre die Easee API synchron.

[andig]

Vllt. mittels

err := wb.waitTick(tick)

oder

err := wb.waitResponseProcessed(resp)

[andig]

Nochmal ein etwas grundsätzlicher Lösungsgedanke ohne durchgängiges active wait: #7366 (comment). Die Debugmeldung "current mismatch" ist tatsächlich blöd da sie zu keiner Lösung führt sondern nur das Problem dokumentiert.

[GrimmiMeloni]

@andig please assign to me, I have started working on the active wait implementation.

[andig]

/cc @naltatis könntest Du das auch mal testen?

[GrimmiMeloni]

Can we reopen the PR, or shall we create a new one? Branch is already updated with an (untested) fix.

[andig]

Not possible- but you can start a new PR from the same branch.