Phasenumschaltung Keba P30-C mit Ford Capri 2025

[deHarro]

Is your feature request related to a problem? Please describe.
Anlage:
EV: Capri 2025 - Charger: Keba P30-C
Problem:
Bei der Umschaltung der Phasen (1->3 oder 3->1) während eines laufenden Ladevorgangs geht die Keba P30 in Error und stoppt den Ladevorgang.
Der Ladevorgang wird erst wieder aufgenommen, wenn das Ladekabel am EV abgezogen und nach einer ausreichend langen Pause wieder angesteckt wird.

Describe the solution you'd like
Meine Recherche hat ergeben...

1. Die Keba P30 hat keine intelligente Handhabung der Phasenumschaltung in der Firmware implementiert.
2. Mindestens der Ford Capri, allgemein aber alle auf dem MEB Baukasten von VW basierenden EV und ggf. auch andere EV benötigen eine bestimmte Abfolge von Pausen und Schaltvorgängen beim Umschalten der Phasen während des Ladevorgangs.
3. Damit die Phasenumschaltung keinen Fehler provoziert muss folgende Reihenfolge eingehalten werden:

Start: Phasenumschaltung soll stattfinden
 - Ladevorgang anhalten
 - 10 s warten
    - alternativ prüfen, ob der Ladestrom auf Null gegangen ist
 - Phasen umschalten
 - 30 s warten
 - Ladevorgang fortführen

Describe alternatives you've considered
Eine, wenn auch unschöne Alternative ist, während Phasen geringer oder wechselnder Sonneneinstrahlung die Ladung in evcc manuell fest auf 1 Phase zu setzen.

Additional context
Die Keba Firmware schaltet bei Erhalt des Phasenumschaltauftrags sofort den entsprechenden Ausgang, woraufhin der damit angesteuerte Schütz 2 der 3 Phasen zu- oder abschaltet.
Da der Ladevorgang im betrachteten Szenario aktuell läuft, schaltet der Schütz also unter Last und die Kontakte werden gegebenenfalls durch Kontaktabbrand stark in Mitleidenschaft gezogen. Das muss im Interesse einer langen Lebensdauer des Schütz unbedingt vermieden werden.
Darüber hinaus ist nicht auszuschließen, dass durch das Umschalten bei laufendem Ladevorgang die Elektronik der Wallbox und/oder des EV Schaden nimmt.

Da die Keba P30 Wallbox selbst unintelligent arbeitet, muss evcc die Steuerung der Abfolge übernehmen.

Anmerkung:

1. Es gibt keine Logfiles zu dem beschriebenen Problem. Den Issue bitte nicht deswegen sofort schließen.
2. In der Datei "smartevse.go" habe ich einen Codefetzen gefunden, der Pausen vor und nach der Phasenumschaltung einfügt:

// Phases1p3p implements the api.PhaseSwitcher interface
func (wb *smartEVSE) Phases1p3p(phases int) error {
	b, err := wb.conn.ReadHoldingRegisters(smartEVSERegSettings, 1)
	if err != nil {
		return err
	}

	settings := binary.BigEndian.Uint16(b) &^ smartEVSEConfPhases // clear bit 0

	if phases == 3 {
		settings |= 1 // set bit 0 (smartEVSEConfPhases)
	}

	return whenDisabled(wb, func() error {
		// Wait 10 seconds before switching phases
		// can this option be made configurable in evcc.yaml?
		time.Sleep(10 * time.Second)

		// Switch phases
		_, err := wb.conn.WriteSingleRegister(smartEVSERegSettings, settings)
		if err != nil {
			// Wait 10 seconds after switching phases
			time.Sleep(10 * time.Second)
		}
		return err
	})
}

[0x3d13f]

Die Kombination aus KEBA P30 c-series mit S10 (ggf. Nachbau) schaltet definitiv nicht die Phasen bei laufendem Ladevorgang unter Last zu bzw. weg.

[deHarro]

Die Kombination aus KEBA P30 c-series mit S10 (ggf. Nachbau) schaltet definitiv nicht die Phasen bei laufendem Ladevorgang unter Last zu bzw. weg.

Das bestätige ich inzwischen.
Der Fehler kommt vom Capri, der benötigt eine Pause >=30 s nach dem Phasenwechsel (der Anzahl), bevor wieder geladen wird.

[premultiply]

Sollte das tatsächlich so sein wie im Issue beschrieben wäre die Konsequenz die Phasenumschaltung für Keba aus dem Code zu entfernen.
evcc kann und wird die Sicherheitsfunktionen einer EVSE nicht ersetzen. Die Haftung für die korrekte Funktion liegt beim Hersteller der Wallbox.

