SOC: VWID

[gvz]

Ich bin sehr, sehr dankbar für das VW-Modul!

Das vorab: Du verwendest (als wohl Einziger) das lxml-Modul. Ich wollte gerade auf meinem Test-Raspi eine "Default-1.9"-Installation hochziehen, aber das "pip3 Install lxml" in at_reboot.sh führte zur Speicherkatastrophe - mein Test-Raspi hat "nur" 4 GB, und per Default in Stretch 1 GB Swap. Beides an der Kante, nach 10 Minuten habe ich abgebrochen. Der Compiler zieht sich das gesamte RAM beim Kompilieren:

Code: Alles auswählen

root     12313 12312 69 22:48 pts/0    00:06:16 /usr/lib/gcc/arm-linux-gnueabihf/6/cc1 -quiet -I /usr/include/libxml2 -I src -I src/lxml/includes -I /usr/include/python3.5m -imultilib . -imultiarch arm-linux-gnueabihf -D_REENTRANT -D NDEBUG -D _FORTIFY_SOURCE=2 -D CYTHON_CLINE_IN_TRACEBACK=0 src/lxml/etree.c -quiet -dumpbase etree.c -march=armv6 -mfloat-abi=hard -mfpu=vfp -mtls-dialect=gnu -auxbase-strip build/temp.linux-armv7l-3.5/src/lxml/etree.o -g -g -O2 -Wall -Wstrict-prototypes -Wformat=1 -Werror=format-security -Wdate-time -w -fwrapv -fdebug-prefix-map=/build/python3.5-RmaDen/python3.5-3.5.3=. -fstack-protector-strong -fPIC -o /tmp/ccEcbeKx.s

Das System sieht dann so aus:

Code: Alles auswählen

top - 22:55:21 up 29 min,  3 users,  load average: 1.80, 1.20, 0.92
Tasks: 117 total,   1 running,  75 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.1 us,  3.5 sy,  0.0 ni, 55.0 id, 36.3 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :   442340 total,    26808 free,   402236 used,    13296 buff/cache
KiB Swap:   102396 total,        0 free,   102396 used.     8264 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                          
12313 root      20   0  445080 338948      0 D  42.8 76.6   6:14.81 cc1                                                                                                                              
   44 root      20   0       0      0      0 S  22.3  0.0   0:05.41 kswapd0                                                                                                                          
   68 root      20   0       0      0      0 S   3.9  0.0   0:07.82 mmcqd/0                                   

Diese "etree.c" ist auch fetter, autogenerierter 10 MB-Code.

Was will ich damit vorschlagen?
"lxml" ist schlichtweg ein zu fettes Schwein für einen 4 GB-Raspi. Da es auch in Stretch fertige Debian-Pakete gibt, würde ich vorschlagen, das nicht mit pip3 "from Source" zu installieren, sondern das Debian/Raspbian-Paket zu verwenden. Ansonsten kann man eben leider OpenWB nicht auf 4 GB-Systemen installieren - egal, ob man das VW-SOC-Modul braucht oder nicht.

Nochmal danke für das Modul

[ID4U]

Hoffentlich nur eine vorübergehende Störung und nicht schon wieder eine Änderung bei VW:

Code: Alles auswählen

2023-03-01 07:45:27 ERROR:libvwid:Lp2 Get status failed
2023-03-01 07:38:39 ERROR:libvwid:Lp1 Get status failed

[derNeueDet]

Sorry, Doppel Post
VG
Det

[gvz]

Diesen Beitrag hattest Du schon eine Seite vorher gebracht, herzlichen Dank, er ist so wichtig, Immer wieder wiederholt zu werden.

M.E. sollte der Staat im Gegenzug für seine äußerst großzügige Forderung drei Dinge als Zusatzanforderung an geförderte BEV stellen:
- Eine dokumentierte, stabile API zu SoC-Abfrage, das brauchen wir für Dinge wie netzdienliches Laden zumindest als Krücke
- Eine fahrzeuginterne SoC-Begrenzung statt "Durchladen auf 100%"
- Eine SoH-Abfrage ohne OBD
Kostet nix, und sollte, wenn man nicht so dilettantisch wie VW arbeitet (deren App im Moment bei mir auch nicht aktualisiert) machbar sein.
(Sofern die Aussage "VW arbeitet dilettantisch" als beleidigend empfunden werden sollte, kann ich gerne meinen Klarnamen ergänzen, um dem gekränkten Konzern die Verfolgung zu ermöglichen).

