e-up - Laden wechselt ständig zwischen ladebereit und lädt

[rtrbt]

Sorry für die späte Antwort, musste erst das Firmware-Release fertig bekommen.

On 1/22/2024 at 9:08 PM, eweri said:

macOS 13.6.3 (22G436) mit Safari Version 17.2.1 (18617.1.17.11.12, 18617) (keine aktiven Erweiterungen oder sonstige Manipulationen)

Ziemlich genau die Version habe ich auch getestet und hier funktionierts. Wir haben aber von einem anderen Kunden ähnliche Probleme gemeldet bekommen mit anderen Browsern und Betriebssystemen. Da muss irgendetwas auf Wallboxseite kaputt sein.

 

Kurz zur Erklärung, was überhaupt bei dem Ping-Pong passiert: Die Wallbox misst einen Widerstand (CP/PE), der vom Auto angelegt wird. Wenn kein Auto angeschlossen ist, ist das "unendlich", wenn ein Auto angeschlossen ist, aber (noch) keinen Strom anfordert sinds 2700 Ω, wenn das Auto Strom anfordert 880 Ω. Details hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

Aufgrund dessen, wie die Signalisierung funktioniert, wird der Widerstand immer nur in einem kurzen Zeitfenster gemessen, die Länge davon hängt vom erlaubten Ladestrom ab. Bei 6 A ist die Messung deshalb maximal schlecht: Vor der Kalibrierung hat deine Box immer irgendwas zwischen 1700 und 1800 Ω gemessen, da liegt aber genau die Grenze für die Wallbox. Insgesamt sah das dann so aus:

(Rot mit rechter Achse der Widerstand, Blau mit linker Achse der Ladezustand. 1 ist "Auto will keinen Strom, Schütz nicht geschaltet", 2 ist "Auto will Strom, Schütz geschaltet")

Die Kalibrierung, die wir dir gegeben haben schiebt deshalb den gemessenen Wert etwas nach Unten, er landet dann bei ~ 1300 Ω

On 1/22/2024 at 9:24 PM, eweri said:

Hier die Ergebnisse vom Hyundai vorher und nach der Installation der Kalibrierungsdatei

Das sieht soweit gut aus. Du hast da aber auch 16 A freigegeben, teste sicherheitshalber bei Gelegenheit nochmal mit 6 A.

On 1/22/2024 at 9:53 PM, eweri said:

So ich also noch einmal nach draußen in die feuchte Kälte:

Kabel vom e-up getrennt, wieder ins Haus, Protokoll starten, wieder zum e-up Lade-Timer abgeschaltet, Kabel gesteckt, NFC-Dongle drangehalten, es klackt sofort in der WARP und im e-up, und es klackt sofort wieder. Es lädt nicht. Irgend wie alles komisch ich halte noch einmal den Dongle an die WARP, es klackt wieder, diesmal lädt der e-up mit 2,7kW was ca. 5,6A entspricht. Eigentlich sollte der e-up aber mit 5A laden (nachträgliche Korrektur: 10A sind wohl richtiger, siehe Beitrag unten).

Wenn man sich im Energieverbrauch vom Volkszähler das ansieht, dann war der erste Klack wirklich nur mit 2,3kW und der zweite Klack hat dann erst 2,7kW gemacht. 

Ist jetzt evcc das Problem? Ich steige nicht so ganz mehr durch.

Ich glaube, da hattest du einfach Pech mit dem NFC-Tag: Im Debug-Report sehe ich, dass genau als das Auto anfangen wollte zu laden, die Nutzerfreigabe blockiert hat:

Der Ladevorgang lief kurz, dann hast du vermutlich das Tag nochmal drangehalten, das stoppte den Ladevorgang und später hast du wieder freigegeben und es wurde weitergeladen. Während des ganzen Ladevorgangs hat EVCC auf 6 A limitiert. Das ist das Minimum, was die Wallbox dem Auto kommunizieren kann. D.h. wenn du im Auto 5 A einstellst, muss die Wallbox trotzdem 6 A erlauben und das Auto zieht dann halt weniger.

On 1/22/2024 at 10:12 PM, eweri said:

