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

[zut]

Schön, das es funktioniert! Aber eigentlich hat keine deiner beiden Maßnahmen etwas mit dem Problem von vorher zu tun. Seltsam. Jedenfalls freue ich mich über die positive Rückmeldungen.

Vergiss nicht, die Ausgabe wieder von debug herunter zunehmen auf warn oder so, wenn die sd-Karte lange leben soll. Ich habe meinem Pi übrigens eine 2,5"-SSD verpasst, über Adapter an USB. Die hält mehr Schreibvorgänge aus.

[wb-2020]

Den loglevel habe ich auf Info gesetzt. Ich stelle das dann mal auf Warning um.
Eine SSD für den Pi ist eine gute Idee. Das überlege ich mir mal.

[aiole]

Mit den neuen industrial SD's aus dem shop gibt es so gut wie keine Probleme mehr. Natürlich auch dort immer auf "Softdown" achten, wenn man "rumspielt".

[mattberlin]

Hallo Zut,

heute ist das Interface gekommen und wie zu erwarten war, komme ich nicht klar

1. Zunächst ein Hinweis zur Doku in Kombination mit der Frage, ob ich es richtig gemacht habe

Screenshot 2024-06-17 202312.jpg

(383.43 KiB) Noch nie heruntergeladen

Die Ausführung habe ich mit dem Befehl python soc_helper.py initiiert.

2) SoC-Berechnung
Dann meldete das Skript einen Fehler:

Screenshot 2024-06-17 203354.jpg

(108.61 KiB) Noch nie heruntergeladen

In Anlehnung an den e-up habe ich eine der beiden Klammern am Anfang entfernt.

3. ID's
Dann bekam ich folgende Meldung:

Screenshot 2024-06-17 204942.jpg

(55.03 KiB) Noch nie heruntergeladen

Das liegt scheinbar an den Hex-Zahlen für den VW MEB (ab Zeile 66) in der configuration.py
Ich habe sie auskommentiert und stattdessen die e-up-Zeilen (ab Zeile 42) aktiviert.
Dann schaut es bei mir so aus:

Screenshot 2024-06-17 211119.jpg

(248.92 KiB) Noch nie heruntergeladen

Zur Info der MQTT-Explorer:

Screenshot 2024-06-17 212804.jpg

(120.81 KiB) Noch nie heruntergeladen

Sehe ich es richtig, dass die IDs ab Zeile 42 für den CUPRA Born andere sind?


PS:
Die Anleitung zum SoC_Helper ist echt super und sogar einigermaßen idiotensicher

[zut]

Danke für das Testen und die ausführliche Rückmeldungen! Du hast einige Fehler gefunden, die ich zeitnah beheben werde.

Die ID vom Up wird nicht zum Erfolg führen, statt dessen muss die Konfigurationsprüfung Zahlen großer 4095 durchlassen.

Hintergrund: es gibt normale IDs mit 11 Bit, die können maximal 2047 (ich dachte, 12 Bit...) groß werden. Die wurden mal auf extended aufgebohrt, dann 29Bit. In der Anforderung ist das extd-Flag zu sehen, das sollte true sein für lange IDs.

Wenn du dich traust, kannst du den Check auf <=4095 entfernen (Funktion checkConfig in soc_helper.py) oder die 4095 durch eine sehr große Zahl ersetzen und dann nochmal probieren.

[zut]

So, neue Version (ungetestet) ist im ersten Posting veröffentlicht. Danke für das Feedback. Die Dokumentation für den Start ist angepaßt, da fehlte das ".py" am Ende:

Code: Alles auswählen

pi@pi4:~/soc_helper$ ./soc_helper.py

Tip: Mit <Tab> kann man in der Linux-shell sehr gut ergänzen. Es reicht, "./soc<Tab>" zu tippen, um das fehlende "_helper.py" anzuhängen. Bei Mehrdeutigkeit wird nur bis zur Uneindeutigkeit ergänzt, bei nochmaligem Drücken von <Tab> werden alle Alternativen gelistet.

