borg

Das Modem fehlt nicht, allerdings benötigen wir den Zähler um z.B. den State of Charge nutzen zu können. Des weiteren gehen wir davon aus dass wir aus regulatorischen Gründen den Zähler benötigen wenn es irgendwann bidirektionales Laden gibt. An der Stelle einmal der Hinweis dass bei WARP4 das Gehäuse zwischen Smart und Pro anders ist und der ein Nachrüsten des Zählers ein bisschen mehr Aufwand ist als bei WARP3.

Mh, komisch. Ich war davon ausgegangen dass der Tesla auf jeden Fall wieder anfängt zu laden wenn die DC-Ladung ohne Fehler beendet wird. Wird denn sonst irgendeine Statusinformation im Tesla oder in der App angezeigt?

Zeigt er mit der neuen Firmware immernoch ein Fehler an in der Tesla-App? Falls ja ist es der gleiche Fehler wie vorher? Was für ein Modell und Baujahr hat der Tesla?

@schonOK: Wenn möglich bitte die Firmware im Anhang auch noch testen (1x laden auf Schnell mit ISO 15118 reicht) und dann den Debug-Report anhängen. Danke! warp4_firmware_2_12_2_6a4ffb0f_ffc4c919d0101d9_ota.bin

@schonOK: Das hin und her von „Ladebereit“ zu „Warte auf Freigabe“ ist der Versuch vom WARP4 Charger den Tesla aufzuwecken. Meine Vermutung wäre dass der Tesla unzufrieden ist weil aus seiner Sicht die DC-Ladung nicht funktioniert hat und sich deswegen weigert per AC zu laden. Kannst du einmal schauen ob es funktioniert wenn du nur Autocharge aktivierst? Du musst da auch das Fahrzeug keinem Nutzer zuweisen o.ä. Der WARP4 führt dann den Kommunikationsaufbau am Anfang einmal aus, aber startet keine ISO 15118 Kommunikation (bzw DIN SPEC 70121 tatsächlich, dein Tesla unterstützt die ISO 15118-2 gar nicht).

Der Standard schreibt drei Versuche mit je 50s Timeout vor. Für deinen Fall (ein Auto mit CSS und ein Auto ohne CSS) würde vermutlich 1x 10s oder so mehr Sinn machen. Aber da sowohl die Versuche als auch den Timeout konfigurierbar zu machen ist mir ein bisschen zu low level / Erklärungsbedürftig für jemanden der nicht so tief in der Materie ist. Wie wäre es mit einer "Fast ISO 15118 Timeout" Checkbox die einen vernünftigen (aber nicht standardkonformen) Timeout mit einem Versuch setzt? Ich muss mal in den Logs schauen wie lange unsere Autos so im Schnitt brauchen um zu antworten.

Die Änderungen haben es noch in die 2.12.2 geschafft.

Hinweis: Ich hab in meinen Tests tatsächlich ein Unterschied beim Timing beim Wakeup zwischen WARP1/2/3 und WARP4 (wenn ISO 15118 aktiviert ist) gefunden. Das hier ist aktuell die Wakeup-Sequenz auf CP nachdem ein Auto >1h nicht geladen werden sollte: Ihr seht da 2x CP-Trennung mit unterschiedlicher Länge und 2x State F mit unterschiedlicher Länge. Die Zeit zwischen PWM-Beginn und erster CP-Trennung sollte eigentlich 90s betragen, ist hier aber 10s. Das kommt zu Stande weil wir nach dem Bestimmen des SoC eine Wakeup bereits nach 10s machen, dieses Timing hat sich jetzt auch bei beim PV-Überschussladen eingeschlichen. Das ist bei uns vor Ort bei den Tests nie aufgefallen. Dafür dass eine Wallbox ja eigentlich nur eine Steckdose mit Schütz ist, ist der Kram ganz schön kompliziert.... Ich baue euch morgen eine Testfirmware in der das gefixt ist.

