EVNotify - überwache den Ladezustand Deines Elektroautos!

[KD Kona]

Für die Zukunft:
@Interessierte
Was haltet ihr davon gemeinsam ein Lastenheft zu erstellen.
@GcAsk
Daraus kannst du dann ein Pflichtenheft erarbeiten.

Ich hätte auch noch Ideen.

[GcAsk]

Ich bin jederzeit offen für Vorschläge und Ideen.

Am liebsten ist mir direkt hier oder - damit es besser trackbar ist - am allerliebsten auf GitHub unter Issues.

Habe dort auch schon ein "v2" Label erstellt

Am besten aber noch den ersten Super-Prototyp Release dann abwarten

Ein Pflichtenheft? Ihhh Da bin ich dann glaub schneller, wenn ich direkt programmiere
Aber wie gesagt- Vorschläge jederzeit (am besten auf GitHub - bitte hier auf Englisch dann auch).

Oh - und hab gerade mal ein "kleines" Video erstellt (wollte eigentlich das streamen - aber irgendwie wollte das Netz nicht mitmachen).

Wer Interesse hat, kann sich das mal anhören. Geht um v2, was zukünftig möglich sein wird - und warum der Schritt notwendig war. Und wie alles begonnen hat.

https://www.youtube.com/watch?v=Vz8pVHa01GU

Oh - ich war eben im Auto erfolgreich. Hab super cooles erreicht - neuer OBD Code (aber noch auf V1 Basis) - wird die Tage migriert.
Mehr im Video

Mal gucken, ob ich morgen noch was schaffe, hab dann ja Geburtstag - mal gucken

[MaXx.Grr]

Mal gucken, ob ich morgen noch was schaffe, hab dann ja Geburtstag - mal gucken

Na dann mach ich mal den Ersten:

Alles Gute zum Purzeltag!!!

Ich wünsche Dir daß Du immer so schön positiv bleibst und weiterhin so viel Spaß am Programmieren hast...

Grüazi MaXx

[KD Kona]

Glückwunsch zum Geburtstag,
mach weiter so.

[GcAsk]

Danke Euch

Ein paar Sachen:

Jetzt am Wochenende versuche ich, den ersten Super-Prototypen von V2 fertig zu stellen.
Mal gucken. Nach der Arbeit heute werde ich auch ein paar Stündchen weiter machen.

Ach ja, was mir eingefallen ist wegen meinem Prediction / Prognose Skript:
Selbst wenn ich die Daten direkt vom Auto bekommen könnte - was das Auto nicht kann - was aber das Skript (gut) kann - ist, vorauszusagen, wann ein bestimmer Prozentwert erreicht ist. Das ist das coole. Nicht, wann ich voll bin. Nein, wann ich 63% erreicht haben werde.
Es gibt so viele Daten. Warum nicht diese Daten sinnvoll nutzen, um einen Mehrwert für alle Nutzer zu schaffen. Ich denke, das hat Potenzial (auch wenn es jetzt erstmal nicht die Priorität hat, das zu verbessern).
BigData und selbst lernende Mechanismen - nice.

Gestern übrigens ein interessater Test:
Typ2 Ladung. Mehrfach Internetverbindung verloren - sprich - es gab Lücken.
Das Skript hat dennoch super gut die Prognose abliefern können.
Schon nach wenigen Datensätzen hat dies gemerkt, dass es sich um eine langsame Ladung handelt. Die erste Prognose:
Gerade mal 8 Minuten Abweichung, von dem, was das Auto sagt. Und das bei einer verbleibenden Ladezeit von über 3h.
Nach wenigen weiteren Minuten nur noch 4 Minuten Abweichung - trotz immer wiederkehrenden Lücken bei der Übertragung.
Am Ende lag das Skript - obwohl es bisweilen NUR aus den eigenen Daten lernt - und noch nicht die anderer Nutzer nutzt (eigenständiges Erlernen der Ladekurve), um gerade einmal 40 Sekunden (!) daneben. Wow.

Achso:
Mit dem user (danke Löschi) hab ich vielleicht auch das Problem gefunden, warum bei manchen nach wenigen Minuten EVNotify aufhört, den Ladezustand zu synchronisieren. Als Workaround gab es dann den keepAwake Modus, welcher verhindert, dass der Display einschläft. Wir haben aber herausgefunden, dass dies (zumindest bei ihm) dann daran gelegen hat, dass in den Einstellungen von Android, "Mobildaten im Hintergrund aktiv lassen" plötzlich (nach dem Wechsel der SIM) deaktiviert war. Nach dem Aktivieren ging es wieder problemlos!

Noch weiter:
Das komische Verhalten, welches eine bestimmte Charge von Dongle (Modellen) auslösen kann, beim IONIQ (wo dann nur noch ein Abklemmen der 12V Batterie hilft), kommt nicht, wie ursprünglich angenommen, vom Energiespar-Befehl AT LP von EVNotify, sondern sehr wahrscheinlich immer dann, wenn man den Dongle abzieht, während der IONIQ noch an ist. Das stört irgendwas intern. Schaltet man den IONIQ vorher komplett aus, gibt es keinerlei Probleme. Danke an @cacula für das Weiterforschen trotz der Umstände - und tausend Dank für das Zukommen eines Test-Dongle für mich!

Last, but not least!
Für all die, die sich ein wenig mit OBD2 auskennen, eine kleine "Challenge".
Mir ist es gelungen, einen ersten Rewrite von OBD2 zu programmieren (noch auf V1 Basis).
Damit kann ich nun auch sauber das neue Kommando absetzen, welches zukünftig das Auslesen mehrerer Daten, wie Temperatur, Ladeanschluss, aktueller Gang, Bremse betätigt, etc., Lademenge auslesen kann.

