Warp1 mit 2.0.6: Ende Ladevorgang für Ladetracker?

[gustavpaula]

Hallo Tinkerforge Team,

mein Warp1 Smart ist mit SDM72 nachgerüstet, SW ist 2.0.6. Ich lade einen VW e-up an der Warp, meistens auf 80% (fahrzeuggesteuert).

Die Ladungssteuerung geht über EVCC (rpi und OpenHAB).

Wenn ich mir die Statusseite des Web UI anschaue, dann läuft die Uhr des "Laufenden Ladevorgangs" endlos weiter, obwohl das Auto keinen Strom mehr zieht. Der "Fahrzeugstatus" ist auf "ladebereit".

Welches Ereignis wird denn als Ladeende gewertet, damit die Uhr dann stehen bleibt? Erst, wenn man den Ladestecker zieht?

Ist das so gewollt?

Ich kann verstehen, dass es schwierig ist, aus Sicht der WB zu sagen, wann die Ladung "zu Ende" ist, weil, nur weil gerade kein Strom fließt, muss ja noch nicht die Ladung "zu Ende" sein. Es könnte ja auch nur über die externe Steuerung pausiert sein.

Also, wie seht ihr das?

 

Danke u. Gruß,

Gebhard

 

[floho]

Das Anstecken ist der Start und das Abstecken das Ende. Passt ja auch als „Ladevorgang“. Zeit in der Strom fließt ist das natürlich nicht unbedingt.

bearbeitet October 1, 2022 at 18:51 von floho
Typo

[gustavpaula]

Ok, danke für die Antwort. Wenn dem so ist, ist die Anzeige der Ladedauer irgendwie ohne Aussage. Kann also ignoriert werden. ;-)

[floho]

Naja, so gesehen schon. Es zeigt "nur" an wie lange das Auto angeschlossen war. Der Begriff "Ladezeit" ist hier vielleicht etwas schwammig. Ich kenne jemanden mit einer OpenWB. Die macht das so, dass jeder Ladevorgang an sich also solcher verbucht protokolliert wird. Da er mit PV-Überschuss lädt ist das ein Buch an Ladungen pro Anstecken. Optimal ist das auch nicht. Ich denke hier gibt es für jede Variante ein für und wieder. Für die Abrechnung an die Firma finde ich die Warp Lösung besser. Denn 800 Einträge pro Monat sind nicht so schön ;-)

[gustavpaula]

Ja, wie gesagt, was die Ladedauer bestimmt ist Definitionssache.

Mehrere hundert Einträge pro Monat hatte ich in meinem ersten Monat mit nachgerüstetem Zähler auch. Ist noch unklar, warum es so viele Ladungen mit Dauer unter 1 Minute gibt (siehe Anhang). Aber das ist ein anderes Thema...

charge-log-warp-SzQ-2022-10-01T19-00-56-354.csv

[rtrbt]

On 10/3/2022 at 11:18 AM, gustavpaula said:

Ist noch unklar, warum es so viele Ladungen mit Dauer unter 1 Minute gibt (siehe Anhang)

Das ist wirklich interessant. Hattest du dazu schonmal was geschrieben? Wenn du das reproduzieren kannst würde mich ein Ladeprotokoll interessieren (kannst du auf der Ladecontroller-Unterseite erzeugen)

[gustavpaula]

Hallo. Freut mich, dass das jemand interessant findet.

Ich werd mal versuchen, das reproduzierbar zu machen und ein Ladeprotokoll dazu zu erzeugen. Kann aber ein bisschen dauern.

Gruß, Gebhard

[gustavpaula]

Nun ja, also das Problem trat zumindest bis 15.10. auf lt. angehängten Charge Log und dann noch  mal am 25.

Aber das reicht ja wohl nicht zur Diagnose, wahrscheinlich braucht es das Ladeprotokoll. Das hab ich jetzt mal gestartet, aber kann das über Wochen laufen?? Und da heißt es auch "Aufzeichnung läuft. Tab nicht schließen!". Wie soll ich das über Wochen machen?? Üblicherweise mach ich bei meinem Rechner abends einen Shutdown bzw. über Nacht schaltet das WLAN ab und damit hat die WARP eh keinen Kontakt mehr zum Heimnetz und irgendeinem Tab im Web UI.

