Implementierung CP-Unterbrechung/Wake-up für einschlafende EVs

[e-driver]

Hallo und ein gutes Neues noch,

ich möchte ein für sicherlich viele Nutzer hilfreiches Feature ansprechen:
Es geht um das Problem, dass mittlerweile doch mehrere E-Autos (PSA, VW, ...) nach Ladeunterbrechungen einschlafen, das macht insbesondere beim PV-Überschuss geführten Laden natürlich große Probleme.

Man kann sich zwar (dankenswerter Weise ) schon manuell per API mittels <IP>/interruptCp behelfen, ein Automatismus bzw. die Implementierung der -fallweise erforderlichen- CP-Unterbrechung in evse-wifi wäre aber eine wirklich tolle Sache. Man möchte ja nicht ständig aufpassen müssen

Ich bin selbst mit folgender Konfiguration leider auch davon betroffen:
- Software-Version: 2.3.1
- Welcher Betriebsmodus wird verwendet (Normal / Always Active / Remote)? Remote
- Welcher Stromzähler wird verwendet (S0 / Modbus)? Modbus
- Betrieb als WLAN-A oder WLAN-Client? Client
- Hardware-Version: smartwb, Auslieferung März 2021
- Wurde die Wallbox selbst aufgebaut? Nein, fertige smartwb, Installation v. Fachbetrieb
- Welcher Ladecontroller wird verwendet? evcc, version 0.79
- Welches Fahrzeug wird geladen? Opel Corsa-e, Auslieferung Jan. 2021

Ich hatte schonmal angeregt, das Ganze im Lademanagement (evcc) einzubauen https://github.com/evcc-io/evcc/discussions/1569. Von iot4all wurde das auch nochmal aufgegriffen https://github.com/evcc-io/evcc/discussions/1322.
Leider sind wir hier aber nicht weitergekommen, dort sieht man die Wallboxen dafür zuständig.

Als Anregung wurde als Beispiel auf die Phoenix EV-CC....-ETH Controller https://www.phoenixcontact.com/online/p ... tegory=ALL hingewiesen. Auf Seite 36-40 des Handbuchs wird dort relativ genau beschrieben, wie man das umsetzen könnte.
Soweit ich das richtig verstanden habe, funktioniert das so:
Wenn das Auto nicht innerhalb von 30 Sek. vom Status B (Kfz. angeschlossen, Bereit) in den Status C (Laden beginnt) übergeht, wird das CP-Signal für 3 Sek. auf -12V DC gesetzt (Status F?), anschließend wieder auf PWM-Signal umgestellt (+9V bzw. +6V).

Also wenn ihr das auch irgendwie bewerkstelligen könntet, wäre das eeeeecht suuuuper !!
Ich stelle mich natürlich gerne als Tester zur Verfügung.

Grüße,
e-driver

[aiole]

Danke für die "Auffrischung" .
Prinzipiell wollen wir die übergeordneten Systeme (aktuell oWB und EVCC) im "remote" vereinen.
Nun steuert aber oWB den CP-interrupt per API, während premultiply von EVCC gern möchte, dass es die WB selbst erledigt. Das ist das Problem.

Prinzipiell ist es egal, ob der CP hart unterbrochen wird (bei smartWB mit API-Befehl) oder mit der genannten Phoenix-Routine. Das HANDLING des Int (Wer ist dafür zuständig?) ist entscheidend.

Eigene Prüfroutinen könnten wir mal verifizieren, aber ein gut funktionierendes System wegen schlecht gemachter OBC anzufassen, ist immer unschön. Außerdem kostet das eine Menge Zeit. Wir haben auch kein betroffenes EV in Nutzung, was für Tests essentiell wäre.

Kannst Du ev. testweise erst einmal mit oWB v1.9.250 nightly probieren?
Es ist so, dass das Aufwecken trotz CP-U nicht immer zuverlässig funktioniert, da das eigentliche Einschlafproblem im Auto liegt.
Recherchiere bitte mal im oWB-Forum nach Corsa-Nutzern, die CP-U verwenden. Wenn ich mich recht entsinne, läuft das wohl ganz gut. Bei den VW-ID-Modellen klemmt es dagegen noch immer.

VG

[e-driver]

Danke für die schnelle Rückmeldung,
ich verstehe einerseits natürlich, wenn Ihr die übergeordneten Systeme alle "gleich" behandeln wollt, das macht schon Sinn, leider werden wir Nutzer so aber zum ping-pong Ball, da die aktuellen Managementsysteme offensichtlich hier unterschiedliche Auffassungen vertreten.

Dennoch danke für den Tip mit der oWB, dann muss ich mich da wohl nochmal dran setzen. Bislang hatte ich leider Probleme, oWB auf meinem Raspi zero vernünftig und stabil zum laufen zu bringen. Deshalb bin ich seit längerem auch auf evcc umgestiegen.
ps. Habe gerade bei snaptec/openwb nachgesehen, dort kann ich die nightly leider nicht finden, nur stable releases bis 1.7.
Zur v1.9.250 nightly finde ich nur Diskussionen/feedbacks auf openwb.de. Was übersehe ich da gerade?
Hast Du da bitte einen link?

