Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

[ChristophR]

Hallo Zut,

erstmal ein ganz großes Danke für Deine Unterstützung, ich habe es mit meinen rudimentären Kenntnissen tatsächlich quasi auf Anhieb zum Laufen bekommen.

Nun kommen doch noch Rückmeldungen zum soc_helper itself.

Ich habe die Sleep-Schwelle auf 13,8V gestellt, da es einen aufgeweckten Zustand mit 13,5V gab, in der trotzdem keine Antworten kamen.
So scheint es nun ganz gut zu funktionieren.

In der 1. Abfrage kurz nach dem Aufwecken kommt ein ungültiger Wert für den Kilometerstand zurück, das ist mehrfach passiert:

Code: Alles auswählen

openwb@openWB2:~/soc_helper$ ./soc_helper.py
2024-08-22 19:57:15,430; CRITICAL;[      soc_helper.py:127 -         <module>() ] Starte soc_helper2 Version 2024-07-18
2024-08-22 19:57:15,431;     INFO;[       energylog.py: 14 -             init() ] Öffne existierende Logdatei /home/openwb/soc_helper/energydata.csv.
2024-08-22 19:57:15,432;     INFO;[      soc_helper.py:144 -         <module>() ] Verbinde Callbackfunktionen der Ladepunkte:
2024-08-22 19:57:15,433;     INFO;[      soc_helper.py:156 -         <module>() ] Verbinde Callbackfunktionen der Fahrzeuge:
2024-08-22 19:57:15,435;     INFO;[      soc_helper.py:112 -       on_connect() ] Verbindung hergestellt zu openwb2 mit Resultat 0
2024-08-22 19:57:15,502;     INFO;[            cars.py: 46 -        cb_status() ] WiCAN-Status: others/wican/AUTO/status b'{"status": "offline"}'
2024-08-22 19:57:15,502;     INFO;[            cars.py: 66 -        cb_status() ] Fahrzeug AUTO ist <<offline>>
2024-08-22 19:58:29,549;     INFO;[            cars.py: 46 -        cb_status() ] WiCAN-Status: others/wican/AUTO/status b'{"status": "online"}'
2024-08-22 19:58:29,549;     INFO;[            cars.py: 52 -        cb_status() ] Fahrzeug AUTO ist online. Sende SOC- und ODO-Anforderung
2024-08-22 19:58:29,550;     INFO;[            cars.py: 57 -        cb_status() ] Sende SOC-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 402391163, "dlc": 8, "rtr": false, "extd": true, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
2024-08-22 19:58:29,550;     INFO;[            cars.py: 63 -        cb_status() ] Sende ODO-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 402391158, "dlc": 8, "rtr": false, "extd": true, "data": [3, 34, 41, 90, 170, 170, 170, 170] }] }
2024-08-22 19:58:29,730;     INFO;[            cars.py:168 -            cb_rx() ] Fahrzeug-Kilometerstand ist 16777215

Könntest Du in die Abfrage vielleicht noch eine Pause einfügen? Vielleicht reicht es ja dann.

Bei den folgenden Abfragen ist es immer mal wieder passiert, dass nur der Kilometerstand als Antwort zurückkam, der SoC jedoch fehlte:

Code: Alles auswählen

openwb@openWB2:~/soc_helper$ ./soc_helper.py
2024-08-22 20:01:00,390; CRITICAL;[      soc_helper.py:127 -         <module>() ] Starte soc_helper2 Version 2024-07-18
2024-08-22 20:01:00,391;     INFO;[       energylog.py: 14 -             init() ] Öffne existierende Logdatei /home/openwb/soc_helper/energydata.csv.
2024-08-22 20:01:00,393;     INFO;[      soc_helper.py:144 -         <module>() ] Verbinde Callbackfunktionen der Ladepunkte:
2024-08-22 20:01:00,393;     INFO;[      soc_helper.py:156 -         <module>() ] Verbinde Callbackfunktionen der Fahrzeuge:
2024-08-22 20:01:00,396;     INFO;[      soc_helper.py:112 -       on_connect() ] Verbindung hergestellt zu openwb2 mit Resultat 0
2024-08-22 20:01:00,496;     INFO;[            cars.py: 46 -        cb_status() ] WiCAN-Status: others/wican/AUTO/status b'{"status": "online"}'
2024-08-22 20:01:00,497;     INFO;[            cars.py: 52 -        cb_status() ] Fahrzeug AUTO ist online. Sende SOC- und ODO-Anforderung
2024-08-22 20:01:00,498;     INFO;[            cars.py: 57 -        cb_status() ] Sende SOC-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 402391163, "dlc": 8, "rtr": false, "extd": true, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
2024-08-22 20:01:00,498;     INFO;[            cars.py: 63 -        cb_status() ] Sende ODO-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 402391158, "dlc": 8, "rtr": false, "extd": true, "data": [3, 34, 41, 90, 170, 170, 170, 170] }] }
2024-08-22 20:01:00,666;     INFO;[            cars.py:168 -            cb_rx() ] Fahrzeug-Kilometerstand ist 19290

