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

[zut]

...
-->

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.

Ich hatte an sowas schon gedacht, allerdings ohne sudo, es reicht völlig aus, wenn der normale Nutzer das in seiner eigenen crontab anlegt (Hättest einfach die sudos weglassen können).

Das Anlegen eines Dienstes ist aus meiner Sicht das eleganteste, aber nicht von jedem Anwender machbar - dafür braucht es entweder ein .deb-Paket oder ein Skript, was das automatisch erledigt. Für mich selbst war das überflüssig, da mein Pi sowieso durchläuft und ich (ausser für updates) sowieso nicht neustarte.

[zut]

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

Ich habe mir eine OBD-Verlängerung mit abgewinkeltem flachem Stecker besorgt und hinter der Knieverkleidung in den Sicherungshalter hinter der Fahrertür gelegt. Dort liegt, mit Schaumfolie umwickelt, der WiCAN. Der Fußraum ist absolut unauffällig, und wenn ich zur Werkstatt oder HU muß, wird der Stecker unten abgezogen und etwas hinter die Verkleidung geschoben. Bemerkt keiner. Meiner ist 1m lang, 0,6m hätten gereicht:

https://www.amazon.de/gp/product/B074Z4 ... =UTF8&th=1

[Matthias]

Für Dummis:
Was ist der Vorteil, es über den Dienst zu machen statt über das Autostart, wie ich es umgesetzt habe?

Hallo,

für diesen Anwendungsfall nehmen sich die beiden Lösungen nicht viel, denke ich. Viele Wege führen nach Rom.

Im Allgemeinen würde ich aber sagen das das mit dem Dienst eleganter ist weil

• wenn man viele Dienste auf ggf. auch mehreren Geräten laufen hat, dies standardisiert bekommt

• man per Definition auch einem User zugewiesen bekommt, der z.B. nur für diesen Dienst vorhanden ist und sich sonst auch gar nicht am System anmelden kann

• man definieren kann, welche anderen Dienste vorher fertig geladen worden sein sollen, und auch welche erst danach gestartet werden sollen

Wie gesagt sind eher allgemeine Dinge und es gibt viele Varianten wie man es machen kann. Sicher gibt es auch noch andere Vor- und Nachteile die mir nicht bewusst sind.

Grüße

[Matthias]

Ich habe mir eine OBD-Verlängerung mit abgewinkeltem flachem Stecker besorgt und hinter der Knieverkleidung in den Sicherungshalter hinter der Fahrertür gelegt. Dort liegt, mit Schaumfolie umwickelt, der WiCAN. Der Fußraum ist absolut unauffällig, und wenn ich zur Werkstatt oder HU muß, wird der Stecker unten abgezogen und etwas hinter die Verkleidung geschoben. Bemerkt keiner. Meiner ist 1m lang, 0,6m hätten gereicht:

https://www.amazon.de/gp/product/B074Z4 ... =UTF8&th=1

Danke,

ich hatte mir bereits das Kabel gekauft: https://www.amazon.de/dp/B09NBVZZK2?psc ... ct_details

Man kann die Seitenverkleidung zur Tür einfach abziehen und da habe ich jetzt ein "Fach" gefunden, wo der Dongle genau reinpasst. Das Kabel kann man dann einfach nach unten durchstecken. Anbei die Bilder dazu. Ich hatte auch überlegt den in Schaumfolie einzuwickeln, aber ich war mir wegen möglicher Wärmeentwicklung nicht so sicher. Daher habe ich ihn nur mit Kabelbinder fixiert, damit er nicht umher fliegt und klappert. Erschütterungen sollten ihm ja nichts anhaben.

image001.jpg (142.82 KiB) 384 mal betrachtet

image002.jpg (153.39 KiB) 384 mal betrachtet

image003.jpg (105.12 KiB) 384 mal betrachtet

[zut]

Genau da liegt meiner auch

PXL_20240622_154335397~2.jpg

(1.68 MiB) Noch nie heruntergeladen

PXL_20240622_154229533~2.jpg

(1.3 MiB) Noch nie heruntergeladen

[mattberlin]

@Matthias
Das Kabel von Dir ist dieses hier: https://www.amazon.de/bbfly-A9-Splitter ... BWFB/?th=1, oder?

Verträgt sich das, wenn man den WiCAN und was anderes gleichzeitig dran hat?