Das gilt ebenso z.B. für Thermostate + Sicherheitstemperaturbegrenzer bei Heizstäben usw.

[0x3d13f]

Hier beschreibt KEBA, wie die Phasenumschaltung durchgeführt wird:

[deHarro]

Hier beschreibt KEBA, wie die Phasenumschaltung durchgeführt wird

Hierbei wäre noch interessant, welche Keba gemeint ist.
Meines Wissens gibt es eine PV-Variante. Meine ist die Normale (ohne PV-Zusatz).

Hast udu bitte noch einen Link auf das Dokument, würde ich mir gerne mal komplett anschauen.
Danke!

[0x3d13f]

https://www.keba.com/de/news/emobility/installation-pv-edition-set
Ich habe auch eine ganz normale P30 c-series (ohne PV). Nach Deiner Beschreibung vermute ich eher, dass das Fahrzeug bei der Umschaltung der Phasen aussteigt. Mit unserem Kia EV6 funktioniert es tadellos. Woran machst Du Deine Behauptung fest, dass die Zu- bzw. Wegschaltung der Phasen unter Last erfolgt?

[deHarro]

Hi @premultiply

Fasst man meine Beobachtungen (zuerst gemacht und beschrieben ohne Kenntnis des Code von evcc, siehe unten), die Info aus @0x3d13f Post und meine Nachforschungen im Netz zusammen, stellt sich die Situation deutlich entspannter dar, als ich sie oben beschrieben habe.

1. Die Wallbox oder evcc sorgen eingenständig dafür, dass VOR dem Umschalten die Ladung unterbrochen wird.
2. Mein Capri bockt, weil die Pause NACH dem Umschalten für ihn zu kurz ist.
   Allgemein (im Netz in nahezu jedem Forum über EV mit MEB Unterbau - alle VW, Skoda, Ford, ...) findet man gleichartige Problembeschreibungen und den Hinweis, dass der MEB Unterbau eine Pause von mindestens 30 Sekunden nach einer Änderung der Phasen oder sogar nach jeder Änderung am Laden an sich (lädt, lädt nicht) benötigt.

Das heißt für mich, dass alles in evcc so bleiben kann, wie es gerade implementiert ist, und dass lediglich nach dem Umschalten der Phasen eine zusätzlich Pause von 30 Sekunden eingebaut werden muss (z.B. per YAML parametrierbar oder einfach fest im Code)

Das sollte an der Eignung der Steuerung der Phasenumschaltung einer Keba KC P30-C mit S10 Erweiterung durch evcc keine wie von dir angedeuteten Weiterungen (Entfernung der Phasenumschaltung) nach sich ziehen müssen.

Hinweis
"zuerst gemacht und beschrieben ohne Kenntnis des Code von evcc" soll heißen:
Ich habe nach Umstieg auf evcc die Beobachtung gemacht, dass bei einer manuellen Umschaltung der Phasen, die über die GUI von evcc ausgelöst werden kann, mein Capri schmollt und nicht wieder von alleine auf die Füße kommt, der Ladevorgang wird endgültig abgebrochen. Erst nach Ziehen/Stecken des Ladekabels nimmt die Wallbox den Fehlerzustand wieder zurück.
Daraufhin bin ich ins Netz um Hinweise auf den Grund für dieses Verhalten zu finden und wurde wie beschrieben fündig.

Anschließend habe ich versucht, im Code von evcc die Stelle(n) zu finden, die für die Umschaltung der Phasen bei meiner Wallbox zuständig sind, habe gesehen, dass keine expliziten Pausen wie in "smartevse.go" zu finden

