EVNotify - überwache den Ladezustand Deines Elektroautos!

[KD Kona]

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!!!

In der c´t 2018 H.15 ist ein interessanter Artikel über OBD2 Nachrüstungen.
Unter anderem geht es auch um die Sicherheit für die dauerhafte Benutzung im Auto.
Ich gebe UliZE40 Recht: Vorsicht. Die Dongle sollten ein E- Mark Zertifikat besitzen ( siehe c`t).
https://phoenix-testlab.de/de/produkt-z ... ent/e-mark

[GcAsk]

Ich habe Uli ja auch nicht widersprochen - ganz im Gegenteil.
Wer will, kann das gerne so zukünftig dann umstellen - gebe auch gerne eine finanzielle Belohnung dafür. Ganz ohne wird man nicht auskommen, wenn man zukünftig mehr Daten erfassen will - das machen auch die "großen" anderen Apps wie gesagt.
Allgemein übrigens: Das ganze CAN System ist kacke. Autos sind absolut unsicher (ausgenommen Tesla -die sind da schon etwas besser - aber auch nicht perfekt). Du kannst froh sein, dass Dein IONIQ nicht am Netz hängt. Letztens übrigens ein nettes Video dazu gesehen, wie leicht man dann (durch einen Fehler beim Hersteller in der Software) die komplette Kontrolle des Autos übernehmen kann.

Apropos - die kleine Bounty-Program-Challenge von mir letztens hab ich jetzt selbst gemeistert
SOH wird nun in EVNotify V2 ausgelesen, heute oder die Tage kommen dann noch viele weitere Daten und damit auch Support für weitere (Hybrid-)Fahrzeuge.
Danke an @olsvse und @UliZE40 - ihr habt mir dann geholfen, das ganze etwas besser zu verstehen

Ein großer Meilenstein!
Die Entwicklung von V2 kann auf Twitter, Twitch und Slack mitverfolgt werden

Das ganze hab ich jetzt plugin basiert und dynamisch erweiterbar aufgebaut - sprich, wenn es jemand schafft, die Daten auszulesen, ohne aktiv Kommandos zu setzen, kann man das dann zukünftig einfach so machen

[olsvse]

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.

Ich verstehe hier das Buffer problem nicht.
Wo tritt es auf?
Im ELM oder im UART des Bluetooth-Moduls im Dongel?
Am Bluetooth Modul des Clients?
Oder am UART des Client?
Bei den ersten beiden Fällen wüste ich nicht wie ich Filtern sollte außer mit dem Filterbefehl des ELM innerhalb des ELM.
Beim Client könnte man die Pollingfrequenz erhöhen damit man rechtzeitig alles ausgelesen bekommt. Am rest kann ich doch nichts einfach Programmieren. Das ust doch alles Fix.


Gruß,
OlSvSe

[DavidW]

Ja, 2105 wird direkt auf den CAN-Bus gesendet. .

Auf 2101 kann man auch einige interessante Daten auslesen.
Ist das auch CAN Bus?

[UliZE40]

Das UART ist die serielle Schnittstelle zwischen ELM und BT-Model (oder WiFi, USB oder RS232).
Diese ist aber im Fall von den Drahtlos-Dongles (BT und WiFi) nicht beidseitig hinsicht der Baudrate konfigurierbar, da man auf der Seite des Drahlosmoduls keine Zugriffsmöglichkeit auf diesen Parameter hat.
Diese interne Schnittstelle läuft häufig nur mit fest vom Hersteller vorgegebenen 38400 Baud, selten auch mal 115200 Baud.
Da der ELM aber auch keine Binärdaten verarbeitet sondern ASCII-Text und Hexcodes mit weiteren zusätzlichen Fülldaten (Leerzeichen, Doppelpunkte, Zeilenumbrüche, usw.) ausgibt fällt für jedes eingehende Byte vom CAN-Bus welches den ELM zum UART passieren soll real die zwei bis dreifache Übertragungsdatenmenge an. Vor dem UART sitzt im ELM ein kleiner Puffer. Kommen vom CAN-Bus nun zu viele Daten rein läuft dieser Puffer über und der ELM meldet ziemlich bytereich per ASCII-Text einen Overflow ("BUFFER FULL"), der das erkannte Problem zusätzlich verstärkt.

Der CAN-Bus arbeitet i.d.R. mit 500.000 Baud. Auch wenn dieser natürlich niemals zu 100% der Zeit mit Daten belegt ist steht diesem selbst bei ca. 20% Auslastung mit rechnerisch 100.000 Bit/s nur ein möglicher Abfluss durch den ELM zum UART von ca. 12000 Bit/s zur Verfügung. Daher läuft der Puffer in kürzester Zeit über wenn man ungefiltert alle CAN-Kommunikation monitoren will.
Man muss den ELM daher vorher explizit den Datenstrom auf z. B. eine einzige filtern lassen. Dann ist die Datenrate niedrig genug. Da man allerdings eigentlich Daten über mehrere PIDs verteilt erfassen will muss man bei der ELM-Krücke dann ständig aktiv den Monitor-Mode verlassen, den Filter neu programmieren und wieder in den Monitor-Mode wechseln und warten bis mindestens ein Datagramm mit der gewünschten PID eingetroffen ist. Da dies auch mal bis zu 1 Sekunde bei manchen PIDs dauern kann ist das nicht gerade effizient.

Bei den ELS27-Adaptern (USB) kann man die UART-Geschwindigkeit z. B. auf 2 MBaud setzen und deren Puffer ist zusätzlich wesentlich größer. Da gibt es dann solche Probleme nicht.
Auch bei echten CAN-Interfaces ohne Interpreter-Chip hat man mit sowas natürlich keine Probleme und kann den gesamten Datenstrom entweder mit Mehrfach-PID-Filtern vorsortieren oder gleich den gesamten Datenstrom von der CPU verarbeiten lassen.

Wie man es auch dreht: Ich hoffe man hat erkannt dass dieses ganze ELM-Zeugs eigentlich ein ziemlich unnötiger Krampf ist. Mit jedem Arduino, ESP & Co. kommt man in gleich mehrfacher Hinsicht deutlich schneller (und nachvollziehbarer) zum Ziel.

[GcAsk]

@DavidW
Alles, was kein AT Befehl ist, geht direkt (mehr oder weniger ungefiltert) an den Bus. Auch ein simples 010D, welches die derzeitige Geschwindigkeit bei Verbrennern ausgibt. Gerade bei Befehlen, die bekannt sind, wie hier auch, ist das an sich nicht das große Problem, selbst unbekannte Befehle werden dann einfach mit einem "?" quittiert. Wenn es aber natürlich einen Implementierungsfehler gibt (z.B. beim Dongle), dann kann man versehentlich natürlich irgendwas unbewusst verändern, da hat @UliZE40 natürlich vollkommen recht.
Um das Risiko eines solchen Falles so gering wie möglich zu halten, könnte man eben direkt "lauschen", was da so abgeht - und sich die gewünschten Bytes einfach abgreifen - anstelle diese explizit mit einem Kommando anzufordern (eben begrenzt auf wenige Daten - nicht alles wandert da einfach so drum herum - explizites Anfordern müsste man also so oder so machen).

EVNotify V2 ist wie gesagt adaptiv erweiterbar jetzt aufgebaut - wenn das wer schafft, kann das gerne jemand machen - wie gesagt, finanzielle Belohnung von mir gibt es auch, wer will.

@UliZE40 Vielen Dank für die gute Erklärung. Ich gebe Dir natürlich da vollkommen recht. Ein Arduino ist sicherlich angebrachter, eben nicht so leicht anzuwenden (der große Vorteil von EVNotify). Und natürlich ist alles, was nicht noch zusätzlich interpretiert werden muss, schneller - und auch weniger gefährlich. Denn Fehler können immer eingebaut werden (Hersteller, Dongle, Software,..).

@All
EVNotify V2 Entwicklung ist in vollem Gang, wird derzeit geschlossen auf Slack getestet in einem kleinen Nutzerkreis. Sobald es hier eine gute brauchbare Version gibt, wird diese für alle Beta-Tester ausgerollt. Wenn dann hier alles gut läuft, gibt es diese für alle Nutzer dann.

[GcAsk]

Hallo ihr Lieben,

mein 2.000 Beitrag soll hier EVNotify V2 gewidmet werden.

Vor über einem Jahr hab ich EVNotify hier vorgestellt.
Anfangs noch am eigenen bzw. dem Auto meiner Mutter getestet - einem Verbrenner. Mit der aktuellen Geschwindigkeit. Als das funktionierte, war ein großer Meilenstein für mich persönlich erreicht. Etwas zu schaffen, was ich nie zuvor gemacht habe. Etwas zu kreieren, woran ich nie geglaubt hatte, dass ich es schaffen würde.
Doch was ich gelernt habe, ist nicht aufzugeben, an sich zu glauben. Weiter zu machen.
Tester geholt - das Gefühl, wenn man dann hört, dass es geht - bei einem Auto, welches man nicht mal besitzt, man noch nie gesehen hat - aber eine Möglichkeit programmieren konnte, den Ladezustand aus der Ferne zu überwachen. Toll.
Ich entschied mich, alles open Source zu machen. Jedem die Möglichkeit zu bieten. Kostenlos.
Ein richtiges Projekt entstand.
Immer mehr haben EVNotify genutzt. Inzwischen gibt es hunderte an Nutzern, die EVNotify nutzen. Denen ich den Alltag erleichtern konnte. Das freut mich!
Nichts desto trotz gab es viele Hürden, die ich überwinden musste, die nun letztendlich dazu führten, dass ich mich entschieden habe, an "v2" zu arbeiten. Einer komplett neuen Version, die auf komplett neuem Code basiert. Vielleicht nicht perfekt - aber wesentlich besser. Erweiterbar. Das ist wichtig.
Viele, viele Stunden hab ich nun schon an v2 investiert - und vieles erreicht. Noch bin ich lange nicht fertig - aber es wird sich lohnen. Es lohnt sich jetzt schon.

Der Super-Prototyp von v2 kann nun seit heute nicht nur den Ladezustand vom Display auslesen, nein, auch den SOH, Reichweite individuell berechnen (sowieso - alles ab sofort ist "plugin" basiert bzw. erweiterbar aufgebaut - jedes Auto hat sein eigenes Handling - super erweiterbar!) - und - SOC BMS - und damit einhergehend sind nun im Super Prototypen nicht nur der Hyundai IONIQ Elektro und der Kia Soul EV, wie bisweilen, unterstützt - nein, ab sofort dann auch der Hyundai IONIQ Hybrid, Hyundai IONIQ PlugIn Hybrid, Kia Optima PHEV und der Kia Ray EV. Weitere Autos plane ich in Kürze.
V2 wird natürlich jetzt noch Zeit brauchen, bis es so reif dann ist, dass es "v1" ablösen kann. Bis dahin gibt es immer wieder hier, auf Twitter, auf Twitch und auf Slack Updates (dort werden diese auch getestet).
Wenn v2 dann komplett in einer brauchbaren Version steht - wird es denke ich dann auch Zeit für einen neuen, eigenen Thread

Jedem Einzelnen danke ich für jegliche Form der Unterstützung!
EVNotify V2 bleibt natürlich weiterhin kostenlos - immer. Keine Werbung, open Source. Gibt sicherlich immer wieder mal ein paar kleine MoneyPools auf PayPal oder so Paypal Spenden "Aufrufe" (klingt doof, will kein Aufruf bewusst machen) - um Kosten etwas auszugleichen (oder für zukünftige Features wie SMS). Geld kosten wird EVNotify allerdings nie. Maximal freiwillige Spenden, wie es sie bisweilen ein paar mal gab (tausend Dank - jeder Cent hilft. Wirklich).

Im Anhang ein erstes Bild der heutigen Super Prototyp Version von V2

[cacula]

WOW - großartig! Herzlichen Glückwunsch und vielen herzlichen Dank für deine Unterstützung der Community. Ich freue mich schon sehr auf die neue Version!

[bigal]

Hallo Guiseppe und alle anderen IONIQ Freunde!
Ich habe seit einigen Tage auch einen IONIQ PHEV und habe schon versucht, eine Überwahungsmöglichkeit für den Ladevorgang zu finden. Heute bin ich endlich fündig geworden
Ich finde die App gehört einfach zu einem PKW mit Akku und mM nach sollte solch eine App direkt vom Hersteller mit entwickelt und angeboten werden. Umso beachtlicher ist es, daß du dir die Mühe und Arbeit gemacht hast, diese App selbst in deiner Freizeit zu entwickeln!!!
Wie ich gesehen habe, ist die V2 noch nicht auf Playstore verfügbar. Sobald ich einen Dongle habe, werde ich die V1 testen und mit Spannung auf die V2 Warten.
Bzgl des OBD2 Dongle habe ich noch eine Bitte: Ich finde ich die Liste der geeigneten Hardware nicht auf Github. Könntest du bitte nochmal den Link auf die Liste hier einstellen?
Herzlichen Dank und Viele Grüße
Alex

[GcAsk]

Guten Morgen,

danke

V2 ist tatsächlich nocht nicht offiziell released, wird derzeit noch geschlossen auf https://evnotify.slack.com getestet.

V1 geht mit dem IONIQ PHEV und HEV nicht. Geht erst mit V2 (dafür aber sogar jetzt schon im Super Prototypen ).
Wenn Du magst, kannst Du dann gerne auf Slack vorbeischauen und testen.

Gegen Ende dieser Woche sollte auch der Super Prototyp V2 langsam aber sicher ein V2 Prototyp werden

Hier die Liste: https://github.com/GPlay97/EVNotify/wiki/Compatibility Keine 100%ige Garantie, ggf. sind Chips auch mal anders.

/EDIT:
Sieh es aber dafür positiv:
Selbst ein hersteller kann mal den Stecker ziehen.
Hier alles OpenSource. Und wenn Du nen Vorschlag hast, implementiere ich ihn.
Versuch das mal bei nem Hersteller