Wenn es klappt, sieht es dann so aus:

Code: Alles auswählen

openwb@openWB2:~/soc_helper$ ./soc_helper.py
2024-08-22 20:01:42,788; CRITICAL;[      soc_helper.py:127 -         <module>() ] Starte soc_helper2 Version 2024-07-18
2024-08-22 20:01:42,789;     INFO;[       energylog.py: 14 -             init() ] Öffne existierende Logdatei /home/openwb/soc_helper/energydata.csv.
2024-08-22 20:01:42,790;     INFO;[      soc_helper.py:144 -         <module>() ] Verbinde Callbackfunktionen der Ladepunkte:
2024-08-22 20:01:42,791;     INFO;[      soc_helper.py:156 -         <module>() ] Verbinde Callbackfunktionen der Fahrzeuge:
2024-08-22 20:01:42,794;     INFO;[      soc_helper.py:112 -       on_connect() ] Verbindung hergestellt zu openwb2 mit Resultat 0
2024-08-22 20:01:42,873;     INFO;[            cars.py: 46 -        cb_status() ] WiCAN-Status: others/wican/AUTO/status b'{"status": "online"}'
2024-08-22 20:01:42,873;     INFO;[            cars.py: 52 -        cb_status() ] Fahrzeug AUTO ist online. Sende SOC- und ODO-Anforderung
2024-08-22 20:01:42,874;     INFO;[            cars.py: 57 -        cb_status() ] Sende SOC-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 402391163, "dlc": 8, "rtr": false, "extd": true, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
2024-08-22 20:01:42,874;     INFO;[            cars.py: 63 -        cb_status() ] Sende ODO-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 402391158, "dlc": 8, "rtr": false, "extd": true, "data": [3, 34, 41, 90, 170, 170, 170, 170] }] }
2024-08-22 20:01:42,919;     INFO;[            cars.py:160 -            cb_rx() ] Fahrzeug-SOC ist 63
2024-08-22 20:01:42,920;     INFO;[            cars.py:168 -            cb_rx() ] Fahrzeug-Kilometerstand ist 19290

Wäre es vielleicht möglich, die beiden Abfragen getrennt (wieder mit einer kleinen Pause) zu versenden?
Dann fällt dem Dongle ggf. die Antwort leichter.

Dann habe ich noch nach dem Rest-Kilometerstand für den SoC geschaut.
Im Carscanner heißt der "geschätzteReichweite(Anzeige)".
Die Antwort auf die Abfrage im Carscanner lautet:

Code: Alles auswählen

{"bus":"0","type":"rx","ts":52885,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,239,0]}]}

Jedoch habe ich nicht herausbekommen, wie man die Abfrage im Carscanner debuggen könnte, damit man auch die Frage erhält.
Lässt sich die aus der Antwort irgendwie erraten?
Der manuelle SoC hat ein Feld für die Restreichweite, die manuell aber nicht gepflegt werden kann, man kann sie aber per MQTT schreiben und dann wird sie auch artig angezeigt. Stimmt dann zwar nur für den ausgelesenen Zeitpunkt, aber wäre doch ganz nett?
Bei mir wäre das z.B. auf dem Topic:
openWB/set/vehicle/1/get/range
Interessant wird das für mich allerdings erst, wenn ich die ODB2-Überwachung der Alarmanlage abgeschaltet bekomme.
Aber vielleicht ist das ja für den einen oder anderen Nutzer ggf. interessant?