[derNeueDet]

Bis auf die 3. Forderung SOH ohne OBD hat das Mercedes für seine Fahrzeuge implementiert. Es gibt eine API, intern im Fahrzeug kann ich drei unterschiedliche Ladeprofile (mit unterschiedlichen SoCs) anlegen.

Über die Stabilität des Mercedes Backends kann man sich streiten, ich denke in der Zwischenzeit ist es wesentlich besser geworden, aber noch nicht optimal.

VG
Det

[rleidner]

Ich bin sehr, sehr dankbar für das VW-Modul!

Das vorab: Du verwendest (als wohl Einziger) das lxml-Modul. Ich wollte gerade auf meinem Test-Raspi eine "Default-1.9"-Installation hochziehen, aber das "pip3 Install lxml" in at_reboot.sh führte zur Speicherkatastrophe - mein Test-Raspi hat "nur" 4 GB, und per Default in Stretch 1 GB Swap. Beides an der Kante, nach 10 Minuten habe ich abgebrochen. Der Compiler zieht sich das gesamte RAM beim Kompilieren:

Code: Alles auswählen

root     12313 12312 69 22:48 pts/0    00:06:16 /usr/lib/gcc/arm-linux-gnueabihf/6/cc1 -quiet -I /usr/include/libxml2 -I src -I src/lxml/includes -I /usr/include/python3.5m -imultilib . -imultiarch arm-linux-gnueabihf -D_REENTRANT -D NDEBUG -D _FORTIFY_SOURCE=2 -D CYTHON_CLINE_IN_TRACEBACK=0 src/lxml/etree.c -quiet -dumpbase etree.c -march=armv6 -mfloat-abi=hard -mfpu=vfp -mtls-dialect=gnu -auxbase-strip build/temp.linux-armv7l-3.5/src/lxml/etree.o -g -g -O2 -Wall -Wstrict-prototypes -Wformat=1 -Werror=format-security -Wdate-time -w -fwrapv -fdebug-prefix-map=/build/python3.5-RmaDen/python3.5-3.5.3=. -fstack-protector-strong -fPIC -o /tmp/ccEcbeKx.s

Das System sieht dann so aus:

Code: Alles auswählen

top - 22:55:21 up 29 min,  3 users,  load average: 1.80, 1.20, 0.92
Tasks: 117 total,   1 running,  75 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.1 us,  3.5 sy,  0.0 ni, 55.0 id, 36.3 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :   442340 total,    26808 free,   402236 used,    13296 buff/cache
KiB Swap:   102396 total,        0 free,   102396 used.     8264 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                          
12313 root      20   0  445080 338948      0 D  42.8 76.6   6:14.81 cc1                                                                                                                              
   44 root      20   0       0      0      0 S  22.3  0.0   0:05.41 kswapd0                                                                                                                          
   68 root      20   0       0      0      0 S   3.9  0.0   0:07.82 mmcqd/0                                   

Diese "etree.c" ist auch fetter, autogenerierter 10 MB-Code.

Was will ich damit vorschlagen?
"lxml" ist schlichtweg ein zu fettes Schwein für einen 4 GB-Raspi. Da es auch in Stretch fertige Debian-Pakete gibt, würde ich vorschlagen, das nicht mit pip3 "from Source" zu installieren, sondern das Debian/Raspbian-Paket zu verwenden. Ansonsten kann man eben leider OpenWB nicht auf 4 GB-Systemen installieren - egal, ob man das VW-SOC-Modul braucht oder nicht.

Nochmal danke für das Modul

Danke für die "Blumen" und den Hinweis.

Bisher bis Du der erste mit diesem Problem.
Bei mir läuft das ohne Probleme auf dem 3B+ (unter beidem, stretch und buster):

Code: Alles auswählen

pi@openwbtest-stretch:~ $ free -h
              total        used        free      shared  buff/cache   available
Mem:           926M        105M        280M         59M        540M        698M
Swap:            0B          0B          0B

Ich bin allerdings auch kein Experte in Python und lerne gerne dazu.
Was wäre denn die Alternative zum "pip3 Install lxml" im Detail?

[luettmatten]

