Kostal Plenticore "Gen1": fix battery mode

[andig]

Fix #18714 (comment). Reverts Gen1 changes from #17793

/cc @iseeberg79

[iseeberg79]

technical revert - passt soweit, aber warum nötig? Beide Implementierungen arbeiten mit dem watchdog gegen das gleiche Register.

[iseeberg79]

@deadrabbit87 gesehen?

[andig]

Ah, sorry- das war mir nicht aufgefallen. In der Tat sollte das ja identisch sein.

[iseeberg79]

Ich denke seit einer Diskussion die zur Meldung des Incident geführt hat darüber nach und komm' nicht zu einem Ergebnis. Deshalb hatte ich selbst keinen PR gemacht, weil ich den für mich nicht begründen kann. Hoffentlich helfen die Traces weiter. Ich hab auch schon nach Modbus Registern vor/während des Fehlers gefragt: das würde wohl am besten helfen, konnten aber noch nicht geliefert werden. Vielleicht sind noch Register gesetzt, die jetzt hier das Verhalten auslösen: dann hätten sich aber beide Versionen auch gleich verhalten müssen: ein Rätsel gerade.

[frankheit]

Ich denke seit einer Diskussion die zur Meldung des Incident geführt hat darüber nach und komm' nicht zu einem Ergebnis. Deshalb hatte ich selbst keinen PR gemacht, weil ich den für mich nicht begründen kann. Hoffentlich helfen die Traces weiter. Ich hab auch schon nach Modbus Registern vor/während des Fehlers gefragt: das würde wohl am besten helfen, konnten aber noch nicht geliefert werden. Vielleicht sind noch Register gesetzt, die jetzt hier das Verhalten auslösen: dann hätten sich aber beide Versionen auch gleich verhalten müssen: ein Rätsel gerade.

Ich bekomm das mit dem auslesen vom Modus gerade nicht auf die Reihe.
Wenn ich aber mit einer Teamviewer-Sesion oder ähnlichem helfen kann (habe eine funktionierende und eine nicht funktionierende Version als Image da) bin ich da gerne bereit dazu.

[iseeberg79]

Es gab schon andere Nutzer, die erklärt haben, das der Watchdog "sensibler" (b172eb2) ist. In der Regel wurde das durch Anpassung aufgelöst - ich hatte bisher bei schneller Suche den commit nicht gefunden.
Richtig wäre ggf. die Templates anzupassen, damit der Watchdog wieder 2x je Intervall bedient wird. Möchtest du die Watchdog-Implementierung so belassen? Dann sollten wir die Modbus-Nachrichten wieder 2x je Timeout senden und das in den Templates so sicherstellen. Ich hoffe, das löst das veränderte Verhalten auf.

[frankheit]

Es gab schon andere Nutzer, die erklärt haben, das der Watchdog "sensibler" (b172eb2) ist. In der Regel wurde das durch Anpassung aufgelöst - ich hatte bisher bei schneller Suche den commit nicht gefunden. Richtig wäre ggf. die Templates anzupassen, damit der Watchdog wieder 2x je Intervall bedient wird. Möchtest du die Watchdog-Implementierung so belassen? Dann sollten wir die Modbus-Nachrichten wieder 2x je Timeout senden und das in den Templates so sicherstellen. Ich hoffe, das löst das veränderte Verhalten auf.

Aktuell ist er im EVCC nicht konfiguriert (also Standart), im Wechselrichter auf 60 Sekunden. Soll ich zum testen den Wechselrichter auf 30 Sekunden stellen?

[iseeberg79]

Dieser Draft sollte nicht mehr nötig sein. Nach meinen heutigen Tests, sollte das Thema erledigt sein. Ich wollte die Modbus-Nachrichten in evcc auswerten, musste dann aber per tcpdump schauen: merkwürdig. Ich hätte erwartet modbus im evcc-Log auswählen zu können, bzw. die Debug-Nachrichten zum Gerät zu sehen - Fehlanzeige.

Das watchdog-Plugin sendet jetzt wieder erwartungsgemäß die Daten und die Batteriesperre ist hier über viele Minuten stabil, inkl. der Netzladung mit dem neuesten Template.

[iseeberg79]

Ich gebe auf. Ich finde den Grund leider nicht, warum sich das anders verhält. Weitere Zeit zu investieren, scheint meinerseits nicht mehr sinnvoll.

Die Traces zu analysieren, den Blick direkt auf die Systeme und der Versuch mit dem rückgebauten Template bringen kein neues Ergebnis, ausser: geht mit limitsoc.

Oder habt ihr noch eine Idee?

Kannst du den PR wieder öffnen? Bei der Analyse ist mir aufgefallen, das maxsoc veraltet ist, aber im UI nicht mehr unter advanced einsortiert wird, das sollte noch angepasst werden.

[andig]

Keine Ideen mehr :(

[iseeberg79]

definition for maxsoc, add "advanced: true"
Ich kann's nicht direkt im Code editieren, hab's versucht.. würde ein neuer PR werden, aber das kann ja auch nicht richtig sein (Overhead)...

[andig]

so?

[andig]

ping @iseeberg79

[iseeberg79]

so, denke ich - da fehlte wohl noch das eigentliche absenden..

[iseeberg79]

Suggested change

	type: int
	deprecated: true
	type: int

so - ist doch richtig, das maxsoc nicht mehr benötigt wird?
Du hast recht: weil es in der UI Konfiguration auftaucht, ist die Angabe des Types vervollständigend?

(hab mich daran erinnert, man vergisst echt schnell, wenn man das inline editing nicht ständig nutzt...)

[andig]

so - ist doch richtig, das maxsoc nicht mehr benötigt wird?

Warum? Die limitsoc Steuerung braucht den.

[iseeberg79]

oh, dann fehlt der unten?

[iseeberg79]

oh, dann fehlt der unten?