Meine Alarmanlage werde ich, wie geschrieben, erstmal über ein manipuliertes ODB2-Verlängerungskabel austricksen, so dass der Dongle nur das Zündungsplus abbekommt. Der Dongle hängt mir sowieso etwas zu weit in den Fußraum hinein, so dass ein Verlängerungskabel eh dran wäre.
Dafür muss die Abfrage bei der Ankunft dann sicher funktionieren.
Kannst Du mir dafür helfen, wie ich die Abfrage mehrfach (am besten alle 10 Sekunden?) starten kann, damit der SoC sicher weggeschrieben wird?
Du hattest weiter oben dazu schonmal geschrieben, dass dafür einige Zeilen aus- und andere einkommentiert werden müssten.

[zut]

Ich habe die Sleep-Schwelle auf 13,8V gestellt, da es einen aufgeweckten Zustand mit 13,5V gab, in der trotzdem keine Antworten kamen.
So scheint es nun ganz gut zu funktionieren.

In der 1. Abfrage kurz nach dem Aufwecken kommt ein ungültiger Wert für den Kilometerstand zurück, das ist mehrfach passiert:

Der ungültige km-Stand nach dem Aufwachen kann sein, eventuell ist das Steuergerät nicht schnell genug wach. Ich denke darüber nach, wie man da eine Verzögerung einbauen kann, ohne den Kontrollfluss nennenswert einzuschränken. Eigentlich muß der Fall ja nicht beachtet werden, denn beim Anfahren des Heim-WLANS sollte das SG ja wach sein. Und der km-Stand sich danach nicht mehr ändern.
Was auf jeden Fall sinnvoll wäre ein Unterdrücken von Kilometerständen 0xffffff, denn das steht mit einiger Sicherheit für "nicht bereit".

Hinsichtlich nicht ankommender SOC wüsste ich gerne erst mal, was da vor sich geht. Lade mal das letzte Release herunter: https://github.com/DerHerrW/soc_helper/ ... 2024-08-22. Eigene configuration.py sichern! Nach dem Aufspielen die eigene configuration.py wieder einspielen und LOGLEVEL auf DEBUG stellen.

Start mit

Code: Alles auswählen

./soc_helper &> logdatei.txt

kurz vor dem Abfragen des Kilometerstandes und nach dem Einfangen des Ereignisses beenden (Strg+C). Die Datei bitte mir schicken oder hier posten.

Hintergrund der Aktion: Der WiCAN kann mehrere schnell aufeinander folgende CAN-Botschaften als in eine MQTT-Botschaft mit mehreren Frames verpacken. Ich habe versucht, dem im neuen Release Rechnung zu tragen. Mit Loglevel DEBUG werden auch die rohen MQTT-Botschaften aufgezeichnet.

[zut]

Dann habe ich noch nach dem Rest-Kilometerstand für den SoC geschaut.
Im Carscanner heißt der "geschätzteReichweite(Anzeige)".
Die Antwort auf die Abfrage im Carscanner lautet:

Code: Alles auswählen

{"bus":"0","type":"rx","ts":52885,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,239,0]}]}

Jedoch habe ich nicht herausbekommen, wie man die Abfrage im Carscanner debuggen könnte, damit man auch die Frage erhält.
Lässt sich die aus der Antwort irgendwie erraten?

Wenn die Botschaft UDS ist, ist sie der erste Teil einer mehrteiligen Antwort:
Das Steuergerät das antwortet nutzt eine 11-Bit-ID (extd:false, id=1914)
Die 16 ist eine 1 im oberen Nibble des ersten Datenbytes, das steht für mehrteilige Botschaft, erster Teil.
Die 10 steht für 10 Byte Nutzdaten incl Kommandowiederholung
98, 42, 182 ist die Wiederholung des Kommandos, wobei dem ersten Byte immer 64 zugeschlagen werden: Kommando war also 34,42,182

Vermutlich sendet CarScanner danach eine Botschaft mit dem Befehl 48,0,0 oder ähnlich, um den zweiten Teil der Botschaft abzufragen.

