Climate Solutions Community

Im udsoncan.log war bei mir gar nichts eingetragen. Ich werde am Montag nochmal den 265er did wie beschrieben über 0x684 auslesen. War nur heute schon auf dem Weg zur Arbeit und morgen den ganzen Tag unterwegs 😔   edit: nun doch zumindest mal noch schnell den did von 0x684 ausgelesen und das kam raus: So war es korrekt angefragt? Bei der 2. identischen Anfrage kurz darauf kam dann besagte TimeoutException: candump lief noch parallel, allerdings auch noch open3e mit Abfragen alle 5 sekunden, deswegen ist der log jetzt mega unübersichtlich. Sorry, wollte es nur schnell noch vorm schlafen machen und dann doch länger geschaut 😩 Beim drüberschauen über den candump log scheint es mir so zu sein: direkt nach anfragen des dids kam nichts über 684, nur einmal kurz nach der ersten TimeoutException kamen die gepostet 3 Einträge. Danach kamen keine 684er mehr. Ich werde Montag nochmal richtig schauen und ordentlich loggen, aber ich bekomme so schon Ärger von meiner Frau und muss erst mal ins Bett 😬   Einen online-meeting fähigen Rechner habe ich  - lohnt es sich sich einmal zu verabreden damit ich direkt alles testen kann was euch eventuell hilft bei der Fehlersuche? Gibts hier eigentlich PNs? 😅 ... Mehr anzeigen

Wenn ich versuche den 256 einzeln auszulesen kommt: 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: 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. ... Mehr anzeigen

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: 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? ... Mehr anzeigen

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 😅 ... Mehr anzeigen

Ein paar Hinweise von mir. Zunächst bzgl. buster und neuerem Kernel  - dazu hatte ich eine mögliche Lösung im github-thread über backports gepostet: klick    ABER  - und damit zum eigentlichen Problem  - mir scheint dass TimeoutException nicht über den Kernel gefixt ist/andere Ursachen hat. Ich habe mit diesem Problem auch zu kämpfen und folgende Erkenntnisse gewonnen:   - als ich es auf meinem pi4 laufen hatte (quasi debian12 mit kernel vom Februar) lief es die Tage ohne jeden error. - vm mit debian 12 und schwierigem Kernel (August): TimeoutErrors (dank open3e "ausgehebelt") und alle paar Tage TimeoutException => Abbruch - also eine vm mit buster und älterem Kernel gemacht (Juli22) => keine TimeoutErrors, aber alle paar Stunden/Tage Abbruch durch TimeoutException - dachte der kernel ist vielleicht ZU alt, also eine vm mit arch und neuem kernel gemacht (29.11.23) => keine TimeoutErrors mehr dank neuem Kernel, aber trotzdem alle paar Tage/stunden TimeoutException + Abbruch   Mein erster Lösungsansatz war ähnlich @Thomas_MG und ich hatte in Open3e ein weiteres try/except für den TimeoutException eingefügt und dann das Ergebnis: Programm läuft weiter und alle 20 Sekunden kommt ein neuer TimeoutException. Allerdings schien er bei mir auch keine Daten mehr zu übertragen. Eventuell ist relevant bei welchem Datenpunkt der Fehler erstmals auftritt und alle Datenpunkte bis dahin werden weiter übertragen? Ist aber nur geraten ohne jede Ahnung... Also weiter getestet: open3e kann nach Abbruch über TimeoutException neu gestartet werden und funktioniert dann bis zum nächsten wieder einwandfrei  - ohne den Can-Adapter vorher einmal down/up zu nehmen. Gleichzeitig habe ich dann noch E2onCAN laufen lassen und das lief ohne Probleme weiter  - auch nach TimeoutException von open3e. Ich würde daraus schließen dass das lesen problemlos weiter funktioniert, es aber irgendwie Schwierigkeiten gibt auf den Bus zu schreiben. Das Problem bleibt wenn open3e es direkt nochmals versucht (über try/except), allerdings nicht wenn das Problem einfach neu gestartet wird.   Mein workaround ist aktuell ebenfalls über einen automatischen Neustart bei TimeoutException (habe es über einen systemd-service realisiert). Eventuell könnte man das aber direkt über open3e umsetzen? ChatGPT schlägt da eine Lösung über subprocess vor...   In jedem Falle wäre zu prüfen ob auch der TimeoutException tatsächlich durch den Kernel verursacht wird und definitiv bereits behoben ist (was meiner Beobachtung mit arch und echt neuem kernel eigentlich widerspricht  - denn der TimeoutError ist dort ja bereits erfolgreich behoben)   Ideen? Kann ich noch irgendwas testen? Bei github noch einen issue mit explizit TimeoutException erstellen?   Danke für eure Unterstützung 😊 ... Mehr anzeigen