What now?

charge-log-warp-SzQ-2022-10-27T17-47-09-335.csv

[rtrbt]

22 hours ago, gustavpaula said:

Das hab ich jetzt mal gestartet, aber kann das über Wochen laufen??

Nein, das Ladeprotokoll solltest du max. ein paar Minuten laufen lassen. Du musst eher, wenn das Problem auftritt, das Protokoll starten, ~ 30 Sekunden laufen lassen und das dann runterladen.

Das hat natürlich das Problem, dass du das mitbekommen musst, während es passiert.

[gustavpaula]

Ok, danke. Jetzt hab ich verstanden, wie das Ladeprotokoll funktioniert. Das ist natürlich aussichtslos, der Fehler tritt ja sporadisch auf (wie man an meinem Charge Log sehen kann). Dann werde ich halt damit leben müssen. Allerdings sind ein Charge Log mit 900 Vorgängen  in 3 Wochen auch nicht wirklich brauchbar.

Wenn ich noch was zur Aufklärung des Fehlers beitragen kann, dann lasst es mich bitte wissen.

[gustavpaula]

Hab gerade nochmal nachgeschaut: Der Effekt ist aufgetreten während das Ladeprotokoll aufgezeichnet wurde. Am 28.10. ab 7:49 haben Charge Log und Ladeprotokoll Aufzeichnungen.

Das Charge Log zeichnet Ladevorgänge mit 45 Sek. auf, das Ladeprotokoll enthält mehrere "tracked end of charge" im Abstand einer halben Minute.

evse-debug-log-warp-SzQ-2022-10-28T18-41-20-665.txt charge-log-warp-SzQ-2022-10-28T18-43-21-828.csv

[rtrbt]

Hm im Debug log fehlen leider die interessanten Einträge. Da ist das Webinterface vermutlich in eine String-Längenbeschränkung gelaufen, weil die Aufzeichnung so lange lief. Das müssen irgendwie besser implementieren. Habe dazu mal ein Issue aufgemacht:https://github.com/Tinkerforge/esp32-firmware/issues/171

Ich dachte erst, dass du eventuell einen Bug in Kombination mit EVCC hast, aber die 45-Sekunden-Ladevorgänge treten auch auf, wenn gerade keine MQTT-Verbindung besteht.

Ich habe mir das Charge Log nochmal angesehen. Auffällig ist, dass die 45-Sekunden-Ladevorgänge immer nach einem "normalen" lang laufenden Ladevorgang passieren. Vielleicht tritt das Problem nur auf, wenn das Auto voll ist. Kannst du testweise mal das Auto an die Wallbox hängen wenn es noch zu ~ 95% voll ist, es voll laden und dann nachsehen ob die kurzen Ladevorgänge wieder passieren? Das sollte auch auffallen wenn du an der Wallbox vorbeigehst. Ich würde erwarten, dass das Schütz dann alle 45 Sekunden schaltet.

[poohnet]

Könnte da evtl. ein Zusammenhang mit meinem (gelösten) Problem bestehen? Ein Update der EVSE-Kalibrierung hat seinerzeit geholfen...

 

[gustavpaula]

> Hm im Debug log fehlen leider die interessanten Einträge.

Kann ich da irgendwas  verbessern beim nächsten Log? Gibt es Stufen der Mitteilsamkeit? (Verbosity)

> Vielleicht tritt das Problem nur auf, wenn das Auto voll ist.

Wenn du mit "voll" 100% geladen meinst:  Ich lade nur bis 80%. Meinst du vielleicht, das Problem tritt auf, wenn das Auto sagt "ich bin satt" und den Ladevorgang  beendet?

Ok, also schon am Schütz klappern merk ich das. Klar, prüf ich beim nächsten Mal.

@poohnet: Neue Kalibierdatei hab ich eigentlich schon erhalten, nachdem es ein Problem mit dem Laden bei 6A gab (toggeln):

 

[rtrbt]

19 hours ago, gustavpaula said:

Kann ich da irgendwas  verbessern beim nächsten Log? Gibt es Stufen der Mitteilsamkeit? (Verbosity)