Hiernach https://www.goingelectric.de/forum/view ... 6#p1322746 liesse sich folgendes vermuten:
Request mit ID 0x710 (?), Daten 3,34,42,182 - das Ergebnis der im Link vorgeschlagenen Formel ist aber unplausibel: 239*65536/1310 ist über 13000...

Der manuelle SoC hat ein Feld für die Restreichweite, die manuell aber nicht gepflegt werden kann, man kann sie aber per MQTT schreiben und dann wird sie auch artig angezeigt. Stimmt dann zwar nur für den ausgelesenen Zeitpunkt, aber wäre doch ganz nett?
Bei mir wäre das z.B. auf dem Topic:
openWB/set/vehicle/1/get/range

Das ist für mich ehrlich gesagt nachrangig, zumal das manuelle SoC-Modul das nicht weiter unterstützt - man müsste die Fahrzeugklassen entsprechend erweitern um ein Frage-Antwort-Pärchen und die Möglichkeit schaffen, das Pärchen zu ignorieren. Wäre nicht sooo schwer. Ich finde es aber momentan schwer genug, die OBD2-Kommanods und Antworten für SoC und Kilometerstand für andere Fahrzeuge herauszufinden.

Kannst Du mir dafür helfen, wie ich die Abfrage mehrfach (am besten alle 10 Sekunden?) starten kann, damit der SoC sicher weggeschrieben wird?
Du hattest weiter oben dazu schonmal geschrieben, dass dafür einige Zeilen aus- und andere einkommentiert werden müssten.

Ich hatte am Anfang der Entwicklung mal eine nicht blockierende Version hinterlegt, so alle Minute oder so die Abfragen rausgehauen wurden. Ich habe das nicht weiter verfolgt, weil man nicht sicher sein kann, ob und wie lange der WiCAN durch das Fahrzeug wach gehalten wird. Beim eUp ist irgendwann Ende mit Erreichbarkeit, auch bei aktiver Ladung, vermutlich, nachdem die NV-Batterie voll geladen ist. Lass uns erstmal sehen, ob der SoC eventuell in einem zweiten Frame der gleichen Botschaft ankommt und die bisherige Version des soc_helpers das einfach ignoriert hat.

[_daniel]

