Loadpoint: readjust guard publishing

[GrimmiMeloni]

fix #11953

@andig / @naltatis - Tests sind weiterhin grün. Szenario das Volker beschreibt ist jetzt auch weg.
Einzige grobe Kante hierbei ist, daß ich jetzt als action beim publish weder enabled noch inactive, sondern silent verwende. Diese Action wird weder vom Server noch von der UI gesondert behandelt, d.h. der Server logged den GuardTimer während er runter läuft, und gleichzeitig zeigt die UI die Schaltschutz Meldung nicht mehr an.

[andig]

Ich werde damit nicht glücklich. Der Code wird immer komplexer um Sonderfälle zu erfüllen. Warum sollte der Fall aus dem Issue kein Guard auslösen? Ich fürchte an der Stelle haben wir kein sauberes Design. Im Zweifel würde ich lieber den alten Commit zurück drehen?

[GrimmiMeloni]

Warum sollte der Fall aus dem Issue kein Guard auslösen?

Der Guard wird ausgelöst und arbeitet auch korrekt. Serverseitig ist das Verhalten wie gewohnt.
Es ändert sich lediglich wann wir den Guard publishen, und ggf. wie.

Der Code wird immer komplexer um Sonderfälle zu erfüllen.

Fairerweise der Hinweis: Dieser Change enthält bereits effektiv einen revert vom #11926. Ich vergleich zu pre-11926 ist hier nur noch der Else-Zweig neu.

Ich bin aber bei Dir - es wird komplizierter und das nur für geringen Benefit.
Wenn wir wirklich zurück wollen, dann zumindest logisch auf den Stand vor #11926.
Ich würde vorschlagen zumindest die neuen Tests (dann nochmal angepasst auf das Verhalten) mit rüber zu retten.

Das bedeutet dann, das wir #11123 als "known bug, won't fix" akzeptieren. Es ist auch dann weiterhin rein kosmetisch.

[naltatis]

Ich stell mal kätzerisch die Frage ob wir den Guard nicht vielleicht komplett entfernen können/sollte?

Der wurde mal angeführt um die Hardware für exzessiven Schaltvorgängen durch externe API Clients zu schützen. Beim Schalten über die UI will der Nutzer ja eigentlich immer Instant Feedback. Da fühlt sich dieser Schutz immer wie ne Bevormundung an.

Im Alltag ohne Interaktion von außen tun die Enable/Disable Timer ja brav ihren Job. Da fällt der Guard Timer nur dann negativ auf wenn der höher konfiguriert ist.

Wir könnten alternativ sowas machen wie dem Modus-Ändern Endpunkt ein einfaches Rate Limiting verpassen sodass er mit nem HTTP Fehler (429) antwortet wenn man innerhalb einer Minute mehr als zehn Umschalteversuche unternommen hat. Das wäre dann immer noch ein Timer aber lokal im Modus Umschalten Handler und nicht tief in der Regellogik.

[GrimmiMeloni]

So ketzerisch ist das gar nicht. @andig hat das erst vor ein paar Tagen ebenfalls vorgeschlagen.

Dann hier am besten einfach nur noch revert, und dann machen wir ein Issue/Feature auf für Ersetzung von Guard durch einen Rate Limiter.

[andig]

Wenn wir wirklich zurück wollen, dann zumindest logisch auf den Stand vor #11926.

Ja, sehe ich auch so.

So ketzerisch ist das gar nicht. @andig hat das erst vor ein paar Tagen ebenfalls vorgeschlagen.

Wäre schön!

Wir könnten alternativ sowas machen wie dem Modus-Ändern Endpunkt ein einfaches Rate Limiting verpassen sodass er mit nem HTTP Fehler (429) antwortet wenn man innerhalb einer Minute mehr als zehn Umschalteversuche unternommen hat. Das wäre dann immer noch ein Timer aber lokal im Modus Umschalten Handler und nicht tief in der Regellogik.

Tja. Schlimm ist ja nicht die Modusänderung sondern das Schalten am Charger. Welche Quellen dafür gibt es:

• massive Fehler in evcc- über die Stufe sind wir hinaus
• Client-Fehler; wie können diese interagieren- nur über den Modus?
• Config-Fehler; z.B. fehlende Hysterese- müssten wir da noch was abfangen?

[VolkerK62]

sorry, dass ich mit meinen Beobachtungen so einen trouble verursacht habe.

wenn man innerhalb einer Minute mehr als zehn Umschalteversuche unternommen hat

Was ist hier mit "Umschaltung" gemeint. Auch Änderung von z.B. PV auf Min+PV?

[GrimmiMeloni]

Was ist hier mit "Umschaltung" gemeint. Auch Änderung von z.B. PV auf Min+PV?

Nein, nur Phasenwechsel und tatsächlicher Ladestart beziehungsweise -stop.