Wenn die 60% erreicht sind, wechselt die Lade-Steuerung wieder auf die Zeitsteuerung und die sagt "5A, 80% SoC und bitte um 6:50 Uhr fertig". Am Tage habe ich "32A, 80% SoC und bitte um 17 Uhr fertig" das in Verbindung mit evcc "Min+PV" sollte mir am Tag das Laden mit PV-Überschuss ermöglichen. 

Mache ich einen Denkfehler?

Nein, das sollte soweit funktionieren. EVCC gibt dir bei Min+PV ja mindestens 6 A + was an Überschuss da ist und das Auto sollte dann alles verwenden, wenn du es auf 32 A gestellt hast.

On 1/24/2024 at 10:36 PM, eweri said:

Heute Abend habe ich den e-up angesteckt und jetzt lädt er mit 5A komplett ohne Ping-Pong.

D.h. jetzt ist alles gut? :D

[eweri]

Am 25.1.2024 um 14:53 schrieb rtrbt:

Sorry für die späte Antwort, musste erst das Firmware-Release fertig bekommen.

Hallo rtrbt!

Alles gut - Firmware für alle geht vor 😉

Zitat

D.h. jetzt ist alles gut? :D

Sieht im Moment so aus. Ich danke dir!

Die Probleme die ich jetzt habe liegen vermutlich an evcc - in der 0.123.* haben die so viel geändert und ich habe den Eindruck, das war nicht unbedingt zum Guten. Es wurde z.B. das Flag "resetonDisconnect" entfernt. Wenn man das Auto trennt, setzt das die WARP nicht zurück. Ich habe letzte Nacht den Hyundai geladen, da war schon wieder etwas komisch, musste evcc neustarten (und sicherheitshalber auch die WARP) damit ließ sich der Hyundai wieder normal laden (Stecker rein, Dongle an die WARP halten, nach einigen Sekunden kommt das Klack und der Ladevorgang beginnt). Fehlermeldung in evcc "Charger out of sync: expected disabled, got enabled" - laut evcc soll man das Intervall erhöhen, das habe ich jetzt auf 40 Sekunden gestellt.

 

Dann heute morgen den Stecker rausgezogen. Ich komme wieder nach Hause, stecke den Stecker rein und es macht sofort Klack in der WARP und am Hyundai blinkt die Ladeleuchte neben der Ladebuchse rot. Ich habe dann völlig verwirrt den Dongle daran gehalten, dann machte es wieder Klack, am Hyundai leuchtete nichts mehr und dann habe ich mit irgend einem Spiel aus Dongle dranhalten und Stecker rein/raus/rein, begleitet von diversen Klacks den Hyundai zum Laden gebracht. 

Dann schaue ich auf evcc und sehe, dass laut evcc kein neuer Ladevorgang gestartet ist, sondern evcc zählt jetzt einfach weiter. Jetzt um 18:15 Uhr sagt evcc ich hätte in 19:02 Stunden 18,2kWh geladen - in einen Akku der nur 13,8kWh fasst. Angeschlossen habe ich den Wagen aber vermutlich gegen 14 Uhr. 

Ich finde dieses Verhalten von evcc nicht gut. Warum läßt man die Funktion "resetonDisconnect" einfach weg? Ich konnte noch keine Lösung finden. Im log von evcc konnte ich auch nichts finden. 

Aber wie gesagt das ist ein evcc-Problem - wenn ich meine SMA-Wechselrichter direkt an die WARP anbinden könnte, dann könnte ich auf evcc verzichten😉

Schönen Wochenanfang wünsche ich.

eweri

 

bearbeitet January 28, 2024 at 17:31 von eweri

[eweri]

... oder kann es sein, dass die WARP per MQTT evcc nicht mitteilt, das ein Fahrzeug getrennt wurde?

[poohnet]

On 1/28/2024 at 6:26 PM, eweri said:

wenn ich meine SMA-Wechselrichter direkt an die WARP anbinden könnte, dann könnte ich auf evcc verzichten😉

