abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

CAN Bus, Home Automation E3 Generation lokal und kostenlos

hier noch mal mein Beitrag aus 'Internet der Dinge', dem Offenen Brief an Max Viessmann, als neuer Thread - Diskussionen, Fragen etc. bitte hier 🙂

 

Moin Freunde!

 

Da Viessmann zwar ein wunderschöne Schnittstelle (UDS, ISO-TP oder DoIP) eingebaut hat, das aber nur eingeschränkt und für eine 4-stellige Summe (per WAGO Gateway) zur Verfügung stellt, haben wir uns bekanntlich dran gemacht, das selber offen zu legen. 🙂

 

Stand der Dinge ist:

 

- Wir haben eine MQTT fähige Lösung zum Anschluss an den externen CAN Bus ("Stecker 91"), die es erlaubt, E3 Geräte (Wärmepumpen, Gasgeräte, (PV Speicher gerade in der Testphase, BSZ brauchen wir noch Kandidaten)) in Home Automation Systeme einzubinden. ioBroker, mosquitto, Home Assistant, Node-RED und so weiter also alles einfach machbar und bei uns schon im dauerhaften Einsatz.

 

- Das Ganze läuft lokal, also ohne irgendeine Hersteller oder sonstwelche Cloud, ohne Internet! Bei der CAN Bus Kopplung kann die gleichzeitige Verbindung mit dem Viessmann Server zwecks Wahrung der Gewährleistungs- und Garantieansprüche aufrechterhalten bleiben.

 

Eine Anbindung über den WLAN Access Point ist auch möglich, damit aber keine parallele Viesmann-Server-Verbindung mehr.

 

- Aktuell ist nur das Auslesen von Daten weitergehend erprobt. Bei den wichtigen Daten haben wir auch schon die Formate zur Interpretation geklärt, wir arbeiten an einer vollständigen Klärung.

 

Das Schreiben ist bei vielen Daten auch schon erprobt.

 

und last not least: das Ganze ist natürlich kostenfrei und open source! im Sinne eins besseren Miteinanders 😉

 

Der laufend aktualisiert werdende Stand der Linux Lösung ist auf

https://github.com/open3e/open3e

verfügbar. Einen guten 'Leitfaden' für den Einstieg hat @Hotzen-Plotz hier zur Verfügung gestellt:

https://github.com/open3e/open3e/discussions/5

Eine Sammlung von nützlichen Informationen hat @TSG initiert:

https://github.com/TheSmartGerman/open3e/wiki

(werden wir bald auch unter das open3e Projekt migrieren) 

 

beste Grüße!

HerrP_2-1692095743490.png

 

Phil

 

zur Beachtung: Der Zugriff auf das Zielgerät mittels dieser durch Viessmann nicht vorgesehenen Lösung zieht möglicherweise den Verlust von Gewährleistungs-/Garantieansprüchen nach sich und kann unter Umständen zu GEFAHREN FÜR LEIBLICHE UNVERSEHRTHEIT ODER SACHWERTE führen! Die Autoren schliessen jegliche Haftung aus.

 

Beispiele aktueller Home Assistant Integrationen von Wärmepumpen:

 

HerrP_3-1692095743607.jpeg

 

HerrP_3-1697543763132.png

Vitocal 250 Kältekreisübersicht: View und Installationsanleitung gibt's hier: https://github.com/MyHomeMyData/iob.vis.vitocal250.git

 
Jürgen hat auch noch weitere schöne Sachen abgeleitet.

Einen Adapter für ioBroker:

https://github.com/MyHomeMyData/ioBroker.e3oncan

und noch ein paar andre Sachen, die aber in dem Adapter integriert sind. Schaut einfach mal sein Repo an...

https://github.com/MyHomeMyData

 

ps. wer uns unterstützen will und kann ist herzlich willkommen!

 

pps. und wir freuen uns über jedes 'like' (👍) - damit zeigt ihr deutlich, dass ihr eine offene und lokale Kommunikation mit den 'One Base' Geräten eigentlich von Viessmann erwartet

1.195 ANTWORTEN 1.195