Nein, das müssen wir in der Firmware fixen. Das Logging war einfach bisher nicht darauf ausgelegt, dass man es länger als ein paar Minuten laufen lässt.

19 hours ago, gustavpaula said:

Wenn du mit "voll" 100% geladen meinst:  Ich lade nur bis 80%. Meinst du vielleicht, das Problem tritt auf, wenn das Auto sagt "ich bin satt" und den Ladevorgang  beendet?

Genau.

 

[kmfrank]

Hallo Zusammen,

mein Auto lade ich ausschließlich mit PV-Überschuß, das bedeutet ,mein Auto ist ständig angesteckt. So sind meine Ladevorgänge im Ladelog manchmal länger als ein Tag.

Gibt es eine Möglichkeit oder Einstellung den Ladevorgang nach dem Ende vom Stromfluß im Ladelog beendet und bei Ladebeginn neu startet?

Im Hinblick auf die THG-Prämie für Ladepunkte, wo die Netzagentur den Ladelog abfragen kann, wäre das wichtig.

[rtrbt]

On 11/15/2022 at 8:50 PM, kmfrank said:

Gibt es eine Möglichkeit oder Einstellung den Ladevorgang nach dem Ende vom Stromfluß im Ladelog beendet und bei Ladebeginn neu startet?

Aktuell geht das nicht. Ich habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/175 Wir müssen aber prüfen, ob das umsetzbar ist.

[gustavpaula]

Muss ich ehrlich gesagt sagen, aus Anwendersicht wäre es wirklich logischer, den Ladevorgangsanfang und Ende vom Stromfluss abhängig zu machen. Mein Auto hängt durchaus mal drei Tage an der WB, lädt aber dann mit PV nur 3h und zum Schluß habe ich eine Dauer des Ladevorgangs von 72 h. In Meinen Augen nutzlos, weil ich will ja nicht wissen, wielange das Auto angesteckt im Carport gestanden hat. Aber wahrscheinlich gibt es auch andere Sichten...

[gustavpaula]

Update zum Thema "45 Sekunden Ladevorgänge im Ladetracker":

Seit dem letzten Rücksetzen am 30.11. ist das Problem nicht mehr aufgetreten. Im Dezember wurden nur plausible Ladevorgänge aufgezeichnet (mehrere kWh, mehrere Stunden).

Ich werde das weiter beobachten.

Warum das jetzt auf einmal funktioniert? K.A., ich habe nichts geändert oder anders gemacht als vorher. Vllt. hat ein automatisches Update der OpenHAB SW auf dem Raspi 4 einen BUg behoben?

Ich werde das noch 2 Monate weiter beobachten.

[gustavpaula]

So, jetzt ist das "Problem" doch wieder aufgetreten, und zwar wenn ich vorher mit EVCC Modus "Min+PV" geladen hatte und beim Erreichen der 80% (eingestellt in der Ladekonfiguration im e-up!) nicht in EVCC auf OFF gestellt hatte. Im Anhang ein Ladelog über ein paar Zyklen im "EVCC Min-PV" Modus, 45 Sek. wird geladen (Ladeenergie ca. 10W), die LED an der WARP atmet aber nicht am e-up (Dauergrün). Dann schaltet das Schütz, die LED ist dauer-blau für ein paar Sek., dann schaltet das Schütz wieder und die LED atmet usw. Am Ende habe ich in EVCC (bzw. der Representation in OpenHAB) auf Modus OFF geschaltet.

Im Dezember hatte ich anscheinend nie mit "Min-PV" geladen, erst gestern wieder.

Im Log gibt es viele Verbindungsabbrüche bei WLAN Verbindung zwischen WARP und Fritzbox, aber ich glaube nicht, dass es da einen Zusammenhang mit den 45 Sek. Ladevorgängen gibt.

Ab 2023-01-04 17:47:24,435  sieht man, dass sich der Charger State dauernd ändert, aber man sieht nicht, wie diese Änderung angestoßen wird.

Kann man das Ladeprotokoll noch irgendwie ausführlicher erstellen, dass man auch sieht, WARUM sich Charger State dauernd ändert?

evse-debug-log-warp-SzQ-2023-01-04T17-53-52-364.txt

[rtrbt]