Ah sorry, das meinte ich nicht. Die Frage ist ob der Tesla generell Probleme hat eine Ladung zu starten, oder ob wir hier ein Problem haben wo das Auto einschläft. Also wenn du den Tesla aussteckst, dann auf Schnell stellst und dann wieder einsteckst, dann lädt der Tesla, richtig? @poohnet Bei dir die gleiche Frage: Ich nehme an die Zoe und der ID.4 funktionieren wenn du den Lademodus auf Schnell stehen hast? Wenn der Status auf Ladebereit steht und das Auto nicht lädt, dann legt der WARP4 erstmal prinzipiell das PWM an, das Auto darf laden und das Auto selbst verweigert die Ladung. Für gewöhnlich bedeutet dass, das Auto ist eingeschlafen (das sieht hier stark danach aus). Falls das Laden aber direkt nach dem Einstecken auch nicht startet ist es ein anderes Problem. Eine andere Sache die ihr einmal testen könntet: Schlafen die Autos bei euch auch ein wenn ihr ISO 15118 nicht aktiviert? Ich teste morgen als erstes mit dem Simulator ob unsere Wakeup-Sequenz und Willkommensladung noch funktionieren oder ob da irgendwas kaputt ist im Zusammenspiel mit ISO 15118. Ein generelles Problem mit den neueren Firmwares ist es eher nicht, dann hätten sich schon mehr Leute gemeldet.

Funktioniert es denn wenn du vor dem Einstecken den Lademodus auf Schnell stellst oder fängt der Tesla nie an zu laden? Weißt du wie viel Zeit ungefähr zwischen Einstecken und genug Strom für PV-Überschuss war?

Stand aktuell musst du von vorne anfangen. Ein Config Import/Export steht aktuell an Platz 1 auf der TODO-Liste der größeren Aufgaben, das wird vielleicht früh genug kommen für dein Upgrade. Ein Ladetracker Backup/Import ist unabhängig davon. Das werde wir frühestens angehen wenn wir bezüglich Eichrecht weiter sind und wissen inwiefern die lokal gespeicherten Daten dort relevant sind oder nicht. Daher gehen die Ladelog-Einträge aktuell definitiv verloren bei einem Upgrade von WARP3 auf WARP4.

Das ist korrekt Das ist möglich und bei WARP3 auch relativ einfach. Bei WARP3 ist der offizielle Zähler der Eltako DSZ15DZMOD-3x80A: https://shop.warp-charger.com/de/spare-parts/warp3-spare-parts/electricity-meter-dsz15dzmod-3x80a.html Wenn du ein Ladelog brauchst (kWh pro Ladevorgang aufgezeichnet) benötigst du die Pro. Die WARP3 Pro kann die dynamischen Strompreise von Tibber abrufen und den günstigsten Zeitpunkt berechnen wann geladen werden soll und dies automatisch umsetzen. Die eigentlichen Ladekosten werden nicht nachgehalten. Korrekt, WARP3 Smart/Pro können das und es funktioniert zuverlässig. Datum, Uhrzeit, geladene kWh werden im Ladelog gespeichert. Preis auf Grund des dynamischen Stromtarifs aktuell nicht. Das ist für die Zukunft geplant, steht aber nicht ganz oben auf der TODO-Liste, wird also eher mittelfristig kommen. Ich könnte mir vorstellen dass es am einfachsten ist den Zähler nachzurüsten und die Ladekosten extern über EVCC oder HA festzuhalten.

Ja die Änderung ist schon im git, wird mit im nächsten Release sein.

Mit einer WARP3 die auf WARP4 aktualisiert wurde, wird autocharge und SoC auslesen mit dem e-tron funktionieren. Freigabe per NFC oder Autocharge funktioniert. Die Ladung wird dem Benutzer zugeordnet (dem das Auto oder NFC zugeordnet wurde). Im Ladeprotokoll wird aktuell nur der Benutzer angezeigt, nicht das Auto.

Den Fehler solltest du nur bekommen wenn der identifier welche du bei get_station_data überträgst nicht bekannt ist. Was gibt get_station_identifiers denn zurück und was übergibst du bei get_station_data?

