Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
-
- Beiträge: 237
- Registriert: Mo Mai 10, 2021 10:07 pm
- Has thanked: 24 times
- Been thanked: 4 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Vielen Dank für die Rückmeldung!
Zu 1)
Die /2,5 sind dann in jedem Fall in Stein gemeißelt.
Was ich schon einmal sagen kann:
Wende ich bei einem BMS-SOC von 96,8 % den Faktor 51/46 an und subtrahiere 6,4, komme ich auf 100,92.
Das deckt sich mit der Anzeige von Car Scanner.
Ich werde trotzdem das Ganze bei einem geringeren SoC verifizieren, um sicher zu gehen, dass der lineare Zusammenhang im Skript auch auf mein Auto zutrifft und hier Rückmeldung geben.
Ob Car Scanner den Anzeige-SOC nur berechnet, kann ich nicht mit Gewissheit sagen, aber ich glaube eher nicht, da er unter Sensoren auftaucht, wo auch alle möglichen anderen Messkanäle aufgelistet sind.
Hier geht es aber nur um ein Detail, das nicht kriegsentscheidend sind.
Zu 2)
Ja, ich stimme zu, es wäre heikel, den WiCAN wach zu lassen, wenn der DC/DC inkativ ist und das 12-V-Netz somit nicht aus HV versorgt wird.
Weiß jemand, wie der Stromverbrauch vom WiCAN im Schlaf- und im Wachmodus ist?
Ich werde das noch einmal verifizieren, aber ich bin der Meinung, dass während des Ladens der DC/DC bei mir (MEB) aktiv bleibt/wird, so dass der WiCAN nicht schlafen gehen sollte bzw. morgens, wenn die PV-Ladung beginnt, aufwacht.
Insofern wäre dann eine kontinuierliche SOC-Übermittlung ganz nett, da die Modellierung über Batteriekapazität und Ladewirkungsgrad in der openWB nie exakt sein kann.
Auch das fällt eher in die Kategorie nice-to-have. Denn ich muss ja mit Zielladen nicht unbedingt auf z.B. exakt 60 % zur Abfahtszeit kommen. Wenn es 59 oder 61 % sind, ist es auch ok.
Wichtig ist, dass am Vorabend bei der Garageneinfahrt der SOC von z.B. 20 % an die openWB übertragen wurde.
PS:
Die Antworten auf Deine anderen Fragen zu 3) und 4) reiche ich noch nach.
Zu 1)
Die /2,5 sind dann in jedem Fall in Stein gemeißelt.
Was ich schon einmal sagen kann:
Wende ich bei einem BMS-SOC von 96,8 % den Faktor 51/46 an und subtrahiere 6,4, komme ich auf 100,92.
Das deckt sich mit der Anzeige von Car Scanner.
Ich werde trotzdem das Ganze bei einem geringeren SoC verifizieren, um sicher zu gehen, dass der lineare Zusammenhang im Skript auch auf mein Auto zutrifft und hier Rückmeldung geben.
Ob Car Scanner den Anzeige-SOC nur berechnet, kann ich nicht mit Gewissheit sagen, aber ich glaube eher nicht, da er unter Sensoren auftaucht, wo auch alle möglichen anderen Messkanäle aufgelistet sind.
Hier geht es aber nur um ein Detail, das nicht kriegsentscheidend sind.
Zu 2)
Ja, ich stimme zu, es wäre heikel, den WiCAN wach zu lassen, wenn der DC/DC inkativ ist und das 12-V-Netz somit nicht aus HV versorgt wird.
Weiß jemand, wie der Stromverbrauch vom WiCAN im Schlaf- und im Wachmodus ist?
Ich werde das noch einmal verifizieren, aber ich bin der Meinung, dass während des Ladens der DC/DC bei mir (MEB) aktiv bleibt/wird, so dass der WiCAN nicht schlafen gehen sollte bzw. morgens, wenn die PV-Ladung beginnt, aufwacht.
Insofern wäre dann eine kontinuierliche SOC-Übermittlung ganz nett, da die Modellierung über Batteriekapazität und Ladewirkungsgrad in der openWB nie exakt sein kann.
Auch das fällt eher in die Kategorie nice-to-have. Denn ich muss ja mit Zielladen nicht unbedingt auf z.B. exakt 60 % zur Abfahtszeit kommen. Wenn es 59 oder 61 % sind, ist es auch ok.
Wichtig ist, dass am Vorabend bei der Garageneinfahrt der SOC von z.B. 20 % an die openWB übertragen wurde.
PS:
Die Antworten auf Deine anderen Fragen zu 3) und 4) reiche ich noch nach.
-
- Beiträge: 237
- Registriert: Mo Mai 10, 2021 10:07 pm
- Has thanked: 24 times
- Been thanked: 4 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Zu 1)
Zur Info zwei Screenshots aus Car Scanner: Die Anzeige im KI war aber 62 %.
Zu 2)
Mir scheint es so, als ob das 12-V-Netz während des Ladens mit 13,5 V betrieben wird. Ist das Laden beendet, geht die Spannung schnell unter 13,5 V.
Zur Info zwei Screenshots aus Car Scanner: Die Anzeige im KI war aber 62 %.
Zu 2)
Mir scheint es so, als ob das 12-V-Netz während des Ladens mit 13,5 V betrieben wird. Ist das Laden beendet, geht die Spannung schnell unter 13,5 V.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Falls du für MEB die OBD2-Daten für die Ausgabe des angezeigten SOCs findest, baue ich die gerne ein. Ich habe sowohl bei evDash als auch EVNotify nur einen aus dem Roh-SOC berechneten SOC gefunden. Für den eUp habe ich noch ein paar Kandidaten hier: https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG01 Die überprüfung hat bei mir aber nicht die höchste Priorität. Was mag wohl die "Restlaufzeit der Fahrbatterie" in % sein?mattberlin hat geschrieben: ↑Do Jun 20, 2024 9:41 pm Zu 1)
Zur Info zwei Screenshots aus Car Scanner:
Screenshot_20240620_182045.jpg
Screenshot_20240620_181926.jpg
Die Anzeige im KI war aber 62 %.
Für meinen eUp hatte ich gestern das folgende (habe ein wenig mit CarScanner gespielt):mattberlin hat geschrieben: ↑Do Jun 20, 2024 9:41 pm Zu 2)
Mir scheint es so, als ob das 12-V-Netz während des Ladens mit 13,5 V betrieben wird. Ist das Laden beendet, geht die Spannung schnell unter 13,5 V.
Code: Alles auswählen
2024-06-20 11:26:08,110; INFO;[ soc_helper.py:258 - cb_status() ] WiCAN-Status: others/wican/nulli/status b'{"status": "online"}'
2024-06-20 11:26:08,111; INFO;[ soc_helper.py:264 - cb_status() ] Fahrzeug ist online. Sende SOC- und ODO-Anforderung
2024-06-20 11:26:08,111; INFO;[ soc_helper.py:267 - cb_status() ] Sende SOC-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
2024-06-20 11:26:08,112; INFO;[ soc_helper.py:271 - cb_status() ] Sende ODO-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 189, 170, 170, 170, 170] }] }
2024-06-20 11:26:08,158; INFO;[ soc_helper.py:351 - cb_rx() ] Fahrzeug-SOC ist 43
2024-06-20 11:26:08,202; INFO;[ soc_helper.py:361 - cb_rx() ] Fahrzeug-Kilometerstand ist 11748
2024-06-20 11:31:11,369; WARNING;[ soc_helper.py:363 - cb_rx() ] Empfangene Botschaft: [2029, 65, 0, 152, 24, 0, 1, 170] ist keine gültige Antwort auf eine konfigurierte Anfrage
2024-06-20 11:31:12,189; WARNING;[ soc_helper.py:363 - cb_rx() ] Empfangene Botschaft: [2029, 65, 0, 152, 24, 0, 1, 170] ist keine gültige Antwort auf eine konfigurierte Anfrage
2024-06-20 11:31:12,920; WARNING;[ soc_helper.py:363 - cb_rx() ] Empfangene Botschaft: [2029, 65, 32, 0, 0, 0, 1, 170] ist keine gültige Antwort auf eine konfigurierte Anfrage
[...]
2024-06-20 11:37:33,432; WARNING;[ soc_helper.py:363 - cb_rx() ] Empfangene Botschaft: [2029, 65, 12, 0, 0, 170, 170, 170] ist keine gültige Antwort auf eine konfigurierte Anfrage
2024-06-20 11:37:34,102; WARNING;[ soc_helper.py:363 - cb_rx() ] Empfangene Botschaft: [2029, 65, 13, 255, 170, 170, 170, 170] ist keine gültige Antwort auf eine konfigurierte Anfrage
2024-06-20 11:37:34,785; WARNING;[ soc_helper.py:363 - cb_rx() ] Empfangene Botschaft: [2029, 65, 1, 0, 4, 0, 0, 170] ist keine gültige Antwort auf eine konfigurierte Anfrage
2024-06-20 11:38:22,612; INFO;[ soc_helper.py:258 - cb_status() ] WiCAN-Status: others/wican/nulli/status b'{"status": "offline"}'
2024-06-20 11:38:22,612; INFO;[ soc_helper.py:274 - cb_status() ] Fahrzeugstatus ist <<offline>>
Ich kann mir vorstellen, daß das ICAS (EV-Steuergerät) im MEB einen hohen Stromverbrauch hat und der DC/DC-Wandler ständig an ist, aber das ist nicht für jedes Fahrzeug gegeben.
Es wäre andererseits wohl auch nicht zu schwer, alle 60s ohne Rücksicht auf den WiCAN-Status in einer Endlosschleife nach dem Ladestand zu fragen. Muss ich mal drüber nachdenken. Gerade versuche ich, den soc_helper komplett zu überarbeiten (ist für mich schließlich ein python-Lernprojekt. Ziel ist, eine beliebige Anzahl von Fahrzeugen mit WiCANs sowie Ladepunkte bedienen zu können)
-
- Beiträge: 237
- Registriert: Mo Mai 10, 2021 10:07 pm
- Has thanked: 24 times
- Been thanked: 4 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Ich habe beim WiCAN 13,4 V eingestellt und habe bis jetzt während des Ladens stets Zugriff (Web-Interface des WiCAN) gehabt. Eben war während des Ladens 14,3 V. Ich vermute aber, dass bei voller 12-V-Batterie auf 13,5 V reduziert wird.
Das blöde ist, dass bei z.B. Car Scanner nicht angezeigt wird, wo die Daten herkommen
Insgesamt muss ich sagen, dass es schon echt gut funktioniert, wie es jetzt ist.
Vorhin wurde die PV-Ladung (nach Regenpause) fortgesetzt, d.h. WiCAN wacht auf und der (leicht abweichende) berechnete SoC der openWB wird durch den frisch ausgelesenen überschreiben.
--> PERFEKT!!!
Ich bin dennoch sehr gespannt, wie sich der SOC_Helper entwickelt und test gerne.
Das blöde ist, dass bei z.B. Car Scanner nicht angezeigt wird, wo die Daten herkommen
Insgesamt muss ich sagen, dass es schon echt gut funktioniert, wie es jetzt ist.
Vorhin wurde die PV-Ladung (nach Regenpause) fortgesetzt, d.h. WiCAN wacht auf und der (leicht abweichende) berechnete SoC der openWB wird durch den frisch ausgelesenen überschreiben.
--> PERFEKT!!!
Ich bin dennoch sehr gespannt, wie sich der SOC_Helper entwickelt und test gerne.
-
- Beiträge: 237
- Registriert: Mo Mai 10, 2021 10:07 pm
- Has thanked: 24 times
- Been thanked: 4 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Du hast Recht, ich habe natürlich unter Windows entpackt.zut hat geschrieben: ↑Mi Jun 19, 2024 8:29 pmMöglicherweise hast du die zip-Datei unter Windows ausgepackt? Dann ist vermutlich das Executable-Bit der Date soc_helper.py nicht gesetzt. Du kannst mal einmattberlin hat geschrieben: ↑Di Jun 18, 2024 9:28 pm 3) Ausführung SOC-Helper
Ich weiß nicht, ob ich ggf. eine andere Version habe, aber der Start von SOC-Helper in der Konsole geht bei mir nicht mit "~/soc_helper$ ./soc_helper.py"
Aber mit "python soc_helper.py" geht es.ausführen und die Ausgabe hier posten. Wenn keine x zu sehen sind wie hier:Code: Alles auswählen
ls -l
, dann bitte malCode: Alles auswählen
-rwxr-xr-x 1 pi pi 20577 18. Jun 08:02 soc_helper.py
absetzen und schauen, ob es danach geht. Siehe auch https://wiki.ubuntuusers.de/chmod/. Oder du hast eine Distribution verwendet, die auf die erste Zeile (#!/usr/bin/env) nicht anspringt. Gibt es eine aussagekräftige Fehlermeldung? Welche Distribution verwendest Du?Code: Alles auswählen
chmod 755 soc_helper.py
Code: Alles auswählen
ls -l
Code: Alles auswählen
-rw-r--r-- 1 matthias matthias 20577 Jun 18 10:02 soc_helper.py
Code: Alles auswählen
chmod 755 soc_helper.py
Code: Alles auswählen
-rwxr-xr-x 1 matthias matthias 20577 Jun 18 10:02 soc_helper.py
Code: Alles auswählen
./soc_helper.py
Als OS verwende ich das, was mit dem Raspberry Pi Imager erstellt wurde auf einem Pi 3 Model B. Ich habe sogar die GUI mit installiert, aber aktuell nutze ich sie nicht und arbeite mit SSH, welches es im Pi natürlich aktivieren braucht, und PuTTY.
Vielen Dank für den Tipp!Prozess mit "ps ax" in der Ausgabe entdecken. Bevor du soc_helper neu startest, muß dieser prozess mit pkill -f soc_helper beendet werden, sonst sind zwei soc_helper gleichzeitig am Start...
Ist das nicht der elegantere Weg als das, was in der Hilfe unter "Stoppen eines im Hintergrund laufenden soc_helper" beschrieben ist?
EDIT: Wer lesen kann, ist klar im Vorteil. Weiter unter steht ja in Deiner Hilfe
Code: Alles auswählen
pi@pi4:~$ pkill -f soc_helper.py
Bleibt mir noch das Autostart-Thema
-
- Beiträge: 237
- Registriert: Mo Mai 10, 2021 10:07 pm
- Has thanked: 24 times
- Been thanked: 4 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
So, jetzt muss ich noch einmal weiterspamen:
Ich bin auf https://www.instructables.com/Raspberry ... n-startup/ gestoßen:
1. mit nano eine Datei angelegt.
2. Inhalt von autostart.sh:
3.
4. Dann Ausführung mit , wobei ich irgendwelche Meldungen mit Access denied hatte
5. Lesen von https://www.shells.com/l/en-US/tutorial ... r-in-Linux
-->
6.
7. Dort steht nun:
Beim Start des Raspberry Pi wird nun der soc_helper ausgeführt.
@zut
Womöglich fällt Dir etwas Eleganteres ein.
Ich bin auf https://www.instructables.com/Raspberry ... n-startup/ gestoßen:
1. mit nano
Code: Alles auswählen
autostart.sh
2. Inhalt von autostart.sh:
Code: Alles auswählen
cd /
cd home/meinname/soc_helper
nohup ./soc_helper.py
Code: Alles auswählen
chmod 755 autostart.sh
Code: Alles auswählen
sh autostart.sh
5. Lesen von https://www.shells.com/l/en-US/tutorial ... r-in-Linux
-->
Code: Alles auswählen
sudo chmod +x autostart.sh
Code: Alles auswählen
sudo crontab -e
Code: Alles auswählen
@reboot sh /home/meinname/autostart.sh
@zut
Womöglich fällt Dir etwas Eleganteres ein.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Hallo,
zunächst möchte ich mich bei Allen für die bisher geleistete Arbeit bedanken und anschließend auch noch mein learning-by-doing Wissen einstreuen.
Nun ist auch endlich mein meatPi WiCAN eingetroffen und ich habe es geschafft ihn einzurichten. Bisher läuft das System top. Danke nochmals.
Meine Randbedingungen:
* openwb 2.1.4
* meatPi WiCAN OBD
* debian 12 Container auf einem Proxmox
Die Anleitungen finde ich etwas verstreut als "README.txt" und "Doku/Inbetriebnahme soc_helper.html". Hier mein Tipp: Meistens werden solche Projekte in irgendeinem Git-Repository gehostet. Die Weböberflächen unterstützen dabei in der Regel Markdown-Dateien. Das sind eigentlich nur Text-Dateien, die einem bestimmten Syntax folgen und daher von den Weböberflachen, als auch z.B. von VScode gerendert werden können und dadurch sowohl in der reinen Textform gut lesbar und editierbar sind sowie viele Funktionalitäten (Überschriften, Absätze, Links, Bilder, Codeschnipsel, etc..) unterstützt werden und in der gerenderten Form sehr schön anzusehen sind.
Wenn gewünscht kann ich auch gerne mal die vorhandenen Anleitungen zu Markdown überführen.
Sicher gibt es viele Wege das Skript automatisch laufen zu lassen, aber ich finde die als Dienst immer recht elegant. In meinem Fall (Debian 12) bin ich dafür nach folgender Anleitung vorgegangen: https://www.thomaschristlieb.de/ein-pyt ... nicht-weh/
Allgemeine Hinweise zu den genutzten Befehlen, mein Benutzer ist kein Admin, damit Befehle die Admin-Rechte benötigen mit entsprechenden Rechten ausgeführt werden können, werden diese daher mit vorangestelltem "sudo" ausgeführt.
1. Skript ausführbar machen:
2. Service-Datei anlegen und im Editor (Nano) öffnen
3. folgenden anzupassenden Inhalt in die Datei einfügen
<BENUTZER> durch den Benutzernamen ersetzen unter dem der Service laufen sollte, am besten ein Benutzer mit eingeschränkten Rechten, nicht root
<PFAD> durch den absoluten Pfad zum soc_helper-Ordner ersetzen
4. Service Daemon neustarten, damit die Datei eingelesen wird
Nun ist der Dienst bereits fertig eingerichtet, läuft aber noch nicht.
5. Dienst starten und aktivieren
"enable" aktiviert den Dienst, das heißt beim nächsten Systemstart wird der Dienst automatisch gestartet
"start" startet den Dienst einmalig
Nun läuft der Dienst auch und startet beim nächsten Systemstart wieder.
Weitere nützliche Befehle zum Dienst
Status des Dienstes abfragen
Dienst stoppen
Dienst neustarten
Log ausgeben
Nun habe ich auch noch eine Frage:
Wie habt Ihr den OBD-Dongle im Fussraum angebracht?
Meiner steckt bisher einfach nur in der OBD-Buchse. Mir gefällt das aber nicht so gut, da man da mit dem Fuss unbeabsichtigt gegentreten könnte und der vermutlich beim nächsten Werkstatt-Termin rausgezogen wird und im schlechtesten Fall vergessen wird den wieder reinzustecken. Ich habe mir daher bereits ein OBD-Y-Kabel bestellt und überlege nun wie und wo ich den Dongle befestigen könnte.
Grüße Matthias
zunächst möchte ich mich bei Allen für die bisher geleistete Arbeit bedanken und anschließend auch noch mein learning-by-doing Wissen einstreuen.
Nun ist auch endlich mein meatPi WiCAN eingetroffen und ich habe es geschafft ihn einzurichten. Bisher läuft das System top. Danke nochmals.
Meine Randbedingungen:
* openwb 2.1.4
* meatPi WiCAN OBD
* debian 12 Container auf einem Proxmox
Die Anleitungen finde ich etwas verstreut als "README.txt" und "Doku/Inbetriebnahme soc_helper.html". Hier mein Tipp: Meistens werden solche Projekte in irgendeinem Git-Repository gehostet. Die Weböberflächen unterstützen dabei in der Regel Markdown-Dateien. Das sind eigentlich nur Text-Dateien, die einem bestimmten Syntax folgen und daher von den Weböberflachen, als auch z.B. von VScode gerendert werden können und dadurch sowohl in der reinen Textform gut lesbar und editierbar sind sowie viele Funktionalitäten (Überschriften, Absätze, Links, Bilder, Codeschnipsel, etc..) unterstützt werden und in der gerenderten Form sehr schön anzusehen sind.
Wenn gewünscht kann ich auch gerne mal die vorhandenen Anleitungen zu Markdown überführen.
Sicher gibt es viele Wege das Skript automatisch laufen zu lassen, aber ich finde die als Dienst immer recht elegant. In meinem Fall (Debian 12) bin ich dafür nach folgender Anleitung vorgegangen: https://www.thomaschristlieb.de/ein-pyt ... nicht-weh/
Allgemeine Hinweise zu den genutzten Befehlen, mein Benutzer ist kein Admin, damit Befehle die Admin-Rechte benötigen mit entsprechenden Rechten ausgeführt werden können, werden diese daher mit vorangestelltem "sudo" ausgeführt.
1. Skript ausführbar machen:
Code: Alles auswählen
chmod +x ./soc_helper/soc_helper.py
Code: Alles auswählen
sudo nano /etc/systemd/system/sochelper.service
<BENUTZER> durch den Benutzernamen ersetzen unter dem der Service laufen sollte, am besten ein Benutzer mit eingeschränkten Rechten, nicht root
<PFAD> durch den absoluten Pfad zum soc_helper-Ordner ersetzen
Code: Alles auswählen
[Unit]
Description=SoC Helper
After=syslog.target
[Service]
Type=simple
User=<BENUTZER>
Group=<BENUTZER>
WorkingDirectory=<PFAD>/soc_helper
ExecStart=<PFAD>/soc_helper/soc_helper.py
SyslogIdentifier=sochelper
StandardOutput=syslog
StandardError=syslog
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
Code: Alles auswählen
sudo systemctl daemon-reload
5. Dienst starten und aktivieren
"enable" aktiviert den Dienst, das heißt beim nächsten Systemstart wird der Dienst automatisch gestartet
"start" startet den Dienst einmalig
Code: Alles auswählen
sudo systemctl enable sochelper
sudo systemctl start sochelper
Weitere nützliche Befehle zum Dienst
Status des Dienstes abfragen
Code: Alles auswählen
sudo systemctl status sochelper
Code: Alles auswählen
sudo systemctl stop sochelper
Code: Alles auswählen
sudo systemctl restart sochelper
Code: Alles auswählen
sudo journalctl -u sochelper
Wie habt Ihr den OBD-Dongle im Fussraum angebracht?
Meiner steckt bisher einfach nur in der OBD-Buchse. Mir gefällt das aber nicht so gut, da man da mit dem Fuss unbeabsichtigt gegentreten könnte und der vermutlich beim nächsten Werkstatt-Termin rausgezogen wird und im schlechtesten Fall vergessen wird den wieder reinzustecken. Ich habe mir daher bereits ein OBD-Y-Kabel bestellt und überlege nun wie und wo ich den Dongle befestigen könnte.
Grüße Matthias
Wechselrichter: Fronius Symo 5.0-3-M
Smartmeter: Fronius Smart Meter TS 65A-3
Wallbox: openWB series2 custom
Fahrzeug: Volkswagen e-up!
Smartmeter: Fronius Smart Meter TS 65A-3
Wallbox: openWB series2 custom
Fahrzeug: Volkswagen e-up!
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Mir fallen gerade noch zwei Sachen ein, die ich im vorherigen Post vergessen habe.
1. Skript in die openWB integrieren
Sicher ist euch der Gedanke auch schon gekommen, aber ich möchte es dennoch hier ansprechen. Es wäre mega wenn man das Skript direkt in die Software der openWB integrieren könnte, dann bräuchte man dafür keine extra Hardware. Keine Ahnung was dazu nötig wäre und ob man da irgendwie unterstützen könnte, z.B. als Tester oder mit dummen Kommentaren oder so
2. Wissen zum Thema UDS
Wenn ich das Skript richtig interpretiere werden die Daten mittels UDS-Diagnoseabfrage ermittelt. Eleganter finde ich es wenn die Daten einfach nur als CAN-Botschaften mitgelesen werden, dann müsste man die Abfrage nicht triggern. Aber keine Ahnung ob VW da was auf dem OBD-Port direkt ausgibt oder es nur den Weg über die Diagnoseabfragen gibt.
Ich fand um die Systeme zu verstehen das folgende Dokument recht hilfreich: http://www.emotive.de/documents/Webcast ... okolle.pdf
Grüße
1. Skript in die openWB integrieren
Sicher ist euch der Gedanke auch schon gekommen, aber ich möchte es dennoch hier ansprechen. Es wäre mega wenn man das Skript direkt in die Software der openWB integrieren könnte, dann bräuchte man dafür keine extra Hardware. Keine Ahnung was dazu nötig wäre und ob man da irgendwie unterstützen könnte, z.B. als Tester oder mit dummen Kommentaren oder so
2. Wissen zum Thema UDS
Wenn ich das Skript richtig interpretiere werden die Daten mittels UDS-Diagnoseabfrage ermittelt. Eleganter finde ich es wenn die Daten einfach nur als CAN-Botschaften mitgelesen werden, dann müsste man die Abfrage nicht triggern. Aber keine Ahnung ob VW da was auf dem OBD-Port direkt ausgibt oder es nur den Weg über die Diagnoseabfragen gibt.
Ich fand um die Systeme zu verstehen das folgende Dokument recht hilfreich: http://www.emotive.de/documents/Webcast ... okolle.pdf
Grüße
Wechselrichter: Fronius Symo 5.0-3-M
Smartmeter: Fronius Smart Meter TS 65A-3
Wallbox: openWB series2 custom
Fahrzeug: Volkswagen e-up!
Smartmeter: Fronius Smart Meter TS 65A-3
Wallbox: openWB series2 custom
Fahrzeug: Volkswagen e-up!
-
- Beiträge: 237
- Registriert: Mo Mai 10, 2021 10:07 pm
- Has thanked: 24 times
- Been thanked: 4 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Erst einmal vielen Dank für die Dienst-Anleitung!
Für Dummis:
Was ist der Vorteil, es über den Dienst zu machen statt über das Autostart, wie ich es umgesetzt habe?
Hat man eine Verkleidung oberhalb der Pedale, würde ich diese entfernen und den WiCAN dort auch irgendwie fixieren.
Von dort aus gehe ich mit einem kurzen Kabel mit abgewinkelten Steckern (zut hatte mich darauf aufmerksam gemacht) zur OBD-Buche.
Erst einmal vielen Dank für die Dienst-Anleitung!
Noch schöner wäre, wenn das flache Kabel auf der anderen Seite abgehen würde - so ein Kabel habe ich aber nicht gefunden . Das Kabel ist jedenfalls zum WiCAN an mehreren Stellen an einem Kabelbaum fixiert.
Im Fußraum steht es nun minimal raus UND (ganz wichtig) man kann den Stecker relativ einfach rausziehen, um ein anderes Gerät heranzustecken.
Mit solchen Y-Kabeln habe ich noch nicht gearbeitet.
Kann man wirklich zwei OBD-Geräte (WiCAN und z.B. einen ELM327 (für Fahrzeugdaten auf dem Handy während der Fahrt) gleichzeitig betreiben?
Für Dummis:
Was ist der Vorteil, es über den Dienst zu machen statt über das Autostart, wie ich es umgesetzt habe?
Steckt man bei mir den Kopf in den Fußraum, hat man "freie Sicht" nach oben, d.h. es ist oberhalb der Pedale keine Verkleidung. Dort habe ich den WiCAN mit Kabelbindern an einem Kabelbaum befestigt.Wie habt Ihr den OBD-Dongle im Fussraum angebracht?
Meiner steckt bisher einfach nur in der OBD-Buchse. Mir gefällt das aber nicht so gut, da man da mit dem Fuss unbeabsichtigt gegentreten könnte und der vermutlich beim nächsten Werkstatt-Termin rausgezogen wird und im schlechtesten Fall vergessen wird den wieder reinzustecken. Ich habe mir daher bereits ein OBD-Y-Kabel bestellt und überlege nun wie und wo ich den Dongle befestigen könnte.
Hat man eine Verkleidung oberhalb der Pedale, würde ich diese entfernen und den WiCAN dort auch irgendwie fixieren.
Von dort aus gehe ich mit einem kurzen Kabel mit abgewinkelten Steckern (zut hatte mich darauf aufmerksam gemacht) zur OBD-Buche.
Erst einmal vielen Dank für die Dienst-Anleitung!
Noch schöner wäre, wenn das flache Kabel auf der anderen Seite abgehen würde - so ein Kabel habe ich aber nicht gefunden . Das Kabel ist jedenfalls zum WiCAN an mehreren Stellen an einem Kabelbaum fixiert.
Im Fußraum steht es nun minimal raus UND (ganz wichtig) man kann den Stecker relativ einfach rausziehen, um ein anderes Gerät heranzustecken.
Mit solchen Y-Kabeln habe ich noch nicht gearbeitet.
Kann man wirklich zwei OBD-Geräte (WiCAN und z.B. einen ELM327 (für Fahrzeugdaten auf dem Handy während der Fahrt) gleichzeitig betreiben?