Seite 25 von 32
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 7:24 pm
von ChristophR
Hallo zut,
mein Dongle kommt in Kürze, ich habe mir daher nochmal mit einem anderen Dongle das Verhalten meiner Alarmanlage angeschaut:
Wenn ein ODB2-Zugriff bei abgeschlossenem Auto erfolgt, legt sie los.
Ausnahme: Kurz nach dem Abschließen, also genau der Moment, wenn der soc_helper den SoC abfragen würde, ist ein ODB2 Zugriff möglich ohne Alarm.
Evtl. auch dauerhaft, wenn dieser ODB2 Zugriff nie unterbrochen wird, das kann ich aber schlecht testen.
Wenn also nach dem Einfahren in mein WLAN, der Dongle sich anmeldet und nach dem Abschließen des Autos sich kurz danach schlafen legt, sollte ich kein Problem haben. So hast Du es ja auch umgesetzt.
Nun ist es bei meinem Fahrzeug so, dass die Bordspannung beim Laden und beim Klimatisieren über 13V steigt, der Dongle also wieder aufwacht.
Nun darf jedoch keine erneute Abfrage erfolgen, da sonst der Alarm loslegt.
Daher nun meine Frage: Was ist der Auslöser der Abfrage im soc_helper, erkennt der den Unterschied zwischen "aus Schlafmodus aufwachen" und dem normalen "Einfahren ins WLAN" ganz zu Beginn?
Ich würde nämlich am liebsten nix am Auto machen lassen wollen, da es ein Firmenfahrzeug ist...
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 8:50 pm
von _daniel
Hallo zut,
ich hab einen ersten Schnelltest gemacht.
mittlerweile gibt es beim WiCAN die Funktion Custom PIDs.
Hier könnte ich eine CAN ID direkt an ein MQTT Topic senden.
Ich habe schon mal in deine Skripte geschaut, komme aber mit der Zuordnung der Paratmeter noch nicht klar.
KAnnst du mir sagen, was ich für den e-Golf SOC hier eintragen muss
- WICAN_CustomPID.PNG (4.83 KiB) 794 mal betrachtet
Auf meinem rpi habe ich nur iobroker laufen, muss mir für python noch einen Container erzeugen und mich dann einarbeiten.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 9:12 pm
von zut
ChristophR hat geschrieben: ↑Di Aug 20, 2024 7:24 pm
Daher nun meine Frage: Was ist der Auslöser der Abfrage im soc_helper, erkennt der den Unterschied zwischen "aus Schlafmodus aufwachen" und dem normalen "Einfahren ins WLAN" ganz zu Beginn?
Wenn man ein Fahrzeug hat, das per UDS kommuniziert, wird der soc_helper immer dann, wenn der WiCAN seinen Status auf online setzt, die Abfragen rausschicken. Das kann auch dann passieren, wenn eine Ladung mangels Sonne abgebrochen wurde und einige Zeit danach wieder startet. Das Fahrzeug lädt dann meiner Erfahrung nach die NV-Batterie und der aktuelle SoC wird abgefragt.
Das sieht nicht so gut aus
- ich wüsste gerade auch nicht, wie man solche Fälle (Ankunft / Abfahrt / Wiederaufwecken) zuverlässig unterscheiden kann. Dazu müsste man die Fahrbereitschaft haben, aber die darf man nicht aktiv abfragen. UDS schickt nichts von alleine. Wenn die Versorgungsspannung der Buchse auf Zündplus (Klemme 15 oder 87) statt Dauerplus (Klemme 30) gelegt würde, ginge es, aber bei Firmenwagen wäre das wohl nicht so gut.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 9:24 pm
von zut
_daniel hat geschrieben: ↑Di Aug 20, 2024 8:50 pm
Hallo zut,
ich hab einen ersten Schnelltest gemacht.
mittlerweile gibt es beim WiCAN die Funktion Custom PIDs.
Hier könnte ich eine CAN ID direkt an ein MQTT Topic senden.
Ich habe schon mal in deine Skripte geschaut, komme aber mit der Zuordnung der Paratmeter noch nicht klar.
KAnnst du mir sagen, was ich für den e-Golf SOC hier eintragen muss
WICAN_CustomPID.PNG
Auf meinem rpi habe ich nur iobroker laufen, muss mir für python noch einen Container erzeugen und mich dann einarbeiten.
Die FIlterfunktion aus Deinem Bild wird vom soc_helper nicht genutzt. Ich bin gerade für eine alte Zoe am entwickeln, die sendet ohne Aufforderung diverse CAN-Werte. Da habe ich einen Filter nutzen lassen, um an zwei SoC-Werte zu kommen, das ist praktisch. Wenn der eGolf sich wie der eUp verhält, kommen an den WiCAN nur nach Aufforderung die interessante Werte.
Bitte achte darauf, die letzte von mir freigegebene Version zu verwenden (für OpenWB2):
https://github.com/DerHerrW/soc_helper/ ... 2024-07-18.
Für den soc_helper bitte keinen Filter definieren, weil dann nichts außerhalb der Kriterien durchkommt. In der Anleitung im Doku-Verzeichnis
https://github.com/DerHerrW/soc_helper/ ... _helper.md ist eigentlich alles beschrieben: Du baust die configuration.py so um, daß statt eUp ein eGolf genutzt wird. Der relevante Abschnitt also im einfachsten Fall ohne Spritmonitor und für die FahrzeugID 0 der OpenWB:
Code: Alles auswählen
myCars.append(cars.eGolf(
name = "Standard", # Name des Fahrzeugs, wie im WiCAN konfiguriert. Definiert einen Zweig unter others/ im MQTT-Broker.
openwbVehicleId = 0 # Fahrzeugnummer in der OpenWB-Konfiguration
))
Ich habe noch keine Rückmeldung vom eGolf - bitte berichte unbedingt (Ich habe bei meinen Recherchen gelernt, daß die Kommunikation wie beim eUp sein soll, daher habe ich die Parameter kopiert)!
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 9:32 pm
von _daniel
Ich wollte customitzed PID testen, um den SoC zu kontrollieren. Ohne den SoC Helper.
Sobald ich dazu komme, folge ich deiner Anleitung, um den SoC Helper zu nutzen.
Ggf. Ist das beim e-Golf etwas komplizierter:
https://github.com/meatpiHQ/wican-fw/issues/168
Korrekturformel:
AA / (250 - 10 - 20) x 100
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 9:48 pm
von zut
Du müsstest eine Möglichkeit haben, einen Custom PID (an CAN ID 2021, Data 3, 34, 2, 140) an das Fahrzeug abzusetzen.
Im MQTT-Explorer: { "bus": "0", "type": "tx", "frame": [{ "id": "2021", "dlc": 8, "rtr": false, "extd": false, "data": "[3,34,2,140,0,0,0,0]"}] } an die entsprechende Stelle im MQTT-Baum (others/wican/golf/can/tx) senden.
Dann sollte die entsprechende Antwort unter rx zu sehen sein.
Für den Filter könntest du probieren:
CAN-ID 2029
Name SoC
PID -1
Start Bit 32
Length 8
Value V/2.5 (nur angenähert)
Die Anfrage oben muss trotzdem ans Fahrzeug. Ich rate von den Filtern ab - der MQTT-Explorer reicht zur Überprüfung aus.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Di Aug 20, 2024 9:57 pm
von ChristophR
zut hat geschrieben: ↑Di Aug 20, 2024 9:12 pm
ChristophR hat geschrieben: ↑Di Aug 20, 2024 7:24 pm
Daher nun meine Frage: Was ist der Auslöser der Abfrage im soc_helper, erkennt der den Unterschied zwischen "aus Schlafmodus aufwachen" und dem normalen "Einfahren ins WLAN" ganz zu Beginn?
Wenn man ein Fahrzeug hat, das per UDS kommuniziert, wird der soc_helper immer dann, wenn der WiCAN seinen Status auf online setzt, die Abfragen rausschicken. Das kann auch dann passieren, wenn eine Ladung mangels Sonne abgebrochen wurde und einige Zeit danach wieder startet. Das Fahrzeug lädt dann meiner Erfahrung nach die NV-Batterie und der aktuelle SoC wird abgefragt.
Das sieht nicht so gut aus
- ich wüsste gerade auch nicht, wie man solche Fälle (Ankunft / Abfahrt / Wiederaufwecken) zuverlässig unterscheiden kann. Dazu müsste man die Fahrbereitschaft haben, aber die darf man nicht aktiv abfragen. UDS schickt nichts von alleine. Wenn die Versorgungsspannung der Buchse auf Zündplus (Klemme 15 oder 87) statt Dauerplus (Klemme 30) gelegt würde, ginge es, aber bei Firmenwagen wäre das wohl nicht so gut.
Ein paar Hersteller, darunter auch VW legen auf PIN1 des ODB2-Steckers, der in der Norm frei definierbar ist, Zündplus:
https://www.flexihub.com/de/oobd2-pinout/#volkswagen
Vielleicht kann man das im WiCAN Dongle umverkabeln? Dann geht es ohne Eingriff ins Fahrzeug.
Schaue ich mir mal an, wenn der Dongle da ist.
Dann muss die SoC-Abfrage nur fertig sein, bevor ich den "Motor" ausmache, das sollte aber m.E. reichen.
Edit:
Ich habe tatsächlich auf PIN1 Zündungsplus.
Wenn alles läuft werde ich das ggf. mit einem Adapter umbauen, dann bleibt auch der Dongle ganz.
Nur fraglich, ob der das so toll findet ständig abgeschaltet zu werden...
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Do Aug 22, 2024 1:32 pm
von ChristophR
Hallo Zut,
ich habe es fast geschafft, den soc_helper in Betrieb zu nehmen, ich denke der soc_helper macht alles richtig, aber der wican sendet den tx frame nicht raus, oder erhält keinen rx frame zurück. Wo ich das protokollieren könnte, habe ich leider nicht gefunden.
Was ich gemacht habe:
1. In einer openWB (erstmal eine Test-VM), habe ich ein Fahrzeug und einen Ladepunkt angelegt, das Fahrzeug mit manuellem SoC.
Hinweis: Man muss einmal einen manuellen SoC <> 0 eingeben, sonst kann der soc_helper den "alten" SoC nicht auslesen und bringt eine Fehlermeldung, da er die Daten nicht konvertieren kann (Float oder so).
2. Konfiguration der Daten im wican nach bestem Wissen und Gewissen vorgenommen.
3. Dongle meldet status=online
4. soc_helper gestartet.
Im MQTT Broker der Wallbox sieht man das topic für den Status, sowie das für den tx-Frame, den der soc_helper artig sendet.
Es kommt jedoch kein rx-Frame zurück, warum auch immer, den MQTT Topic für´s tx habe ich mit der Konfiguration im wican verglichen, der passt...
Hast Du eine Idee, wo man nun suchen könnte?
Edit: Lag am Auto, jetzt klappt es.
Nun kommt noch der Test der Alarmanlage dran
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Do Aug 22, 2024 2:02 pm
von _daniel
zut hat geschrieben: ↑Di Aug 20, 2024 9:48 pm
Im MQTT-Explorer: { "bus": "0", "type": "tx", "frame": [{ "id": "2021", "dlc": 8, "rtr": false, "extd": false, "data": "[3,34,2,140,0,0,0,0]"}] } an die entsprechende Stelle im MQTT-Baum (others/wican/golf/can/tx) senden.
Dann sollte die entsprechende Antwort unter rx zu sehen sein.
Ich habe im MQTT Explorer getest und das Paket manuell abgesendet.
Im RX kommt zunächst nichts und nach ca. 15min ein Bulk an Antworten zurück:
{"bus":"0","type":"rx","ts":17504,"frame":[{"id":401604624,"dlc":8,"rtr":false,"extd":true,"data":32,16,0,0,0,0,0,0]}]}
wie kann ich das in den SOC zurück rechnen?
In deinem Sript finde ich folgende Formel: round((bytes[4]/2.5-8)/0.88)
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Verfasst: Do Aug 22, 2024 7:06 pm
von zut
_daniel hat geschrieben: ↑Do Aug 22, 2024 2:02 pm
Ich habe im MQTT Explorer getest und das Paket manuell abgesendet.
Im RX kommt zunächst nichts und nach ca. 15min ein Bulk an Antworten zurück:
{"bus":"0","type":"rx","ts":17504,"frame":[{"id":401604624,"dlc":8,"rtr":false,"extd":true,"data":32,16,0,0,0,0,0,0]}]}
wie kann ich das in den SOC zurück rechnen?
Vermutlich gar nicht. Die Nachricht stammt von einem mir nicht bekannten Steuergerät: Die ID ist extended (extd:True) mit einer 29-Bit-ID. Darin ist mit einiger Sicherheit kein SoC enthalten. In meinem Verbrenner-Golf habe ich diese periodische Botschaft auch. Falls das eine UDS-Antwort ist, bedeutet sie, daß es ein Folgeteil einer mehrteiligen Botschaft ist. Ich habe aber noch nie einen ersten Teil dazu gesehen. Also einfach ignorieren.
_daniel hat geschrieben: ↑Do Aug 22, 2024 2:02 pm
In deinem Sript finde ich folgende Formel: round((bytes[4]/2.5-8)/0.88)
WICAN_MQTTExplorer_Test.png
Das ist die Formel, die ich in anderen Projekten gefunden habe. Das ist aber nachrangig, solange du nicht die richtige Antwort bekommst. Erstmal muss was zum Umrechnen kommen.
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]}] }
Zuletzt:
Deinem Bild nach sind die Can-Pfade für den soc_helper im WiCAN falsch definiert. im WiCAN muß others/wican/<name>/can/tx bzw. rx definiert sein, mit can! Aufpassen: Der Status ist ohne can im Pfad. Siehe
https://github.com/DerHerrW/soc_helper/ ... ttings.png