Nun weiß ich aktuell noch nicht so recht, was die ganzen Daten bedeuten (gibt Torque Berechnungsformeln online auf GitHub für den IONIQ, wem das hilft).
Wer will - und helfen will, kann hier mal vorbeischauen:

https://gist.github.com/GPlay97/8ace7a4 ... d2107592b0

Und wer dann will, es schafft (vor allem den SOC BMS Wert zu finden) - inkl. Erklärung, kriegt von mir eine kleine, finanzielle Belohnung.
Ist nicht viel, soll nur als Dankeschön gelten.
Wer dies nicht will, kann auch darauf verzichten, das Geld wird dann zur Finanzierung von EVNotify aufgehoben.

Tausend Dank!
Gemeinsam können wir was cooles schaffen

[Sawok]

Kannst du noch mal drüber nachdenken einen SMS Push als Telegramm Alternative einzubauen, so alle 10 % oder bei bestimmten SOC bzw. Ladeabbruch....sonst, mach weiter und DANKE für Zeit und Mühen....

[GcAsk]

Ich kann darüber gern mal nachdenken.
Habe dies auch schon einmal geplant.

Wenn überhaupt - dann nur bei Erreichen des Ladezustands und bei Ladeabbrüchen.

SMS müsste zudem limitiert sein (bspw. 1 Mal am Tag nur - und ggf. auch max. 50 insgesamt pro Tag).
Hintergrund:
SMS zu versenden kostet Geld.

Theoretisch könnte man auch die interne SMS Funktion vom Handy ansteuern - dann würden Kosten beim Nutzer anfallen. Hier müsste man aber das Android API SDK Level anheben - damit sind alle Android Geräte unter Android 4.4 ausgeschlossen - was uncool ist.

Ich kann gerne bei Gelegenheit mal sowas testweise mal implementieren - mit dem Limit - und schauen, welche Kosten entstehen würden. Ggf. gibt es dann einfach einen kleinen PayPal Pool, bei dem Leute, die das nutzen, einfach 50ct oder so einzahlen können, um wieder ein paar SMS versenden zu können.
Geringe Kosten kann natürlich auch ich übernehmen.

[UliZE40]

Those commands were sent, before the response received (one after the other - in the given order):
'ATD', 'ATZ', 'ATE0', 'ATL0', 'ATS0', 'ATH0', 'ATSP0', 'AT0', 'ATSTFF', 'ATFE', 'ATBRD45', 'ATBRD23', 'ATBRD11', 'ATBRD08'

Das sieht mir nicht nach irgendwas sinnvollem aus.

Mit welcher Baudrate arbeitet denn der CAN-Bus im Ioniq?
Das gibt man entweder fest vor oder lässt den ELM das automatisch erkennen.
Dann musst du wissen welche PID(s) von welchem Steuergerät du empfangen willst.
Dann programmierst du einen Filter damit der Puffer in dem billigen ELM-Chip und dem lahmen UART nicht sofort überläuft.
Anschließend startest du das mitlesen mit ATMA.
Die gewünschten PIDs treffen in der Regel dann zyklisch << 1s ein.

[GcAsk]

Beim Fest-Vorgeben hat man das Problem, dass man Baudraten angeben kann, die der Dongle nicht kann.
BRD macht meines Erachtens doch das. Ich setze verschiedene Baudraten (45 -> 57.6kbps), die erste sollte immer gehen. Das nächste setzt es dann, geht als Fallback dann aber auf die zuvor gesetzte. Das macht das Kommando meines Erachtens nach so.
Wenn Du mir sagst, wie das besser geht, gerne.
Was ist daran denn nicht sinnvoll? Die Daten oder die Kommandos? Die ersten sind zur Konfiguration, wie z.B. Echo Off. Die hinteren für die Baudraten. Steuergerät bleibt immer 7E4. Kommando zuvor: 2105. Jetzt neues Kommando 2101.
Filter tatsächlich noch nicht rein. So lange man das Kommando nicht mehrfach hintereinander macht, kommt kein BUFFER FULL. Ist ja nur ein erster Test gewesen.

Du meinst also, dass so, wie es da in dem Test war, nciht richtig war? Wenn Du da näher helfen kannst, gerne. Der 2105 Befehl war wesentlich schlanker, da war das nicht notwendig.

[UliZE40]

Es sind zwei Baudraten zu beachten: Einmal die CAN-Schnittstelle Fahrzeug zu ELM und zum anderen die ELM via UART (zu BT-Modul). Erstere ist vom Fahrzeug fest vorgegeben. In der Regel werden dort 500k oder 1M verwendet. Kenne den Ioniq aber nicht. An dem zweiten Interface kannst du in der BT-Kombination ohnehin nichts ändern, da dies nur in einer Kombination funktioniert (sowohl BT-Modul als auch ELM müssen die gleiche Geschwindigkeit sprechen) und vom Hersteller fest vorgegeben ist.
Das kann man sich also völlig sparen. Ohnehin: Weniger ist mehr.

Warum gehst du da mit den Diagnosebefehlen rein? Da kannst du jede Menge Mist machen wenn deine Software oder die Hardware fehlerhaft ist. Kein Wunder dass es hier schon zu Problemen mit dem Fahrzeug gekommen ist. Du brauchst dazu quasi zwingend eine genaue Dokumentation der Steuergeräte. Aus dem einfachen Datenwust kann man nichts rauslesen. Das geht eben nur bei der normalen offenen Buskommunikation über die Zeit und mit Beobachtungs- und Interpretationsgabe.
Schickt dir Ioniq die Daten nicht einfach so auf den Bus raus? Was kommt denn bei ATMA raus?