// Phases1p3p implements the api.PhaseSwitcher interface
func (wb *smartEVSE) Phases1p3p(phases int) error {
	b, err := wb.conn.ReadHoldingRegisters(smartEVSERegSettings, 1)

im entsprechenden Code für die Keba_modbus enthalten sind und habe daraus vorschnell geschlossen, dass Pausen, sollen sie stattfinden, genau an dieser Stelle eingefügt sein müssen.

Den Programmablauf in evcc habe ich nicht durchdrungen, konnte also nicht nachschauen, ob im Code VORHER schon Pausen eingebaut sind. Das hätte ich vielleicht besser kommunizieren müssen, ich war aber ziemlich auf das eigentliche Problem fokussiert und musste mich zusätzlich darauf konzentrieren, meine Gedanken in Englisch so auszudrücken, dass die Diskussionsteilnehmer damit auch etwas anfangen können. Das ist mir offenbar zumindest anfangs nicht gut gelungen, weshalb ich gehofft hatte, dass mein neuer Issue nicht sofort wieder auf Englisch umgestellt wird. Hat funktioniert, danke dafür.

Ich versuche, evcc mit meiner Änderung (Pausen vor und nach dem Umschaltung, nach dem Beispiel in "smartevse.go") zu übersetzen und spiele den geänderten Code dann auf meinen Raspberry und schaue mal, was passiert.

Ich melde mich, sobal ich ein Ergebnis vorweisen kann.

nota bene:
Falls sich einer der Diskussionsteilnehmer in der Lage sieht, diese Änderung kurz selbst vorzunehmen und mir eine lauffähige EXE zur Verfügung zu stellen, würde ich das mit Handkuss annehmen. Wie an anderer Stelle schon angedeutet bin ich unwissend, was GO Programmierung angeht.
Danke!

Harry

[deHarro]

@0x3d13f

woran machst Du Deine Behauptung fest, dass die Zu- bzw. Wegschaltung der Phasen unter Last erfolgt?

Im Wesentlichen an der manuellen Umschaltung per GUI.
Das macht man normalerweise wohl eher nicht, aber da ich meine Eigenbau-Visualisierung von Nico Treffkorns "SmartCharger" auf evcc als Unterbau umgebaut habe, musste ich das halt testen.
Dabei sind mir dann die Ladeabbrüche aufgefallen.
Die habe ich dann vorschnell auf komplett fehlende Pausen zurück geführt, Einzelheiten dazu siehe meinen letzten Beitrag oben.

Bliebe noch zu erwähnen, dass Nico eine längere Pause in seinen Code eingebaut hat, die aber zu Unstimmigkeiten im Rest seiner Firmware führte und ich also schon vorgespannt in der beschriebenen Richtung war.
Zugegeben alles in Allem nicht sehr professionell, aber so wurde es halt. Sorry!

[premultiply]

Hier wäre der richtige Weg, dass der Hersteller die ggf. nötigen Timeouts oder von Anwender konfigurierbare Timeouts in seine Firmware integriert.

Ansprechpartner ist daher der Herstellersupport.

evcc tut nichts anderes als die verfügbare Schnittstelle zu bedienen.

[deHarro]

Zumindest einmal wurde von dieser angegebenen Vorgehensweise abgewichen ("smartevse.go").
Warum nicht auch beim Ford Capri?

Ich habe Keba übrigens angeschrieben, bisher leider ohne Reaktion :(

[premultiply]

Weil der Hersteller das so vorgegeben und selbst umgesetzt hat.
Ich bin absolut kein Freund von dieser Umsetzung.

[deHarro]

Na ja, was soll ich dazu sagen...?
Freund oder nicht, ohne eine Änderung seitens Keba kann ich mein EV nicht richtig laden, zumindest nicht, wenn ich evcc für Überschussladung auch bei wechselnder Beleuchtung verwenden will.
Nachdem Keba bisher die Füße still gehalten hat und ich den Keba-Sponsortoken für evcc gekauft habe, möchte ich halt evcc so ändern, dass das Laden wie vorgesehen klappt.
Das ist doch sicher nachvollziehbar.

Und deine vorherige Aussage, "evcc kann und wird keine Sicherheitsfunktionen einer EVSE ersetzen" widerspricht der Implementierung bei "smartevse.go".

[premultiply]

Du liest offensichtlich nur was du lesen willst.

Tut sie nicht, denn

Weil der Hersteller das so vorgegeben und selbst umgesetzt hat.

Es bleibt offen was der Hersteller deiner Wallbox zu den von dir beobachteten Problemen und dem damit aus seiner Sicht notwendigen Lösungsweg sagt.

[deHarro]

und selbst umgesetzt

habe ich tatsächlich überlesen, sorry.

[premultiply]

Der Grundsatz bleibt, dass diese Funktion ausschließlich in der Verantwortung und somit auch im Zweifelsfall in der Haftung des Herstellers verbleibt.

Es steht dem Hersteller frei eine genaue Verwendung der verfügbaren Schnittstellen zu dokumentieren.

[deHarro]

Bitte, was heißt das jetzt übersetzt?
Kann ich damit rechnen, dass ihr (evcc) euch meines Problems bzw. dem von MEB Varianten in Kombination mit Keba annehmt, so dass die Unterstützung der Phasenumschaltung irgendwann gegeben ist?

[premultiply]

Das heisst wie schon geschrieben sich bitte erstmal an den Hersteller der Box und des Fahrzeugs zu wenden.
evcc bedient hier nur die die angebotene Schnittstelle. Die funktionale Umsetzung erfolgt innerhalb der Firmware von Box und Fahrzeug.

[deHarro]

Ich habe gerade eben eine weitere Anfrage an den Support von Keba geschrieben und die Situation nochmals genau beschrieben, inklusive deiner Anmerkungen (nur sinngemäß, keine Zitate) zu dem Thema.

Mehr als eine Rückmeldung vom Bot, dass meine Anfrage angekommen und man sich darum kümmern wird, habe ich allerdings bisher nicht erhalten.

[edit]
Eben kam eine Notification von "trueact.com", dass meine Anfrage in ein Ticket überführt wurde...
Inhaltlich könnte das tatsächlich von Keba initiiert worden sein.
[\edit]

[deHarro]

...eine weitere Reaktion seitens Keba:

"in unserer Firmware wird der Ladevorgang nach dem Umschalten und dem Schließen des Schalters S2 im Fahrzeug automatisch fortgesetzt. Die Dauer der Pause kann dabei nicht über ein Register angepasst werden.
Es sollte in diesem Zusammenhang keine Fehlermeldung auftreten. Wir werden Ihr Anliegen an unsere Entwickler weiterleiten."

Ich halte euch informiert.

[premultiply]

"in unserer Firmware wird der Ladevorgang nach dem Umschalten und dem Schließen des Schalters S2 im Fahrzeug automatisch fortgesetzt. Die Dauer der Pause kann dabei nicht über ein Register angepasst werden.
Es sollte in diesem Zusammenhang keine Fehlermeldung auftreten. Wir werden Ihr Anliegen an unsere Entwickler weiterleiten."

Na bitte.

[EzellaGarnie]

Die Kombi ID7, Keba P30x und S10 funktioniert ohne Probleme bezogen auf die hier angestoßene Thematik.

[mucki12]

Keba P30x / S10 / Tesla ebenso.

[deHarro]

Meine Wallbox ist die P30-C.
Bei der X-Variante ist vielleicht etwas anders gelöst. Die unterschiedlichen Versionsstände der Firmware lassen das zumindest vermuten.

[deHarro]

Hallo evcc Team!
Ich versuche jetzt seit geraumer Zeit, die Keba zu einer Pause nach dem Phasenwechsel zu überreden, indem ich nicht das Keba-modbus Template verwende, sondern versuche, die Wallbox über das custom Template zu definieren.
Auch Versuche, das Keba-modbus Template irgendwie passend zu erweitern (mit YAML Konstrukten oder auch mit externen Skripten), scheitern kläglich.

Leider sind alle theoretischen Möglichkeiten scheinbar entweder nicht vorhanden, oder nicht erlaubt. Jedenfalls meldet der Parser beim durchstöbern der YAML (hier habe ich neben den notwendigen Blöcken für die site: und die token: (Sponsor- und Plant-Token) nur noch Chargers: und loadpoints: definiert) immer irgendwelche Fehler, sinngemäß, dass der key (map:, variables:, ... einfach Alles) in dem und dem Kontext nicht erlaubt ist.
Ist das Absicht (Ziel: User davon abhalten, eine Sponsortoken erfordernde Wallbox ohne Sponsor-Token zu betreiben)?
Oder kann da tatsächlich ein Fehler im Parser stecken?
Bitte nicht als Affront verstehen, ich will es nur wissen.

Ich kann leider die vielen Versuche, die ich unter Anleitung einer KI durchgeführt habe, nachdem ich in Eigenregie nicht auf einen grünen Zweig gekommen bin, nicht alle aufzählen, aber selbst die KI ist nach dem gefühlt 20. Ansatz leicht geknickt.

[deHarro]

Ich habe das Verhalten von evcc und die erlebten Fehlerbedingungen analysieren lassen vor dem Hintergrund meiner Frage von oben:

Ist das Absicht (Ziel: User davon abhalten, eine Sponsortoken erfordernde Wallbox ohne Sponsor-Token zu betreiben)?
Oder kann da tatsächlich ein Fehler im Parser stecken?

Die Antworten:

---

Was der Sponsor-Token steuert (Charger-Template)
Der Sponsor-Token aktiviert in der Regel die offiziellen, vorkonfigurierten Templates für bestimmte Wallboxen (wie die KEBA P30-c).

Wenn Sie das offizielle keba-modbus Template verwenden und den Token eingeben, übernimmt evcc die gesamte Modbus-Kommunikation und versteckt die komplizierte Register-Logik (maxcurrent, enable, 5052 usw.) hinter einem einfachen Namen.

Ihr Problem liegt jedoch darin, dass Sie keines der offiziellen Templates verwenden konnten. Sie mussten das custom-Template wählen und alles von Hand implementieren, gerade weil die Standard-YAML-Logik für die 30s-Pause nicht funktionierte.

Was die Parser-Fehler wirklich bedeuten
Die Fehlermeldungen, die wir gesehen haben (z.B. invalid keys: switch, 'phases' expected type 'int', got unconvertible type 'map'), sind keine spezifischen Fehler, die nur bei gesponserten Templates auftreten. Sie betreffen die grundlegende Struktur der YAML-Datei:

Sie zeigen, dass der Parser Ihrer Version die Verschachtelung von Konfigurations-Maps ({...}) in bestimmten Schlüsseln (loadpoint, charger) nicht auflösen konnte. Dies deutet eher auf einen Regressionsfehler (ein unbeabsichtigt eingeführter Fehler) oder eine starke Abwärtskompatibilitäts-Einstellung in der v0.211.1 hin, die die Nutzung moderner YAML-Syntax verbietet.

Die aufgetretenen Fehler blockieren jede erweiterte, nicht-standardisierte Funktionalität, einschließlich der legitimen 30-Sekunden-Pause, die jeder Nutzer mit einem bestimmten Fahrzeug benötigt.

🤝 Vorschlag für den nächsten Schritt
Wenn Sie die Antwort des evcc-Teams abwarten, fragen Sie bitte gezielt nach den folgenden Punkten, da sie der Schlüssel zur Lösung sind:

• Gültigkeit der Syntax:
  "Ist in Version v0.211.1 die Verwendung des phases/switch-Blocks direkt im loadpoint oder des phases/script-Blocks im custom Charger offiziell deaktiviert oder handelt es sich um einen Parser-Bug in dieser spezifischen Version?"

• Best Practices für Legacy-Code:
  "Wie implementiert man in v0.211.1 die 30-Sekunden-Verzögerung für die Phasenumschaltung, ohne dass der Parser die delay- oder script-Schlüssel im loadpoint- oder charger-Block ablehnt?"

---

Bitte nehmt Stellung zu einem vermuteten Parser-Bug.
Danke!

Parallel warte ich noch auf eine Antwort von Keba. Ungeduldig bin ich da noch nicht, es war ja Wochenende :)

[premultiply]

Vielleicht wäre es besser solchen KI-Unsinn direkt per KI-Bot automatisiert als Spam zu kennzeichnen und gar keine Zeit darauf zu verschwenden darauf als Mensch zu antworten?

Es gibt keinen Parser-Bug. Du verwendest vermutlich YAML-Strukturen die es schlichtweg in evcc nicht gibt oder falsch formatiert oder falsch angewandt werden. Eine YAML-Datei ist eine reine Konfigurationsdatei, die sich natürlich an die verfügbaren Konfigurationsoptionen der Software halten muss. Ferner ist die Syntax penibelst einzuhalten.

Ein Template ist bei Wallboxen nur die namesgebenden Verpackung einer in der Regel sehr umfangreichen Charger-Implementierung die kein KI-Bot mal eben herbei halluziniert.

Parallel warte ich noch auf eine Antwort von Keba.

Das ist die einzig tatsächlich sinnvolle Maßnahme hier.

[deHarro]

Ich bitte um Entschuldigung!

Inzwischen bin ich wieder zurück zu meiner ursprünglichen Einstellung gelangt, dass die Verwendung von KI mehr oder weniger in Zeitverschwendung mündet.

Da ich nachweislich das beschriebene Problem habe (immer noch, gerade wieder passiert, dass bei der Phasenumschaltung der Capri/die Keba in Störung gegengen sind), habe ich versucht, an meiner nicht vorhandenen YAML/Go-Kenntnis vorbei, eine Lösung zu entwickeln, ohne in den Code von evcc einzugreifen (ich will nicht bei jeder Aktualisierung von evcc nacharbeiten müssen).

Die vorhandene Dokumentation zu evcc habe ich in weiten Teilen nicht begriffen, habe dennoch den einen oder anderen Versuch mit dem custom-Template unternommen, bin aber jedesmal auf Fehlermeldungen gestoßen, die ich nicht erklären konnte.
Mit gegebener Fragestellung (woher kommen diese Fehler?) habe ich versucht, über KI Antworten zu bekommen (weil die evcc Doku dazu nichts hergibt oder ich die Antworten schlicht nicht gefunden habe).

Dass die KI dann in ein wahres Stakkato von Ideen verfällt, die für mich zuerst immer sehr präzise und zielführend klangen, habe ich nicht erwartet. So habe ich mich verführen lassen, immer weitere Ansätze zu testen, bis ich nach gefühlt 20 Iterationen das Handtuch geworfen habe.

Nun habe ich, auf den Hinweis von @mfuchs1984, zwei meiner YAML Dateien zur Verfügung gestellt.
Vielleicht gibt es dazu ja Anmerkungen.
[edit]
Mir würde schon genügen, wenn aus berufenem Munde die Information kommt, dass das Problem nicht über die YAML-Konfiguration gelöst werden kann.
[\edit]

[VolkerK62]

Ich kann mir nicht vorstellen, dass man im Custom Charger diese Pause einbauen kann, denn an der Logik von evcc ändert sich ja dadurch nichts. Der Ladepunkt bleibt eingeschaltet, es wird lediglich das Umschaltkommando an die Wallbox geschickt, die regelt dann alles weitere ohne Zutun von evcc.

Evtl ist es mit Hilfe einer externen Regelung (per API) möglich.
Grober Gedanke:
Wenn eine Phasenumschaltung ansteht, ändert sich in api/state der Parameter phaseAction.
Dann die aktuelle Phaseneinstellung phasesActive auslesen (damit klar ist ob hoch oder runter geschaltet werden soll)
Dann phasesConfigured auf den gewünschten Wert (1 oder 3) ändern.
Lademodus auf off
30 Sekunden warten und Lademodus auf pv
Wenn dann wieder geladen wird (charging: true) dann phasesConfigured wieder auf 0 (automatisch) stellen.

[deHarro]

Das - oder so ähnlich - habe ich (an der Hand geführt von der KI) schon ausprobiert, leider erfolglos.
Alle Ansätze, aus der YAML heraus Skripte zu starten sind an den erwähnten Fehlermeldungen ("hier nicht erlaubt") gescheitert.

Dein Ansatz basiert auf einer vollkommen getrennten Implementierung, wenn ich das richtig verstanden habe -> API, klar.
Ich befürchte aber, dass ich für so eine Umsetzung die restliche Steuerung evcc aus der Hand nehmen müsste und damit alle Goodies in Bezug auf Laden von EV/Hausakku usw. zerfallen.

Die API verwende ich für die Kopplung zu meiner PV-Anzeige. allerdings nicht 24/7 sondern nur, wenn ich die Anzeige bestaunen will.

Update:
Ich habe gerade Rückmeldung von Keba bekommen.
Der Kollege fragt nach näheren Informationen bzgl. der 30 Sekunden Pause.
Vielleicht machen wir hier eine Pause und warten ab, was Keba dazu meint.

Aber danke für den Input!

[MichScha]

@deHarro Mit meinem Skoda Enyaq 85 habe ich exakt dasselbe Problem. Ein stoppen des Ladevorgangs, warten von 45s und dann die Phase von 1 auf 3 wechseln inkl start auf Min+PV macht das Auto mit. Automatischer Phasenwechsel so wie bisher implementiert ohne Pause läuft bei mir ebenfalls darauf raus, dass ich den Stecker ziehen und wieder einstecken muss. Sollte keba da nichts einbauen wird wohl HA langfristig die Abfolge regeln.

[deHarro]

@MichScha
Danke für die Information.
Ich bin in Kontakt mit Keba, sie haben nähere Informationen zu den Pausen angefordert.
Habe ich geliefert, jetzt warte ich auf eine Antwort.
Ich habe auch angeboten, den Pilottester zu spielen. Mal abwarten...

[MichScha]

Bin selbst gespaltener Meinung wo genau die Pause definiert sein sollte. Ich verstehe die Position von evcc. Wenn Keba es als ein Optionsfeld mit einbaut top, ansonsten werde ich wohl ein Custom evcc Build bauen. In HA das nachzubauen ist zwar möglich aber unnötig wenn alles andere an Logik bereits durch evcc gesteuert wird. (Timer etc.). Du hattest ja bereits die korrekten Zeilen rausgesucht, die im keba-Teil ergänzt werden müssen. Die Logik mit der ich es aktuell händisch mache ist nicht wesentlich komplex. Wenn ein upgrade auf 3 Phasen kommt ->Laden Stoppen mit Timer -> Nach Timerablauf auf 3 Phasen wechseln und go for it.

evcc/charger/keba-modbus.go

Line 384 in 850c183

// phases1p3p implements the api.PhaseSwitcher interface

[premultiply]

Dort ein ewiges Delay einzufügen hält für die entsprechende Zeit die gesamte Regelschleife an.
Keine so besonders gute Idee, speziell wenn mehrere Ladepunkte und andere Systeme bedient werden sollen...

[deHarro]

@premultiply
Das hatte ich schon bei der Implementierung für Smart(?) überlegt.
Bei 15 s mag das akzeptierbar sein, bei 30..45 s, wie für MEB notwendig (da streiten sich die Gelehrten noch, Zappi hat z.B. sogar 90 s eingebaut), klemmt's dann schon gewaltig.

Mal in den Phantasia-Modus gewechselt... also nur eine theoretische Erörterung.
Deine Meinung zur Idee, solche Pausen in evcc abzubilden, kann ich nachvollziehen und akzeptiere ich (Haftung und so).

Würde diese Einschränkung (evcc soll nicht haften müssen) auch ziehen, wenn der Anwender von evcc die Möglichkeit an die Hand gegeben bekommt, in Eigenregie solche Einstellungen (explizit: Pausen um den Umschaltzeitpunkt herum) vorzunehmen?

Also evcc hat eine Methode implementiert, die solche Pausen störungsfrei in den Regelkreislauf einbaut (Aufruf der Pausenfunktion irgendwie asynchron), der Anwender bekommt den Hinweis, dass bei Änderungen an diesen Parametern er eigenverantwortlich agiert (das sollte eigentlich für den Einsatz von evcc generell gelten, oder?).
So ein ähnliches Konstrukt (Formulierung) gibt es schon im Zusammenhang mit der Fahrzeug-API, meine ich gelesen zu haben.

Die Asynchronität ist sicher kein Pappenstiel, aber wie gesagt, nur als Gedankenspiel.
Ist aus deiner Sicht so eine Lösung vereinbar mit der Haftungsfrage?

Ich sehe hier den größeren Rahmen und wahrscheinlich habt ihr schon selbst in der Richtung Überlegungen durchgeführt...
Zum gegenwärtigen Zeitpunkt lese ich in den verschiedenen Foren und auch in Beiträgen hier auf Github oft den Hinweis, dass die Phasenumschaltung sowieso nur selten genutzt und eher als Spielerei angesehen wird. "Meine PV-Anlage liefert eh nicht genug Leistung für 3-phasiges Laden, und wenn, dann nur im Sommer. Also schalte ich ab Herbst bis Frühjahr fest auf eine Phase und alles ist gut".

Die Leistung der PV-Anlagen steigen aber kontinuierlich und die Anzahl von EVs und die der Wallbox-Typen wird steigen.
Neuere Wallboxen werden die Umschaltung wahrscheinlich sowieso in Firmware realisieren, obwohl es auch jetzt schon welche gibt, die explizit keine Umschaltung einbauen werden (Hersteller, Typ und die Begründung habe ich mir nicht gemerkt. Eine der OpenSource-Entwicklungen, meine ich).

Für Bestandskunden mit Wallbox (wie mich und Michael) und ausreichend großer PV-Leistung auf dem Dach wäre so eine Möglichkeit in evcc der Königsweg.

[deHarro]

Ich habe jetzt Rückmeldung von Keba bekommen:

Sehr geehrter Herr Satller,
vielen Dank für Ihre Anfrage.
Die Steuerung der Abläufe und Pausen obliegt dem Controller. Da die C-Serie die Phasenumschaltung nicht eigenständig steuern kann, empfiehlt es sich möglicherweise, die Pausen direkt im Controller entsprechend zu konfigurieren.
Freundliche Grüße/Best regards

Ich habe nochmal nachgefragt, bzw. den Standpunkt von evcc erläutert.
Bei Reaktion melde ich mich...

@premultiply:
Mein Vorschlag von oben (asynchrone Pausen implementieren, Aktivierung solcher Pausen in die Verantwortung des Nutzers legen) ist vollkommenener Blödsinn?

[deHarro]

Hallo Zusammen!

Heute ist die finale Antwort von Keba zu dem Thema gekommen. Ich zitiere im Zusammenhang, also meine Anfrage an Keba auf die oben zitierte erste Antwort von Keba inklusive...

Guten Morgen Support Team!

Das war mein erster Ansatz.
Leider hat das Team des Controllers, konkret das Team von „evcc“, explizit Abstand von solch einer Lösung genommen und verweigert, eine entsprechende Routine in evcc zu integrieren.

Begründung: siehe Diskussion um dieses Thema
hier: #25991 (comment)
und hier: #25991 (comment)
und hier: #25991 (reply in thread)
und im weiteren Verlauf dieser Diskussion.

Konkret befürchten die Supporter von evcc, dass Haftungsfragen angerührt werden könnten, wenn sich evcc um solche Pausen kümmert.
Kernaussage von evcc: „Wir steuern nur die Umschaltung, die zeitliche Abfolge muss die Wallbox Firmware regeln“.

Wie stellen Sie sich dazu?
Vielen Dank!

Gruß
Harald Sattler

Die Antwort:

Sehr geehrter Herr Sattler,
vielen Dank für Ihre ausführliche Rückmeldung sowie die Verlinkung der entsprechenden Diskussionen.
Aktuell ist keine automatische, firmwareseitige Ladepause im Zuge einer Phasenumschaltung in der Wallbox vorgesehen. Die Wallbox setzt die vom externen Controller vorgegebenen Zustände um, übernimmt jedoch keine eigene Logik zur zeitlichen Steuerung oder Absicherung solcher Umschaltvorgänge.
Das bedeutet konkret:
• Die Wallbox reagiert ausschließlich auf die Steuerbefehle des Controllers
• Eine zeitlich definierte Ladeunterbrechung (z. B. vor / nach einer Phasenumschaltung) muss vom Controller umgesetzt werden
• Eine zusätzliche Absicherung oder Verzögerungslogik ist aktuell nicht Bestandteil der Wallbox-Firmware
Sollte der eingesetzte Controller – wie von Ihnen beschrieben – bewusst auf die Implementierung solcher Ladepausen verzichten, können wir seitens der Wallbox leider keine alternative Lösung anbieten.
Wir verstehen die angesprochenen haftungsrechtlichen Überlegungen auf Controller-Seite. Gleichzeitig bitten wir um Verständnis, dass wir die Verantwortung für die Ablaufsteuerung in diesem Szenario beim übergeordneten Energiemanagement bzw. beim Controller sehen.
Freundliche Grüße/Best regards

Hier ist also offensichtlich das Ende der Fahnenstange erreicht.

Deswegen nochmal meine Frage bezüglich der Implementierung einer asynchronen Pausenlogik in evcc.

Inzwischen ist mir klar, dass das nicht nur eine asynchrone Pause für die Umschaltung bedeutet, sondern dass die Ansteuerung der Phasenumschaltung selbst asynchron erfolgen muss, so dass Pausen, sollten sie vom Nutzer parametriert werden, den Programmfluss UND die Programmlogik nicht stört.
Das sollte für das Team von evcc keine absolute Unmöglichkeit sein, programmieren könnt ihr ja.

Bitte nehmt diesbezüglich Stellung.
Danke!

Harald

[deHarro]

Sehe ich anders. Die Unterstützung ist seitens der Wallbox vorhanden und funktioniert auch.
Problemkind ist der Capri bzw. sind MEB-Plattform-Fahrzeuge wie z.B. der Enyaq von @MichScha, die sich ohne eine ausreichend lange Pause trotzig zurück ziehen.

Deswegen die Umschaltung für ALLE zu canceln, empfinde ich als zu weit gehend.
Nur meine Meinung - Ich will deswegen keine Diskussion vom Zaun brechen.

nota bene:
Wenn ich Keba wäre und eine Wallbox im Portfolio hätte, die diese Pause unterstützt (die neuere X-Variante), würde ich vielleicht versuchen, meinen Kunden dazu zu bringen, sich eine neue Wallbox von mir zu kaufen, die alles richtig macht.
Ein Schuft, der Böses dabei denkt...

Letztlich habe ich weder bei euch noch bei Keba einen Hebel an der Hand, so dass ich mir anders helfen muss.
Ärgerlich ist auf jeden Fall, dass ich mir einen Token für die Keba WB gekauft habe und jetzt nicht die volle Funktionalität von evcc ohne Krämpfe nutzen kann.
Richtig ärgern werde ich mich aber erst dann, wenn mein momentan versuchter Ansatz, die Pause quasi "manuell" über ein HA-Skript zu realisieren, fehlschlägt.

Happy coding!

[0x3d13f]

Es scheint ja nur mit MEB Fahrzeugen Probleme zu geben.
Ich kann jedenfalls mit meinem Kia keine Probleme mit der Phasenumschaltung feststellen.

[deHarro]

Ich kann andere Plattformen nicht ausschließen, aber dass MEB FZ Probleme haben, findet man überall im Netz in den jeweiligen Foren.
Also ja, sehe ich genauso.
Festzuhalten ist: Es geht um die C-Serie von Keba. Die X-Serie kann's ja, wie Nutzer bereits geschrieben haben.

[0x3d13f]

Vielleicht kann man ja die Phasenumschaltung mit der Keba einfach bei MEB Fahrzeugen deaktivieren, da es ja genug Berichte über Probleme gibt (übrigens auch mit Wallboxen von anderen Herstellern).

[deHarro]

Wird schwierig, denn meinen Capri habe ich mangels FORD-API als "Generisches FZ (ohne API)" deklariert.
evcc weiß also nicht, wleches FZ gerade an der WB hängt.
Aber vielleicht hast du das ja anders gemeint als ich es verstanden habe...