Hast du zufällig auch den SMA Home Manager 2.0 (bzw. das Energy Meter) im Einsatz? Falls ja, so könnte das in den nächsten Monaten tatsächlich funktionieren. Mit der WARP 3 wird Überschussladen ja ein zentraler Bestandteil der Wallbox, d. h. es wird kein WEM mehr benötigt - und da die Software ja in weiten Teilen auch auf WARP 1&2 laufen wird, könnte mein Zählermodul für SMA evtl. weiterhelfen. Im Moment nutze ich das zwar nur auf dem WEM, es funktioniert aber auch auf der WARP.

Gruß Thomas

bearbeitet January 28, 2024 at 18:58 von poohnet

[poohnet]

On 1/28/2024 at 7:50 PM, eweri said:

... oder kann es sein, dass die WARP per MQTT evcc nicht mitteilt, das ein Fahrzeug getrennt wurde?

Wenn du das Regelintervall von EVCC auf 40 Sekunden erhöht hast, dann musst du im schlimmsten Fall genau diese 40 Sekunden warten, bevor du das Auto wieder ansteckst. Einfach ab- und wieder anstecken kann tatsächlich dazu führen, dass EVCC das nicht mitbekommt.

[eweri]

Am 28.1.2024 um 19:52 schrieb poohnet:

Hast du zufällig auch den SMA Home Manager 2.0 (bzw. das Energy Meter) im Einsatz? Falls ja, so könnte das in den nächsten Monaten tatsächlich funktionieren. Mit der WARP 3 wird Überschussladen ja ein zentraler Bestandteil der Wallbox, d. h. es wird kein WEM mehr benötigt - und da die Software ja in weiten Teilen auch auf WARP 1&2 laufen wird, könnte mein Zählermodul für SMA evtl. weiterhelfen. Im Moment nutze ich das zwar nur auf dem WEM, es funktioniert aber auch auf der WARP.

Gruß Thomas

Hallo Thomas!

Genau für das Überschussladen benutze ich evcc. Ich habe als Smart-Meter einen elgris (unter anderem SMA-kompatibel, kostet aber nur die Hälfte) und einen Sonny Boy 3.6. evcc spricht also mit dem Smart-Meter, dem Wechselrichter und der WARP - hat bis 0.122 eigentlich völlig problemlos funktioniert. Da hatten wir aber auch nur ein Auto das geladen werden musste. Seit Dezember haben wir ein e-up dazu bekommen und ungefähr um die Zeit kam auch evcc Version 0.123.* und seit dem verhält sich das ganze irgend wie unvorhersehbar.

Wenn ich das also direkt in der WARP regeln könnte wäre das spitze. 

Gruß, eweri

 

bearbeitet January 28, 2024 at 21:32 von eweri

[eweri]

Am 28.1.2024 um 19:57 schrieb poohnet:

Wenn du das Regelintervall von EVCC auf 40 Sekunden erhöht hast, dann musst du im schlimmsten Fall genau diese 40 Sekunden warten, bevor du das Auto wieder ansteckst. Einfach ab- und wieder anstecken kann tatsächlich dazu führen, dass EVCC das nicht mitbekommt.

Hallo Thomas!

Ich hatte gerade den Wagen abgeklemmt war ca. 40-50 Minuten unterwegs, kam wieder nach Hause und schließe den Wagen an - Klack - die Kiste fängt sofort an zu laden, ohne Dongle oder sonstiges. 

Vorher hatte ich auf evcc und die WARP geschaut - beide standen nach meiner Rückkehr auf Ladebereit. evcc schließt den Ladevorgang einfach nicht ab, wenn man das Kabel abzieht. Das ist irgend wie nicht schön. Da ich nicht genau weiß, wie evcc eigentlich mitbekommt, dass das Auto nicht mehr angeschlossen ist, ist meine Fehlersuche etwas eingeschränkt. Da die WARP irgend wie über MQTT mit evcc kommuniziert, gehe ich davon aus, das beim Trennen der Ladeverbindung keine MQTT-Nachricht erzeugt wird oder evcc diese Nachricht nicht erreicht. Da die WARP Firmware bis vorgestern nicht verändert war, tippe ich auf einen Fehler in evcc 0.123.*. Eine Fehlkonfiguration will ich auch nicht ausschließen. 

Danke!

 

[eweri]

