Warp1 mit 2.0.6: Ende Ladevorgang für Ladetracker?

[gustavpaula]

Super schnelle Reaktion, danke!

Mit OpenHAB bzw. EVCC hat das aber nichts zu tun, oder? Weil ich hab ja extra die externe Steuerung "disabled". Dass noch die MQTT Kommunikation aktiv ist, sollte dann ja keinen Einfluss mehr haben. Ich kann natürlich auch versuchen, nochmal den Zustand herzustellen OHNE irgendeine Kommikation ins NW und die Wallbox Steuerung über den integrierten HTTP Server zu machen. Was meint ihr?

Zumindest funktioniert das Ladeprotokoll jetzt schon mal besser als noch im Winter! ;-)

[rtrbt]

Deaktiviere mal testweise die MQTT-Kommunikation. Mir ist im Log gerade aufgefallen, dass diese Meldungen

MQTT: Ignoring message with payload length 2526 for topic warp/SzQ/charge_tracker/last_charges. Maximum length allowed is 2048.

auch ~alle 45 Sekunden erscheinen und zwar genau zwischen dem Ab- und Anschalten. Das ist an sich schon komisch, weil charge_tracker/last_charges ein State ist, was heißt, dass last_charges von außen sowieso nicht geschrieben werden darf. Die Längenprüfung ist davor, deshalb sehen wir das jetzt im Log, anstatt dass die Nachricht einfach ignoriert wird.

Etwas zusammengekürzt:

2023-06-13 13:29:56,780  Charger state changed from 3 to 0
2023-06-13 13:29:57,167  MQTT: Ignoring message[...]
2023-06-13 13:29:58,914  Charger state changed from 0 to 2
2023-06-13 13:30:44,023  Charger state changed from 3 to 0
2023-06-13 13:30:44,751  MQTT: Ignoring message[...]
2023-06-13 13:30:46,169  Charger state changed from 0 to 2
2023-06-13 13:31:31,306  Charger state changed from 3 to 0
2023-06-13 13:31:32,449  MQTT: Ignoring message[...]
2023-06-13 13:31:33,495  Charger state changed from 0 to 2

Kann es sein, dass openHAB regelmäßig (oder z.B. bei Reconnect?) alle MQTT-Topics schreibt, die es findet? Ich weiß das ioBroker das Problem hat, siehe z.B. hier:

Das hat im Extremfall dazu geführt, dass ioBroker die Wallbox andauernd neugestartet hat, weil es andauernd auf die /reboot-API geschrieben hat :D

[gustavpaula]

Am 14.6.2023 um 08:57 schrieb rtrbt:

Deaktiviere mal testweise die MQTT-Kommunikation. Mir ist im Log gerade aufgefallen, dass diese Meldungen

 Das ist an sich schon komisch, weil charge_tracker/last_charges ein State ist, was heißt, dass last_charges von außen sowieso nicht geschrieben werden darf.

Kann es sein, dass openHAB regelmäßig (oder z.B. bei Reconnect?) alle MQTT-Topics schreibt, die es findet?

Ok, beim nächsten Laden deaktiviere ich die MQTT-Kommunikation und versuche, sonst alles gleich zu lassen.

Wieso OpenHAB regelmäßig eine Nachricht schickt, die aber für euch zu groß ist und was das für Konsequenzen hat (und wer nun das "Problem" hat: die WB oder OpenHAB) ist mir nicht klar. D.h. OpenHAB versucht, last_charges zu schreiben? Oder vllt. ist das auch EVCC?

Jetzt mach ich erst mal Laden ohne MQTT Komm und dann sehen wir weiter, ob ich da bei OpenHAB nachfragen muss.

[rtrbt]

On 6/14/2023 at 2:31 PM, gustavpaula said:

Wieso OpenHAB regelmäßig eine Nachricht schickt, die aber für euch zu groß ist und was das für Konsequenzen hat (und wer nun das "Problem" hat: die WB oder OpenHAB) ist mir nicht klar. D.h. OpenHAB versucht, last_charges zu schreiben? Oder vllt. ist das auch EVCC?

Das Problem ist nicht die zu große Nachricht, die wird sowieso ignoriert, eben weil sie a) zu groß ist und b) auf ein Topic geht, dass nicht geschrieben werden darf.

Ich vermute aber, dass openHAB mehr bzw. alle Topics der Wallbox beschreibt, unter anderem auch evse/stop_charging und evse/start_charging o.Ä.

EVCC ist das vermutlich nicht.

[gustavpaula]

