Ich habe nur auf den normalen CAN L/H Pins geschaut (6/14). Morgen kann ich schnell prüfen ob auf Pins 2/10 was drauf ist, es würde mich aber sehr erstaunen wenn da was nützliches (sprich: nicht honda-proprietär) vorhanden ist. Die Zeiten der nackten CAN-Bus-Signale am OBD-Port sind grösstenteils durch, heutzutage hat praktisch jeder Hersteller ein CAN-Gateway als Firewall. Der OBD-Port selbst ist nicht einmal mehr vorgeschrieben wenn kein Verbrennungsmotor verbaut ist.

Falls du tiefer in die kritischen CAN-Nachrichten willst, würde ich dir einen kontaktloser Leser wie den CANcrocodile empfehlen. Der kann direkt an einem "richtigen" CAN-bus angebracht werden. Gute Interface-Boards gibts wie Sand am Meer, ich bin Fan von GVRET-Kompatible Boards (CANDue, Macchina M2, etc.) oder SocketCAN-Boards.

Zitat von HausO

Hallo,

welchen CAN-Bus nutzt dein Bluetooth OBD-Doogle? Laut dem Teltonika-PDF hat der "e" zwei CAN-Busse und die normalen Adapter nutzen nur PIN6/14 der OBD-Buchse (CAN L&H J-2234). Ich hoffe der 2.CAN-BUS ist auf PIN 2/10 (J-1850) der OBD-Buchse "gemappt".

Gruß

Henning

Alles anzeigen

Ich habe weder mit dem CAN-Interface noch mit dem Oszilloskop Kommunikation auf anderen Pins als 6/14 festgestellt. Falls was da ist, braucht es wahrscheinlich eine entsprechende Anfrage bevor die Kommunikation läuft.

Hallo, hat jemand von euch eventuell noch so eine Log Datei von der CanBus Kommunikation?

Hallo zusammen,

der Thread ist anscheinend tot, aber ich probiere es einfach mal: Habe aktuell die OVMS v3 Hardware hier und bekomme vom Honda e leider keine Daten. Hatte mir erhofft, daß ich wenigstens SOC usw. sehen kann, wenn ich als Fahrzeugtyp OBD2 auswähle. Testweise mal alle anderen unterstützten Modelle durchprobiert, ob vielleicht etwas kompatibel ist. War leider auch nicht der Fall.

Ist hier jemand beim Analysieren der Daten weitergekommen? Es wäre toll, wenn man damit den Honda e in OVMS integrieren könnte. Habe einen (unterstützten) IONIQ 5 und da kommt alles, von SOC über SOH bis hin zum Zellstatus, geöffnete Türen, etc.

Kannst du eventuell irgendwie herausfinden wie die Belegung am OBD Port ist? Eventuell ist der "DiagnoseCan" wo anders bei Pin 6/14.

Ich habe zumindest beim Honda CRV Daten auslesen können. Über pin 6/14

Hallo, damit kann ich lieder nicht dienen. Hab jetzt erstmal beschlossen, den OVMS im anderen Auto (Hyundai) einzusetzen. Der wird bereits voll von OVMS unterstützt. Hoffentlich kommt irgendwann auch der Honda e hinzu, denn geil ist OVMS schon.

Honda lässt keine genaue Datenabfrage zu.Bei Hyundai ist das alles offen.

Doch, ich habe mich nun ein bisschen an einem Fahrzeug austoben können. Man kann wirklich sehr viel auslesen. Aber recht aufwändig, da die Payload teilweise über 400 bytes lang ist. Aber ich habe schon einige Werte dekodieren können. Die richtigen Ecu Ids sind nur komplex zu finden.

Nur leider nicht so einfach wie bei Hyundai. Aber die Hyundai DiagnoseDaten sind aber auch grundsätzlich sehr schlecht.

Oh, das klingt ja vielversprechend. Ich bin selbst kein Entwickler, aber vielleicht gibt es ja eine Möglichkeit für dich, den Support für den Honda e voranzubringen? Beim OVMS-Projekt gibt es hier z.B. einen Getting Started Info-Bereich: https://www.openvehicles.com/developers

Das wäre der Hammer!