So, bei mir ist jetzt erstmal Ruhe ... der CAN-BUS lässt sich hier nicht bändigen.
Ob es nun ein Installationsproblem (Verdrahtung / Gnd) ist, der Adapter spinnt, oder die ViAnlage wegen der fehlenden CAN-BUS Verbindung zwischen PV + WP bzw des zusätzlichen CAN2USB Bus Teilnehmers ... ist mir alles schleierhaft. Ich werde mal drauf dringend, dass der CAN-BUS sauber und durchgängig installiert wird. Erst dann geht's weiter.

Just for the records hier einige Aspekte der momentanen Installation:

Ausgang:
CAN2USB Adapter im Bus am E380 verdrahtet, aber USB nicht am RPI angeschlossen.
Keine Fehlermeldungen der VX3 Anzeige /ViCare

Adapter an RPI gesteckt (wie heute mittag schon beschrieben):
Kommunikationsstörung: Externer CAN-BUS mit Uhrzeit und "Batterie"

Diese ViCare Meldung wird ca. stündlich angezeigt, solange der CAN2USB Adapter am RPI angeschlossen ist.

Ein Blick auf den RPI:
-- Open3E_depictSystem findet nix
-- der Adapter ist aktiv, doppelter Aufruf sagt busy
-- statistics zeigen, dass auf dem BUS was los ist, aber Open3e "sieht" nix
-- ein paar logs dazu:

pi@rpixyz:~/open3e $ python3 Open3E_depictSystem.py
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
0 responding COB-IDs found.
write devices.json ...
done.

configuration:
{}

run Open3Eclient with -mqtt and -a to get EVERYTHING on your MQTT app.
pi@rpixyz:~/open3e $ candump can0
 
^C

pi@rpixyz:~/open3e sudo ip link set can0 up type can bitrate 25000000
RTNETLINK answers: Device or resource busy

