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!
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:
Vitocal 250 Kältekreisübersicht: View und Installationsanleitung gibt's hier: https://github.com/MyHomeMyData/iob.vis.vitocal250.git
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
Moin zusammen, wow, hab die letzten Tage dieses phantastische Projekt beobachtet und mir natürlich auch schon die Hardware beschafft, zusammengeschraubt und an meine V300-B3HG gestöpselt. Und was soll ich sagen. Läuft auf meinem Pi3 perfekt lokal. Muss mir nur noch die relevanten Adressen raussuchen, erstmal alles nur lesend. Hab dann versucht die Daten zu meinem Home Assistant MQTT Broker auf meinem Nuc zu senden. Da scheitert es leider bei mir und ich habe nirgendwo eine für mich nachvollziehbare Integration gefunden.
Im Protokoll des MQTT Brokers sehe ich den Connect
2023-12-07 11:10:10: New connection from 192.168.2.77:48747 on port 1883.
2023-12-07 11:10:10: New client connected from 192.168.2.77:48747 as Open3E_1701943810703 (p2, c1, k60, u'open3E').
Hab dann in der Configuration.yaml einen Sensor testweise hinzugefügt:
mqtt:
sensor:
- name: "Open3E_526"
state_topic: Open3E_1701943267569/526
unique_id: Open3E_526
icon: mdi:tbd
Leider komme ich jetzt nicht weiter. Den Sensor kann ich abfragen unter Entwicklerwerkzeuge, aber leider kommen keine Werte an.
Jemand ne Idee, wie ich da weiter komme. Fehlt glaube ich nicht mehr viel.
Ist die Frage hier überhaupt sinnvoll aufgehoben oder lieber im github unter discussions?
Hallo.
Ich hab die gleiche Konfiguration. Gehe davon aus du hast den Mosquitto MQTT laufen auf dem NUC. Wenn username und pwd angelegt hast, musst Du das mit übermitteln.
Du musst auf dem RASPI nachdem Du depictsystem gemacht hast, den Open3Eclient.py starten aus dem terminal heraus. Am Anfang habe ich es ohne args gemacht.
python3 Open3Eclient.py -c can0 -dev vdens -m 192.168.2.77:1883:vdens -muser usrname:pwd -r 268,269 -t 30 &
Du kannst Dir parallel auf irgendeinem Rechner in deinem Netzwerk den MQTT Explorer installieren. Den mit deinem NUC verbinden und dann siehst Du schon die topics vdens mit den DIDs 268 und 269 im obigen Bsp.
Dort heraus kannst Du das state topic kopieren und dir in HA eine mqtt.yaml anlegen und diese DIDs einfügen. Ein sensor sieht z.B. so aus (Bsp von mir):
sensor:
#Sensor für aktuellen Volumenstrom WP
- name: "VCCAN_Volumenstrom"
unique_id: "VCCAN_Volumenstrom"
state_topic: "vitocal/1043_AllengraSensor/Actual"
unit_of_measurement: 'l/h'
state_class: measurement
Dann kannst Du wie gewohnt den sensor verwenden in deinen Dashboard, Automatisierungen, etc.
Wo wird der gelbe Stecker bei der 252 angebracht?
Perfekt, so funktionierts! Hilfe zur Selbsthilfe, vielen lieben Dank! mqtt -Explorer war der Trick, welcher mir gefehlt hat. Kann mir nun die relevanten Daten aus Open3E rausholen.
Gibt es irgendwo eine Übersicht, welche Parameter bei der 300W-B3HG relevant sind, sprich Parameterliste oder geht man manuell alle Einträge durch und schaut, wo etwas sinnvolles ankommt?
Wenn Du Open3e_depictSystem.py durchlaufen lässt siehst Du alle Datapoints für deine Addressen. Der Aufruf prüft die bekannten Device Addressen und die dazugehörigen Datapoints. Kannst dir auch alle Datapoints in Open3E_datapoints.py anschauen. Heist aber nicht dass die 300 alle hat. Einfach depictSystem durchlaufen lassen.
Gerne mein Ziel wäre es allerdings das Wiki wieder bei HerrP "unterzubringen". Ich habe letzlich "nur" meine Erfahrungen / Schritte zusammengetragen.
Ein Wiki lebt, um so mehr sich daran beteiligen.
Soweit ich da sehe, betrifft das nur die "Code" section. Auf das Wiki ist das nicht so einfach anzuwenden... Ich schaue gerade was sich da noch findet.
Das habe ich akutell dazu gefunden: https://til.simonwillison.net/github/migrate-github-wiki
Ich bin total begeistert wie der Gemeinschaftsgeist um sich greift! 😀 'Unser' @JörgWende hatte sich schon Gedanken um ein Wiki gemacht, ich hab ihn intern auch noch mal angetriggert, vielleicht hat er ja schon einen Plan...
@Thomas_MG vielen Dank dass du @garagenlager schon mal weiter geholfen hast! Ich war heute mit Holz Rücken ziemlich beschäftigt - auch der nächste Winter wird mit ziemlicher Wahrscheinlichkeit kommen. Leider fehlt mir das Pferd, der Hund ist zu blöd (oder so geschickt, so zu tun, als verstünde sie nicht, was sie tun soll, um sich die Arbeit zu ersparen), und so muss ich die ganze Schufterei selber machen, glücklicherweise mit nem Nachbarn zusammen...
@ghNeandr hast du dein System wieder am laufen? Hast du mal Buster in Erwägung gezogen? das würde zum 2er ja auch ganz gut passen...
Ich hab nochmal drüber nachgedacht... Serielle (RS232 und so) Kommunikation habe ich immer mit 2..3 (re)tries programmiert, damit es egal ist, wenn mal was schief geht. Bei CAN garantieren aber schon die unteren Schichten im OSI Modell eine sichere Übertragung, und die 'Software Gurus' haben gesagt, bei der Python Geschichte würde man keine Exceptions 'verschleiern', sondern das aufrufende System soll damit umgehen (z.B. so wie Thomas das jetzt gemacht hat). Im aktuellen Fall frage ich mich allerdings, ob man es nicht doch in open3e regeln sollte, weil es immer wieder Thema wird (keine Ahnung wie lange der Kernel Fix noch braucht, bis er sich überall durchgesetzt hat)?!
@Juergen-B du hattest doch auch schon zwei Instanzen betrieben - gab es da auch 'Hänger' in der 2. Instanz?
Grüsse, Dank an alle Mitwirkende - weiter so!!
Phil
Hallo Phil, ich find's auch klasse, wie sich das Thema entwickelt und wie breit die Unterstütung inzwischen ist. Jetzt fehlt nur noch das Weihnachtsgeschenk von Viessmann: Die Zusage, uns zu unterstützen, mit Informationen zu versorgen und Fragen zu beantworten. Es soll ja schon Weihnachtswunder gegeben haben 😉
Zu Deiner Frage: Ja, ich hatte 2 Instanzen als Services laufen. Auf dem gleichen CAN-Bus für unterschiedliche ECU-Adressen (0x680 und 0x6a1). Das hat viele Wochen problemlos und stabil funktioniert. Im Status des jeweiligen Service sieht man ja die Laufzeit. Das hat immer gepasst, also keine Abstürze oder Restarts.
Inzwischen bin ich komplett auf den Listener-Mode mit einer Instanz umgestiegen.
Gruß, Jürgen
Morgen. Ich habe immer noch abstürze und das regt mich so auf dass ich mir schnell Buster installiert habe. Dummerweise kommt beim start von Open3e immer diese Fehlermeldung. Hat jemand ne Idee:
Der Adapter fährt hoch wenn ich ihn starte.
Danke!
Funktioniert candump? Wie sieht die Kommandozeile aus?
Ja.
Das sieht gut aus. Und die Kommandozeile?
>> Buster installiert ... kommt beim start von Open3e immer diese Fehlermeldung.
du musst ein update-upgrade machen. Das 'wehrt' sich erstmal, weil Buster keine aktuelle Version mehr ist, aber wenn du die Meldung, die dazu kommt, auf google eingibst, bekommst du die Lösung, was du machen musst, damit es trotzdem geht.
ich hatte irgendwo ein '#' weggemacht oder gesetzt und dann einen etwas geänderten upgrade Befehl genutzt. leider hatte ich das nicht aufgeschrieben, aber wenn du es nicht findest, poste bitte die genaue Meldung und ich finde es hoffentlich wieder...
Danke für die Tipps. Hab das upgrade ausgeführt. Die Fehlermeldung wegen des alten Betriebssystems kam nicht (eventuell weil ich vorher schon ein update --allow-releaseinfo-change gemacht habe.
Ich hab das remote gemacht und jetzt lässt er mich nicht mehr per ssh drauf (connection refused).
Muss heute abend zu Hause nachschauen.
Ja … lasst uns das koordinieren. Wiki‘s im GitHub lassen sich leider nicht direkt ‚forken‘ - da brauchen wir einen anderen Weg.
Diskussion: https://github.com/abnoname/open3e/discussions/53
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 😊
@HerrP >>hast du dein System wieder am laufen? Hast du mal Buster in Erwägung gezogen? das würde zum 2er ja auch ganz gut passen...
Danke der Nachfrage und Nein das "System" läuft nicht wieder, nicht der CAN etc
Das ist einerseits dem Alltagsgeschäft geschuldet, aber auch verschiedener Unklarheiten.
Mal einen Blick auf mein gesamtes Projekt:
Die neue WP/PV Anlage monitoren und auswerten, mehr als was die ViCare bietet.
Im Moment nutze ich für die WP Seite ViAPI mit Nodered. Das geht zumindest so weit gut, als ich sehr viele Datenpunkte bekomme. Die Aufarbeitung hakt noch, aber das ist dann Standardfleißaufgabe.
Über die ViAPI bekomme ich keine PV Datenpunkte abgefragt, nicht mit dem Viessmann Basic, da müsste ich ein Abo abschließen. Aber der dann mögliche, kostenpflichtige Datenumfang ist lachhaft.
Deshalb die Hoffnung auf eine Lösung mit dem CAN/Open3e Ansatz.
CAN/Open3e Projekt Status:
-- CAN Bus ist nicht durchgängig. Die Verbindung wird erst im Januar erfolgen.
-- Der CAN2USB Adapter ist am E3800CB angeschlossen. Nach anfänglichen Zugriffen streikte der CAN Zugriff.
Die PV Anlage und die ViCare gab Fehlermeldungen, sobald der CAN2USB Adapter angeschlossen wurde:
Kommunikationsstörung: Externer CAN-BUS mit Uhrzeit und "Batterie"
Unmittelbar danach kam dann "Gelöst" mit Bezug auf die vorherige Meldung. Da ganze wiederholte sich alle paar Minuten. Habe dann den Adapter abgezogen, danach war Ruhe. Heute morgen Adapter wieder aufgesteckt, bisher keine Fehlermeldungen.
Auf dem RPI sind keine Open3e Funktionen aktiv, dh. es ist unklar, warum die Fehlermeldungen kamen und jetzt nicht mehr.
Die Probleme von Open3e mit verschiedenen, neueren Betriebssystemen machen mir zusätzliche Schwierigkeiten. Wie gesagt läuft mein Produktiv-RPI mit Nodered/MQTT und einer Reihe Tasmota Geräte. Dieser Teile ist wichtig für den Tagesbetrieb und dürfen nicht gestört werden. Der Produktiv-RPI hat:
Linux rpixyz 6.1.65-v7+ #1703 SMP Tue Dec 5 16:20:29 GMT 2023 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
Raspberry Pi 2 Model B Rev 1.1
Auf diesem Status sollte zusätzlich Open3e laufen. Zurück auf Buster oder ähnlich verbietet sich andererseits, da die jetzt einwandfrei laufenden Funktionen Schwierigkeiten mit Buster hatten.
Außerdem sollte Open3e auf diesem RPI laufen, da dieser am LAN hängt. Die Teile sind selbstverständlich in der Nähe von WP/PV/Batterie im Keller installiert und dorthin ist das WLAN zu unstabil. Ein weiter RPI geht dort nicht, kein zusätzliches LAN Port frei.
Ziel ist also:
-- Open3e auf Bullseye oder neuer ... jede Lösung hierzu ist highly welcomed
-- Verbindung der CAN Buse zwischen WP und PV/Batterie ... das wir dann erst im Janaur oder so erfolgen.
-- MUSS: Auf einem RPI Verbindung Open3e mit Nodered/MQTT zum CAN-BUS Monitoren, Auswerten, Aufzeichnen und was sonst noch alles Spaß macht.
danke für die Rückmeldung! dass open3e auch mit den alktuellen Systemen laufen wird hoffe ich doch sehr, aber es ist wie gesagt eine Frage der Zeit. Das Update vom April mit dem ISO-TP Issue ist etwa vor einem Monat überall (nicht nur bei open3e) angekommen und hat 'plötzlich' haufenweise zu den inzwischen hinlänglich bekannten Fehlern geführt. Ich hab keine Ahnung, wie lange es gedauert hatte, bis das Issue 'geortet' und beseitigt wurde, aber die Zeit zum Durchmigrieren wird ähnlich sein wie beim Einbauen des Problems.
Es gibt noch so Lösungsansätze wie den out-of-tree iso-tp driver und so, aber auf einem Produktivsystem würde ich dererlei Experimente nicht unbedingt empfehlen.
Da hilft dann eben nur Geduld und die Hoffnung, dass die Sache wirklich in Ordnung gebracht wurde. open3e ist da jedenfalls unschuldig, und alles was wir tun können, ist, den Fehler zu ignorieren und ggf. ein Retry einbauen.
Ich glaube, das werde ich machen, auch wenn es 'sich nicht ziemt', aber dann läuft es zumindest irgendwie. depictSystem wird damit allerdings nur schwerlich zu realisieren sein, weil das guckt halt, was da ist, und wenn es mal da ist und mal nicht, können wir auch nur schwerlich ein sicheres Abbild machen.
~~~~~~~~~~~~~~~~
Wenn der CAN Adapter zu Problemen im System führt, wenn er nur elektrisch verbunden wird (nicht gestartet), und dann mal und mal nicht, dann ist das mit an Sicherherit grenzender Wahrscheinlichkeit das Problem mit dem fehlenden CAN_GND (es sei denn der Adapter wäre durch ESD oder so zerschossen, oder vlt reicht es, ihn mit falscher Baudrate zu initialisieren).
Der E380 hat wenigstens noch PE/N, was zwar eine denkbar schlechte Bezugsmasse ist, aber wahrscheinlich hat Viessmann den GND von der VX3 auch irgendwie an PE gekoppelt, und so reicht es im Rahmen der -/+27..40V um zu funktionieren.
Der isolierte CAN Adapter hat garkeinen Massebezug, da reicht schon eine ungünstige Phasenlage an irgendeinem Filterkondensator eines Schaltnetzteils, und der Adapter driftet irgendwohin (deswegen verschwindet der Fehler dann auch wieder, wenn es der 25k Widerstand geschafft hat, das Potential langsam ranzuziehen...).
Verbinde bitte irgendwie das CAN_GND von der VX3 mit dem CAN_GND (Pin 3!) deines Adapters. Dann ist das in trockenen Tüchern.
Zur allergrößten Not leg den CAN_GND vom Adapter an PE/N, vielleicht über 1k Widerstand oder so. Was andres kann der E380 ja auch nicht machen. Wirklich, ich verstehe nicht, wie man so eine Schei... bauen kann, und auch nicht, wie Viessman sowas dann auch noch einkaufen kann. Da haben wieder nur irgendwelche Business Fraggles geguck "wer labelt uns einen Energiezähler mit CAN?" aber die Ingenieure wurden nicht einbezogen...
Grüsse!
Phil
So sieht meine Installation des VX3/E380 CAN-BUS aus:
Da kann ich wohl GND erstmal vergessen. Der Kabelmantel ist definitiv nicht mit GND verbunden. An beiden Enden gecheckt.
Hey, super Projekt was ihr hier gestartet habt und hoffentlich zeigt es Viessmann auch, dass offene Lösungen gewünscht sind.
Ich selber habe die kleine VX3 4.6 1 Phasig, den Zähler e3100cb und die Gridbox. Leider nicht das gelbe vom Ei....
Besteht eine Chance, dass auch diese "alte" VX3 irgendwie ausgelesen werden kann? In source code konnte ich bisher nur Hinweise auf die 3 Phasigen VX3 finden (ThreePhaseInverterCurrentApparentPower). Auch zu dem Zähler e3100cb gibt es nicht super viele Infos. Beide reden aber über den Canbus miteinander.
Gruß
@ghNeandr kannst du denn den Adapter nicht einfach an die Klemme von der VX3 machen, wo jetzt der Widerstand dran sitzt, und die T-Brücke am E380 wieder rein machen?
Ich weiss nicht, wie ich es noch anders erklären soll - ein isolierter Adapter ist potentialfrei, braucht aber einen Potentialbezug, damit die -27..40V aus dem Datenblatt eingehalten werden. Ohne ein Kabel ist das eine äusserst wackelige Angelegenheit...
Hast du ein Multimeter oder im besten Fall ein Oszilloskop? dann könntest du mal messen, ob das Bezugspotential vom E380 die PE/N Klemme links ist.
@Flopsing aber deine Anlage hat einen CAN Bus oder? Dann den Adapter dran und depictSystem laufen lassen (und bitte ein Systen ohne den Timeout Kernel Issue nehmen). Es kann gut sein, dass bei den Werten dann L2 und L3 eben 0 sind aber der Rest funktioniert.
1824 : O3EComplexType(16, "ThreePhaseInverterCurrentPower", [
O3EInt32(string_len=4, idStr="cumulated", scale=1),
O3EInt32(string_len=4, idStr="L1", scale=1),
O3EInt32(string_len=4, idStr="L2", scale=1),
O3EInt32(string_len=4, idStr="L3", scale=1)]),
1825 : O3EComplexType(16, "ThreePhaseInverterCurrentApparentPower", [
O3EInt32(string_len=4, idStr="cumulated", scale=1),
O3EInt32(string_len=4, idStr="L1", scale=1),
O3EInt32(string_len=4, idStr="L2", scale=1),
O3EInt32(string_len=4, idStr="L3", scale=1)]),
Es gibt zwar schon wieder ein paar neue Datenpunkte, aber die 1-phasigen wären wohl eher älter, und wenn es sie gäbe, ständen sie dabei...
Den Energiezähler kannst du allerhöchstwahrscheinlich mit E3onCAN mitlesen.
Habs Dann auch mal geschafft, ioBroker und mqtt auf den Raspi zu bringen. Nur den gelben Stecker bei der 252 muss ich noch finden sowie herausfinden, wie das dann funktioniert. Als blutiger Anfänger, sehr schwierig für mich.
@Awot252 schrieb:Habs Dann auch mal geschafft, ioBroker und mqtt auf den Raspi zu bringen. Nur den gelben Stecker bei der 252 muss ich noch finden sowie herausfinden, wie das dann funktioniert. Als blutiger Anfänger, sehr schwierig für mich.
Scheinbar musst du die Innenheiheit aufmachen, dann scheint es eine komfortabele Anschlussleiste zu geben.
Steht in der Montageanleitung für die 252.
TimeoutError, TimeoutException - ich hab jetzt die Faxen dicke 😎
und es ist mir jetzt auch egal, ob 'man das macht' oder nicht, ich habe es jetzt eingebaut:
TimeoutError und TimeoutException werden jetzt direkt in der class getrapt und im Falle eines Falles werden bis zu 3 Retries gemacht.
Wenn es auch beim 4. Mal immer noch nicht geklappt hat, erfolgt eine Meldung in der Console und es kommt eben kein Wert, aber das Skript läuft unbeeindruckt weiter.
Die Fehlerbehandlung muss so kompliziert sein, weil das eine ein generischer Fehler ist und der andre aus der usdoncan Lib kommt.
Negative Response Exception und so sind damit nicht unterdrückt, die führen weiterhin zum Fehler und sollen das auch.
Ich habe das auch für den DID Scan in depictSystem eingebaut, für den COB Scan geht es leider nicht (so einfach), weil da Timeout die normale Reaktion ist, wenn eine ECU nicht reagiert weil sie nicht da ist. Man könnte natürlich bei jeder ECU fragen "bist du echt nicht da? wirklich nicht? auch gaaaanz sicher nicht??" aber dann dauert das Ganze nochmal dreimal so lang und selbst dann ist es nicht wirklich sicher... Ich werde mal bei den Car Hacking Tools gucken, ob es noch eine andre Möglichkeit gibt, die Anwesenheit einer ECU festzustellen, aber ich fürchte ein bugy System ist und bleibt eine unsichere Sache, da kann man programmieren so viel man will 😕
@Sebliner dass es bei E3onCAN nicht passiert, hängt mit dem eigentlichen Problem zusammen. Beim nur 'Mithören' gerät der ISO-TP Kern nicht in Gefahr, in diese Race Condition zu geraten, weil es da kein Race gibt, das mal so und mal so ausgeht und eben mal diesen oder jenen Timeout verursacht. Wegen der Race Condition ist es auch sinnlos, vorm Retry länger zu warten, weil das Race schon vorbei ist, wenn der Fehler kommt (eigentlich bräuchte man garnicht warten). Das ist alles schon genau erforscht, geklärt und eben gefixt. In dem Issue Thread https://github.com/pylessard/python-can-isotp/issues/92 bei dem Autor gibt es ausgiebig Info und Links dazu, da kann man das alles haargenau nachlesen. Es nutzt aber nichts, davon kommt der Fix auch nicht schneller in den Distributionen an.
Ich hoffe, jetzt ist aber soweit zumindest erstmal Ruhe 🙂
ist online im develop branch. alpha geteste von mir mit provozierten Timeouts (bei mir gibt es ja keinen bugy Kernel), bitte testet es auch und gebt Rückmeldung falls noch was hakt (oder auch wenn alles perfekt ist 😉 )
Grüsse & viel Spass damit!
Benutzer | Anzahl |
---|---|
5 | |
2 | |
2 | |
1 | |
1 |