On 1/4/2023 at 6:32 PM, gustavpaula said:

So, jetzt ist das "Problem" doch wieder aufgetreten, und zwar wenn ich vorher mit EVCC Modus "Min+PV" geladen hatte und beim Erreichen der 80% (eingestellt in der Ladekonfiguration im e-up!) nicht in EVCC auf OFF gestellt hatte.

Hm das ist eine interessante Kombination aus Einstellungen. Hast du den e-up in EVCC konfiguriert?

On 1/4/2023 at 6:32 PM, gustavpaula said:

Kann man das Ladeprotokoll noch irgendwie ausführlicher erstellen, dass man auch sieht, WARUM sich Charger State dauernd ändert?

Das sollte ausführlicher sein. Ich befürchte, dass durch die WLAN-Verbindungsprobleme das eigentliche Ladeprotokoll verloren gegangen ist. Im Log sind nur der Header und Footer jeweils bestehend aus Debug-Report und Event-Log und dazwischen nur der Header des Ladeprotokolls (der hier:

millis,STATE,iec61851_state,charger_state,contactor_state,contactor_error,allowed_charging_current,error_state,lock_state,HARDWARE CONFIG,jumper_configuration,has_lock_switch,evse_version,LL-State,led_state,cp_pwm_duty_cycle,charging_time,time_since_state_change,uptime,ADC VALUES,CP/PE,PP/PE,VOLTAGES,CP/PE,PP/PE,CP/PE (High),RESISTANCES,CP/PE,PP/PE,GPIOs,Input (0),Output (1),Motor Input (2),Relay (3),Motor Fault (4)

Danach sollten eigentlich CSV-Zeilen kommen, die die ganzen Ladecontroller-Infos entsprechend des Headers enthalten und das alle 50 ms. (Das ist dann das eigentliche Ladeprotokoll)

 

Da du einen VW hast: Kannst du im Moment sauber mit 6 Ampere laden? Deine Wallbox ist schon einmal kalibriert, aber eventuell müssen wir da nochmal nachjustieren. Eventuell interagiert da auch gerade VW-Verhalten, der Ladestop bei 80%, die Kalibrierung und EVCC ungünstig.

[gustavpaula]

Hi.

> Hm das ist eine interessante Kombination aus Einstellungen. Hast du den e-up in EVCC konfiguriert?

Nein, so wie ich die evcc Doku verstehe, wird ein Fahrzeug nur in der evcc.yaml Datei konfiguriert, wenn es die Möglichkeit gibt, den Ladezustand der Batterie abzufragen. Das geht beim e-up nur über das VW webinterface und kostet unverschämt, hab ich nach dem ersten kostenlosen Jahr nicht verlängert.

> Das sollte ausführlicher sein. Ich befürchte, dass durch die WLAN-Verbindungsprobleme das eigentliche Ladeprotokoll verloren gegangen ist.

Ok, dann muss ich als nächsten versuchen, rauszu bekommen, warum es zu Verbindungsabbrüchen kommt.

> Da du einen VW hast: Kannst du im Moment sauber mit 6 Ampere laden?

Ja, nach Kalibrierung (in einem anderen thread) kann evcc alle Ladeströme von 6-16A sauber durchfahren.

Diese 45s Ladungen treten ja auf, nachdem der e-up die in seiner Konfiguration (per VW App) eingestellten 80% erreicht hat. D.h. eigentlich gibt es gar keinen Ladebedarf mehr. Ich verstehe auch noch nicht, wer diese 45s Ladungen initiiert, das Auto oder evcc oder die WB von sich aus??

Danke für eure Hartnäckigkeit! ;-)

[rtrbt]

22 hours ago, gustavpaula said:

Nein, so wie ich die evcc Doku verstehe, wird ein Fahrzeug nur in der evcc.yaml Datei konfiguriert, wenn es die Möglichkeit gibt, den Ladezustand der Batterie abzufragen. Das geht beim e-up nur über das VW webinterface und kostet unverschämt, hab ich nach dem ersten kostenlosen Jahr nicht verlängert.

Das ist gut. Dann können wir seltsame Steuerungsversuche von EVCC ausschließen.

22 hours ago, gustavpaula said:

Ok, dann muss ich als nächsten versuchen, rauszu bekommen, warum es zu Verbindungsabbrüchen kommt.

Ist der Rechner mit dem du das Ladeprotokoll aufzeichnest auch im WLAN? Eventuell war das Problem in dem Moment, dass der Rechner kurz keinen Empfang hatte.

22 hours ago, gustavpaula said:

Ja, nach Kalibrierung (in einem anderen thread) kann evcc alle Ladeströme von 6-16A sauber durchfahren.

Diese 45s Ladungen treten ja auf, nachdem der e-up die in seiner Konfiguration (per VW App) eingestellten 80% erreicht hat. D.h. eigentlich gibt es gar keinen Ladebedarf mehr. Ich verstehe auch noch nicht, wer diese 45s Ladungen initiiert, das Auto oder evcc oder die WB von sich aus??

Rein technisch muss das Auto die Ladung starten: Das funktioniert so, dass die Wallbox dem Auto (über ein PWM-Signal) mitteilt wie viel Strom gerade erlaubt ist und das Auto auf das Signal einen Widerstand anlegt. Je nach Größe des Widerstands will das Auto laden (880 Ω) oder nicht (2700 Ω).

Den Widerstand zurückzumessen ist aber bei WARP1 und VWs knifflig, deshalb u.A. die Nachkalibrierung die wir bei dir gemacht hatten.

Wir müssen jetzt im Endeffekt mit dem Ladeprotokoll rausfinden, ob das Auto wirklich zwischen den zwei Widerstandswerten wechselt oder ob die Messung nicht sauber passt und deshalb in der Situation z.B. ganz knapp über bzw. unter dem Schwellwert liegt den wir als Grenze zwischen 880 Ω und 2700 Ω verwenden und die Wallbox deshalb nur glaubt, dass das Auto laden will.

22 hours ago, gustavpaula said:

Danke für eure Hartnäckigkeit! ;-)

Immer gerne :)

[gustavpaula]

So, endlich mal eine Log-Datei, die jetzt hoffentlich zeigt, was ich meine (also 45 Sekunden-Ladevorgänge am Ende eines Ladens).

Meine SW Version an der WARP1 ist 2.1.2-6439406f. Konfigurationsversion 2.0.0.

Wie ich das Log erstellt habe:

Im Wallbox Webinterface die externe Steuerung deaktiviert (EVCC in OpenHAB) und die Änderung abgespeichert.

Dann mit fester Ladestromeinstellung (zunächst 8A, später 6A) meinen e-up von 80% auf 100% aufgeladen.

Als ich gesehen habe, dass die Ladeleistung von 2,8 kW auf 10W gefallen ist, habe ich das erste Ladeprotokoll gestartet. Das hab ich dann ca. 20 Minuten laufen lassen, aber das Auto hat noch minimal weiter geladen (wg. Balancing), also hab ich abgebrochen. -> evse-debug-log-warp-SzQ-2023-06-13T13-40-38-672.txt

Eine viertel Stunde später hab ich dann nochmal gecheckt und gesehen, dass der Zustand erreicht war, dass 45 Sekunden-Ladevorgänge stattfinden, mit Relaisklackern.

-> zweites Ladeprotokoll evse-debug-log-warp-SzQ-2023-06-13T13-54-16-796.txt

Ich hoffe, dass man an diesen Protokollen sehen kann, ob das evtl. immer noch ein Problem mit der Widerstandmessung / WARP1 ist.

Danke für eure Hilfe!

gustavpaula

evse-debug-log-warp-SzQ-2023-06-13T13-40-38-672.txt evse-debug-log-warp-SzQ-2023-06-13T13-54-16-796.txt

[borg]

Die Kalibrierung/Widerstandsmessung sieht leider sehr gut aus.

Im Log kann man sehen das der "allowed_charging_current" (das ist das Minimum aller gesetzten maximalen Ladeströme) für 150ms auf 0 geht:

Das passiert dann ca. alle 45 Sekunden. Manchmal ist es etwas länger als 150ms aber immer nur für kurze Zeit.

Die große Frage ist jetzt was da den Strom runter setzt, geht leider aus dem Log nicht hervor. Eventuell müssen wir dir eine Testfirmware mit mehr Debug-Ausgabe geben.