VG

[aiole]

Für oWB wird ein RPi Zero nicht ganz reichen. RPi3, RPi3+ mit Stretch (Buster geht wohl mittlerweile auch) sind die Vorzugsvarianten. RPi4 soll wohl inoffiziell auch gehen.
v1.9.xxx dann nach dieser Anleitung Installieren.
https://github.com/snaptec/openWB#installation
http://openwb.de/main/wp-content/upload ... nWB_v2.pdf (oh Mann - das ist meine Uranleitung ).

Bei oWB ist gerade viel los, weil alle Module für v2.0 auf Python umgestellt werden. Es gibt ein erstes Image vom v.2.0 alpha1-release, was aber nicht für den Produktiveinsatz geeignet ist. Ich würde das auch nicht wirklich empfehlen.
https://openwb.de/forum/viewtopic.php?f=3&t=4513
https://openwb.de/uploads/openWB-2-bull ... ha1.img.gz

Ich hatte heute morgen noch die Idee, eine Checkbox in den Settings mit "internal EV-sleep-check" zu platzieren. Diese könnte als Zusatzschalter verwendet werden, um mit EVCC zu arbeiten.
In diese völlig separate Funktion könnten dann die (aufwendigen) Prüfprozeduren direkt von EVSE-Wifi gefahren werden.
Für oWB müsste das dann aber zwingend deaktiviert werden.

Wirtschaftlich abbilden wird sich das wohl leider nicht, da die meisten user oWB nutzen. Es ist einfacher einzurichten und mit v2.0 erreichen sie jetzt auch ein noch höheres Level.
EVCC ist schön schlank und rank, aber aktuell doch mehr für Leute mit Programmierkenntnissen geeignet.

[aiole]

...
ich verstehe einerseits natürlich, wenn Ihr die übergeordneten Systeme alle "gleich" behandeln wollt, das macht schon Sinn, leider werden wir Nutzer so aber zum ping-pong Ball, da die aktuellen Managementsysteme offensichtlich hier unterschiedliche Auffassungen vertreten.
...

OWB muss "CP_int" für seine eigene HW selbst in der oWB-SW erledigen. Unsere HW ist ähnlich wie die oWB-HW aufgebaut, weshalb das direkt bei der smartWB genutzt wird.

EVCC setzt dagegen auf "SW only" und bindet möglichst viele unterschiedliche Fremd-WB ein. Dort soll es die WB selbst richten.
Allerdings wäre es mit unserem CP-Int-API-Befehl möglich, auch von EVCC-Seite den "CP_Int" zu initiieren. Aber scheinbar fehlt dort das Prüfprocedere, wann es passieren soll.

[e-driver]

Hey aiole,
zunächst mal ein großes Lob und Dankeschön an den hervorragenden Support.
Ich habe noch einen rpi3 rumliegen, dann mache ich mich erstmal mit Deiner Anleitung an die Arbeit ...

Ich hatte heute morgen noch die Idee, eine Checkbox in den Settings mit "internal EV-sleep-check" zu platzieren. Diese könnte als Zusatzschalter verwendet werden, um mit EVCC zu arbeiten.
In diese völlig separate Funktion könnten dann die (aufwendigen) Prüfprozeduren direkt von EVSE-Wifi gefahren werden.
Für oWB müsste das dann aber zwingend deaktiviert werden.

Das hört sich sehr vielversprechend an und lässt mein Herz höher schlagen es wäre ein Traum.

Wirtschaftlich abbilden wird sich das wohl leider nicht, da die meisten user oWB nutzen.

... ich wäre schon auch bereit, einen kleinen obulus beizusteuern

[aiole]

Wirtschaftlich abbilden wird sich das wohl leider nicht, da die meisten user oWB nutzen.

... ich wäre schon auch bereit, einen kleinen obulus beizusteuern

Das ist nett, aber
a) ist das Einschlagproblem nicht überall gegeben und
b) ist EVCC bei der smartWB weniger verbreitet als oWB.

Zunächst müsste das Prüfszenario entwickelt werden. Hier kannst Du gern Ideen dazu posten. Wenn man weiß, was zu tun ist (Prinzip), ist die sw-technische Umsetzung kein unüberwindbares Problem.

Zunächst sollte aber erst einmal die "CP-Int" mit oWB getestet werden. Dort muss das irgendwo in den Einstellungen aktiviert werden. Hinweise sollten im oWB-Forum zu finden sein.

Was mir auch noch einfällt. Wenn der Corsa eingeschlafen ist, mal direkt auf die EVSE-Wifi-setting-Seite gehen und manuell einen CP_int auslösen, um zu sehen, ob das zum Aufwachen führt (mehrfach prüfen).