BTW,
kürzlich hat ein anderer Anwender in ähnlicher Vorgehensweise wie VWID ein Modul für Skoda erstellt.
Cupra, Audi, etc. sind also machbar, es muss sich nur jemand finden, der das bauen und testen kann.

(Manuell) Testen könnte ich das mit einem Skoda Enyaq iV 60 Und einer OpenBW Series zwei. Leider reichen meine Fähigkeiten nicht aus, um so ein Modul zu bauen / zu integrieren.

[rleidner]

BTW,
kürzlich hat ein anderer Anwender in ähnlicher Vorgehensweise wie VWID ein Modul für Skoda erstellt.
Cupra, Audi, etc. sind also machbar, es muss sich nur jemand finden, der das bauen und testen kann.

(Manuell) Testen könnte ich das mit einem Skoda Enyaq iV 60 Und einer OpenBW Series zwei. Leider reichen meine Fähigkeiten nicht aus, um so ein Modul zu bauen / zu integrieren.

Oder gibt es irgendwo einen Workaround um vom Skoda Enyaq (gleiche Software wie ID-Familie) zu verwenden?

Da war ich etwas unpräzise, sorry.

Das Skoda Modul wurde für owb 2.0 entwickelt; der PR scheint OK zu sein ist aber noch nicht gemerged: https://github.com/openWB/core/pull/762

[gvz]

Bisher bis Du der erste mit diesem Problem.
Bei mir läuft das ohne Probleme auf dem 3B+ (unter beidem, stretch und buster):

Ich bin allerdings auch kein Experte in Python und lerne gerne dazu.
Was wäre denn die Alternative zum "pip3 Install lxml" im Detail?

Mein Vorschlag ist ja, statt mit pip3 die lxml zu bauen, das fertige Debian-Paket (zumindest bei Stretch und Buster gibt es das) "pyhton3-lxml" zu installieren.
Konkret hat meine OpenWB auf Buster das Debian-Paket installiert (warum/woher, weiß ich nicht, ich spiele da öfters). Mein neu hochgezogenes Stretch-Image (Lite) hatte das Paket nicht installiert, es ist ja in der großen, magischen Installdatei ("https://raw.githubusercontent.com/snapt ... install.sh") auch nicht aufgeführt:

Code: Alles auswählen

apt-get -q -y install vim bc apache2 php php-gd php-curl php-xml php-json libapache2-mod-php jq raspberrypi-kernel-headers i2c-tools git mosquitto mosquitto-clients socat python-pip python3-pip sshpass

Ich habe jetzt versucht, den Rebuild in "at_reboots.sh" zu erzwingen, das klappt auf meinem Buster-Produktivsystem aber auch nicht:

Code: Alles auswählen

2023-03-01 12:11:42: at_reboot: Collecting lxml
2023-03-01 12:11:46: at_reboot: Downloading https://www.piwheels.org/simple/lxml/lxml-4.9.2-cp37-cp37m-linux_armv7l.whl (2.5MB
)
2023-03-01 12:11:48: at_reboot: Installing collected packages: lxml
2023-03-01 12:11:49: at_reboot: Successfully installed lxml-4.9.2

Auf dem Stretch-System hingegen:

Ohne Paket "python3-lxml":

Code: Alles auswählen

2023-03-01 12:22:14: at_reboot: Collecting lxml
2023-03-01 12:22:22: at_reboot: Using cached https://files.pythonhosted.org/packages/06/5a/e11cad7b79f2cf3dd2ff8f81fa8ca667e7591d3d8451768589996b65dec1/lxml-4.9.2.tar.gz
2023-03-01 12:22:28: at_reboot: Building wheels for collected packages: lxml
2023-03-01 12:22:28: at_reboot: Running setup.py bdist_wheel for lxml: started

==> große Speicherkatastrophe

Mit Paket "python3-lxml" installiert:

Code: Alles auswählen

2023-03-01 12:24:19: at_reboot: lxml installed...

Mein Vorschlag wäre also, "python3-lxml" gleich per apt-get zu installieren, damit es nicht per pip3 gebaut werden muss. Ich habe jetzt allerdings auf die Schnelle nicht "Bullseye" zur Hand, um zu prüfen, ob auch hier "python3-lxml" als Paket zur Verfügung steht.

[gvz]

P.S.: Hatte eigentlich schon jemand geschrieben, dass sowohl VW-App als auch die SOC-Abfrage in OpenWB seit heute morgen wieder funktioniert?