Die von mattberlin gefundenen weiteren Fehler sollten behoben sein. Ich freue mich auf die weitere Inbetriebnahme!

[mattberlin]

Alter, wie geil!!! Nun geht es! Tausend Dank!

Der SoC wird von der Kiste auf die openWB geschrieben


Was aber noch nicht checke:
1) SoC-Berechnung
Für was stehen bzw. woher kommen die Faktoren in "soc = round(bytes[4]/2.5*51/46-6.4)" (Zeile 140 in configuration.py)?
Es wird der Wert mit 0,443 multipliziert und dann um 6,4 gemindert. Das checke ich nicht.

Darüber hinaus ist mir in Car Scanner (Android-App und ELM327-BT-Interface) aufgefallen, dass auch der angezeigte SoC verfügbar sein muss:

Screenshot_20240618_214031.jpg

(462.46 KiB) Noch nie heruntergeladen

Könnte man diesen stattdessen mit SOC-Helper abfragen?


2) Übermittlung SoC wann
Wenn ich das richtig verstanden habe, wird ja der SoC nur einmalig bei der Anmeldung vom WiCAN im WLAN in die openWB geschrieben. Wenn die Karre aus ist und der WiCAN sinnvollerweise schlafen geht, kann ja auch kein SoC übermittelt werden.
Was ist aber während des Ladevorganges? Hierbei ist ja der DC/DC im Auto in Betrieb, so dass die 12-V-Batterie geladen wird, wodurch der WiCAN ja auch wieder aufwacht.
Wäre hier nicht eine kontinuierliche Übermittlung des SoCs möglich?


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.

Ich habe aber kein Plan, wie ich Dich den Start mit nohup hinbekommen soll:

image_2024-06-18_232959978.png

(20.56 KiB) Noch nie heruntergeladen

4) Autostart
Kann man den SOC-Helper eigentlich automatisch starten lassen, wenn der Pi hochfährt?

[mattberlin]

Zu 3)
Hat sich erledigt.
Mit "nohup python soc_helper.py" geht es.

@zut
Vielleicht magst Du das mit dem "python" im Ausführungsbefehl als mögliche Varianz in Deiner Hilfe einpflegen. Dann haben es andere Neulinge ein wenig einfacher.

[zut]

Was aber noch nicht checke:
1) SoC-Berechnung
Für was stehen bzw. woher kommen die Faktoren in "soc = round(bytes[4]/2.5*51/46-6.4)" (Zeile 140 in configuration.py)?
Es wird der Wert mit 0,443 multipliziert und dann um 6,4 gemindert. Das checke ich nicht.

Darüber hinaus ist mir in Car Scanner (Android-App und ELM327-BT-Interface) aufgefallen, dass auch der angezeigte SoC verfügbar sein muss:
Screenshot_20240618_214031.jpg
Könnte man diesen stattdessen mit SOC-Helper abfragen?