[e-driver]

Ich werde auf jeden Fall die CP-Int mit oWB testen, die Installation läuft gerade noch ... dauert ja wirklich eine Weile
bin schon auf die Konfiguration gespannt ... ich muss als Grid und PV dann den E3DC-Speicher einbinden und dann noch den Corsa-e. Ich werde weiter berichten, wie es läuft ...

...
Zunächst müsste das Prüfszenario entwickelt werden. Hier kannst Du gern Ideen dazu posten. Wenn man weiß, was zu tun ist (Prinzip), ist die sw-technische Umsetzung kein unüberwindbares Problem.
...

Da kann ich mich gerne beteiligen, bei mir haperts leider eher an der programmiertechnischen Umsetzung.
Das Problem ist grundsätzlich so:
der Corsa-e schläft ein wenn:
- nach dem Anstecken des Ladekabels nicht sofort (innerhalb etwa 2 Min.) mit dem Laden begonnen wird
- es beim Überschussladen (Modus PV) zu zeitweiligen Ladeunterbrechungen (mit ca. mehr als 2 Min.) kommt
- man das Laden manuell beendet und (nach mehr als 2 Min.) wieder manuell starten möchte (Lademodus egal)

es hilft dann nur folgendes:
- manuell CP-Interrupt über die Settingseite oder per http-api im Browser
- Abfrage bzw. Aktualisieren des Ladestatus (Refreshbutton) oder kurzes Switchen von "Sofortladen" auf "zeitversetztes Laden" jeweils über die myopel-app
- Auf- und Wiederzusperren mit Schlüssel am Corsa selbst

Ein Wechsel der Lademodi (off, sofort, min+pv, pv in EVCC) im Remotemodus hilft leider auch nicht, im Übrigen besteht das Problem auch ohne ein übergeordnetes Management, auch im Normalmodus ohne EVCC schläft die Kiste also ein.
Es muss dann jeweils immer wie oben beschrieben (vorzugseise CP-Int) manuell angestoßen werden.
Dann klappts aber bislang unabhängig vom Modus wirklich auch zuverlässig.
Bislang habe ich auch noch keine Begrenzung feststellen können, wie oft der Corsa den CP-Interrupt am Tag "verträgt". Andere EVs haben da wohl Einschränkungen, mehr als zehnmal am Tag hatte ich das Problem aber zugegeben bisher auch noch nicht.

Prüfszenarien könnten etwa sein:
- Auto meldet weiterhin Status_B und geht innerhalb einer gewissen Zeit nicht in Status_C über, obwohl der Controller das PWM-Signal für Status_C angelegt hat
- vielleicht könnte das auch über Abgleiche der Soll-/Ist-Werte der Stromstärke bzw. Ladeleistung gelöst werden?
Wenn es vorstehende Abweichungen gibt, wird der CP-Int ausgelöst.

...
Was mir auch noch einfällt. Wenn der Corsa eingeschlafen ist, mal direkt auf die EVSE-Wifi-setting-Seite gehen und manuell einen CP_int auslösen, um zu sehen, ob das zum Aufwachen führt (mehrfach prüfen).
...

mit dem manuellen CP-Int habe ich schon einiges getestet (sowohl über die setting-seite als auch direkt im Browser über http://192.168.xxx.xxx/interruptCp), das hat immer super funktioniert, siehe oben

[aiole]

...
- vielleicht könnte das auch über Abgleiche der Soll-/Ist-Werte der Stromstärke bzw. Ladeleistung gelöst werden?
Wenn es vorstehende Abweichungen gibt, wird der CP-Int ausgelöst.
...

Wenn ich nicht irre, macht das oWB so.

Man müsste bei EVSE-eigener Überwachung berücksichtigen, dass der Ladestrom durchaus von der remote-Vorgabe abweichen kann (z.B. am Ladeende). Also in etwa so:

Code: Alles auswählen

If I_Soll >=6A & after 30s
    if I_Ist < 1A then Cp-Int (API) end if
end if    

Die 1A sollten reichen, um vom Ladeende abzugrenzen. Das Ganze gilt automatisch je Phase (CP-Int bei Unterschreitung von 1p => 230W, 3p => 690W)

Melde Dich bitte per PN bei Mathias für den Testerbereich an.

[e-driver]

ich habe nun oWB installiert, es läuft allerdings noch nicht wirklich rund, die Konfiguration ist halt ob der vielen Möglichkeiten auch nicht mehr so durchsichtig...
Momentan funktioniert zwar die Ladestromvorgabe bzw. Weiterreichung an smartWB so einigermaßen, allerdings wird die Ladung NICHT gestartet. Das "automatische CP-Interrupt" klappt auch (noch) nicht. Ich muss mich nochmal über die Einstellungen machen und berichte weiter ...

Dein Codeschnipsel klingt logisch und ist für mich gut nachvollziehbar.
PN ist raus, freu mich schon...