Habe gerade mal in meiner evcc.yaml die Log-Level etwas ausführlicher gemacht, stehen jetzt alle auf info und ich habe in der Doku auch gefunden, das man mqtt auch loggen kann. Mal sehen was ich finde.

[eweri]

habe gerade auch festgestellt, dass mein Smart Meter von elgris von der WARP gefunden wird - das Ding kann wohl auch Sunspec und nicht nur Speedwire

[MatzeTF]

On 1/28/2024 at 11:07 PM, eweri said:

habe gerade auch festgestellt, dass mein Smart Meter von elgris von der WARP gefunden wird - das Ding kann wohl auch Sunspec […]

Bekommst du da mit der WARP sinnvolle Werte raus? Viele Hersteller haben eine sehr eigene Interpretation von Sunspec und wir hatten noch kein elgris-Gerät zum Testen.

Falls zumindest der Leistungswert für den Netzbezug richtig ausgelesen wird, kannst du damit voraussichtlich ohne evcc direkt PV-Überschussladen nutzen, wenn wir die Integration für WARP 1, 2 und 3 fertig haben.

[eweri]

Leider scheint sich die Gerätesuche an einem bestimmten Punkt (3%) aufzuhängen, aber der Typ und wird scheinbar richtig erkannt. Aber auch nach 6 Stunden scannen kam nichts mehr dazu (siehe unten) Wenn ich dann das Smart-Meter hinzufüge, steht es in der Liste, aber mit dem Kommentar "Noch wurden keine Werte gesendet" (oder so ähnlich).

Sollen wir dafür einen eigenen Thread aufmachen? Das hat jetzt nichts mehr mit einem e-up zu tun. 

Der Hersteller macht auf seinen Seiten groß Werbung mit  wie vielen Wechselrichtern das Smart Meter kompatible ist. https://www.elgris.de/produkt/smart-meter-produkte/

Es kann aber sein, dass ich nicht die neuste Software des Herstellers auf meinem Smart Meter habe.

Ich kann das Scan-Fenster zwar schließen, wenn ich aber versuche einen weiteren Zähler hinzuzufügen, bekomme ich die Meldung das ein Scan bereits läuft. Nur durch einen Neustart bekomme ich diese Meldung weg. 

Starting scan
Resolving elgris.fritz.box
Connecting to elgris.fritz.box:502
Using device address 1
Using base address 40000
Reading SunSpec ID
SunSpec ID found
Reading Common Model
Common Model found (block-length: 65)
Manufacturer Name: elgris
Model Name: SMART METER
Options: 
Version: 1.15.16
Serial Number: 1900005339
Device Address: 240
Reading Standard Model
Found Meter Wye Three Phase Integer Model (model-id: 203, block-length: 105)
Reading Standard Model
End Model found
Using device address 2
Using base address 40000
Reading SunSpec ID
Reading timed out, retrying
Reading timed out, retrying
Reading timed out, retrying
Reading timed out, retrying
Reading timed out, retrying
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 3
Using base address 40000
Reading SunSpec ID
Reading timed out, retrying
Reading timed out, retrying
Reading timed out, retrying
Reading timed out, retrying
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 4
Using base address 40000
Reading SunSpec ID
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 5
Using base address 40000
Reading SunSpec ID
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 6
Using base address 40000
Reading SunSpec ID
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 7
Using base address 40000
Reading SunSpec ID
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 8
Using base address 40000
Reading SunSpec ID
Could not read SunSpec ID (error: TIMEOUT [228])
Using device address 9
Using base address 40000
Reading SunSpec ID

 

[MatzeTF]

Ja, mach mal bitte einen neuen Thread auf. Poste da dann nicht nur das Log vom Scan, sondern auch ein Debug-Log, das du am besten direkt nach dem Schließen den Scan-Fensters runterlädst.

Es würde uns auch sehr helfen, wenn du uns eine Portweiterleitung auf dein Smart Meter einrichtest und wir damit testen können. Falls das okay für dich ist, nimm einfach irgeindenen TCP Port über 10000 und leite ihn auf Port 502 deines Smart Meter weiter. Wenn du DynDNS hast, wäre das super, ansonsten kannst du deine IP des Tages per PM an mich schicken oder ich schaue nach, von welcher IP dein letzter Post gesendet wurde. 😉