So, hier das neue Ladeprotokoll.

MQTT disabled, man. Start der Ladung im Web-IF mit 7A, nach Ende des Ladevorgangs durch den e-up wieder 45 Sek. Ladezyklen.

Als ich den Ladestrom manuell auf 16A gestellt habe, haben die Zyklen aufgehört. Als ich den Ladestrom auf 6 A runtergestellt habe, sind keine neuen Zyklen entstanden. Ich hab die Details mal oben in das Log reingeschrieben.

Jetzt bin ich aber wirklich gespannt!

Gruß,

GP

evse-debug-log-warp-SzQ-2023-06-17T11-42-11-617.txt

bearbeitet June 17, 2023 at 10:11 von gustavpaula

[gustavpaula]

Heute morgen habe ich zufällig entdeckt, dass das Umschalten auf 16A Ladestrom zwar die 45 Sek. Ladezyklen gestoppt hat, da ich aber danach wieder auf 6 A zurück geschaltet habe, sind die 45 Sek. Ladezyklen heute nach kurz vor 1 Uhr wieder losgegangen.

Siehe angehängtes PDF Charge Log. Interessanterweise lädt der e-up auch nachts zweimal nach, aber nur mit ca. 800W.

Falls es was hilft, habe ich auch noch ein Debug Log erzeugt direkt nach dem Charge Log.

Jetzt hab ich noch eine Frage: Wäre es nicht sinnvoll, dass das Laden auf Stop geht, wenn das Auto mal sagt "ich bin voll!" und dann manuell wieder gestartet werden muss?

charge-log-warp-SzQ-2023-06-18T09-25-03-018.pdf evse-debug-log-warp-SzQ-2023-06-18T09-40-36-884.txt

[rtrbt]

On 6/18/2023 at 9:54 AM, gustavpaula said:

Jetzt hab ich noch eine Frage: Wäre es nicht sinnvoll, dass das Laden auf Stop geht, wenn das Auto mal sagt "ich bin voll!" und dann manuell wieder gestartet werden muss?

Schonmal unabhängig vom Rest: Nein, das würde dazu führen, dass wenn sich ein Auto leer steht, nicht nachgeladen wird. Außerdem gibt es Autos (die Teslas z.B. wenn ich mich richtig erinnere), die im Winter ihre Heizung aus Wallbox-Strom betreiben können.

Wir hatten dieses Verhalten mit dem Lastmanagement mal ausversehen implementiert und dann aber geändert. Siehe hier:

 

[rtrbt]

Im Anhang eine Testfirmware. Damit sollte das Problem weiterhin auftreten, aber im debug-log sind noch ein paar Informationen mehr. Reproduziere das Problem mit der Firmware bitte nochmal.

warp2_firmware_2_1_2_649060b0_d5c477b78835162__merged.bin

[gustavpaula]

Super! Mach ich. Natürlich muss ich jetzt noch schaffen, das Problem zu reproduzieren.

wie ist das mit dem debug-log, wird die Info jetzt eigentlich dauernd geschrieben und nur dann in eine Datei lesbar abgelegt? Also sind da dann auch Daten vor dem Start des debug-logs enthalten? Ist mir noch nicht ganz klar, wie das geht.

Ist halt wichtig, wie schnell ich nach Ende des Ladevorgangs das Debug Log starten muss.

[rtrbt]

Die Daten die wir brauchen werden erst gesammelt, wenn du auf Start klickst. Also musst du den Moment abpassen, wenn das Schütz klackert. Das ist im Moment leider noch relativ primitiv gebaut, langfristig wird das besser: https://github.com/Tinkerforge/esp32-firmware/issues/171

[gustavpaula]

Ich kann kein Update mit der FW machen. Die scheint für WARP2 zu sein, ich habe aber eine WARP1.

[rtrbt]

Oh sorry. Hier eine WARP1-Firmware.

warp_firmware_2_1_2_649147fc_d5c477b78835162__merged.bin

[gustavpaula]

Danke, hab das Update ausgeführt. Mal sehen, ob ich nachher aufladen kann.

Was mir jetzt noch gerade auffällt:

In der Vergangenheit hat meine WB beim Eigenverbrauch ständig zwischen 1W und 3W hin und her gewechselt. Ich dachte immer, das hat was mit  WLAN zu tun.

Nun habe ich seit dem letzten Ladevorgang mit "Manuelle Ladefreigabe = Aktiv" konstant nur noch 1W Eigenverbrauch der WB.

GIbt's dafür eine Erklärung?

