Hallo, muss mich mit einem Problem an die Gemeinschaft wenden (wo auch sonst). Die Datenübernahme per open3e-Client läuft bei mir seit 2 Monaten ohne Problem (can0). Seit dem 17.04. erhalte ich jetzt einen Fehler (siehe Fehlerbeschreibung). Der Vitocharge liefert mir ebenfalls einen Fehlercode Fehlerbeschreibung: Script zur Datenübernahme: $ python3 /home/leitwolfpi/open3e/Open3Eclient.py -c can0 -dev vx3 -r 506,1664,1801,1802,1831,1833,1834,1836,1839,2240 -m 192.168.178.100:1883:/ESP8266 -muser mosquitto1:xxxxxxxx -t 15 *) 2024-04-17 15:56:12 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. Global request timeout time has expired (timeout=20.000 sec) Traceback .. /Fehlerbeschreibung *) Das Script war seit etwa 3 Wochen aktiv Anlage: Aktive Status Meldungen: Aktiver Fehler: F.1034 - Kommunikationsstörung Externer CAN-BUS Durch Neustart des Vitocharge VX3 konnte ich den Fehler zurücksetzen. Nach nochmaligem Aktivieren des open3e-Client trat der Fehler wieder auf. Ich habe anschließend auch versucht, einzelne Werte ohne MQTT abzurufen. Immer die gleiche Fehlermeldungen wie oben beschrieben. Nach Zurücksetzen des Vitocharge und Trennung von dem USB_zu_CAN Konverter (Amazon https://www.amazon.de/dp/B07Q812QK8?ref=ppx_yo2ov_dt_b_product_details&th=1) läuft der Vitocharge wieder fehlerfrei. Der Konverter hängt an einem Raspberrypi 3 (Linux leitwolfrpi 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux). Zeitgleich läuft eine Anwendung zur Datenübernahme von einer Stiebel WP (can1). Auch nach einer Beendigung dieser Datenübernahme über can1 erfolgte keine Kommunikation mit dem Vitocharge über can0 mehr. Da das Datenaufkommen auf ca. 40% des Wertes reduziert wurde, der bei Aktivierung von can0 und can1 anfiel, dürfte die anfallende Datenmenge meiner Meinung nach nicht der ausschlaggebende Grund des Problems sein. Der Speicher des Raspberrypi 3: leitwolfpi@leitwolfrpi:~ $ df -h Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf udev 316M 0 316M 0% /dev tmpfs 91M 1,2M 90M 2% /run /dev/mmcblk0p2 29G 6,4G 21G 24% / tmpfs 455M 8,0K 455M 1% /dev/shm tmpfs 5,0M 12K 5,0M 1% /run/lock /dev/loop0 93M 93M 0 100% /snap/core/16578 *) /dev/loop1 92M 92M 0 100% /snap/core/16931 *) /dev/mmcblk0p1 510M 73M 438M 15% /boot/firmware tmpfs 91M 44K 91M 1% /run/user/1000 ------------------------------------------------------------------------------------------------------ *) die Angaben bei den /snap/core/... Einträgen sind ok, da virtuelle Laufwerke read/only. ("That is normal. /dev/loopX are virtual devices to mount image files. And they are -read only- so do not get larger or smaller than they are when created. " Übernommen aus : https://askubuntu.com/questions/990013/system-mounts-dev-loop0-on-snap-core-3604-and-its-100-full-where-is-it-comi --------------------------------------------------------------------------------------------- leitwolfpi@leitwolfrpi:~/open3e $ ip -details -statistic link show can0 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 can state ERROR-PASSIVE restart-ms 100 bitrate 20000 sample-point 0.875 tq 3125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 150 gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1 clock 48000000 re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 20229 568602 528248 *) numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus usb parentdev 1-1.2:1.0 RX: bytes packets errors dropped missed mcast 9454045 1181851 0 9484 0 0 TX: bytes packets errors dropped carrier collsns 128 16 0 27 0 0 ------------------------------------- *) Die Zeile mit den Fehler (error-warn error-pass bus-off) ist bei meinem can1 komplett auf 0. Ist ja auch ein anderer Can-Bus, der auch an einen zweiten USB zu CAN Konverter angeschlossen ist. Bin im Moment etwas ratlos. Weitere Info auf Anfrage Gruss Harald
... Mehr anzeigen