[poohnet]

On 1/28/2024 at 10:40 PM, eweri said:

Vorher hatte ich auf evcc und die WARP geschaut - beide standen nach meiner Rückkehr auf Ladebereit. evcc schließt den Ladevorgang einfach nicht ab, wenn man das Kabel abzieht. Das ist irgend wie nicht schön. Da ich nicht genau weiß, wie evcc eigentlich mitbekommt, dass das Auto nicht mehr angeschlossen ist, ist meine Fehlersuche etwas eingeschränkt. Da die WARP irgend wie über MQTT mit evcc kommuniziert, gehe ich davon aus, das beim Trennen der Ladeverbindung keine MQTT-Nachricht erzeugt wird oder evcc diese Nachricht nicht erreicht.

Das ist in der Tat merkwürdig. Wir haben mittlerweile auch zwei E-Autos, die wechselweise an meiner WARP1 (on Steroids) geladen werden - inkl. WARP Energy Manager und externer Steuerung über EVCC. Solche Probleme habe ich bislang noch nicht gesehen.

Wenn ich das richtig im Kopf habe (kenne den Code von EVCC noch nicht sooo gut), dann aboniert EVCC einfach nur diverse MQTT-Topics, die von WARP gesendet werden. Vielleicht ist das ja auch ein Problem des Brokers? Hast du den mal neugestartet?

[eweri]

Am 29.1.2024 um 10:48 schrieb poohnet:

Wenn ich das richtig im Kopf habe (kenne den Code von EVCC noch nicht sooo gut), dann aboniert EVCC einfach nur diverse MQTT-Topics, die von WARP gesendet werden. Vielleicht ist das ja auch ein Problem des Brokers? Hast du den mal neugestartet?

Nein, das habe ich noch nicht gemacht, aber heute hat sich das Problem nicht wieder holt. Heute hat es sich normal verhalten.

[eweri]

Hallo rtrbt, hallo MatzeTF!

HILFE!! Das Ping-Pong ist wieder da, aber jetzt ist es da wenn der Hyundai voll geladen ist. Die WARP wechselt jetzt im 3-5 Sekundentakt zwischen Verbunden, Ladebereit und Lädt. Und so hört man auch aus Klack vom Schütz in der WARP.

Angefügt habe ich die zwei Debug-Protokolle

 

evse-debug-protocol-warp-W2y-2024-01-30T09-28-01-720.txt evse-debug-protocol-warp-W2y-2024-01-30T07-51-38-453.txt

[rtrbt]

Dann war die Kalibrierung für den e-up vermutlich zu stark. Damit wir dir eine bessere Kalibrierung erstellen können, müsstest du einmal alle relevanten Fälle wie folgt protokollieren:

• 16 A Ladestrom einstellen
• Ladeprotokoll starten
• Auto anschließen
• Warten bis es lädt
• in 1-Ampere-Schritten bis auf 6 A runtergehen, dazwischen immer ~ 20 bis 30 Sekunden warten. Wenn du dich den 6 A näherst, kann es sein, dass du dann das Schütz-Ping-Pong triffst.

Das ganze machst du mit dem e-up wenn er laden möchte, dann nochmal mit dem e-up wenn er voll ist und beides auch mit dem Hyundai. Das sollten also vier Protokolle werden, mit denen wir dir dann (hoffentlich! hat aber bisher immer geklappt) eine Kalibrierung erstellen können, bei der alles funktioniert.

[eweri]

🤢 wann ist die WARP3 verfügbar?

 

... fällt mir gerade noch ein - das Ping-Pong trat auf, nach dem der Hyundai geladen war - am Auto passierte gar nichts mehr, der Wagen hatte schon abgeschaltet. Nur die WARP war fröhlich am Klacken.

bearbeitet January 30, 2024 at 14:00 von eweri

[eweri]

So ich habe jetzt das erste Protokoll:

e-up von 16A runter, aber der e-up hat nur mit maximal 10A geladen (dafür müsste ich dann noch im Auto was änder)