(Gerade nochmal auf "Manuelle Ladefreigabe = Inaktiv" gewechselt: Jawoll, auch mit der neuen Debug-FW Wechsel zwischen 1W und 3 W.)

 

[gustavpaula]

So, hier nun 2 debug logs:

1. Beginnend mit 90% auf 100% aufladen, mit "Manuelle Ladefreigabe = Inaktiv", sämtliche externen IF abgeschaltet, Ladevorgang per "Manuelle Freigabe = Start" gestartet. Angefangen mit 6A, dann man. erhöht, damit ich nicht solange warten muss. War leider dann früher fertig mit Laden und ich hab es nicht gleich gesehen. Runtergeschaltet auf 6A, nochmal gestartet _> 45 Sek. Ladezyklen generiert.

2. "Manuelle Ladefreigabe = Aktiv" gesetzt, Log gestartet, man. Freigabe, Ladung startet mit 28W, dann 12W, 8W, Ladung endet. UNd bleibt auch dort, startet nicht neu.

AUs der Laienperspektive sieht es so aus, als ob man per Web-IF Einstellungen eine Einstellung setzen kann, wo sich die Wallbox immer wieder selbst die Freigabe gibt. Nach 45 Sek. Sagt der e-up dann "nee, ich brauch keinen Strom mehr" und beendet den Ladevorgang. Aber die Wallbox startet einfach selbstständig wieder einen neuen.

Bin gespannt auf eure Analyse.

P.S.: Kann es sein, dass die WB konstant 1W zieht wenn KEIN Fahrzeug angeschlossen ist, aber dauernd zwischen 1W und 3W wechselt, wenn ein Fahrzeug angeschlossen ist und die WB im Zustand "Warten auf Freigabe" ist? Was braucht da +2W, die WB wartet doch nur auf sich selbst, oder? Oder braucht das IF zum Auto, das dann aktiv ist, die +2W?

Sorry, ich komm halt immer gleich in SW ENtwicklungs- und Testmodus, wo ich immer gerne ich die Spec reinschauen würde, was da eigentlich das Requirement ist. ;-))

evse-debug-log-warp-SzQ-2023-06-20T10-38-51-771.txt evse-debug-log-warp-SzQ-2023-06-20T10-40-49-092.txt

bearbeitet June 20, 2023 at 08:56 von gustavpaula

[MatzeTF]

On 6/20/2023 at 10:55 AM, gustavpaula said:

P.S.: Kann es sein, dass die WB konstant 1W zieht wenn KEIN Fahrzeug angeschlossen ist, aber dauernd zwischen 1W und 3W wechselt, wenn ein Fahrzeug angeschlossen ist und die WB im Zustand "Warten auf Freigabe" ist? Was braucht da +2W, die WB wartet doch nur auf sich selbst, oder? Oder braucht das IF zum Auto, das dann aktiv ist, die +2W?

Schon mal kurz zur Info: Standbyverbrauch der WB und Stromverbrauch vom Schütz liegen im Bereich 1-3 W. Leider ist der Zähler bei so kleinen Verbrauchswerten etwas ungenau und exakt 2 W kann er nicht messen, weswegen die Anzeige zwischen 1 und 3 W wechselt.

[gustavpaula]

Am 20.6.2023 um 11:11 schrieb MatzeTF:

Schon mal kurz zur Info: Standbyverbrauch der WB und Stromverbrauch vom Schütz liegen im Bereich 1-3 W. Leider ist der Zähler bei so kleinen Verbrauchswerten etwas ungenau und exakt 2 W kann er nicht messen, weswegen die Anzeige zwischen 1 und 3 W wechselt.

Ok, versteh ich. Aber ist die Beobachtung richtig, dass ohne angeschlossenes Auto der Stromverbrauch geringer ist (konstant ~1W) im Vergleich zu wenn angeschlossen? Mir kommt's ja nicht auf präzise Werte an, aber es ist halt ein Unterschied im Verhalten feststellbar.

[MatzeTF]

On 6/20/2023 at 11:20 AM, gustavpaula said:

Ok, versteh ich. Aber ist die Beobachtung richtig, dass ohne angeschlossenes Auto der Stromverbrauch geringer ist (konstant ~1W) im Vergleich zu wenn angeschlossen? Mir kommt's ja nicht auf präzise Werte an, aber es ist halt ein Unterschied im Verhalten feststellbar.