Die Berechnung des angezeigten SoC habe ich von EVNotify abgeschaut. Der zurückgelieferte Wert ist der Rohwert, wobei 0 für 0% und 250 oder so für 100% steht. Üblicherweise reserviert man die größten Werte für Fehler und "nicht bereit". Eine Umrechnung /2.5 würde also den Rohwert in Prozent ergeben. Die oberen und unteren Prozent werden für das Erreichen einer langen Lebensdauer nicht genutzt, deshalb zeigt die Anzeige schon bei etwa 6,4% Roh-SoC 0% an. Auch oben sind einige Prozent nicht genutzt. Die Formel dient also der Umrechnung des genutzten Bereiches ( so etwa 6% bis 85% Roh-SOC) auf die Anzeige von 0% bis 100%. Als Außenstehender kann man die Umrechnung nur experimentell ermitteln und ein Ansatz mit einer Geradengleichung mit Offset die einfachste Möglichkeit. Fiat scheint im oberen Bereich etwas steiler zu laufen als unten, und Tesla hat wohl eine noch aufwändigere Funktion gebaut - ich meine, da hat sogar jemand eine Klage angestrengt, weil die angezeigte Ladung erst langsam fällt und dann schneller oder umgekehrt.
Ich habe jedenfalls bei Nutzung des Roh-SOC bemerkt, daß bei (x<100%) Roh-Ladestand das Batterie-SG die Ladeleistung zuzog und bei (y<100%) beendete. Deshalb möchte ich auf den Anzeige-SOC: 100% in der Wallbox sollten den Punkt markieren, wo die Ladung endet und das Kombi 100% anzeigt.
Ich kenne auch keinen CAN-Wert am OBD2-Stecker, der dem Anzeige-SOC entspricht. möglicherweise rechnet Car Scanner das alleine um? Mir fehlt die Zeit, hier den CAN zu belauschen (das sollte mit dem WiCAN und mqtt-explorer gehen: Carscanner mit der IP-Adresse des WiCAN im Heimnetz verbinden, laufen lassen und den MQTT-Verkehr im mqtt-explorer mitschneiden.

2) Übermittlung SoC wann
Wenn ich das richtig verstanden habe, wird ja der SoC nur einmalig bei der Anmeldung vom WiCAN im WLAN in die openWB geschrieben. Wenn die Karre aus ist und der WiCAN sinnvollerweise schlafen geht, kann ja auch kein SoC übermittelt werden.
Was ist aber während des Ladevorganges? Hierbei ist ja der DC/DC im Auto in Betrieb, so dass die 12-V-Batterie geladen wird, wodurch der WiCAN ja auch wieder aufwacht.
Wäre hier nicht eine kontinuierliche Übermittlung des SoCs möglich?

Ich hatte die Möglichkeit, alle 60s den SOC abzufragen in den ersten Varianten vorgehalten, dann aber bemerkt, daß der WiCAN nach Ablauf des WeConnect-Abos trotz Ladung der HV-Batterie nicht mehr aufwachte. Grund war, daß die 12V-Batterie nicht mehr vom On-Board-Lader nachgeladen wurde. Ich habe jetzt nicht ausprobiert, ob der SOC weiterhin abfragbar ist, denn in diesem Fall müßte ich den Schlafmodus des WiCAN abschalten, so daß der immer - auch ohne Ladung - an wäre. Das täte der Lebensdauer der Bleibatterie nicht gut, denn die mag Zyklisierung überhaupt nicht gerne.

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?

4) Autostart
Kann man den SOC-Helper eigentlich automatisch starten lassen, wenn der Pi hochfährt?

Das geht bestimmt auf mehrere Weisen. Die naheliegenste wäre, ihn als Dienst zu definieren und systemd hinzuzufügen. Da müsste ich mich allerdings schlau machen wie das geht, und jeder Nutzer müsste an Systemverzeichnissen herumbauen - das würden wohl auch nicht so viele Leute hinbekommen. Alternativ müsste ich ein Installskript bauen, das das Starten, Stoppen und Neustarten übernimmt. Mir fehlt da gerade die Muße für - evt wird das in Zukunft.

[zut]

Zu 3)
Hat sich erledigt.
Mit "nohup python soc_helper.py" geht es.

@zut
Vielleicht magst Du das mit dem "python" im Ausführungsbefehl als mögliche Varianz in Deiner Hilfe einpflegen. Dann haben es andere Neulinge ein wenig einfacher.

Bitte am Ende der nohup-Zeile noch ein "&" anfügen, dann wird der Prozess von der Kommandozeile gelöst und arbeitet im Hintergrund weiter. Die shell ist für andere Dinge weiter nutzbar.
Normalerweise blockieren Programme nach Start die Shell und enden, wenn man sie mit Strg+C unterbricht. mit dem kaufmännischen Und & am Ende schickt man einen Prozess in den Hintergrund, wo er weiterläuft. Allerdings würde er beim Abmelden beendet, da die shell und alle ihre Kinder mit beendet werde. Mit dem nohup- Kommando verhindert man das. Wenn du dich wieder anmeldest, kannst du den 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...

Die alternative Startmethode ergänze ich gerne, am liebsten noch mit dem Wissen, warum ein direkter Start bei Dir nicht funktioniert (siehe vorherigen Post).