[seaspotter]

Der Hilfetext zur Einstellung "Pufferzeit zwischen automat. Phasenumschaltungen"
verspricht explizit:

Ist ausreichend Überschuss vorhanden, wird beim Ladestart die
Umschaltverzögerung nicht abgewartet, sondern direkt mit mehrphasiger
Ladung begonnen.

Das funktioniert bisher nur zufällig zuverlässig, nicht durchgängig. Es gibt
dafür bereits eine Logik (switch_on_timer_expired() in counter.py, Meldung
"Der Überschuss ist ausreichend, um direkt mit {} Phasen zu laden."), die beim
Ablauf der Einschaltverzögerung den Überschuss prüft und korrekt direkt mit
maximaler Phasenzahl startet – das funktioniert für sich genommen.

Das Problem liegt an einer zweiten, unabhängigen Stelle: get_phases_by_selected_chargemode()
setzt beim Ladestart im Automatikmodus unconditional phases = 1, unabhängig
vom Überschuss und unabhängig davon, auf welcher Phasenzahl die Hardware
gerade tatsächlich steht. Stand die Hardware zufällig schon auf 1 Phase,
fällt das nicht auf – switch_on_timer_expired() schaltet dann sauber in
einem Schritt auf 3 Phasen hoch. Stand die Hardware aber noch auf 3 Phasen
(z. B. Restzustand vom vorherigen Ladevorgang), wird durch das erzwungene
phases = 1 unnötig auf 1 Phase heruntergeschaltet, bevor die
Überschussprüfung überhaupt zum Zug kommt. Diese Umschaltung setzt den
Zeitstempel für die Umschaltverzögerung zurück, wodurch anschließend die
volle Pufferzeit (Standard 7 Minuten) erneut abgewartet werden muss, bevor
wieder auf 3 Phasen hochgeschaltet wird – das ist der eigentliche Bug, und er
tritt nur bei dieser Vorbedingung auf.

Konkret beobachtet: Ladepunkt wurde gestartet, obwohl bereits ausreichend
PV-Überschuss vorhanden war. Es folgte dennoch eine unnötige Umschaltung
3→1 Phase und danach eine Statusmeldung "Umschaltung von 1 auf 3 Phasen in
7 Min. 41 Sek.", bevor tatsächlich mehrphasig geladen wurde.

references #3496 (comment)

[seaspotter]

Ergänzung: Warum es manchmal schon funktioniert und manchmal nicht

