EVNotify - überwache den Ladezustand Deines Elektroautos!

[GcAsk]

Danke für die Erklärung:

Im übrigen sollten diese Filter gehen: War von den (erfolgreichen) Tests, muss ich später nochmal testen, ggf. krieg ich das dann schon auch hin:

ATCAF1
ATCFC1
ATCM7FF
ATAR
ATCF7EC

Diagnosebefehle? Was ist daran denn gefährlich?
Diese ATE0 Befehle oder so sind doch laut ELM Doku nur dazu da, die Art und Weise, wie die Antwort zurückkommt (z.b. ohne Echo oder Line Feed), zu bestimmen.

AT D + AT Z- alles auf Default vom Dongle wieder
die anderen echo off, line feed off, usw.

Oder sehe ich nur was nicht?

Auf jeden Fall tausend Dank.

Ich versuche mal nochmal die Befehle später, die ich oben hier gepostet habe. Damit hatten wir damals Erfolg schon beim 2101 Befehl.

[UliZE40]

Du musst da normalerweise gar keine direkten Befehle zu irgendwelchen Fahrzeugsteuergeräten senden sondern einfach nur mit passendem Filter und ATMA passiv zuhören. Fertig. Da kann dann auch nix passieren.

Du solltest mal unterscheiden zwischen Befehlen die du zum ELM-Interpreter sendest du Kommandos die tatsächlich von diesem auf den Fahrzeugbus ausgesendet werden.

Nur die AT-Befehle landen beim ELM der Rest wird quasi ungefiltert ans Fahrzeug durchgeleitet. Daher VORSICHT bzw. wenn man nicht weiß was man da genaut tut: Finger weg!!!

[GcAsk]

Ich sende doch aber nur diese AT Befehle? Das einzige, was ich sonst schicke, ist "2105". Das Kommando, um den Ladezustand zu erhalten.
Und wenn Du die Anspielung machst auf den Wahlschalter, der nicht mehr ging. Das passiert beim Entfernen des Dongle während er Daten sendet bzw angeschlossen ist. Da hat der Chip-Hersteller einen Fehler und mich damals kontaktiert.

Aber danke für die Tipps. Ich gucke mal, ob ich erfolgreich bin.
Ich denke mit den Filtern, die ich zuvor geschrieben habe. Da ich so schon einen Listener für Daten habe, braucht es eigentlich keinen Monitor All Befehl. Muss ich aber mal testen.

[UliZE40]

Ich sende doch aber nur diese AT Befehle? Das einzige, was ich sonst schicke, ist "2105". Das Kommando, um den Ladezustand zu erhalten.

"Nur". Du baust da eine gezielte Verbindung mit einem Steuergerät auf.

[GcAsk]

Kannst Du Dich mal deutlicher ausdrücken?

Wenn Du doch schreibst: Alle AT Befehle sind "harmlos", da sie an den ELM nur gehen. Und ich schicke Dir eine Auflistung an AT Befehlen. Und dann sagst Du ich steuere direkt Steuergeräte an. Wo tu ich das denn? Bin verwirrt.
Dann sag doch, was genau da falsch ist und wo ich was falsch ansteuer?
Ist es 2105? Das ist doch der "offizielle" Befehl zum Ansteuern. Das nutzt auch das Torque Plugin. Versteh jetzt nicht, wo ich hier explizit was ansteuer.

Schön, dass Du da so gut drin bist. Nur dann bitte ich Dich, hier nicht rumzulachen oder so.

[UliZE40]

Ja, 2105 wird direkt auf den CAN-Bus gesendet. Der ELM wickelt dann das relativ komplexe Kommunikationsprotkoll ab um dir die ziemlich lange Antwort des Steuergeräts auf dem UART zuzustellen.
Wie gesagt: Probier doch erstmal einfach die Daten mitzunehmen die die Steuergeräte für die Kommunikation untereinander ohnehin auf den Bus schicken. Da sind normalerweise viele relevante Daten dabei die z. B. für die Anzeige in diversen Displays, zum Energiemangement usw. benötigt werden.
Da fängt man einfach mit einem ungefilterten ATMA an wenn man kein richtiges CAN-Interface zur Hand hat um mal zu sehen was so auf dem Bus los ist. Durch den kleinen Puffer des ELM und das lahme UART wird da aber quasi sofort der Puffer überlaufen. Dann muss man mit Filtern arbeiten um die Datenflut für den ELM auf einzelne PIDs zu beschränken deren Daten dann tröpfchenweise über das UART abfließen können. Mit einem ELS27 über USB geht das deutlich besser weil bis zu 2 MBit/s auf dem UART möglich sind.

[GcAsk]

Danke Dir.

Das klingt ja echt nach einer guten Idee. Dessen war ich mir gar nicht bewusst, dass die Daten auch so anscheinend über den Bus wandern (klar, natürlich ja, aber dass man die so jederzeit dann abrufen kann - ohne explizit noch was zu machen).

