DIE FORENSOFTWARE BZW. DEREN FIREWALL BLOCKT HIER FAST JEDEN YAML CODE UND ICH HABE NUN SCHON 8 STUNDEN VERLOREN, WEIL IMMER WIEDER DIE FIREWALL BEIM SPEICHERN EINE SPERRE AUSLÖST UND DIE BEARBEITUNGEN NICHT GESPEICHERT SONDERN GELÖSCHT WERDEN.
GRAUSAMER ALPTRAUM
COPY & PASTE HILFT NICHT, weil beim Einfügen alle Formatierungen weg sind, die Lösung aber davon lebt, das zu strukturieren.
WORKAROUNG NACH 3 h PROBIERENS: im yaml Code sind in jeder Zeile vor dem 1. BEFEHL das "Leerzeichen" durch "" ersetzt worden, weil die Firewall den yaml code dann nicht mehr erkennt und durchlässt und speichert.
Wer den Code nutzen will, der darf nun NUR VOR DEM 1. WORD DER ZEILE DEN "" durch Leerzeichen ersetzen, also keinesfalls pauschal, denn sensor.abc_soc wäre dann ein Opfer davon!
Der Meatpi OBD2 Dongle entstand aus einem erfolgreichen Crowd Funding Projekt in Australien.
Ihn zeichnet aus, dass er sein eigenes WLAN aufspannt und sich zugleich auch in ein (heimisches) WLAN einbuchen und darüber via MQQT an HA "reporten"kann.
Da die verschiedenen Control Units (CU) des Wagen zu unterschiedlichen Zeitpunkten ausgeschaltet sind oder werden, gibt es nicht permanent Antworten in dem Sinne, dass der Wagen auch schläft und nicht erreichbar ist. Da manche Werte wie der SoC aber auch mehrfach vorkommen und damit in verschiedenen CU stecken, führen viele Wege nach Rom. Zum Beispiel das Steuergerät fürs Display kennt manche Werte, schläft aber beim Laden, wenn das Fahrzeug abgeschlossen ist, so dass dieses Steuergerät als Quelle eher 2. Wahl ist. Das muss man aber herausfinden, denn je nachdem, um was es gerade geht, ist das eine Steuergerät / CU besser als das andere.
Aber hier mal ein "ABLAUF", der bei den genannten Themen SoC, Reichweite und Km Stand immer funktionieren sollte:
Das Fahrzeug kommt vor oder in der Garage an und bucht sich ins WLAN ein, sendet eine MQTT Message über den Zustand ONLINE und eine Automation erkennt diesen Auslöser, worauf dann die Automation REQUESTS via WiCAN dongle an das Auto stellt für besagte Werte SoC, Reichweite, km Stand, worauf das angesprochene Steuergerät die Antworten herausfeuert, die die Automation gefiltert in MQTT Sensoren sendet. Gleiches passiert auch beim Öffnen/Schließen des Autos wie auch Zündung an. Die Verbindung bleibt bei Ankunft teils Minuten oder auch Stunden erhalten, was bedeutet, dass dann in HA die MQTT Sensoren weiter minütlich aktualisiert werden, bis der Wagen bzw. der WiCan Dongle STATUS <> "online" wird. Dann versiegt der Datenfluß.
Hier die besagten 3 Sensoren in HA als Ausblick, wie das gehen kann.
Verlässt das Fahrzeug das heimische WLAN, dann bleiben die letzten Werte erhalten, denn ansonsten würde Reichweite auf 0 km zurückgesetzt, was hier beim 1. Anblick schon mal für Herzkasper sorgte, wieso der Up so leer sein könne, dass der nur noch 0 km Reichweite gehabt hätte.
RÜCKBLICK:
VW bietet mit We Connect PLUS einen mehr oder eher minder stabilen Online Zugang zum Fahrzeug, der immer wieder unter Erreichbarkeits- / Funktionsproblemen leidet, jedenfalls in unser 1 jährigen Testphase (vgl. Autozeitschriften & Foren) wie auch den Berichten vieler 145€ jährlich bzw. 120€ im 2 Jahresabo (239€) zahlender Kunden, was in 2020 noch unter 100€ waren, sprich 45% Inflation bei VW.
Seltsamerweise gab dennoch es bisher im Web keine abofreie Lösung, diese Werte auszulesen und in HA & EVCC anzeigen zu lassen.
Diese Lösung entstand in Zusammenarbeit und Dank großartiger Hilfe von 2 gleichfalls "Home Assistant & PV & EV" Infizierten, die man hier wie in anderen Foren unter HisN (hier wie auch im PV Forum mit e-Up) und von JabeBRD (aus Finnland mit e-Up & PASSAT GTE 2020 = Hybrid mit 13 kWh Batterie) finden kann und zwar über 10 Tage in 120 Kommentare hin & her, weil der e-GOLF am Ende doch so anders war wie der e-Up, obschon das Gegenteil behauptet wurde.
Hier folgt eine Beschreibung aller Abläufe vom Kauf des Dongle über die Architektur, Dongle Konfiguration, der HA wie auch evcc Einrichtung wie auch die Grundlagen zum Verständnis der CanBus Architektur und Kommunikation, was die Anleitung "LÄNGER machen wird", aber dafür jeden in die Lage versetzen sollte, auch andere Werte auszulesen wie z.B. den Verbrauch / hkm.
Mittels CanBus erfolgt die Kommunikation der Steuergeräte in einem PKW. Mit dem normierten OBD2 (OnBoardDiagnose2) Stecker bekommen dann Techniker wie Endkunden Zugang zu dem Bus und damit in das Fahrzeugsystem.
CanBus kann mal Zicke oder DiVa spielen, von daher bei Problemen nicht zu früh aufgeben und ruhig mehrfach probieren.
Km Stand 0 km ist so ein Fall oder auch mal ein 4% SoC mit 250 km, wenn mqtt Nachrichten unterbrochen wurden oder abgerissen sein dürften. Das sind aber Ausnahmen von der Regel, denn ansonsten passen die Werte in HA zum in der Auffahrt parkenden Auto.
Der Hersteller Meatpi bietet den WiCan Dongle in diversen Varianten mit / ohne USB und seit kurzem auch als WiCan Pro Dongle an, der aber das Doppelte kostet, dafür aber eben erweiterbar ist um 4G Modem und ab Werk auch auf SD Karte die gefilterten CanBUS Nachrichten während der Fahr protokollieren kann, aber hier kaum Mehrwert bietet. Der einfache OBD2 Dongle hier im Bild reicht.
Klare Ansage: der WiCan ist bei Mouser Deutschland am günstigsten, aber man sollte wissen, was im Hintergrund passieren wird und wann der günstig ist.
Die Versandkosten liegen - wenn man den folgenden Trick nicht beachtet - bei grob 20€, denn am Ende bestellt man scheinbar bei Mouser in München, doch die Abwicklung und der Versand erfolgen von GRAND PRAIRIE in TEXAS, von wo der Dongle binnen 3 Tagen per Fedex nach Deutschland geschickt wird.
Da ab 50€ der Versand gratis ist, wird man sich bei einem Dongle Preis um 37€ besser einen 13€ Füllartikel bestellen als 20€ Versand zu zahlen.
ABER ACHTUNG: Mouser Deutschland wickelt die Bestellung über die USA ab, so dass die 37€ nur die halbe Wahrheit sind: 37€ netto.
Erst zum Ende der Bestellung erkennt man das, wenn die Abgaben alle drauf kommen, denn die USA sind ein NETTO Preis Land, immer ohne Verkaufssteuer.
Somit ist auch klar, dass der Dongle inkl. Mehrwertsteuer 44 bis 45€ kostet.
Die 50€ Mindestbestellwert kann man dann erreichen durch
- einen oder mehrere Füllartikel (z.B. für eine Heizungssteuerung ein Olimex Board, das so günstiger ist als beim bulgar. Hersteller) wie ESP32-EVB-EA 25,78€ oder
- 2 Dongle und den 2. Dongle verkaufen / vorher Partner für Sammelbestellung suchen
Der Hersteller entwickelt das Produkt firmwareseitig kontinuierlich via Github weiter und bittet dort auch um SOFORTIGES UPDATE bei Erhalt, von daher ist immer der 1. Schritt das Update der Firmware auf per 18.8.2024 die stabile Version 2.98 , was am Ende hier noch erklärt wird.
Am Horizont schon länger sichtbar und von mir auch getestet wird Meatpi mit der bete 3.11 bald einen großer Meilenstein ausrollen u.a. mit Auto Pid etc., aber das war heut Abend schon wieder Schnee von gestern, denn heute ist bereits parallel eine neue beta 3.21 parallel als 2. Meilenstein veröffentlicht worden.
Im Web haben wir keine Beschreibung gefunden, wie man einem GOLF VII ohne VW Abo diese Daten entlocken und in HA bereitstellen kann, daher alles mühselige Grundlagenarbeit
AUSGANGSPUNKT: gerüchteweise hieß es fast überall, der e-GOLF und der e-Up seien auf der Steuergeräteseite gleich oder einschränkend weitestgehend - nur das stellt man erst hinterher fest, wie weit man gekommen ist. Ich hab es leider nicht geschafft mit dem zum e-Up analogen Weg, sondern war stattdessen mit einer Ableitung aus dem PASSAT GTE (Hybrid) erfolgreich, was damit auch für GOLF GTE (ebenso Hybrid) passen dürfte.
QUELLEN:
- GOLF Steuergeräte (teils aus für e-Up) ohne diese Liste bzw. Script wäre nix gegangen, weil man hier allein die Adressierung findet, wie ein CU = Control Unit angesprochen wird und wie diese wiederum antworten wird - Details dazu später.
- Und die Antwort bzw. deren Wert kann dezimal oder hexadezimal sein, weshalb man dez-hex Umrechner brauchen wird.
- Für den Zusammenbau von multi messages oder yaml Sensoren / Konvertierungen kann noch ein ninja 2 Tester hilfreich sein und viel Zeit sparen.
GRUNDPRINZIP AUS DER VOGELPERSPEKTIVE
- Eine Automation prüft permanent den WiCan Dongle GOLF Status auf einen Wechsel auf "online" (ACHTUNG auf online meint eine Änderung von was auch immer auf online und keinesfalls einen Dongle, der die ganze Zeit online ist)
- Wenn der auf online wechselt, so läuft die Automation ab dem Moment jede Minute erneut und holt die 3 gesuchten Werte, bis der Status <> online wird. ACHTUNG: Zum Testen einen Zeitauslöser Sekunden vor der aktuellen Zeit als 2. Auslöser wählen, wenn man beim Testen schon die ganze Zeit online war oder ist, denn dann gibt es keinen Wechsel des Status auf Online, der Auslöser tritt also an sich nicht mehr ein. Alternativ empfiehlt sich als 3. Auslöser der Trigger "bei jedem HA Neustart starten" lässt, denn ist das Auto schon während des Bootens da und damit der Wagen online, während HA noch startet, gibt es keinen Wechsel auf Online.
- Die Automation schickt also 3 Anforderungen / Requests via WLAN per MQTT an den WiCan Dongle, der diese mqtt Nachrichten in CANBus umsetzt und in das Auto zum hoffentlich richtigen Steuergerät schickt, was dann auf diese Anfrage so antworten wird wie auf eine Anfrage eines im Auto befindlichen Steuergeräts.
- Die CanBUS Antworten des Steuergeräts kommen beim WiCan Dongle vorbei und werden dort für HA in MQTT übersetzt und an den Home Assistant MQTT Broker geschickt.
- Von dort gehen die Daten an die mqtt Sensoren, wo jede CANBus Antwort auf ihren Empfänger etc. überprüft wird, was wir noch bis ins Detail hier behandeln werden, sobald die Vogelperspektive verlassen werden kann.
- Passen sowohl Absender wie auch die Antwortart zu einer der 3 ANFRAGEN / REQUESTS , dann wird deren Wert einem der 3 Sensoren zugeordnet.
- und sodann via mqtt als EXPORT auch publiziert, um auf diesem Weg evcc mit dem SoC zu versorgen.
- Doch alles das hier zuvor genannte erforder zuerst die Konfiguration des WiCan Dongle im heimischen WLAN etc. , was aber jetzt den Interessierten ohne so einen Dongle nicht weiterhelfen wird und daher erst zum Schluss erklärt wird.
SCHRITT FÜR SCHRITT ANLEITUNG
I. EVCC
Weil es der kleinste Schritt ist, aber am Ende einer Liste zu gern übersehen oder vergessen wird, jetzt evcc.yaml öffnen und dort "vehicle" suchen, um dessen Beschreibung um die ### Meatpi WiCan section ### zu verlängern
vehicles: - name: eGOLF title: GOLF type: custom icon: car capacity: 32.0 # net capacity in kWh phases: 2 ### Meatpi WiCan section ### soc: # optional SoC (%) source: mqtt topic: export/golf/soc range: # optional electric range (km) source: mqtt topic: export/golf/reichweite odometer: # optional odometer (km) source: mqtt topic: export/golf/odometer
II. DIE ABFRAGE AUTOMATION
Die Abfrage wird zwecks Erklärung hier in SEKTIONEN aufgeteilt, um sie Schritt für Schritt zu erklären.
- SEKTION: Die 3 Auslöser
Nach einer erfolgreichen Testphase von 10 Tagen, wo jeder SoC bei Anfahrt und Abfahrt übermittelt worden ist, kann der 3. Auslöser Plattform Uhrzeit gelöscht werden.
alias: "# MQTT GOLF SoC, REICHWEITE & KM Zähler - JabeBRD edition #" description: >- 'SoC High Voltage Batter charge state - absolut value' + REICHWEITE + km STAND trigger: - platform: state entity_id: - sensor.golf_status to: online from: null - platform: homeassistant event: start - platform: time at: "19:23:35" condition: []
2. SEKTION: SCHLEIFEN BEGINN ob DONGLE STATUS = "online" und WAKE UP CALL an DONGLE
Zu Beginn der Schleife, die alle 6 Sekunden neu durchlaufen werden wird, wird hier geprüft, ob der DONGLE Status = "online" ist.
Darauf wird ein Wake Up CAN Bus Call abgesetzt, der laut Hersteller meatpi in der Lage sein soll, den ggf. eingeschlafenen CanBus wieder aufzuwecken.
action:
-_repeat:
_sequence:
-_condition: state
_entity id: sensor.golf status
_state: online
-_service: mqtt.publish
_data:
_qos: "0"
_payload: >-
_{ "bus": "0", "type": "tx", "frame": [{ "id": 2015, "dlc": 8,
_"rtr": false, "extd": false, "data": [2, 1, 0, 170, 170, 170, 170,
_170] }] }
_topic: wican/dongleNummer123/can/tx
3. SEKTION: ANFRAGE ANS FAHRZEUG, DEN SOC MITZUTEILEN und EXPORT DER ANTWORT PER MQTT FÜR EVCC
Der Ernst des Lebens beginnt: Anfrage an das Fahrzeug zum SoC und Veröffentlichung der Fahrzeugantwort unter den
TOPICS: 1. export/golf/soc
2. export/golf/soc_permanent
für EVCC und Home Assistant.
-_service: mqtt.publish
_data:
_qos: "0"
_retain: true
_payload: >-
_{ "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8,
_"rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170,
_170, 170] }] }
_topic: wican/dongleNummer123/can/tx
-_service: mqtt.publish
_data:
_qos: "0"
_retain: false
_topic: export/golf/soc
_payload_template: "{{ states('sensor.golf_soc') }}"
-_service: mqtt.publish
_data:
_qos: "0"
_retain: true
_topic: export/golf/soc_permanent
_payload_template: "{{ states('sensor.golf_soc') }}"
4. SEKTION: ANFRAGE ANS FAHRZEUG, DIE REICHWEITE MITZUTEILEN und EXPORT DER ANTWORT PER MQTT FÜR EVCC
Anfrage an das Fahrzeug zur REICHWEITE und Veröffentlichung der Fahrzeugantwort des unter dem
TOPIC "export/golf/reichweite"
für Home Assistant und EVCC.
-_service: mqtt.publish
_data:
_qos: "0"
_retain: true
_payload: >-
_{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]}
_topic: wican/dongleNummer123/can/tx
-_service: mqtt.publish
_data:
_qos: "0"
_retain: true
_topic: export/golf/reichweite
_payload_template: "{{ states('sensor.golf_reichweite') }}"
5. SEKTION: ANFRAGE ANS FAHRZEUG, DEN KM STAND MITZUTEILEN und EXPORT DER ANTWORT PER MQTT FÜR EVCC
Anfrage an das Fahrzeug zum KM STAND und Veröffentlichung der Fahrzeugantwort des unter dem
TOPIC "export/golf/odometer"
für Home Assistant und EVCC.
-_service: mqtt.publish
_data:
_qos: "0"
_payload: >-
_{"bus":"0","type":"tx","frame":[{"id":1812,"dlc":8,"rtr":false,"extd":false,"data":[3,34,34,3,170,170,170,170]}]}
_topic: wican/dongleNummer123/can/tx
_retain: false
-_service: mqtt.publish
_data:
_qos: "0"
_retain: true
_topic: export/golf/odometer
_payload_template: "{{ states('sensor.golf_km_stand')}}"
6. SEKTION: SCHLEIFENENDE MIT 6 SEKUNDEN PAUSE UND ABBRUCH, falls STATUS = "offline"
Schleife von vorne beginnen, wenn nicht das Abbruchkriterium STATUS = "offline" erfüllt ist.
- delay: hours: 0 minutes: 0 seconds: 5 milliseconds: 0 until: - condition: state entity_id: sensor.golf_status state: offline
Ob es nun jemandem aufgefallen ist, dass sich die letzte Sektion wodurch unterscheidet ?
Tatsächlich, der Yaml Code ging ohne "_" durch. Was für ein Wunder.
III. EXKURS: EIN PAAR CAN BUS GRUNDLAGEN
Diese Grundlagen helfen, wenn man beispielsweise selber einen anderen Wert wie Verbrauch / hkm aus dem parkenden Auto abfragen und in HA integrieren will, denn das Beispiel erklärt, wie man die Abfragen / Anfragen so gestalten muss, dass man auch die richtigen Antworten bekommt, denn es kommt auf jedes Zeichen in der Syntax am Ende an - oder man wird Stunden oder eher Tage länger brauchen, ums ans Ziel zu kommen.
Um praxisnah zu bleiben geht es hier nun um die Erweiterung der yaml.configuration in der vermutlich existierenden "mqtt:" Sektion um den mqtt gespeisten SoC Sensor.
Wer schon eine "mqtt: sensor:" Sektion darin hat, der kopiert nur den Sensor "GOLF SoC". Alle anderen fügen halt den gesamten Code ein.
mqtt:
sensor:
- name: "GOLF SoC"
unique_id: "golf_soc"
state_topic: "wican/dongleNummer123/can/rx"
state_class: "measurement"
unit_of_measurement: "%"
value_template: >-
{% if value_json.frame[0].id == 2029 %}
{% set PID = value_json.frame[0].data[3] %}
{% if PID == 140 %}
{% set AA = value_json.frame[0].data[4] %}
{{ ( (AA - 0) / 240) * 100 | round(1) }}
{% endif %}
{% endif %}
Und wie schon zuvor gilt immer nach dem Einfügen, zuerst den Begriff "dongleNummer123" durch den eigenen WiCan Dongle Wert zu ersetzen.
1. AUFBAU DER CANBUS ANFRAGE und DER ANTWORT DES STEUERGERÄTES
Bevor wir uns aber nun dem Sensor von oben widmen, müssen wir uns die Anfrage an das Steuergerät im eGOLF anschauen.
Dazu hier zuerst die aus der Automation von oben, aber verkürzt auf den relevanten Teil, damit es übersichtlicher bleibt.
Diese Zeile stammt aus der 2. SEKTION der obigen Automation mit dem SOC und zwar extrahiert ab dem Wort payload und in 1 Zeile umgesetzt.
{ "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
Diesen Code kann so im MQTT Explorer in der PUBLISH Zeile rechts unten eingefügt und abgeschickt werden.
Dadurch wird sozusagen im "Empfangskanal" bzw. dessen History binnen 100 ms eine Nachricht vom CanBus des Auto eingehen, sobald der DONGLE konfiguriert worden ist.
Dazu muss man nach dem Absenden der ANFRAGE aber ZUERST DAS WLAN unterbrechen, damit die Histroy nicht mit CAN BUS Nachrichten ge- und überflutet wird.
Dann die History - wie hier im Screenshot zu sehen - aufklappen, dann den rechten Arbeitsbereich zuerst nach links so vergrößern, so dass man jede der eingehenden mqtt Nachrichten aus dem Auto in 1 Zeile ohne Umbrüche sehen kann.
Nun auf eine der 3 Nachrichten klicken und mit STRG + F suchen nach ":2029", woraufhin der Cursor auf einen ersten Treffer springen wird.
Und dieser 1. Treffer enthält tatsächlich den SOC in dieser Zeile, wenn auch noch verschlüsselt, so doch bei Kenntnis der Formel "lesbar".
11.08.2024 22:24:46(-0.04 seconds)
{"bus":"0","type":"rx","ts":6616,"frame":[{"id":2029, "dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,179,170,170,170]}]}
Der type ist "rx", was für receive = empfangene Antwort vom GOLF steht, die den MQTT Broker erreicht hat, während die eingefügte Zeile an der Stelle ein "tx" für transmitt oder senden aufwies, was eine Anfrage von HA an den GOLF bedeutet, wo der SOC erbeten wird.
2. DAS SCHÄLEN DER ANTWORTEN bis zum 1. SoC ermitteln
Nun nähern wir uns wie beim Zwiebeln häuten der Kernbotschaft von außen nach innen mit allem "rechts von id:" sozusagen
{"id":2029, "dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,179,170,170,170]}
Die "id":2029 besagt, welches Steuergerät hier geantwortet hat. Damit kann man prüfen, ob das die Antwort auf unsere Anfrage war, was aber gleich noch vertieft werden soll, wenn wir mit dem konrekten SoC ein erstes Erfolgserlebnis hatten.
Dazu die nächste Zwiebelhaut abziehen und alles außerhalb der wegstreichen. Es bleiben die reinen "data": aus der Antwort übrig, die auch den SOC enthalten:
[4,98,2,140,179,170,170,170]
Der SoC errechnet sich aus dem 5. Wert: 179
179 / 240 = SoC 0,75 = SoC 75%
3. DIE ARCHITEKTUR UND KOMMUNIKATION VON CANBUS
Vereinfacht betrachtet wird der WiCan Dongle vom GOLF wie eines seiner Steuergeräte - oder auch Control Unit CU genannt - behandelt, also wie ein Bruder.
Diese Steuergeräte schicken sich im CanBus dauernd Botschaften, wo das eine das andere fragt und um eine genaue Antwort bittet, wodurch im CANBUS viel Datenverkehr und Gewusel herrscht, so dass im MQTT Explorer die Nachrichten nur so vorbeizuhuschen scheinen, während wir auf 1 Antwort mit dem SOC warten.
Und dazu steigen wir nun in die Tiefen, denn jedes Steuergerät hat sozusagen 2 Adressen, die eine Adresse, unter der es Fragen empfängt und eine 2. Adresse, mit der es seine Antworten herausschickt. Diese Nachrichten passieren dann alle möglichen Steuergeräte, die die Nachricht bei Interesse aufnehmen und verarbeiten oder links liegen lassen. Der WiCan Dongle hingegen ist da ein Zwitter, denn auf der einen Seite lauscht und spricht er CANBUS zum GOLF und auf der anderen Seite lauscht und sprich er MQTT, sobald man ihn konfiguriert hat.
4. ANFRAGE UND ANTWORT oder REQUEST & REPLY am Beispiel SoC
Beim CanBus ist es so, dass wir eine Anfrage an ein Steuergerät (z.B. Battery) auf eine genaue Adresse (SoC Hochvoltbatterie absolut) stellen, um eine bestimmte Antwort zu bekommen, die zwischen 0 und 1 liegen kann, also mit 0,75 eben 75% SoC entspricht.
Die Anfrage lautet dabei wie folgt:
{ "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
und ausgeschält so
{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }
Mit der id: 2021 wird nur 1 Steuergerät angesprochen, was wir in dieser Liste hier finden können, sobald wir 2021 in das Speicherplatz sparende HEX Format umgewandelt haben, denn der CANBUS wurde in den 80ern entwickelt und Ende der 80er weltweit eingeführt, als Speicher noch sehr teuer war.
Diese Seite konvertiert die dezimal 2021 in den hex Wert von 7E5, den wir nun in zuvor genannter Liste mit STRG + F suchen und das orange markierte Steuergerät finden in der Liste der CU/Control Units.
RANDNOTIZ: zur Unterscheidung werden HEX Zahlen auch häufig 0x vorausgestellt mit 0x7E5, weshalb dann 2021 dezimal sein muss.
Das Resultat spricht Bände, denn ganz oben in der Liste steht "our %cu" und damit zeigt die 1. Spalte die CU = Control Unit Nummer
'8C'=>{hdr=>'7E5', rhdr=>'7ED', fc=>0, desc=>'HV Battery Regulation'}, # +0x08 <
8C ist wieder HEX und steht für 140 HV Battery Regulation oder auch Hochvolt BMS genannt, was noch wichtig werden wird, also merken.
hdr=>'7E5' ist die Adresse, über die man dem Steuergerät 8C "HV battery regulation" eine Frage stellen kann.
Das ist die Sequenz in obiger Anfrage mit "id":2021. Und da wir oben bereits den SoC mit 75% entschlüsseln konnten, stellt sich die Frage, wie das möglich war.
Das verrät uns rhdr=>'7ED', was für dezimal 2029 steht und die Glocken schellen lassen sollte, denn 2 Punkte zuvor wurde nach einer eingehenden Nachricht mit ":2029" gesucht, deren Daten wir dann zur Errechnung des SOC von 75% heranzogen mit
{"id":2029, "dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,179,170,170,170]}, denn ganz am Ende war der SoC doch in der 179 versteckt.
Es ist elementar zu wissen, welches Steuergerät ich wie ansprechen kann und WO / AUF WELCHEM "KANAL" ich eine Antwort zu erwarten habe wie hier beim SOC mit der Anfrage ID 2021, die eine Antwort auf ID 2029 bringen wird. Keine andere Antwort als mit ID 2029 zählt.
Aber wie komme ich nun auf den SOC ?
In der o.g. Liste der Steuergeräte des e-GOLF und auch teils e-Up finden sich darunter eine große Menge an Sensoren bzw. Adressen, wobei die 1. Spalte ja die Adresse des Steuergerätes bzw. CU enthielt, eben besagter 8C oder dezimal 140.
Also suchen wir in der Steuergeräte Liste nun nach "# 8C" (die werden in der Liste alle mit "# "CU Nummer sofort gefunden), dann gibt es dieses Bild
mit u.a. dieser Zeile
SoC_g40=>{cmd=>'22 02 8C', cu=>'8C', desc=>'SoC gross (.40)', unit=>'%', d=>1, formula=>'sprintf("%.2f", V1/2.5)'}, # verified correct, also eGolf
Hier geht es um den "SoC gross .40" des Steuergerätes 8C auch bekannt als SoC_g40
Und um diesen SoC gross .40 als Antwort vom CU 8C zu bekommen muss man welche Frage / Request stellen an welche Adresse stellen ?
Das Steuergerät 8C hat die Empfängeradresse 7E5 und die Absenderadresse 7D5, womit es mit 7E5 in dezimaler Schreibweise 2021 adressiert wird, was im Übrigen mit obeiger Anfrage übereinstimmt.
Und wie man von der Funktion SoC gross des Steuergerät 8C man eine Auskunft bekommt, das verrät der 2. Parameterblock in der obigen Zeile mit '22 02 8C', sobald der in dezimal "34, 2, 140" umgewandelt wurde.
KURZ: Wir fragen "id":2021 nach einer Antwort für "34,2,140"
Und mit einem Blick zurück auf die Anfrage von oben finden wir die 34,2,140 an 2., 3. und 4. Stelle hier wieder [3, 34, 2, 140, 170, 170, 170, 170]
oder in der vollständigen mqtt Anfrage hier. 4 Parameter hierin sind der Schlüssel
{ "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
5. ANFRAGE UND ANTWORT oder REQUEST & REPLY am Beispiel KM STAND aka Odometer
Wenn man weiß, in welchem Steuergerät der Odometer steckt und man die o.g. Zeile beim Beispiel SoC_g40 findet, dann hat man alles, was man braucht.
Und welch ein Zufall findet sich genau 4 Zeilen unter besagtem SoC_g40 diese Zeile
mlg_tot_8C=>{cmd=>'22 02 BD', cu=>'8C', desc=>'odometer', unit=>'km', d=>10, formula=>'U24(V2,V3,V4)'}
wo in der Mitte desc (description = Beschreibung) mit 'odometer' bzw Km Stand sagt, um was es geht und bordintern als mlg_tot_8c bekannt, was für mileage_total steht und zwar aus der Control Unit Cu 8C.
Wenn man den wissen will, so stellt man die gleiche Anfrage wie beim SoC und ändert nur die "Funktionsadresse" ab, die sich hinter 22 02 BD verbirgt,
was dezimal für 34, 2, 189 steht, wo beim SoC noch nach 34,2,140 gefragt worden ist.
SoC: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
KM Stand: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 189, 170, 170, 170, 170] }] }
Zugegeben: Das kann verwirrend und erschlagen wirken, aber hier kann man alles nachlesen und nachvollziehen, statt mit hören sagen Wissen sich zuversuchen, ob ein eGolf wie eUp erreicht werden kann oder nicht.
Alles mehrfach in Ruhe Schritt für Schritt lesen und am Auto nachher per Tablet oder Laptop testen.
6. DER KREIS WIRD GESCHLOSSEN: DER SoC SENSOR WIRD ALLE 6 SEKUNDEN MIT DATEN BELIEFERT SOLANGE ONLINE ERREICHBAR
Hier noch einmal der zu Beginn des EXKURS CANBUS angelegte Sensor "GOLF SoC" und zwar nur die Zeilen zum value_template.
mqtt:
sensor:
- name: "GOLF SoC"
unique_id: "golf_soc"
state_topic: "wican/dongleNummer123/can/rx"
state_class: "measurement"
unit_of_measurement: "%"
value_template: >-
{% if value_json.frame[0].id == 2029 %}
{% set PID = value_json.frame[0].data[3] %}
{% if PID == 140 %}
{% set AA = value_json.frame[0].data[4] %}
{{ AA / 240 * 100 | round(1) }}
{% endif %}
{% endif %}
Wir prüfen nun diesen Code mit Nachricht von oben, wo wir den SoC mit 75% bereits entschlüsseln konnten (Car Scanner geprüft)
{"id":2029, "dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,179,170,170,170]}
und das Zeile für Zeile des value_templates
{% if value_json.frame[0].id == 2029 %}
prüft, ob die eingehende MQTT MESSAGE die id:2029 hat, wie sie die Anfrage 2021 erfordert, sprich: nur 2029 Nachrichten kommen als Antwort in Betracht !
ERGEBNIS: TRUE
{% set PID = value_json.frame[0].data[3] %}
Weist der Variablen PID mit data[3] das 4. Element in der JSON Datenreihe zu, denn das 1. Element wird mit [0] adressiert, womit die [3] das 4. Element meint
PiD 140 meint den SoC
ERGEBNIS: PID = 140
{% if PID == 140 %}
Prüfung, ob die Antwort den SoC in % liefert
ERGEBNIS: TRUE
{% set AA = value_json.frame[0].data[4] %}
Weist AA den Wert des 5. Elements in der JSON Datenreihe mit 179 zu
ERGEBNIS: AA = 179
{{ AA / 240 * 100 | round(1) }}
SoC Berechnung 179 / 240 * 100 = 75,6
Der sensor.golf_soc bekommt den Wert 75,6 und der Sensor kann sobald er vorhanden ist mit % formatiert werde.
IV. WiCAN Dongle KONFIGURATION
Es fehlt noch WiCan Konfiguration
