borg

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 😃.

Wird im Ladeprotokoll der Benutzer denn angezeigt?

Das wird es für Android mit der nächsten App-Version geben (ist technisch schon länger fertig sogar). Für iOS ist es auf Grund der hohen Hürden bei Apple aktuell mittelfristig nicht geplant.

Das ist schon im initialen WARP4-Release mit drin.

-180° + 360° = 180° 😀

Du brauchst im Prinzip das hier: https://www.tinkerunity.org/topic/12097-warp2-zu-warp3-aufr%C3%BCsten/page/2/#comment-55013 und kannst dort EVSE/ESP durch das Upgrade-Kit austauschen.

Wenn ihr das kWh-Genau abrechnen wollt seid ihr da auf jeden Fall in einer Grauzone. Da könnte man euch vorwerfen dass die WARP1 nicht manipulationssicher genug ist (es geht dabei nicht um die Genauigkeit des Zählers, dafür reicht auch MID). Ein Trick das zu umgehen wäre nicht pro kWh sondern als Mischkalkulation pro Tag pro Stellplatz o.ä. abzurechnen. Also ein Autostellplatz mit Zugriff auf (kostenlose) Wallbox kostet 10€/Tag (zum Beispiel).

Ja das ist kein Problem, man kann WARP1/2/3/4 zusammen im Lastmanagement nutzen.

Genau, du musst nur die Wallbox (auch wenn es nur eine ist) im Lastmanagement einfügen, §14a-Steuerung aktivieren und konfigurieren wie in deinem Screenshot und noch unten bei "Kontrollierte Wallboxen" den haken setzen.

Nächster Schritt wäre dann vermutlich die Box einmal aufzuschrauben und zu schauen ob der Zähler noch etwas anzeigt oder tot ist. Eventuell einmal das Kabel zwischen Zähler und EVSE prüfen (hat sich das gelöst o.ä.). Wenn nichts davon zutrifft ist die Frage ob der Zähler oder das EVSE Probleme hat bei der Kommunikation. Wir können Austauschteile rausschicken, oder du schickst die Box ein und wir schieben die hier durch unseren Tester, da haben wir dann schnell raus was defekt ist. Diesbezüglich müsstest du dich dann einmal bei info@tinkerforge.com melden.

Ja, das geht.

Hier gibt es eine Zusammenfassung der Unterschiede zwischen WARP3 und WARP4: https://warp-charger.com/de/blog/warp4 Für deinen Aufbau wäre denke ich erstmal nur relevant dass Support für ISO15118 dazu gekommen ist. WARP1/2/3/4 sind im Lastmanagement beliebig miteinander kompatibel.

The DC fault "Differential Current Sensor" that we use in the WARP3 is a fluxgate current sensor. For testing it has an auxiliary winding in the toroid where it can induce test currents. It does not actually touch the live wires at all. It is physically impossible for the sensor to induce a fault current in your live wires that go into the solar inverter.

Do you have a WARP1 Charger or WARP2/3 Charger? WARP2/3 can not cause a RCD to trip. With WARP1 a type A RCD can be tripped if there is a dc leakage current, but not during any testing.

Vom Biegeradius her wird das schon ein bisschen enger von oben, aber bei 2,5 mm² für 11kW wird das gehen.