Kurz zur Einordnung: Es gibt bereits eine bestehende
Logik in switch_on_timer_expired() (counter.py), die beim Ablauf der
Einschaltverzögerung den Überschuss prüft und ggf. direkt mit maximaler
Phasenzahl startet (Meldung "Der Überschuss ist ausreichend, um direkt mit
{} Phasen zu laden."). Diese Logik ist unverändert und funktioniert für sich
genommen korrekt.

Das Problem liegt an einer zweiten, unabhängigen Stelle: get_phases_by_selected_chargemode()
setzt bei jedem Zyklus, in dem noch nicht geladen wird, im Automatikmodus
unconditional phases = 1 – unabhängig vom Überschuss und unabhängig davon,
auf welcher Phasenzahl die Hardware gerade tatsächlich steht.

• Steht die Hardware zufällig bereits auf 1 Phase (z. B. weil der
  Ladepunkt vorher gesperrt war oder das letzte Fahrzeug schon einphasig
  geladen hat), passiert durch das erzwungene phases = 1 nichts
  Zusätzliches. switch_on_timer_expired() schaltet dann sauber in einem
  Schritt auf 3 Phasen hoch – das sieht dann korrekt aus, ist aber Zufall,
  kein Beweis, dass alles funktioniert.
• Steht die Hardware noch auf 3 Phasen (z. B. Restzustand vom vorherigen
  Fahrzeug/Ladevorgang), erzwingt dieselbe Stelle unnötig eine Umschaltung
  3→1, bevor switch_on_timer_expired() überhaupt zum Zug kommt. Dabei
  wird timestamp_last_phase_switch neu gesetzt, wodurch anschließend die
  volle Pufferzeit (Standard 7 Minuten) erneut abgewartet werden muss, bevor
  wieder auf 3 Phasen hochgeschaltet wird – das ist der eigentliche Bug.

Das eine Problem tritt also nur bei einer bestimmten Vorbedingung (Hardware
steht noch auf 3 Phasen) auf, weshalb es sich in Logs unterschiedlich
darstellt.

Was diese PR wirklich behebt: get_phases_by_selected_chargemode() prüft
jetzt selbst den Überschuss (dieselbe Bedingung und Formel wie in
switch_on_timer_expired()), bevor es phases = 1 erzwingt. Ist genug
Überschuss vorhanden, wird direkt die maximale Phasenzahl gewählt – dadurch
entfällt die unnötige Zwischenumschaltung auf 1 Phase in jedem Fall, auch
wenn die Hardware noch auf 3 Phasen steht. counter.py bzw.
switch_on_timer_expired() selbst wurde nicht verändert.

[LKuemmel]

Steht die Hardware noch auf 3 Phasen (z. B. Restzustand vom vorherigen
Fahrzeug/Ladevorgang), erzwingt dieselbe Stelle unnötig eine Umschaltung
3→1, bevor switch_on_timer_expired() überhaupt zum Zug kommt. Dabei
wird timestamp_last_phase_switch neu gesetzt, wodurch anschließend die
volle Pufferzeit (Standard 7 Minuten) erneut abgewartet werden muss, bevor
wieder auf 3 Phasen hochgeschaltet wird – das ist der eigentliche Bug.

Das stimmt so nicht. An der Stelle wird die Phasenzahl fest gelegt, aber nicht umgeschaltet. Es gibt mehrere Stellen, die Einfluss auf die vorgegebene Phasenzahl haben. Umgeschaltet wird erst am Ende in

core/packages/control/process.py

Line 47 in 983f47d

cp.initiate_phase_switch()

Die Lösung berücksichtigt auch keine Gleichzeitigkeit. In der algorithm.py wird vorher noch geprüft, ob eine automatische Umschaltung gemacht werden muss und es wird für jeden LP ggf eine Leistung reserviert. Auch im Sinn der Trennung von Verantwortlichkeiten ist es unschön, dass die Ladepunkt-Klasse , die erstmal Soll-Strom und -Phasen ermitteln soll, beurteilt, ob der Überschuss ausreicht. Last- und Überschussverteilung sollte innerhalb der algorithm.py bleiben.

[LKuemmel]

Das Problem bei zB #3496 (comment) ist, dass direkt mit der Umschaltung begonnen wird und nicht erst die Umschaltverzögerung durchlaufen wird, an deren Ende die 1p oder 3p-Entscheidung getroffen wird. Ich habe dafür aber noch keine Ursache gefunden.

[seaspotter]

Danke für den Hinweis, das deckt sich mit meiner eigenen Erfahrung – genau dieses Verhalten hatte ich selbst auf meiner Anlage, deshalb kam die PR überhaupt zustande.

Ich glaube, die eigentliche Ursache liegt tiefer: get_phases_by_selected_chargemode() setzt vor Ladestart bei jedem Zyklus phases = 1. Das beeinflusst nicht nur die spätere Umschaltung, sondern fließt auch in switch_on_threshold_reached() in die Berechnung der Einschaltschwelle ein (switch_on_threshold * control_parameter.phases). Dadurch wird die Schwelle künstlich klein und der Timer startet, bevor die Hardware überhaupt auf die zum Überschuss passende Phasenzahl steht – und die Umschaltung auf 1 Phase passiert dann sofort, ohne die Umschaltverzögerung, weil es sich um den ersten Sync beim Ladestart handelt (_is_phase_switch_required()).

Alternativvorschlag, damit das komplett in der Algorithmus-Logik bleibt statt in der Ladepunkt-Klasse:

1. In get_phases_by_selected_chargemode() vor Ladestart nicht mehr fest 1 setzen, sondern die bisherige/aktuelle Phasenzahl beibehalten (steht sinngemäß eh schon im Kommentar darüber).
2. In switch_on_threshold_reached() für die Schwellenberechnung beim Fahrzeug fest mit 1 Phase rechnen, unabhängig vom aktuellen control_parameter.phases.
3. In switch_on_timer_expired() die Phasenzahl in beiden Fällen explizit setzen (aktuell nur bei ausreichend Überschuss für die maximale Phasenzahl), damit dort auch der 1-Phasen-Fall sauber gesetzt wird statt sich auf einen Vorgabewert von außen zu verlassen.

Damit bräuchte es die separate Überschussprüfung in der Ladepunkt-Klasse aus meiner PR gar nicht mehr. Wenn das so für dich passt, würde ich das entsprechend umbauen.

[LKuemmel]

Ich kann deiner Argumentation nicht ganz folgen und es auch nicht nachstellen:

Ich glaube, die eigentliche Ursache liegt tiefer: get_phases_by_selected_chargemode() setzt vor Ladestart bei jedem Zyklus phases = 1. Das beeinflusst nicht nur die spätere Umschaltung, sondern fließt auch in switch_on_threshold_reached() in die Berechnung der Einschaltschwelle ein (switch_on_threshold * control_parameter.phases). Dadurch wird die Schwelle künstlich klein und der Timer startet, bevor die Hardware überhaupt auf die zum Überschuss passende Phasenzahl steht – und die Umschaltung auf 1 Phase passiert dann sofort, ohne die Umschaltverzögerung, weil es sich um den ersten Sync beim Ladestart handelt (_is_phase_switch_required()).

Dann müsste man das mit Sofortladen 1-phasig, Stop und dann bei ausreichend Überschuss auf PV nachstellen können, dass er dann umschaltet und sofort anfängt. Bei mir wird immer erst die Einschaltverzögerung abgewartet.

Das beeinflusst nicht nur die spätere Umschaltung, sondern fließt auch in switch_on_threshold_reached() in die Berechnung der Einschaltschwelle ein (switch_on_threshold * control_parameter.phases). Dadurch wird die Schwelle künstlich klein

Das ist richtig, die Einschaltverzögerung soll im Automatikmodus ja auch für eine Phase starten. Am Ende der Einschaltverzögerung wird der Überschuss geprüft und ggf die Soll-Phasen auf 3 gesetzt.

und der Timer startet, bevor die Hardware überhaupt auf die zum Überschuss passende Phasenzahl steht

Die Phasenzahl ist während der Umschaltverzögerung nicht relevant. Es reicht, wenn nach der Einschaltverzögerung und vor dem Ladestart auf die benötigte Phasenzahl umgeschaltet wird.

und die Umschaltung auf 1 Phase passiert dann sofort, ohne die Umschaltverzögerung, weil es sich um den ersten Sync beim Ladestart handelt (_is_phase_switch_required()).

Du meinst wahrscheinlich den Aufruf aus der process.py von _is_phase_switch_required. In _is_phase_switch_required wird aber nicht umgeschaltet, wenn state == ChargepointState.SWITCH_ON_DELAY ist.

[seaspotter]

Zu _is_phase_switch_required()/SWITCH_ON_DELAY: du hast recht, keiner der Zweige kann in diesem State feuern, das nehme ich zurück.

Der eigentliche Auslöser ist ein anderer, bisher nicht diskutierter Zweig - NO_CHARGING_ALLOWED, also vor jeder Einschaltverzögerung, im allerersten Zyklus nach Erkennung des Fahrzeugs. Beleg aus einem realen Log (Matt, 08.08.): Auto wird erkannt, phases durch get_phases_by_selected_chargemode() unconditional auf 1 gesetzt, Hardware steht noch auf 3 - in derselben Sekunde folgt "Umschaltung von 3 auf 1 Phase", noch bevor überhaupt geladen wird. Kein SWITCH_ON_DELAY beteiligt.

Zu deinem zweiten Punkt (gehört nicht in die Ladepunkt-Klasse, keine Berücksichtigung von Gleichzeitigkeit): dem stimme ich zu und habe den PR entsprechend umgebaut. Die Überschussprüfung sitzt jetzt in Algorithm._check_phases_at_charging_start(), direkt neben _check_auto_phase_switch_delay(), und reserviert den beanspruchten Überschuss lokal fort, damit nicht zwei gleichzeitig startende Ladepunkte denselben Überschuss beanspruchen. Push ist raus, PR ist aktualisiert.

Mit den echten Werten aus Matts Log getestet: mit dem Fix wählt der Algorithmus direkt 3 Phasen, _is_phase_switch_required() findet danach keinen Mismatch mehr - keine unnötige Umschaltung.

[LKuemmel]

Der eigentliche Auslöser ist ein anderer, bisher nicht diskutierter Zweig - NO_CHARGING_ALLOWED, also vor jeder Einschaltverzögerung, im allerersten Zyklus nach Erkennung des Fahrzeugs. Beleg aus einem realen Log (Matt, 08.08.): Auto wird erkannt, phases durch get_phases_by_selected_chargemode() unconditional auf 1 gesetzt, Hardware steht noch auf 3 - in derselben Sekunde folgt "Umschaltung von 3 auf 1 Phase", noch bevor überhaupt geladen wird. Kein SWITCH_ON_DELAY beteiligt.

Genau das ist die Frage: In welcher Situation wird im ersten Zyklus nach dem Anstecken nicht auf SWITCH_ON_DELAY gewechselt? Im normalen Ablauf ist das der Fall.

Zu deinem zweiten Punkt (gehört nicht in die Ladepunkt-Klasse, keine Berücksichtigung von Gleichzeitigkeit): dem stimme ich zu und habe den PR entsprechend umgebaut. Die Überschussprüfung sitzt jetzt in Algorithm._check_phases_at_charging_start(), direkt neben _check_auto_phase_switch_delay(), und reserviert den beanspruchten Überschuss lokal fort, damit nicht zwei gleichzeitig startende Ladepunkte denselben Überschuss beanspruchen. Push ist raus, PR ist aktualisiert.

Das behebt mMn nicht den Bug, sondern baut einen parallelen Weg, um die Phasenzahl zu setzen. Wartungsfreundlich ist das nicht, es gibt mehrere Wege, mal greift der eine, mal der andere.

[seaspotter]

In welcher Situation wird im ersten Zyklus nach dem Anstecken nicht auf SWITCH_ON_DELAY gewechselt?

Immer dann, wenn im ersten Zyklus der Überschuss noch nicht ausreicht. In switch_on_threshold_reached() (counter.py) setzt nur der if-Zweig (Schwelle erreicht) den State auf SWITCH_ON_DELAY. Der else-Zweig (Schwelle nicht erreicht, texts.not_exceeded) lässt den State unverändert auf NO_CHARGING_ALLOWED - das ist der Normalfall, wenn beim Anstecken nicht sofort genug Überschuss da ist.

Und _is_phase_switch_required() hat einen eigenen, expliziten Zweig für genau diesen State (chargepoint.py, der elif control_parameter.state == ChargepointState.NO_CHARGING_ALLOWED-Zweig)

Reihenfolge innerhalb eines Zyklus passt auch dazu: prepare.py (cp.update() -> get_phases_by_selected_chargemode() setzt phases=1) -> algorithm.py/min_current.py -> switch_on_threshold_reached() (State bleibt NO_CHARGING_ALLOWED, wenn Überschuss fehlt) -> process.py (führt die Umschaltung aus). Alles im selben Tick - passt zu "in derselben Sekunde" aus Matts Log.

Noch ein Vorschlag:

1. get_phases_by_selected_chargemode() erzwingt vor Ladestart nicht mehr 1, sondern behält die bisherige Phasenzahl bei.
2. switch_on_threshold_reached() rechnet die Einschaltschwelle weiterhin fest mit 1 Phase, unabhängig von control_parameter.phases.
3. switch_on_timer_expired() setzt die Phasenzahl explizit in beiden Fällen (aktuell nur bei ausreichend Überschuss für die maximale Phasenzahl).

Damit bleibt die Entscheidung komplett an der einen Stelle, kein zweiter Weg in der algorithm.py nötig - und der eigentliche Bug (unnötige Umschaltung während NO_CHARGING_ALLOWED, weil phases vorher grundlos auf 1 gesetzt wurde) ist behoben, weil control_parameter.phases dann während NO_CHARGING_ALLOWED einfach dem tatsächlichen Hardware-Zustand entspricht.

Ich baue das gerne so um, wenn das für dich passt.

[LKuemmel]

Ehrlich gesagt, kann ich aus Deiner bisherigen Argumentation weder den Bug theoretisch nachvollziehen noch nachstellen, um zu verifizieren, dass der PR den Bug wirklich behebt.

Immer dann, wenn im ersten Zyklus der Überschuss noch nicht ausreicht. In switch_on_threshold_reached() (counter.py) setzt nur der if-Zweig (Schwelle erreicht) den State auf SWITCH_ON_DELAY. Der else-Zweig (Schwelle nicht erreicht, texts.not_exceeded) lässt den State unverändert auf NO_CHARGING_ALLOWED - das ist der Normalfall, wenn beim Anstecken nicht sofort genug Überschuss da ist.

Und _is_phase_switch_required() hat einen eigenen, expliziten Zweig für genau diesen State (chargepoint.py, der elif control_parameter.state == ChargepointState.NO_CHARGING_ALLOWED-Zweig)

Reihenfolge innerhalb eines Zyklus passt auch dazu: prepare.py (cp.update() -> get_phases_by_selected_chargemode() setzt phases=1) -> algorithm.py/min_current.py -> switch_on_threshold_reached() (State bleibt NO_CHARGING_ALLOWED, wenn Überschuss fehlt) -> process.py (führt die Umschaltung aus). Alles im selben Tick - passt zu "in derselben Sekunde" aus Matts Log.

Kannst Du mit dem beschriebenen Ablauf den Bug nachstellen?
Wenn mangels Überschuss keine Ladung gestartet wird, wird kein Soll-Strom freigegeben und auch nicht umgeschaltet:

core/packages/control/chargepoint/chargepoint.py

Line 353 in 82e691a

self.data.set.current != 0 and self.data.get.charge_state is False):

