Skip to content
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

Remove guard timer #12053

Closed
wants to merge 1 commit into from
Closed

Remove guard timer #12053

wants to merge 1 commit into from

Conversation

andig
Copy link
Member

@andig andig commented Feb 4, 2024

Fix #11953, Replace #12001

@GrimmiMeloni @MarkusGH der Versuch zeigt dass das nicht ganz trivial ist da mittlerweile einige Logik vom Guard Timer abhängt. Könnt ihr Euch das Diff mal bitte in Ruhe anschauen?

TODO

  • ui

@andig andig added the enhancement New feature or request label Feb 4, 2024
@andig andig marked this pull request as draft February 4, 2024 12:11
if !enabled && lp.charging() {
lp.log.WARN.Println("charger logic error: disabled but charging")
enabled = true // treat as enabled when charging
if lp.guardGracePeriodElapsed() {
if err := lp.charger.Enable(true); err != nil { // also enable charger to correct internal state
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wann passiert das hier? Muss das enable nicht trotzdem gemacht werden?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ja, sehe ich auch so.

@naltatis
Copy link
Member

naltatis commented Feb 4, 2024

Ist auf jeden Fall schon mal ne ganze Menge Code, die hierdurch verschwinden würde. Auf jeden Fall lohnenswert 😄

@MarkusGH
Copy link
Contributor

MarkusGH commented Feb 5, 2024

So wünschenswert die Vereinfachung auch wäre, man wird aber auf Grund der verzögerten Reaktion mancher Charger nicht umhin kommen einen Timer zu haben, der ab der letzten Änderung des Enabled State läuft. Braucht man im Grunde überall da wo guardGracePeriodElapsed() aufgerufen wird. Ansonsten wird man mindestens sinnlose Fehlermeldungen bekommen, wahrscheinlich wird es schwer den Charger sinnvoll zu synchronisieren. In der momentanen Implementation steckt diesbezüglich viel Aufwand. Auf Wunsch mache ich einen Vorschlag.

@GrimmiMeloni
Copy link
Collaborator

@MarkusGH kannst Du nochmal kurz zusammenfassen wofür guardGracePeriodElapsed() sorgt?

@MarkusGH
Copy link
Contributor

MarkusGH commented Feb 5, 2024

Hier mein Vorschlag: #12084

@GrimmiMeloni: guardGracePeriodElapsed (in meinem PR #12084 umbenannt in in enabledCommandTimeoutElapsed) verhindert vor allem dass der enabled state eines verzögert reagierenden chargers auf den loadpoint zurückgeschrieben wird. Wie man das in allen Fällen richtig macht wurde recht mühsam in #9959 und in darauf folgenden Änderungen ausgearbeitet.

Copy link
Collaborator

@GrimmiMeloni GrimmiMeloni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Member guardUpdated sollte dann konsequenterweise auch rausfliegen.

SyncCharger() ist zu stark ausgedünnt.

if !enabled && lp.charging() {
lp.log.WARN.Println("charger logic error: disabled but charging")
enabled = true // treat as enabled when charging
if lp.guardGracePeriodElapsed() {
if err := lp.charger.Enable(true); err != nil { // also enable charger to correct internal state
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ja, sehe ich auch so.

Comment on lines -674 to -675
lp.elapsePVTimer()
return nil
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Die zwei müssen auch bleiben.

Comment on lines -660 to -663
defer func() {
lp.enabled = enabled
lp.publish(keys.Enabled, lp.enabled)
}()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dieser defer Block muß bleiben.

@GrimmiMeloni
Copy link
Collaborator

Danke @MarkusGH für den Kontext. Konkret haben wir das hier zerlegt.

Das würde also bedeuten, daß wir zwar keinen GuardTimer mehr brauchen - aber zumindest diese grace period. Was nach meinem Verständnis dein PR bietet. Könnte man so erstmal versuchen.

@MarkusGH
Copy link
Contributor

MarkusGH commented Feb 5, 2024

Danke @MarkusGH für den Kontext. Konkret haben wir das hier zerlegt.

Das würde also bedeuten, daß wir zwar keinen GuardTimer mehr brauchen - aber zumindest diese grace period. Was nach meinem Verständnis dein PR bietet. Könnte man so erstmal versuchen.

@andig: Wollen wir wie von @GrimmiMeloni vorgeschlagen hier zumachen und in #12084 weitermachen?

@andig andig closed this Feb 5, 2024
@andig andig deleted the feature/remove-guard-2 branch February 5, 2024 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

manuelles Schalten aktiviert guardduration
4 participants