Hallo zusammen,

ich habe Zeit gefunden, mich dem Thema wieder zu widmen.

Datenverkehr auf CAN Pin 6/14 ist nur vorhanden, wenn vorher etwas angefordert wurde, z. B. durch Handy-App + BLE-Adapter. Man hat hier keine Broadcast-Signale.

Honda e (ZC7) – CAN-Bus DID-Mapping

Aufbau der abgefragten ECUs (alle über UDS 0x62-Antworten, ISO-TP-reassembliert):

• 18DAF107 – ECU liefert u.a. VIN
• 18DAF115 – Haupt-Batterie-ECU (Spannung, Strom, Zell-SoC)
• 18DAF101 – weitere Batterie-Detail-ECU (teils redundante Felder zu 18DAF115)
• 18DAF160 – Fahrzeug-/Umgebungsdaten (Ambient-Temp, Odometer)

Im gesamten Capture wurden keine periodischen Broadcast-Frames gefunden – nur UDS-Request/Response-Paare. D.h. alles, was nicht hier gelistet ist, kommt nicht vom CAN-Bus (z. B. Speed vermutlich vom Handy-GPS).

✅ Exakt bestätigte Felder (Bit-genauer Abgleich, nicht nur Korrelation)

🟡 Wahrscheinlich, aber nicht abschließend bestätigt

• Battery Temperature: zwei Kandidaten-Offsets in DID 202A (off 169/170 und off 201/202), beide /10 → °C. Beide zeigten im Test denselben Wert (18,0 / 18,1 °C) – plausibel, da der Honda-e-Akku zweigeteilt verbaut ist (zwei Packhälften). Zum sicheren Nachweis wird ein Moment mit spürbar unterschiedlicher Temperatur zwischen beiden Packhälften benötigt (z. B. nach Schnellladen).
• Battery Current: zwei Kandidaten – 2021 off136 (Skalierung ≈ 1/37, nicht wie ursprünglich angenommen 1/34) oder 2029 off61 (Skalierung ≈ 1/10, kleiner Restfehler evtl. durch Zeitversatz). Noch nicht eindeutig getrennt – Strom ändert sich zu schnell für 2 Referenzpunkte mit ±6 s Toleranz.
• Is charging / Charging DC / Charging AC (Boolean-Flags): Kandidaten 2029 off45 oder off76 (0→1-Wechsel beobachtet, passend zum Start eines AC-Ladevorgangs), nicht sicher von Zufall unterscheidbar.

🟢 Berechnete App-Anzeigen (keine eigenen CAN-Felder)

• Energy (kWh): kWh = 3 + (28,5 kWh_nutzbar × SoH%) × SoC_max% / 100 – abgeleitet aus Max-Zell-SoC (DID 2029 off65) plus bekannter Nennkapazität (28,5 kWh nutzbar / 31,5 kWh neu / 3 kWh Reserve bei 0 %) und aktuellem SoH. Mit realen Fahrzeugdaten verifiziert: rechnerisch 24,7 kWh nutzbare Kapazität ≈ 28,5 kWh × 86,6 % SoH (24,68 kWh) – stimmt fast exakt überein.
• kW (Leistung): kW = Battery Voltage × Battery Current / 1000. Exakt bestätigt an einem Referenzpunkt: 352,6 V × -2,53 A / 1000 = -0,892 kW ≈ angezeigte -0,89 kW.

❌ Nicht über CAN verfügbar (andere Quelle)

Offene Punkte

1. Battery-Current-Feld eindeutig zuordnen (mehr Referenzpunkte mit schnell wechselndem Strom nötig, engere Zeittoleranz als 6 s).
2. Battery-Temperature-Duplikat als zwei echte Sensoren (vordere/hintere Packhälfte) bestätigen – braucht ungleiche Erwärmung beider Packteile.
3. Charging-Flags (Is charging / Charging DC / Charging AC) verifizieren – braucht mehrere Lade-/Nichtlade-Übergänge.
4. DID 7022 und 7028 vollständig durchscannen – bisher nur Odometer/Ambient-Temp identifiziert, Rest der 54 Byte unbekannt.

Viel Spass beim Basteln.

Gruß Henning