Wobei das ja dann echt kurios ist, dass CanZE, Torque und viele weitere das immer explizit anfordern (wie ich). Selbst OpenVehicles - hier für die Zoe z.B.: https://github.com/openvehicles/Open-Ve ... _zoe.c#L90

Wenn ich Dich also richtig verstehe:
ATZ (erstmal alle Einstellungen löschen)
Filter setzen
Monitor All
Jetzt krieg ich die Daten (sind die auch immer dann mit dem Delimiter > ?)

Filter dann wie den, den ich hier oben gepostet habe. Wobei ich in der Doku noch zu doof war, herauszufinden, wie ich das auf PIDs beschränken kann (2101 bzw. 2105)? Weißt Du da was?

Muss mir das auf jeden Fall mal anschauen, ob sich das so implementieren lässt.
/EDIT:
Das hier der Filter:
ATCAF1
ATCFC1
ATCM7FF
ATAR
ATCF7EC

wobei ich ja nur 7E4 bräuchte oder? Muss dann nur 2105 bzw 2101 irgendwie hinbekommen

[UliZE40]

Wie gesagt ist das von Fahrzeug zu Fahrzeug unterschiedlich was da für Daten "frei herumschwirren". Muss man sich beim Ioniq ansehen. Bei der ZOE kenne ich die schon fast auswendig und da bekommt man fast alles relevante direkt um die Ohren gehauen und den Rest kann man sich mit minimalen Berechnungen oder Logiken herleiten. Siehe ZOEdisplay - das ist wirklich rein passiv.
Die Formatierung des ELM kannst und solltest du natürlich nach deinen Bedürfnissen anpassen. Das ist vom Fahrzeug und vor allem von deinem konkreten Interpretercode abhängig. CanZE holt auch viele Daten direkt vom Bus - aber gemischt mit Direktzugriffen auf einzelnen Steuergeräte.

Der Nachteile bei den Direktzugriffen sind:
Nur über Polling, vglw. langsam, aktive Kommunikation mit dem Fahrzeug, komplexes Protokoll (wird durch ELM verborgen/vereinfacht), Abhängigkeit von Softwareversionen des Steuergeräts, i.d.R. genaue Dokumentation erforderlich, unbeabsichtigte Konfigurationsänderungen in Steuergeräten möglich (Vorsicht!).

Die Nachteile beim Mithören am Bus sind:
Große Datenmenge (filtern!), oft eher beschränkt auf ausgewählte Daten die für andere Steuergeräte (dazu gehören auch Displays usw.) relevant sind.

[GcAsk]

Cool, danke Dir für die Aufklärung.

Ich werde heute / morgen mal damit rumspielen. Mal gucken.

Auf jeden Fall klingt das echt gut - den Weg sollte ich gehen. Da hast Du schon recht.

Das Handling gehe ich ja eh an.
Könnte zwar noch sein, dass, wenn das doch erstmal nicht so einfach geht, wie ich das denke, erstmal noch vorerst das direkte Ansteuern über Polling bleibt, schnellstmöglich dann aber gewechselt wird.

Da ich das ganze leicht erweiterbar bzw. austauschbar jetzt aufbaue, sollte das dann nachträglich auch kein großes Problem mehr darstellen.

Danke Dir.

[GcAsk]

Juhu

Nach stundenlanger Arbeit in den letzten Wochen ist jetzt endlich der erste Super-Prototyp von EVNotify Version 2 fertig!
Jippie!

Mit komplett neuem Code, mit komplett neuem Design, mit komplett neuen Möglichkeiten bald, mit neuem OBD2 Handling - sauber, erweiterbar - zukünftig mehr Daten und mehr Fahrzeuge (gebt mir dafür aber noch ein wenig Zeit ).

Die allererste Version geht jetzt in Kürze an die ersten Tester raus - muss noch alles hier vorbereiten, dann sollte die erste Version schon testbar sein.

Das neue Handling für das Auslesen der Daten ist jetzt "plugin" basiert aufgebaut - jedes Fahrzeug hat ein eigenes Handling dann - erlaubt zukünftig auch anderes Handling und Fahrzeuge ( -> @UliZE40 -> kein Polling dann vielleicht irgendwann, sondern lauschen auf dem Bus -> vorerst weiter auf Polling -> gibt dann irgendwann eine Challenge mit Preisgeld -> werde jetzt nach und nach ein wenig Geld "zurücklegen" - auch wenn es vielleicht am Ende "nur" 20-30€ sind).

Ach ja, ich freue mich so.

Es wartet zwar jetzt immer noch super viel Arbeit auf mich, denn schließlich ist das jetzt erstmal nur der Super Prototyp, aber es wird sich lohnen