Nach dem Wechsel in SWITCH_ON_DELAY gibt es kein passenden Branch in _is_phase_switch_required.

switch_on_threshold_reached() rechnet die Einschaltschwelle weiterhin fest mit 1 Phase, unabhängig von control_parameter.phases.
Dann wird bei dreiphasigen Ladung die Einschaltverzögerung gestartet, obwohl nicht genügend Überschuss da ist.

[seaspotter]

Danke für deine Geduld Lena und die kritischen Nachfragen - die ursprüngliche These (phases=1 löst über NO_CHARGING_ALLOWED eine vorzeitige 3→1-Umschaltung aus) konnte ich trotz mehrerer Versuche nicht reproduzieren. Da lag ich falsch, und du hattest die ganze Zeit zurecht Zweifel. Ein Teil davon liegt sicher auch daran, dass der Code an der Stelle über mehrere Module verteilt und nicht immer auf den ersten Blick zu überblicken ist - mea culpa. Ich würde vorschlagen, ich mach den PR hier zu.

Dabei ist mir bei Matts Log aber ein separates "Problem" aufgefallen:
Die Phasenzahl wird nur einmal entschieden, beim Verlassen von NO_CHARGING_ALLOWED (switch_on_timer_expired(), Überschussprüfung). Ist eine Session bereits CHARGING_ALLOWED und das Fahrzeug fängt später eigenständig an zu laden, übernimmt get_phases_by_selected_chargemode() einfach das alte phases_to_use, ohne den Überschuss neu zu prüfen - korrigiert wird das erst reaktiv, sobald das Fahrzeug schon an der 1-phasigen Grenze hängt. Bei Matt: Er hat um 12:13 das Ladelimit im Fahrzeug von 80% auf 100% angehoben, das Fahrzeug hat daraufhin eigenständig geladen, PV-Überschuss lag durchgehend bei ~5-6kW. Ist das etwas was man fixen sollte? Lohnt sich dafür ein neuer PR oder soll das so bleiben?
#3908 (comment)