pi@rpixyz:~/open3e $ ifconfig
can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 1922901  bytes 15383208 (14.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 24 (24.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@rpixyz:~/open3e $ ip -details -statistics link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-PASSIVE restart-ms 0 
	  bitrate 250000 sample-point 0.875 
	  tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  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          102929     3138478    2950268   numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped missed  mcast   
    51979792   6497474  0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    24         3        0       0       0       0       
pi@rpixyz:~/open3e $ ip -details -statistics link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-PASSIVE restart-ms 0 
	  bitrate 250000 sample-point 0.875 
	  tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  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          114977     3483140    3303651   numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped missed  mcast   
    57948456   7243557  0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    24         3        0       0       0       0       

 


Sollte euch noch etwas auffallen, was ich in dieser Situation ändern/testen kann ... gerne mach’ ich noch 'n Schleife.
Ansonsten melde ich mich erst nach dem CAN-BUS Update durch den Fachbetrieb zurück.
Danke für eure Hilfe und Mühe

Danke für die schnelle Einarbeitung @HerrP  🙏

Natürlich sofort gezogen zum testen und schon mal ein erstes feedback:

depict laufen lassen. 0x680 emcumaster lief zügig durch, bei 0x684 HMI kam beim 2. did "ERROR max retry" und ab da wurde das bei jedem did angezeigt bis ich abgebrochen habe (noch innerhalb von HMI. das dauert ja ewig...). Der neue Scan lief dann fehlerfrei durch.

open3e läuft dann jetzt planmäßig  - sobald errors kommen sollte melde ich mich. Und falls nicht natürlich ebenfalls nach einiger Zeit 😅

 

  • Error Passive State:

    • In the error passive state, the node remains connected to the bus but restricts its participation in communication.
    • The node stops actively transmitting messages but continues to listen to the bus.

 

Dabei kann open3e nicht mehr funktionieren, weil es Anfragen rausschickt um zu funktionieren.

 

          re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          102929     3138478    2950268

die error counter sind viel zu hoch. Davon kommt das auch, dass der Adapter in Error Passive State geht. 

leider ohne Zeitstempel, aber ich vermute mal nicht lange später

	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          114977     3483140    3303651

die error counter schon wieder merklich angestiegen.

 

Da die Baudrate ok ist, und ich nicht annehme, dass du an den Timing Registern irgendwas geändert hast, bleibt nur noch ein Problem im Physical Layer. Ich bin mir nicht sicher, ob fehlerhafte Buswiderstandswerte das gleiche Bild hervorrufen, aber da passt was mit deiner Verdrahtung nicht.

 

Buswiderstände hast du doch genau 2 Stück draufgeschaltet (1 an VX3 und 1 am Adapter) richtig?

 

Wenn es das nicht ist, bleibt nur noch das Potential / GND Problem, oder an der Elektronik von deinem Adapter ist ein Teil kaputt (teilweise funktioniert er ja).

 

Wie gesagt - ein potentialfreier CAN Adapter braucht ein Bezugspotential. Es sieht für mich alles danach aus, dass genau das fehlende Bezugspotential das Problem ist. Das komplette Bild passt: Erst 'sieht' der Adapter dauernd geklippte Signale und ruft noch "Hilfe! Error! Hilfe!", danach läuft der Fehlerzähler so voll, dass er nicht mehr weiter schreien darf, weil er dadurch die ganze Kommunikation blockieren würde (Active Error Frames sind sehr dominant!) und er winselt nur noch 'passiv' vor sich hin... So funktioniert das bei CAN, seit über 30 Jahren...

 

HerrP_0-1702078312714.png

 

Hol dir den CAN_GND von der VX3 und die Welt ist wieder in Ordnung. 🙂

 

 

 

 

@HerrP   Nun gut. Ungern lege ich Hand an das VX3, aber was soll's.

Der Vorschlag den RPI an die VX3 geht nicht, LAN Kabellänge und dort "kein" WLAN. Also muss ich GND zumE380 führen. Das Kabel zw VX3 und E380 (ca. 4 mtr) hat wie gesagt keinen Schirm, aber es sind noch zwei Adern mit denen ich GND ziehen kann. Ein Versuch ist es Wert. Werde das Samstag mal machen.

 

Und den Open3e Dev branch habe ich schonmal runtergeladen.

gute Sache!! extra Kabel für GND ist in meinen Augen eh besser als einen Schirm mit GND zu verbinden, aber das Thema hatten wir ja schon und es ist wahrscheinlich sowieso eher philosphischer Natur... Hauptsache irgend was Leitendes! 😁

 

 

@Sebliner 

>> beim 2. did "ERROR max retry" und ab da wurde das bei jedem did angezeigt bis ich abgebrochen habe 

 

hmm... vielleicht ist es doch ein Versuch wert, die Wartezeit vor dem retry mal hochzusetzen (testweise 1..2 Sekunden um sicher zu gehen)?

 

das bekommst du wahrscheinlich selbst gemacht?! würde mich interessieren ob das was ändert! (ich kann's ja nicht ausprobieren... 😁 )

Hab die Wartezeit gerade auf 2 sek hochgesetzt und nochmal depict laufen lassen  - wieder exakt beim gleich did "ERROR max retry" und dann immer weiter so bis zum Abbruch. Der 2. Durchlauf dann wieder ohne Fehler.

Zur Präzisierung: Es war jetzt beide Male bei 0x684 : HMI. Der erste did 256 wurde noch korrekt gefunden, die nächsten paar wurden (da nicht vorhanden richtigerweise) nicht gefunden. Der nächste zu findende did ist auch korrekt 265, dort nun aber mit error. Der nächste zu findende did unter HMI wäre erst wieder 575. Hier mal ein screen:

Screenshot 2023-12-09 102316.png

Ich würde jetzt dann erst mal so laufen lassen und mich beim ersten TimeoutException melden was passiert ist - oder gibt es noch etwas was ich probieren kann?

Moin!

 

das sieht ja so aus als würde das HMI (0x684) irgendwann (?!) darauf verzichten, eine Negative Response zu geben wenn ein angefragter Datenpunkt nicht existiert. Das ist natürlich äusserst hinderlich, weil ich beim DID Scan den p2_timeout auf 3 Sekunden hochgesetzt habe, und das dann auch noch 4x versucht wird -> gut 12 Sekunden pro Datenpunkt - da dauert der Scan natürlich ne halbe Ewigkeit (3250*12sec = gut 10 Stunden).  [edit] alles Blödsinn - eher wahrscheinlich dass sich die ISO-TP Geschichte weggehängt hat... Hast du zufällig einen candump mitlaufen lassen? das ist immer sehr hilfreich bei sowas!

 

Das hier hab ich von einer 250A10 0x684 bei uns aus der Gruppe:

 

HerrP_0-1702120674598.png

Da wäre der nächste existierende DID nach 256 dann der 575. Bist du sicher, dass es bei dir die 256 (ErrorDtcList) im HMI gibt? Hast du schon mal versucht, die einzeln auszulesen?

 

Die Frage ist jetzt, was den 'Schalter umlegt', dass entweder keine Antwort mehr geschickt wird oder dass sich die Sache 'rechnerseitig' weghängt und wie man das dann wieder zurück gestellt bekommt. Im zweiteren Fall würde ich mal 

ipconfig can0 down -> up

versuchen...

 

Aber klar ist, dass das so auch keine Lösung ist. Sollten die Software Gurus doch Recht haben?!?

 

ps. danke überhaupt für den Test mit den 2 Sekunden vorm Retry! Leider bringt es ja anscheinend alles nix...

Hallo.

Habs endlich geschafft Buster zu installieren. Die SD Karte ist kaputt gegangen arrrrghh.

 

Hab alles wieder installiert und meine zuvor gesicherten args, devices und Datenpunkte raufgespielt und es lief. Aber nur 2 Stunden und dann schon wieder timeouts. 😫

Dann hab ich die develop version vom Open3Eclient raufgespielt. Parallel kam hier das Thema GND wieder hoch. Ich habe den einen Adapter an der VCal hängen mit GND. Der zweite hängt am E380 (welcher mit der PA2 verdrahtet ist) ohne GND. Aufgrund der Info von @HerrP hab ich dann gleichzeitig (dummerweise) den GND vom Adapter über 1k Widerstand auf PE gezogen. 

Es kamen immer noch Fehler. Ich kann nicht mehr genau nachvollziehen welche develop Version es war (die vor HerrPs fix oder die danach).

Heute morgen habe nochmal die develop Version drauf gespielt und die Anzahl an DIDs auf dem 2. Adapter auf ein Minimum (3) reduziert und es lief mehrere Stunden durch. Habs jetzt wieder auf 13 erhöht (ggü 25 von vorher) und jetzt läuft es ohne Probleme. Auch nach einer Stunde zeigt 

ip -details -statistics link show can0
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 250000 sample-point 0.875 
	  tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  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          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    54986748   7308941  0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    185432     23179    0       0       0       0    

 keine Fehler.

 

Ich hab das vorher aber auch nie getestet.

Schauen wir mal ob es so bleibt. 

Es wundert mich nur dass der Fehler wieder kam trotz Buster. Vielleicht war es tatsächlich der GND alleine.

Ich berichte weiter.

Wenn ich versuche den 256 einzeln auszulesen kommt:

Screenshot 2023-12-09 154611.png

depict zeigt halt "found" an, deswegen dachte ich es gäbe ihn...

 

Bzgl. candump faszinierende, wenn auch wenig hilfreiche Ergebnisse. Während Candump parallel läuft hat er bei mir jetzt konsequent (3x probiert) mit folgendem error bei genau diesem did abgebrochen:

Screenshot 2023-12-09 133055.png

Nachdem candump beendet war lief depict dann wieder entweder sauber durch oder mit besagtem "error may retry" ab besagtem did.

 

can0 down=>up ist wie gesagt nicht notwendig damit es wieder funktioniert. Es läuft ja auch sofort nach Neustart von open3e wieder einwandfrei bis zum nächsten error, sofern open3e aber einmal im error "gelandet" ist kommt er halt nicht mehr raus.

Als depict dann nur noch den "error may retry" ausgeworfen hat habe ich ich sofort nach beenden den prozess wieder gestartet und dann lief es wieder. Gleiches mit TimeoutException  - als ich open3e über try/except habe weiterlaufen lassen kamen keine Daten mehr. Nach process-kill und direktem Start von open3e ging alles wieder.

Insofern sieht es für mich als Ahnungsloser so aus als würde sich open3e (bzw. dessen Zugriff auf isotp o.ä.) verschlucken. Woran das nun aber liegt (bzw. welche Systembedingungen bei mir/uns dazu führen dass das passiert) ist mir leider ein Rätsel 😔

Workaround ist halt Neustart des scripts, aber die Ursache würde mich schon echt interessieren und in Anbetracht der Tatsache dass ich es mit verschiedenen älteren und neueren Kernels ausprobiert habe lässt mich vermuten dass es sich nicht alleine erledigt. Zur Erinnerung: mein aktueller Kernel ist vom 29.11.23 und die "klassischen" TimeoutErrors sind da bereits gefixt und treten nicht mehr auf.

schon mal danke für die Info! @Thomas_MG 

 

die Statistik sagt ja nur dass 'nachrichtentechnisch' alles ok ist, also auch die Physik. Wenn jetzt noch ein Timeout auftritt siehst du den glaubich garnicht mehr, es sei denn, es kommen 4 nacheinander. sollte man vlt zumin im -v Mode was einbauen... obwohl - im udsoncan.log sollten sie noch stehen

@Sebliner  du musst zuerst unterscheiden zwischen 0x680 und bsw. 0x684. Auf 0x680 gibt es den did 265 und den liest du auch aus wenn du einfach -r 265 machst. Wenn du keine explizite ECU Adresse angibst, wird immer die 0x680 ('Main Control Unit') genommen.

 

Wenn du die 265 von 0x684 auslesen willst, musst du das hinschreiben: -r 0x684.265

 

Da oben steht (in Zusammenhang mit 0x684) 265 ERROR max retry. Die Meldung wird ausgegeben nachdem 4x versucht wurde, den Datenpunkt zu lesen, und anschliessend wird weiter gegangen zum nächsten DID (das wäre hier dann 266).

 

Die Meldung links ist sehr interessanrt. Sowas hatten wir noch nicht. Bei diesem Fehler (bzw. bei allen anderen ausser den beiden Timeouts) soll depictSystem aussteigen, und es ist ja auch so gemacht, dass dann der zuvor abgefangene Fehler innerhalb der Fehlerbehandlung ge-raise-t wird. Deswegen auch das "During handling of the above exception another exception occured" - in Wirklichkeit ist es kein anderer, sondern eben genau der Fehler. Und depict steigt dann aus und muss neu gestartet werden, dass ist alles richtig so und gewollt.

 

Leider hat dein Dump auf der rechten Seite nichts mit dem Fehler zu tun. Links waren wir ja beim Scannen von 0x684, rechst ist aber nur 0x680 Kommunikation zu sehen (Ausleseversuche von dids 3484 bis 3500, die aber alle nicht existieren und folglich ganz korrekt mit Negative Response (7F), Code 22 (Conditions not correct) auf Attempt ReadDataByIdentifier, SID 22 beantwortet werden).

 

wir müssen mal strukturieren. 'bin gleich zurück...

wir wissen ja so garnicht, bei welchem did (Parameter) der Fehler aufgetreten ist. birgt der udsoncan.log weitere Infos? Komischerweise finde ich Errno 84 nicht in den udsoncan Sourcen.

 

Hast du vlt grad Langeweile und einen online-meeting fähigen Rechner?

Hat hier schon jemand erfolgreich in Home Assistant die MQTT Konfigurationen für Climate und Water_Heater vorgenommen? Habe eine Vitodens und es wäre super, falls jemand die YAML Config teilen könnte, denn ich steig da noch nicht so durch.

 

Einfache Sensors sind rel. simpel zu konfigurieren und die konnte ich anlegen. Und zum Werte schreiben nutze ich Automationen dem Service MQTT Push und alles läuft seit einer Woche stabil. Habe damit die ViCare Zeitprogramme ersetzt.

 

Aber die Climate/HVAC und Water_Boiler Integrationen sind ein bisl komplexer, geschweige denn das ganze Thema MQTT Audodiscovery.

moin Stefan!

kann es sein, dass du ein wenig im Thread 'verrutscht' bist? Aber vielleicht 'erwischst' du ja trotzdem wen, der da weiterhelfen kann... Evtl. schickst du mal @Juergen-B  ne PM, der kennt sich da glaubich ziemlich gut aus.

Hier falls es jemandem hilft die Home Assistant YAML Sensor Config für den Aussentemperaturfühler bei der Vidodens (nur als Beispiel): 

mqtt:
  sensor:
    - name: "Heizung_Aussentemperatur"
      unique_id: "Heizung_Aussentemperatur"
      state_topic: "open3e/OutsideTemperatureSensor/Actual"
      unit_of_measurement: "°C"
      state_class: measurement
      device_class: temperature

 

Ergibt:

Stefan_Ge_0-1702142209325.png

 

 

 

vielleicht was für's Wiki - danke!

 

@Sebliner  ich hab gegoogelt und gefunden, dass der Fehler "Invalid or incomplete multibyte or wide character" garnix mit Kommunikation, sondern mit der Darstellung von 'wide chracters' (sowas wie UTF und so) zu tun hat. Wie der sich jetzt da reinschleicht ist mit ziemlich schleierhaft. Wir wenden ja bei depictSystem überhauft keine Codecs wie O3EUtf8 oder so an!?!

So, zumindest ist jetzt der VX3 CAN-BUS Stecker mit GND belegt und geht an den CAN2USB Adapter. Am E380 sehe ich keinen für mich erreichbaren GND Pin/Anschluss (ausser dem dicken GEGR Kabel).

Die open3e als "development" version von https://github.com/abnoname/open3e installiert.

 

Es sieht zwar ein wenig besser aus, aber ich bekomme einen (neuen?) Fehler:

 

pi@rpixyz:~/open3e $ python3 Open3E_depictSystem.py
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
Traceback (most recent call last):
  File "/home/pi/open3e/Open3E_depictSystem.py", line 75, in scan_cobs
    response = client.send_request(
  File "/home/pi/.local/lib/python3.9/site-packages/udsoncan/client.py", line 2143, in send_request
    self.conn.send(payload)
  File "/home/pi/.local/lib/python3.9/site-packages/udsoncan/connections.py", line 65, in send
    self.specific_send(payload)
  File "/home/pi/.local/lib/python3.9/site-packages/udsoncan/connections.py", line 321, in specific_send
    self.tpsock.send(payload)
  File "/home/pi/.local/lib/python3.9/site-packages/isotp/tpsock/__init__.py", line 89, in send
    return self._socket.send(*args, **kwargs)
OSError: [Errno 105] No buffer space available

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/open3e/Open3E_depictSystem.py", line 282, in <module>
    lstEcus = scan_cobs(startcob, lastcob)
  File "/home/pi/open3e/Open3E_depictSystem.py", line 94, in scan_cobs
    raise Exception(e)
Exception: [Errno 105] No buffer space available

 

 

Am Memory des RPI sollte es nicht (?) liegen!

 

pi@rpixyz:~/open3e $ free -m -t
               total        used        free      shared  buff/cache   available
Mem:             933         115         654           0         163         765
Swap:             99           0          99
Total:          1033         115         754
pi@rpixyz:~/open3e $ 

 

 Hier noch die Statistik.

 

 

pi@rpixyz:~/open3e $ ip -details -statistics 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 minmtu 0 maxmtu 0 
    can state ERROR-PASSIVE restart-ms 0 
	  bitrate 250000 sample-point 0.875 
	  tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  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          6455       194745     181570    numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped missed  mcast   
    3215824    401978   0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    24         3        0       0       0       0  

Ach, und die VX3 wirft dann auch eine Fehlermeldung auf dem ViCare. Aber auch nut "Kommunikationsfehler, der eine Minute später wieder verschwindet ... so wie vorher auch immer

 

[edit] ups, gh's Beitrag verschwunden? eben war hier doch noch einer....

 

welchen Fehler? (Screenshot vergessen?) oben haben wir ja auch grad nen ganz seltsamen...

 

aber deine Fehlerzähler sind wieder im normalen Bereich und 'stabil'?

Mein letztes Post wartet auf einen Moderator ...

interessant! 😎 öfter mal was neues...

sehen die Fehlerzähler denn wieder gut aus?

GND Kabel gezogen, aber python3 Open3E_depictSystem.py steigt mit "Exception: [Errno 105] No buffer space available" aus. Jedoch sieht "free -t -m" gut (?) aus:

pi@rpixyz:~/open3e $ free -m -t
total used free shared buff/cache available
Mem: 933 115 654 0 163 765
Swap: 99 0 99
Total: 1033 115 754

bei mir is eher noch weniger frei. bekommst du nicht mal die allererste Ausgabe "read DID enums ..."?

 

Nein,  versuche gerade im py Code zu verstehen wo es her kommt

   ... irgendwo tief unten in udsoncan/client.py

no chance

unten unter Main und den Args

# peparations
dataIdentifiers = dict(Open3Edatapoints.dataIdentifiers["dids"])
e3Devices = Open3Eenums.E3Enums['Devices']
dicDidEnums = read_didenums("DidEnums.txt")

 

die dataidentifiers sind die Open3Edatatpoints.py. aber sooo groß ist die ja nun auch nicht. Die Enums hat auch nur bei 100kB. Die DidEnums 118k. alles in allem nicht mal n halbes MB. und bis zur DidEnums kommt er ja nicht mal

 

 

Top-Lösungsautoren