der hat runter bis 6A problemlos geladen und auch heute als der Wagen angeschlossen wurde hat der sofort geladen. 

evse-debug-protocol-warp-W2y-2024-01-30T20-32-24-332.txt

[rtrbt]

On 1/30/2024 at 2:56 PM, eweri said:

🤢 wann ist die WARP3 verfügbar?

Wir arbeiten dran :D

On 1/30/2024 at 8:47 PM, eweri said:

e-up von 16A runter, aber der e-up hat nur mit maximal 10A geladen (dafür müsste ich dann noch im Auto was änder)

Das ist okay. Wie viel das Auto tatsächlich zieht, beeinflusst die Messung nicht. Relevant ist nur, dass das Auto prinzipiell lädt bzw. für die anderen beiden Debug-Protokolle, dass es voll ist und nicht laden möchte.

[eweri]

So hier jetzt ein Protokoll vom Hyundai von 16A runter auf 6A aber noch nicht voll.

evse-debug-protocol-warp-W2y-2024-01-31T16-36-50-812.txt

[eweri]

Heute morgen habe ich den Hyundai bei 99% voll erwischt, bei 11A ladend, dann habe ich auf 16A gestellt und etwas gewartet, ich weiß jetzt nicht mehr ob er mit Laden fertig war, als ich das Protokoll gestartet hatte, aber als ich den Ladestrom runter gestellt habe war der Wagen fertig mit laden. 

Bei 7A fing dann plötzlich das Ping-Pong an, das die WARP die Zustände wechselt, bei 6A schein es wieder aufzuhören. Ich bin dann wieder auf 7A hoch, habe einige Ping-Pongs abgewartet, bin dann wieder auf 6A runter und habe das dann länger stehen lassen. 

Brauchst Du jetzt noch das gleiche vom e-up?

evse-debug-protocol-warp-W2y-2024-02-01T06-39-45-550.txt

[eweri]

Aus Neugierde habe ich nach dem ich das Laden gestoppt hatte, ohne den Stecker zu ziehen, wieder auf Start geklickt (bei 6A) und sofort fing die WARP das Spielchen wieder an. Ich konnte allerdings nicht sehen, ob sich das Spiel mehrmals wiederholt hat. Hilft das?

evse-debug-protocol-warp-W2y-2024-02-01T06-49-57-515.txt

[eweri]

So und hier kommt das letze Protokoll wenn der e-up voll lädt. Ich wollte am Ende schön runter fahren, aber plötzlich war er dann doch voll. Der e-up zeigt nicht dieses Ping-Pon Problem.

evse-debug-protocol-warp-W2y-2024-02-01T22-48-03-570.txt

[eweri]

Jetzt habe ich die ganzen Protokolle gemacht und jetzt hat der Hyundai das letzte mal anscheinend ohne Ping-Pong seine Ladung beendet 

[eweri]

Schade .... komme ich heute nach Hause, über nacht hat der e-up geladen. Ich stecke den Stecker rein, es macht in der WARP1 sofort klack - dann blinkt die LED am Wagen rot - in der WARP1 wieder ein klack - die LED am Wagen geht aus - nach einiger Zeit macht es wieder klack - am Wagen passiert nichts mehr .....

Ich habe das Spiel dann mehrfach wiederholt, dann die WARP1 neugestartet und evcc und das Spiel blieb, nach zwei - drei mal erneut Stecker rein-raus und plötzlich fing der Wagen an zu laden.

Ich habe keine Ahnung was passiert ist, aber seit dem evcc die Option "resetOnDisconnet" entfernt hat und die irgend wie das angeschlossene Auto "raten" habe ich dieses Problem. Ich habe die Vermutung in evcc 0.123 bis 0.124 ist irgend ein logischer Fehler drin. Bis zur Version 0.123 hatte ich keinerlei Probleme mit dieser Kombination.

Seit dem die Fehler begannen, haben wir zwei BEV, die Firmware der WARP aktualisiert und 4-5 evcc Updates eingespielt. 

evse-debug-protocol-warp-W2y-2024-02-05T15-25-45-224.txt evse-debug-protocol-warp-W2y-2024-02-05T15-28-48-752.txt