@zut
Eine Kleinigkeit ist mir aufgefallen, die aber eigentlich keine Beeinträchtigung ist:
- Das Auto war auf 100 %
- Ich hatte zum Probieren den SoC in openWB manuell runter gestellt
- Der WiCAN hat sich eingesschaltet nach Zündung ein
- Der SoC wurde NICHT in die openWB geschrieben

Ich dachte schon, dass mein Pi hängt, aber als ich später nach Hause kam, wurde der dann niedrigere SoC korrekt in die openWB geschrieben.
Ich vermute, dass aus der SoC-Berechnung ein Wert >100 % rauskam, womit es dann im Skript zu einem Fehler kommt.

[zut]

Eine Kleinigkeit ist mir aufgefallen, die aber eigentlich keine Beeinträchtigung ist:
- Das Auto war auf 100 %
- Ich hatte zum Probieren den SoC in openWB manuell runter gestellt
- Der WiCAN hat sich eingesschaltet nach Zündung ein
- Der SoC wurde NICHT in die openWB geschrieben

Ich dachte schon, dass mein Pi hängt, aber als ich später nach Hause kam, wurde der dann niedrigere SoC korrekt in die openWB geschrieben.
Ich vermute, dass aus der SoC-Berechnung ein Wert >100 % rauskam, womit es dann im Skript zu einem Fehler kommt.

Das ist momentan sogar beabsichtigt. Hintergrund: Ich kenne es so, daß die höchsten n Werte einer CAN-Botschaft der Signalisierung von Fehlern oder "nicht bereit" vorbehalten sind. Welche und wieviele, liegt im Ermessen des Herstellers. Ein Freund hatte mit seinem eUp das Phänomen, daß er mit niedrigem Ladestand nach Hause kam und beim Laden nach Wakeup bei einer SoC-Abfrage einen Rohwert von 254 bekam, woraufhin die Wallbox auf 100% gesetzt wurde und das Laden eingestellt wurde.
Mir stellte sich die Frage, wie man sich verhalten soll: Ich entschied mich dafür, zu große Werte einfach ignorieren und nicht an die Wallbox zu übertragen.
Wenn man für ein Fahrzeug genau die Definition kennt, könnte man vor der Berechnung diese Werte abfangen und nichts übertragen, aber das ist Fahrzeugmodellabhängig.

[mattberlin]

Besten Dank für die Aufklärung. Dann ist es, so wie es ist, die beste Lösung.

[Matthias]

@Matthias
Das Kabel von Dir ist dieses hier: https://www.amazon.de/bbfly-A9-Splitter ... BWFB/?th=1, oder?

Verträgt sich das, wenn man den WiCAN und was anderes gleichzeitig dran hat?

Nein, ich habe das Kabel bestellt: https://www.amazon.de/dp/B09NBVZZK2?psc ... ct_details

Ich hatte bei der Bestellung nicht darauf geachtet, wie rum der Doppelstecker angebunden ist und habe gerade nochmal beim Vergleich der Produktbilder festgestellt, das das Detailbild falschrum bei Amazon drin ist, oder die verschicken zufällig eine der Varianten. Wer weiß.

Ich habe bisher nicht getestet, was passiert, wenn ich noch einen OBD-Stecker reinstecken, aber ich erwarte dort keine Probleme. Zum einen gibt es die Spannungsversorgung, die ich nur als kritisch einschätze, falls ein Dongle extrem viel zieht, was ich aber nicht denke. Und zum anderen die CAN-Datenleitung, bei der ich ebenso kein Problem erwarte da es sich um ein Bus-System handelt bei dem man mehrere Teilnehmer aufschalten kann. Die Dongle sollten ja auch erstmal nur lauschen, keine CAN-Signale senden und maximal Diagnosebotschaften senden, was ja aber nur von dem Python-Skript ausgeführt wird, was in der Werkstatt aber nicht passiert, da es nicht in Reichweite des Heimnetzes ist.

Soweit meine theoretischen Überlegungen.

Grüße

[mattberlin]

Hallo zusammen,

ich hatte mit dem Y-Kabel rumgespielt und wunderte mich, dass der SoC nicht mehr ausgelesen wurde. Ich dachte schon, dass der WiCAN rumspinnt.
In PuTTY zeigte mir das ps ax, dass soc_helper nicht lief. Ein manueller Start lieferte zwar den km-Stand in der Konsole zurück, aber keinen SoC.
Ein Reboot half, soc_helper startete automatisch und alles ist schick.

Jemand eine Idee, woran das liegen könnte?
Gibt es irgend einen Log, der Aufschluss gibt?