Vorschlag: Für den bestätigten Fall (Überschussprüfung erneut anstoßen, wenn charge_state innerhalb einer laufenden CHARGING_ALLOWED-Session auf True wechselt)?
Was meinst du dazu?

Ich hatte defintiv auch einen Fall wo er mit 1p gestartet ist obwohl Überschuss für 3p vorhanden war, das war der Ausgang für den PR, ich hab leider den Log von damals nicht mehr und kann nachvollziehen ob das genauso war. Ansonsten mach ich auch gern nochmal ein Issue auf wo wir die Fälle nochmal sammeln mit Logs (als txt damit es im paste nicht verloren geht)?

[LKuemmel]

Ich hatte defintiv auch einen Fall wo er mit 1p gestartet ist obwohl Überschuss für 3p vorhanden war, das war der Ausgang für den PR, ich hab leider den Log von damals nicht mehr und kann nachvollziehen ob das genauso war. Ansonsten mach ich auch gern nochmal ein Issue auf wo wir die Fälle nochmal sammeln mit Logs (als txt damit es im paste nicht verloren geht)?

Ja, das macht Sinn.

[LKuemmel]

Dabei ist mir bei Matts Log aber ein separates "Problem" aufgefallen:
Die Phasenzahl wird nur einmal entschieden, beim Verlassen von NO_CHARGING_ALLOWED (switch_on_timer_expired(), Überschussprüfung). Ist eine Session bereits CHARGING_ALLOWED und das Fahrzeug fängt später eigenständig an zu laden, übernimmt get_phases_by_selected_chargemode() einfach das alte phases_to_use, ohne den Überschuss neu zu prüfen - korrigiert wird das erst reaktiv, sobald das Fahrzeug schon an der 1-phasigen Grenze hängt. Bei Matt: Er hat um 12:13 das Ladelimit im Fahrzeug von 80% auf 100% angehoben, das Fahrzeug hat daraufhin eigenständig geladen, PV-Überschuss lag durchgehend bei ~5-6kW. Ist das etwas was man fixen sollte? Lohnt sich dafür ein neuer PR oder soll das so bleiben?
#3908 (comment)

Ich finde das zu perfektionistisch. Da gibt es aktuell Themen, die wichtiger sind.
In dem Fall wurde das Verhalten ja auch vom Nutzer ausgelöst.