Wir haben 11 Firmenwagen von VW/Skoda/Cupra, Citroën/Opel, Renault, Hyundai, MG mit denen wir jederzeit testen können. ISO 15118 in WARP4 haben wir mindestens auch mit BMW und Tesla getestet, wo ich mich gerade dran erinnern kann. Am Ende spielt das aber ab einem gewissen Punkt keine Rolle mehr. Auf der einen Seite ähneln sich Sonderheiten/Quirks zwischen den Herstellern (da die Hersteller die ISO 15118 Stacks von Sevenstax/Vector etc zukaufen). Auf der anderen Seite ändert sich das Verhalten vom gleichen Auto oft nach einem Werkstattbesuch (wo der Ladecontroller aktualisiert wurde) oder sogar nach einem OTA Update. Da bringt es dann auch nichts wenn ich für einen Tag ein Auto zum Testen da hab, was sich dann am nächsten Tag anders verhält. Ich hab allerdings Hoffnung was die neue ISO 15118-20 angeht. Da dort ohne beidseitiger Zertifizierung gar keine Kommunikation möglich ist, erwarte ich da zumindest dass alle nicht-optionalen Features tatsächlich eine hohe Kompatibilität zwischen Autos und Wallbox haben. Ohne großes Hickhack.

Jop sieht gut aus jetzt, keine unerwarteten Nachrichten oder Fehler mehr im Protokoll 👍

Jo, der Inster hat dort in der Tat keinerlei Kommunikation von sich gegeben. Eventuell ist er aktuell in einem Fehlerzustand und du musst ein paar Meter fahren bis er wieder redet?

Probier nochmal mit der Firmware im Anhang. Gerne nach dem nächsten Ladeversuch den Debug-Report nochmal anhängen (auch wenn es funktioniert). warp4_firmware_2_12_1_6a4b84b4_21dd66cb41c088c_ota.bin

OK, ich kann genau sehen was passiert. Dein Kona unterstützt nur die DIN SPEC 70121 und verhält sich erwartet/standardkonform. <Technische Tirade> Der Inster nutzt die ISO 15118-2 und die Kommunikation bricht nach ServiceDiscoveryReq ab weil die SessionID nicht passt: SessionID legt der WARP4 als 5BE98A46 fest. Der Inster sendet aber 5BE98A4600000000. Er fügt also (warum auch immer) nullen hinzu.... was eigentlich nicht OK ist. Die zwei Hyundai IONIQ5 (auch BJ 2025) die wir hier haben zum Testen verhalten sich korrekt. Es verhält sich einfach jedes Auto anders... 💩 </Technische Tirade> Ich baue nachher eine Firmware für dich zum Testen die das toleriert und das kommt ins nächste Release wenn es funktioniert.

Bitte einmal unter System -> Ereignis-Log den Debug-Report herunterladen nachdem du versucht hast den Inster zu laden.

Es gibt da leider nichts sinnvolles... Du kannst hier einmal durchstöbern: https://github.com/Tinkerforge/libcbv2g/blob/main/include/cbv2g/iso_2/iso2_msgDefDatatypes.h Dazu der Hinweis das alle Autos mit denen wir bisher getestet haben alles was ein "*_isUsed" hat (also Optional ist) nicht anbieten, bis auf SoC. Zum Beispiel gibt es optional EVEnergyCapacity, was super praktisch wäre, wird aber in keinem der Autos die wir bisher getestet haben gesetzt. Und ich denke wir haben mehr oder weniger alle großen Hersteller durchprobiert.

Auch lustig, es scheint so zu sein dass sie stehen bleiben wenn man den Nutzer der dort zugeordnet ist löscht. Wenn man zuerst den Tag vom Nutzer löscht verschwindet der Tag aus der Liste. Ich vermute das ist ein Bug den wir uns mit der zentralen Nutzerverwaltung eingefangen haben.

Oh, das ist in der Tat komisch dann. Der müsste angezeigt werden. Das muss sich @rtrbt vermutlich einmal anschauen.

Jo, das ist aktuell so erwartet. Das Ladelog ist intern ein fixes Binärformat und wir haben das für WARP4 bisher nicht geändert. Es ist allerdings geplant das aufzubohren (wir hätten z.B. auch gerne den dynamischen Strompreis mit drin). Das sollte allerdings gut durchdacht sein, da es schon viel Aufwand ist auf Grund der notwendigen Migration von einem Format auf ein anderes und es dürfen da auch definitiv keine Daten verloren gehen etc. Ich vermute eine Anpassung da wird frühestens passieren wenn wir mit Eichrecht weiter sind und dort genau wissen was wir brauchen. Zusätzlich geht das in den Flash des ESP32, der ist auch nicht unendlich groß. Edit: Aber schön zu hören das SoC auslesen und Autocharge mit deinem ID.4 funktioniert 😃.