[
Probier mal eine etwas geänderte Botschaft an das rx-Topic zu senden (stimmt das mit der Konfiguration im WiCAN überein?) - ich habe einige Anführungszeichen entfernt:

Code: Alles auswählen

{ "bus":"0","type":"tx","frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3,34,2,140,0,0,0,0]}] }

Danke für die bisherige Hilfe. Die Anleitung zum SoC_Helper ließ sich gut umsetzen. Leider funktioniert es noch nicht. Würde mich über Unterstützung freuen

Die CAN Pfade habe ich für meine Test mit dem SoC Helper heute korrigiert "others/wican/egolf/can/...".
Leider bekomme ich weder über MQTT noch über den SoC Helper eine Antwort mit Inhalt zurück:
SoC Helper: " logging.debug(f'payload ist: {self.payload}') AttributeError: 'eGolf' object has no attribute 'payload'

Ich habe die Parameter bereits in Formate von von "wican-fw" (github) kopiert.

Code: Alles auswählen

 { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }

Als auch andere Aufrufe aus Issue zum e-Golf "km" (ID 1812) an TX gepublished.
Unter dem RX Topic kommen Nachrichten, aber ohne den gewnüschten Inhalt (keine Nachrichten mit ID "2029" für SoC oder "1918" für km in der Historie) zurück.

[ChristophR]

Ich habe die Sleep-Schwelle auf 13,8V gestellt, da es einen aufgeweckten Zustand mit 13,5V gab, in der trotzdem keine Antworten kamen.
So scheint es nun ganz gut zu funktionieren.

In der 1. Abfrage kurz nach dem Aufwecken kommt ein ungültiger Wert für den Kilometerstand zurück, das ist mehrfach passiert:

Der ungültige km-Stand nach dem Aufwachen kann sein, eventuell ist das Steuergerät nicht schnell genug wach. Ich denke darüber nach, wie man da eine Verzögerung einbauen kann, ohne den Kontrollfluss nennenswert einzuschränken. Eigentlich muß der Fall ja nicht beachtet werden, denn beim Anfahren des Heim-WLANS sollte das SG ja wach sein. Und der km-Stand sich danach nicht mehr ändern.
Was auf jeden Fall sinnvoll wäre ein Unterdrücken von Kilometerständen 0xffffff, denn das steht mit einiger Sicherheit für "nicht bereit".

Hinsichtlich nicht ankommender SOC wüsste ich gerne erst mal, was da vor sich geht. Lade mal das letzte Release herunter: https://github.com/DerHerrW/soc_helper/ ... 2024-08-22. Eigene configuration.py sichern! Nach dem Aufspielen die eigene configuration.py wieder einspielen und LOGLEVEL auf DEBUG stellen.

Start mit

Code: Alles auswählen

./soc_helper &> logdatei.txt

kurz vor dem Abfragen des Kilometerstandes und nach dem Einfangen des Ereignisses beenden (Strg+C). Die Datei bitte mir schicken oder hier posten.

Hintergrund der Aktion: Der WiCAN kann mehrere schnell aufeinander folgende CAN-Botschaften als in eine MQTT-Botschaft mit mehreren Frames verpacken. Ich habe versucht, dem im neuen Release Rechnung zu tragen. Mit Loglevel DEBUG werden auch die rohen MQTT-Botschaften aufgezeichnet.

Ich sehe nach dem Versand des tx Pakets vom soc_helper an den MQTT Broker der openWB auch schon mit dem MQTT-Explorer das ausbleibende rx Paket nicht, daher wird sich auf der Seite des soc_helpers nicht viel protokollieren lassen. Es ist ja nichts da zum abholen.
Ich habe in der car-Konfiguration schonmal testweise den ODO-Request auf 0 gesetzt, da Du den dann nicht versendest.
Das führt aber auch nicht dazu, dass der SoC öfter zurückkommt.
Ich hatte daher ggf. Netzwerkprobleme zum MQTT-Broker vermutet, daher habe ich jetzt den MQTT-Broker meiner Produktiven Wallbox genutzt, um die VM als Ursache auf der Seite (wican -> MQTT) auszuschließen.
Hat genau gar nichts geholfen.
Natürlich läuft auf der VM weiter der soc_helper, aber die hat ja wie gesagt nichts zum Abholen.

Irgendwie muss das Problem zwischen dem wican-Dongle und dem MQTT-Broker der Wallbox liegen, oder das Auto antwortet einfach gar nicht...
Wir bräuchten also eine Protokollierung auf dem Dongle.
Ich habe auch schonmal in das MQTT Log der openWB geschaut, aber da steht gar nichts zum topic /others.

[zut]

Leider bekomme ich weder über MQTT noch über den SoC Helper eine Antwort mit Inhalt zurück:
SoC Helper: " logging.debug(f'payload ist: {self.payload}') AttributeError: 'eGolf' object has no attribute 'payload'

Auch wenn ich sonst zu nichts mehr Zeit habe - diesen Fehler habe ich hoffentlich mit dem aktuellen Release behoben:

https://github.com/DerHerrW/soc_helper/ ... 2024-08-23

Du könntest mal den LOGLEVEL auf DEBUG stellen in der configuration.py.

Um den Rest muss ich mich später kümmern. Der eGolf scheint ja spannend zu werden. Mit etwas Aufwand könnte ich vermutlich einen hier in die Finger bekommen, um da selbst Hand anzulegen. Aber vielleicht geht es ja auch remote.

[_daniel]

Danke. Ich sehe den Fehler noch nicht im soc_helper.
Kann aber auch an meinen Einstellungen keinen Fehler finden.
Über MQTT bekomme ich ja auch keine Response auf der ID2029.
Alternativ frage bei wican-fw nach.

[zut]

Oh - gerade eine OBD-Lib für python entdeckt: https://python-obd.readthedocs.io/en/latest/ Die läuft allerdings direkt per Bluetooth und nicht per MQTT...

Ich bin hierdurch darauf gekommen: https://www.goingelectric.de/forum/view ... 3#p1432793

Zur SoC-Abfrage für den eGolf (zumindest heisst das Thema so) nutzen die die IDs 0x7e5 / 0x7ed, also 2021 und 2029, alternativ die Anzeige unter 0x7E0, die aber nur bei Zündung an und nicht beim Laden aktiv ist:

Hallo nochmal.

@Blue shadow
Brutto:
- 35,8 KWh
- 7E5 / 028C
- Lesbar bei 'Zündung an' und ca. 1 Minute lang nach Abstellen der 'Zündung'. Ebenfalls lesbar beim Ladevorgang.

Netto:
- 31,5 KWh. (Brutto - 12%)
- 7E0 / 1164
- Nur lesbar bei 'Zündung an'

Leider kann man den Netto-SoC nur bei eingeschaltener 'Zündung' auslesen. Deswegen lese ich den Brutto-SoC und rechne mir aus dem Wert den Netto-SoC aus.

Der OBD-Dongle wird im Auto immer mit 12V versorgt. Der kann also immer mittels BT angesprochen werden. Was aber über das Gateway an Daten ausgelesen werden kann ist abhängig von der Betriebssituation des Autos. Siehe oben. Der ESP32 fragt einfach brav zyklisch ab und 'merkt' sich immer den letzten empfangenen SoC-Wert und einen Timestamp dazu.

[ChristophR]

Ich habe die Sleep-Schwelle auf 13,8V gestellt, da es einen aufgeweckten Zustand mit 13,5V gab, in der trotzdem keine Antworten kamen.
So scheint es nun ganz gut zu funktionieren.

In der 1. Abfrage kurz nach dem Aufwecken kommt ein ungültiger Wert für den Kilometerstand zurück, das ist mehrfach passiert:

Der ungültige km-Stand nach dem Aufwachen kann sein, eventuell ist das Steuergerät nicht schnell genug wach. Ich denke darüber nach, wie man da eine Verzögerung einbauen kann, ohne den Kontrollfluss nennenswert einzuschränken. Eigentlich muß der Fall ja nicht beachtet werden, denn beim Anfahren des Heim-WLANS sollte das SG ja wach sein. Und der km-Stand sich danach nicht mehr ändern.
Was auf jeden Fall sinnvoll wäre ein Unterdrücken von Kilometerständen 0xffffff, denn das steht mit einiger Sicherheit für "nicht bereit".

Hinsichtlich nicht ankommender SOC wüsste ich gerne erst mal, was da vor sich geht. Lade mal das letzte Release herunter: https://github.com/DerHerrW/soc_helper/ ... 2024-08-22. Eigene configuration.py sichern! Nach dem Aufspielen die eigene configuration.py wieder einspielen und LOGLEVEL auf DEBUG stellen.

Hallo Zut,

Danke für Deine Hilfe.
Es lag wohl einfach am Auto, dass die Werte nicht rausgeschickt wurden. Beim Ein- und Ausfahren funktioniert es nun.
Ich hatte bei meinen Tests erstmal mit Klimatisierung und Ladung zum Aufwecken gearbeitet, dann kommen die Antworten vom SoC aber anscheinend nur manchmal, der km-Stand war etwas sicherer...

Momentan läuft alles, ich habe den soc_helper nun dauerhaft am Laufen und Tronity erstmal deaktiviert.

[_daniel]

Zur SoC-Abfrage für den eGolf (zumindest heisst das Thema so) nutzen die die IDs 0x7e5 / 0x7ed, also 2021 und 2029, alternativ die Anzeige unter 0x7E0, die aber nur bei Zündung an und nicht beim Laden aktiv ist:

Vielen Dank.
Das darauf hätte ich wohl selbst kommen können. Ladekabel gesteckt und die Daten fließen. Hab die Fehler die ganze Zeit am WiCan und den Telegrammen gesucht.
Getestet mit FW 2.98 und 3.25.

Denke der SoC kommt ungefähr hin. Die gefahrenen Kilometer stimmen, das Terminal gibt fast jede Sekunde eine Zeile dazu aus, ist das so gewollt?
Damit kann ich auf jeden Fall auf ca 90% statt auf 100% laden.
Willst du mit dem egolf noch was getestet haben?