Seite 32 von 59
Re: SOC: VWID
Verfasst: Di Feb 28, 2023 10:25 pm
von 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
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 6:48 am
von 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
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 7:07 am
von derNeueDet
Sorry, Doppel Post
VG
Det
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 7:57 am
von 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).
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 9:18 am
von 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
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 9:39 am
von rleidner
gvz hat geschrieben: Di Feb 28, 2023 10:25 pm
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?
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 10:09 am
von luettmatten
rleidner hat geschrieben: Mo Feb 27, 2023 8:29 am
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.
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 10:40 am
von rleidner
luettmatten hat geschrieben: Mi Mär 01, 2023 10:09 am
rleidner hat geschrieben: Mo Feb 27, 2023 8:29 am
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
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 11:31 am
von gvz
rleidner hat geschrieben: Mi Mär 01, 2023 9:39 am
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:
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.
Re: SOC: VWID
Verfasst: Mi Mär 01, 2023 11:32 am
von gvz
P.S.: Hatte eigentlich schon jemand geschrieben, dass sowohl VW-App als auch die SOC-Abfrage in OpenWB seit heute morgen wieder funktioniert?