Wenn ein Auto angeschlossen ist und Strom anfordert, ist das Schütz angezogen. Ohne Auto entsprechend nicht. Das wird bei dir wahrscheinlich einfach der Stromverbrauch vom Schütz sein. Bei unseren Test-Wallboxen hier ist etwas zusätzliche Hardware eingebaut, sodass der angezeigte Stromverbrauch auch ohne Auto zwischen 1 und 3 W schwankt, obwohl sich der reale Stromverbrauch in dem Zustand nicht ändern sollte.

[gustavpaula]

Gibt schon irgendwelche neuen Erkenntnisse vom Auswerten der debug logs?

Danke!

[rtrbt]

Sorry, das ist bei mir untergegangen. Habe gerade einen Blick reingeworfen, die Implementierung des Energie/Zeitlimits blockiert alle 45 Sekunden für 250ms. Jetzt muss ich nur rausfinden, warum.

[gustavpaula]

Ok, danke für den Status.

[rtrbt]

Okay, ich glaube ich habe jetzt verstanden, was da passiert. Da das kompliziert ist habe ich das ganze mal geplottet (mein Excel-Foo ist nicht gut deshalb einfach drei Graphen untereinander) und annotiert.

Du hast folgende Reihenfolge erzeugt:

• 10 Ampere erlaubt, Auto ist voll (das ist der Anfang des Graphen)
• Strom auf 6 Ampere reduziert. Das beeinflusst bei WARP1 die CP-PE-Widerstandsmessung, was man im 3. Graph sieht (Rote 1)
• Auf Stop geklickt (Blaue 1, Rote 2) -> Wir melden dem Auto über das PWM auf CP, dass kein Strom verfügbar ist -> Das PWM geht auf 100% -> Der Widerstand geht wieder etwas hoch.
• Auf Start geklickt. (Blaue 2) Es scheint so zu sein, dass der VW immer wieder anfängt zu laden, wenn das PWM zwischenzeitlich aus war, selbst wenn er voll ist.
• Das Auto will laden und setzt deshalb den Widerstand runter (Rote 3)
• Wir schalten das Schütz (Blaue 3)
• Nach 45 Sekunden bemerkt der VW, dass er voll ist. (Blaue/Rote 4) Er will deshalb den Widerstand wieder auf die 2,7kOhm setzen, macht das aber in der VW-Weise, die bei WARP1 Sprünge in der Messung erzeugt.
• Der gemessene Widerstand springt auf einen so hohen Wert, dass wir glauben, das Auto ist abgezogen (Blaue 5, Rote 5)
• Jetzt der interessante Teil: Einer der Ladestromslots, nämlich der für das Energie/Zeitlimit wird von 32A auf 0A (also blockieren) gesetzt. Das passiert vermutlich direkt durch den Ladecontroller, weil dieser Ladeslot fälschlicherweise bei dir so markiert ist, dass der Ladecontroller ihn auf 0 A setzen soll, wenn ein Auto abgezogen wird. (Gelbe 1)
• ~ 250ms später setzt der ESP den Slot wieder zurück auf 32 A (Gelbe 2)
• Der gemessene Widerstand hat sich wieder gefangen, wir messen ~2.7kOhm -> Das Auto ist angesteckt aber will nicht laden (Rote 6, Blauer Übergang von 6 zu 7.)
• Den Übergang habe ich nochmal beim nächsten Block orange eingekreist, weil man da gut sieht wie es erst kurz auf 2.7kOhm springt, dann etwas abfällt (weil wir wieder das PWM starten) und dann auf ~800 Ohm fällt (weil das Auto Strom anfordert)
• Jetzt geht es im Endeffekt von vorne los, das Auto "lädt" wieder 45 Sekunden (Blaue 8 bis 9)

Das heißt es kommen folgende Probleme zusammen:

• Der VW schaltet die Widerstände so um, dass wir diesen Peak in der Messung sehen.
• Das Zeit/Energielimit geht davon aus, dass der entsprechende Ladeslot nicht beim Abziehen eines Autos geleert wird, setzt das aber nicht explizit. Aus irgendeinem Grund ist bei dir dieser Slot aber so konfiguriert, dass geleert wird. Hattest du eventuell mal eine andere Beta-Firmware, Test-Firmware oder einen der Forks laufen?
• Durch das Nullen des Ladeslots ist die Zeit, die der VW sehen kann, dass wir keinen Strom zur Verfügung stellen so lang, dass er dann glaubt er müsste wieder anfangen zu laden, wenn Strom verfügbar ist.

