openWB Forum

Verfasst: **Do Jun 20, 2024 3:13 pm**

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.

Verfasst: **Do Jun 20, 2024 9:41 pm**

Zu 1)
Zur Info zwei Screenshots aus Car Scanner:

Screenshot_20240620_182045.jpg: (141.71 KiB) Noch nie heruntergeladen

Screenshot_20240620_181926.jpg: (265.91 KiB) Noch nie heruntergeladen

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.

Verfasst: **Fr Jun 21, 2024 11:19 am**

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 %.

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 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.

Für meinen eUp hatte ich gestern das folgende (habe ein wenig mit CarScanner gespielt):

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>>

Das zeigt mir, daß 12 Minuten nach dem Ankommen (und etwa 11 Minuten nach Ladebeginn) der DC/DC-Wandler das Laden eingestellt hat - vermutlich war die 12V-Batterie voll genug. Das Fahrzeug hat dann noch etwa 3h weitergeladen.
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)

Verfasst: **Fr Jun 21, 2024 11:27 am**

Gibt es eigentlich einen Zoe-Besitzer, der Interesse an dieser Lösung hat? Für eine Umsetzung brauche ich einen Tester.

Verfasst: **Fr Jun 21, 2024 1:38 pm**

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.

Verfasst: **Fr Jun 21, 2024 5:22 pm**

zut hat geschrieben: ↑Mi Jun 19, 2024 8:29 pm
mattberlin 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.
Mö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 ein
Code: Alles auswählen
ls -l
ausführen und die Ausgabe hier posten. Wenn keine x zu sehen sind wie hier:
Code: Alles auswählen
-rwxr-xr-x 1 pi pi  20577 18. Jun 08:02 soc_helper.py
, dann bitte mal
Code: Alles auswählen
chmod 755 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?

Du hast Recht, ich habe natürlich unter Windows entpackt.

Code: Alles auswählen

ls -l

führt zu

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

führt zu

Code: Alles auswählen

-rwxr-xr-x 1 matthias matthias  20577 Jun 18 10:02  soc_helper.py

Nun klappt auch die Ausführung mit

Code: Alles auswählen

./soc_helper.py

--> Daher macht die Beschreibung in der Hilfe Sinn zu Deinem o.g. Weg und ggf. zu dem Weg, wie ich es bisher mit "python sol_helper.py" gemacht habe. Denn das ist für wenig Bewanderte wie mich definitiv ein Stolperstein (ich habe es inzwischen Dank Dir gelernt, andere wissen es sicher noch nicht).

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.

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...

Vielen Dank für den Tipp!
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

Verfasst: **Fr Jun 21, 2024 8:36 pm**

So, jetzt muss ich noch einmal weiterspamen:

Ich bin auf https://www.instructables.com/Raspberry ... n-startup/ gestoßen:

1. mit nano

Code: Alles auswählen

autostart.sh

eine Datei angelegt.

2. Inhalt von autostart.sh:

Code: Alles auswählen

cd /
cd home/meinname/soc_helper
nohup ./soc_helper.py

3.

Code: Alles auswählen

chmod 755 autostart.sh

4. Dann Ausführung mit

Code: Alles auswählen

sh autostart.sh

, wobei ich irgendwelche Meldungen mit Access denied hatte

5. Lesen von https://www.shells.com/l/en-US/tutorial ... r-in-Linux
-->

Code: Alles auswählen

sudo chmod +x autostart.sh

6.

Code: Alles auswählen

sudo crontab -e

7. Dort steht nun:

Code: Alles auswählen

@reboot sh /home/meinname/autostart.sh

Beim Start des Raspberry Pi wird nun der soc_helper ausgeführt.

@zut
Womöglich fällt Dir etwas Eleganteres ein.

Verfasst: **Sa Jun 22, 2024 4:42 am**

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:

Code: Alles auswählen

chmod +x ./soc_helper/soc_helper.py

2. Service-Datei anlegen und im Editor (Nano) öffnen

Code: Alles auswählen

sudo nano /etc/systemd/system/sochelper.service

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

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

4. Service Daemon neustarten, damit die Datei eingelesen wird

Code: Alles auswählen

sudo systemctl daemon-reload

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

Code: Alles auswählen

sudo systemctl enable sochelper
sudo systemctl start sochelper

Nun läuft der Dienst auch und startet beim nächsten Systemstart wieder.

Weitere nützliche Befehle zum Dienst

Status des Dienstes abfragen

Code: Alles auswählen

sudo systemctl status sochelper

Dienst stoppen

Code: Alles auswählen

sudo systemctl stop sochelper

Dienst neustarten

Code: Alles auswählen

sudo systemctl restart sochelper

Log ausgeben

Code: Alles auswählen

sudo journalctl -u sochelper

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

Verfasst: **Sa Jun 22, 2024 4:58 am**

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

Verfasst: **Sa Jun 22, 2024 7:08 am**

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?

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.

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.
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?

openWB Forum

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

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

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

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

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

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

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

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

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

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

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