Ich baue dir heute Nachmittag noch eine Testfirmware, bei der ich den Bug fixe, dass der Ladeslot zurückgesetzt wird. Im Idealfall reicht das schon, weil dann der VW nach den 45 Sekunden und der Abschaltung nicht wieder anfängt zu laden. Falls das weiterhin passiert, müssen wir (lies @borg ) in der Ladecontroller-Firmware das Timing etwas anpassen um mit dem Peak in der Messung umgehen zu können.

[gustavpaula]

Am 29.6.2023 um 13:07 schrieb rtrbt:

Jetzt der interessante Teil: Einer der Ladestromslots, nämlich der für das Energie/Zeitlimit wird von 32A auf 0A (also blockieren) gesetzt. Das passiert vermutlich direkt durch den Ladecontroller, weil dieser Ladeslot fälschlicherweise bei dir so markiert ist, dass der Ladecontroller ihn auf 0 A setzen soll, wenn ein Auto abgezogen wird. (Gelbe 1)

Wow, was für eine Ausarbeitung. Ich verstehe nicht alles (spezieller Jargon), aber bei der obigen Aussage habe ich den Eindruck, wird's wichtig:

Was genau ein "Ladestromslot" ist, weiß ich nicht. Habe ICH den Ladestromslot so gesetzt? Wer/wie/was hat den Ladeslot fälschlicherweise falsch markiert?

Am 29.6.2023 um 13:07 schrieb rtrbt:

Das Zeit/Energielimit geht davon aus, dass der entsprechende Ladeslot nicht beim Abziehen eines Autos geleert wird, setzt das aber nicht explizit. Aus irgendeinem Grund ist bei dir dieser Slot aber so konfiguriert, dass geleert wird. Hattest du eventuell mal eine andere Beta-Firmware, Test-Firmware oder einen der Forks laufen?

Keine Beta-FW, nur Test-FW für erweiteretes debug log, aber das war die, die du mir neulich erzeugt hast NACHDEM das Problem ja schon seit mind. einem Jahr auftritt.

Ok, wenn die FW da ist probier ich's aus.

[rtrbt]

On 6/29/2023 at 1:44 PM, gustavpaula said:

Was genau ein "Ladestromslot" ist, weiß ich nicht. Habe ICH den Ladestromslot so gesetzt?

Sorry, zwei Wörter für's gleiche. Ein Slot ist eine Ladestromgrenze, so wie du sie im Ladestatus siehst. Den Slot hast nicht du so gesetzt.

On 6/29/2023 at 1:44 PM, gustavpaula said:

Wer/wie/was hat den Ladeslot fälschlicherweise falsch markiert?

Das war die große Frage. Inzwischen habe ich es rausgefunden: Der Slot ist ursprünglich bei WARP1 und WARP2 falsch konfiguriert gewesen. Bei WARP2 haben wir das mit Firmware 2.1.2 schon gefixt gehabt, aber bei WARP1 hatten wir übersehen, dass das selbe Problem existiert.

Ich habe das jetzt für WARP1 auch gefixt, neue Firmware ist im Anhang.

warp_firmware_2_1_2_649d74a0_4e2c6ba61f00eb4__merged.bin

[gustavpaula]

Danke für die neue FW. Hab sie aufgespielt und geladen. Leider unverändert wenn manuelle Ladefreigabeb NICHT aktiviert. IF alle deaktiviert.

Ich hab mal ein Log angehängt, wieder irgendwann nach Ladeende, aber mit den 45 Sek. Ladezyklen.

 

Danke!

evse-debug-log-warp-SzQ-2023-07-01T10-43-15-276.txt

[rtrbt]

Hm, das hatte ich befürchtet. Im Anhang die Variante, bei der wir den Widerstandspeak beim Übergang von "Auto will Strom" nach "Auto will keinen Strom" ignorieren.

Da ich optimistisch bin, dass das jetzt funktioniert, habe ich dir die Firmware in zwei Varianten angehangen: Teste erstmal mit der warp_firmware_2_1_2... Das ist wie gehabt eine WARP1 2.1.2-Firmware mit den Bugfixes zusätzlich drin. Falls das funktioniert, kannst du dann auf die warp_firmware_2_1_3... wechseln. Dann hast du die ganzen Neuerungen aus 2.1.3 und die Bugfixes oben drauf. Sonst müsstest du auf der 2.1.2+ bleiben, bis wir irgendwann 2.1.4 veröffentlichen.

warp_firmware_2_1_2_64a2be5b_57432b34a765d3f__merged.bin warp_firmware_2_1_3_64a2bae8_49abde32bf9c00e_merged.bin