EVNotify - überwache den Ladezustand Deines Elektroautos!

[Ernesto]

Empfehlen kann ich keinen von denen. Aber ich kann auch kein 70 € Android-Phone empfehlen.

Ich habe einen ziemlich teuren Netgear-Hotspot im Auto liegen. Daher ist das Thema für mich persönlich auch eigentlich nicht relevant und daher habe ich die "fehlende" GSM-Verbindung auch anfänglich übersehen.

Kannst du dazu bitte einen kurzes Statement geben, evt ein eigener Thread? Interessiert mich sehr. Ist er immer am Kabel? Lädst du den Akku immer extra auf? Geht das Laden aus, wenn das Auto aus ist. Bitte berichten Thoralf

[SWERNER]

WLAN-OBD2 Stecker werden nicht unterstützt. Neben dem anderen Protokoll, kommt hier ein Nachteil dazu, der EVNotify unbrauchbar macht - ein WLAN OBD2 Stecker hat ein eigenes Netz - das Handy muss sich in dieses einwählen - nur dann kann man nicht mehr ins normale Internet, sodass Benachrichtigungen und der Echtzeit-Ladezustand nicht mehr rausgeschickt werden können.

Beim Iphone stellt das mit dem WLAN kein Problem dar:
- die IP Adresse des WLANs liegt nicht im Internet (z.B. 192.168.1.1)
- dann für diese WLAN Verbindung die Maske auf 255.255.255.0 stellen
- nun werden alle 192.168.1.X Anfragen an das WLAN gesendet
- alle anderen gehen weiter über Mobilfunkt

Das nutze ich z.B. mit CanZE und einem OBDII- WIFI Dongle.

Sascha.

[UliZE40]

Die Subnetzmaske ist zwar für das Routing hier nicht so entscheidend sondern vielmehr das ausgelassene Standardgateway aber ansonsten ist das der korrekte Weg. Übrigens nicht nur bei iOS. Mit Android und anderen Systemen klappt es genauso.

[umrath]

WLAN-OBD2 Stecker werden nicht unterstützt. Neben dem anderen Protokoll, kommt hier ein Nachteil dazu, der EVNotify unbrauchbar macht - ein WLAN OBD2 Stecker hat ein eigenes Netz - das Handy muss sich in dieses einwählen - nur dann kann man nicht mehr ins normale Internet, sodass Benachrichtigungen und der Echtzeit-Ladezustand nicht mehr rausgeschickt werden können.

Beim Iphone stellt das mit dem WLAN kein Problem dar:
- die IP Adresse des WLANs liegt nicht im Internet (z.B. 192.168.1.1)
- dann für diese WLAN Verbindung die Maske auf 255.255.255.0 stellen
- nun werden alle 192.168.1.X Anfragen an das WLAN gesendet
- alle anderen gehen weiter über Mobilfunkt

Das Netz ist trotzdem offen und so gesehen hat GcAsk recht.
Allerdings lässt sich das mit wenigen Handgriffen ändern und das WLAN in ein existierendes WLAN integrieren. Das werde ich auch demnächst machen.

[eriksson25]

Two things thing I have noticed. On my "car host phone" atomatic change works. But on my personal phone I usaly have to set to "recive mode" before I get charge state. It would be nice if it was possible in settings to set "standard mode" on the local phone so you dont have to change it every time. Since my personal phone always will be "recive data".

The other thing. Maby implement a "last date" for charging info. For example, if I charge to 70% with EVnotify on, and then take the car for a drive. Then plug in the car for charging again but the "car phone" fails the connection without me noticing. If I open evnotify in my personal phone I will recive 70% charge status since that was the last valid data. But its old and I might then think that my car is charging and are at 70%.

So a "last date" to delete charge information when its older then say 20min or something?

/KG

[GcAsk]

Danke für die Information - dann ist das tatsächlich also, wenn auch über Umwege, machbar.
Ändert aber leider nichts daran, dass WiFi komplett anders behandelt werden muss, als Bluetooth. Da es auch auf Byte-Ebene kommunizieren muss, müsste man hier ein komplett eigenes "Modul" oder so selbst bauen. Habe mich noch nicht näher damit befasst, wird aber dann vermutlich auf Sockets hinauslaufen, die die Pakete über TCP oder so hin und herschicken.
Wäre zwar "nice to have", aber ich glaube, es gibt erst einmal noch wichtigeres. Zumal ich auch endlich eine iOS Version hinbekommen will. Wer natürlich Zeit und Lust hat (und die Kenntnisse), kann natürlich jederzeit gerne auf GitHub (Teile) des Codes einreichen

@eriksson25 Thank you for providing such useful information! Thank you for reporting, this helps me a lot.
Regarding to your last report, I've created an issue on GitHub: https://github.com/GPlay97/EVNotify/issues/37.
Your two new points will also be added as an issue to track. Especially the last point is a very useful point to be able to see WHEN the state of charge had been updated.

Thank you!

Ich versuche heute mal einiges zu schaffen Vor allem das Stromtankstellenupdate will ich schnellstmöglich rausbringen, sodass das dann nach und nach erweitert werden kann.

Wie in einem anderen Thread schon erwähnt, plane ich, auch Ladelogs anzubieten. Die offizielle GoingElectric-API (von der ich die Ladesäulen beziehe), bietet das leider nicht an. Ich überlege auch (bzw. muss das abklären), inwiefern ich vielleicht sogar mit @Remus (die iOS Ladesäulen-Finder App) gemeinsam das Log pflegen kann.

Und ein kleiner Teaser:
Es wird auch die Möglichkeit geben, Favoriten abzuspeichern von Ladesäulen. Diese sieht man dann separat, sodass diese schnell erreichbar und direkt navigierbar sind. Desweiteren plane ich, einen Service zu schreiben, der diese Favoriten überwacht und einen automatisch benachrichtigt, falls sich was an diesen ändert (bspw. sie wird als defekt gemeldet oder etwas anderes, wichtiges, ändert sich).

Ich bedanke mich bei allen Nutzern von EVNotify. Die App ist sicherlich noch nicht perfekt und braucht noch viele Updates und Optimierungen, aber ich bin mir sicher, dass sie, gemeinsam mit Euch, nach und nach immer besser wird

[cacula]

Danke für die Information - dann ist das tatsächlich also, wenn auch über Umwege, machbar.
Ändert aber leider nichts daran, dass WiFi komplett anders behandelt werden muss, als Bluetooth. Da es auch auf Byte-Ebene kommunizieren muss, müsste man hier ein komplett eigenes "Modul" oder so selbst bauen. Habe mich noch nicht näher damit befasst, wird aber dann vermutlich auf Sockets hinauslaufen, die die Pakete über TCP oder so hin und herschicken.
Wäre zwar "nice to have", aber ich glaube, es gibt erst einmal noch wichtigeres. Zumal ich auch endlich eine iOS Version hinbekommen will. Wer natürlich Zeit und Lust hat (und die Kenntnisse), kann natürlich jederzeit gerne auf GitHub (Teile) des Codes einreichen

@eriksson25 Thank you for providing such useful information! Thank you for reporting, this helps me a lot.
Regarding to your last report, I've created an issue on GitHub: https://github.com/GPlay97/EVNotify/issues/37.
Your two new points will also be added as an issue to track. Especially the last point is a very useful point to be able to see WHEN the state of charge had been updated.

Thank you!

Ich versuche heute mal einiges zu schaffen Vor allem das Stromtankstellenupdate will ich schnellstmöglich rausbringen, sodass das dann nach und nach erweitert werden kann.

Wie in einem anderen Thread schon erwähnt, plane ich, auch Ladelogs anzubieten. Die offizielle GoingElectric-API (von der ich die Ladesäulen beziehe), bietet das leider nicht an. Ich überlege auch (bzw. muss das abklären), inwiefern ich vielleicht sogar mit @Remus (die iOS Ladesäulen-Finder App) gemeinsam das Log pflegen kann.

Und ein kleiner Teaser:
Es wird auch die Möglichkeit geben, Favoriten abzuspeichern von Ladesäulen. Diese sieht man dann separat, sodass diese schnell erreichbar und direkt navigierbar sind. Desweiteren plane ich, einen Service zu schreiben, der diese Favoriten überwacht und einen automatisch benachrichtigt, falls sich was an diesen ändert (bspw. sie wird als defekt gemeldet oder etwas anderes, wichtiges, ändert sich).

Ich bedanke mich bei allen Nutzern von EVNotify. Die App ist sicherlich noch nicht perfekt und braucht noch viele Updates und Optimierungen, aber ich bin mir sicher, dass sie, gemeinsam mit Euch, nach und nach immer besser wird

Danke dir für dein großes Engagement

[eriksson25]

Danke für die Information - dann ist das tatsächlich also, wenn auch über Umwege, machbar.
Ändert aber leider nichts daran, dass WiFi komplett anders behandelt werden muss, als Bluetooth. Da es auch auf Byte-Ebene kommunizieren muss, müsste man hier ein komplett eigenes "Modul" oder so selbst bauen. Habe mich noch nicht näher damit befasst, wird aber dann vermutlich auf Sockets hinauslaufen, die die Pakete über TCP oder so hin und herschicken.
Wäre zwar "nice to have", aber ich glaube, es gibt erst einmal noch wichtigeres. Zumal ich auch endlich eine iOS Version hinbekommen will. Wer natürlich Zeit und Lust hat (und die Kenntnisse), kann natürlich jederzeit gerne auf GitHub (Teile) des Codes einreichen

@eriksson25 Thank you for providing such useful information! Thank you for reporting, this helps me a lot.
Regarding to your last report, I've created an issue on GitHub: https://github.com/GPlay97/EVNotify/issues/37.
Your two new points will also be added as an issue to track. Especially the last point is a very useful point to be able to see WHEN the state of charge had been updated.

Thank you!

Ich versuche heute mal einiges zu schaffen Vor allem das Stromtankstellenupdate will ich schnellstmöglich rausbringen, sodass das dann nach und nach erweitert werden kann.

Wie in einem anderen Thread schon erwähnt, plane ich, auch Ladelogs anzubieten. Die offizielle GoingElectric-API (von der ich die Ladesäulen beziehe), bietet das leider nicht an. Ich überlege auch (bzw. muss das abklären), inwiefern ich vielleicht sogar mit @Remus (die iOS Ladesäulen-Finder App) gemeinsam das Log pflegen kann.

Und ein kleiner Teaser:
Es wird auch die Möglichkeit geben, Favoriten abzuspeichern von Ladesäulen. Diese sieht man dann separat, sodass diese schnell erreichbar und direkt navigierbar sind. Desweiteren plane ich, einen Service zu schreiben, der diese Favoriten überwacht und einen automatisch benachrichtigt, falls sich was an diesen ändert (bspw. sie wird als defekt gemeldet oder etwas anderes, wichtiges, ändert sich).

Ich bedanke mich bei allen Nutzern von EVNotify. Die App ist sicherlich noch nicht perfekt und braucht noch viele Updates und Optimierungen, aber ich bin mir sicher, dass sie, gemeinsam mit Euch, nach und nach immer besser wird

Thank you for your hard work =) I am hapy to report things that I notice =) I have just uploaded a "installation guide" in swedish for the Nordiq ioniq forum. If you want to have a look https://www.dropbox.com/s/gxh78attb8r5m ... e.pdf?dl=0

I remember I talked about "poping out" the OBD2 port to be able to have it pluged in and the plastic cover. As you can see I have worked that out. I have also installed a on/off button to be able to controll the OBD2 adapter without having to unplug it all the time. I use a OBD2 30cm extension cable for that solution. Picture for that



Just some insperation for you.
I had broken the plastic on my OBD2 dongle so had to do this special build. But in my guide I tell people just to open the black plastic for 2cm on the middle of the cable. Cut the green/white cable and extend that to the on/off buton(dubble check that its the correct cable). Then put it all together and just plug the dongle in the extension cable.

[UliZE40]

Danke für die Information - dann ist das tatsächlich also, wenn auch über Umwege, machbar.
Ändert aber leider nichts daran, dass WiFi komplett anders behandelt werden muss, als Bluetooth. Da es auch auf Byte-Ebene kommunizieren muss, müsste man hier ein komplett eigenes "Modul" oder so selbst bauen. Habe mich noch nicht näher damit befasst, wird aber dann vermutlich auf Sockets hinauslaufen, die die Pakete über TCP oder so hin und herschicken.
Wäre zwar "nice to have", aber ich glaube, es gibt erst einmal noch wichtigeres. Zumal ich auch endlich eine iOS Version hinbekommen will. Wer natürlich Zeit und Lust hat (und die Kenntnisse), kann natürlich jederzeit gerne auf GitHub (Teile) des Codes einreichen

Zwischen einer seriellen Verbindung (RS232 - auch via USB oder Bluetooth) und einer Socket-Verbindung für TCP/IP gibt es softwareseitig keinen wesentlichen Unterschied der eine andere Behandlung der Datenkommunikation erfordern würde. Nur die Schnittstellen werden anders geöffnet bzw. haben dabei andere Eigenschaften. In den ELM327-WiFi-Dongles ist auch nichts anderes drin als ein "RS232-WLAN"-Konverterchip im Gegensatz zum RS232-BlueTooth-Konverterchip bei den Alternativen. Natürlich gibt es auch welche die direkt nativ mit der kabelgebundenen RS232 zum Rechner rausgehen. Mit dem wesentlichen Vorteil dass man dabei die Schnittstellengeschwindigkeit problemlos per Softwarekommando hochschrauben kann und die Daten im ELM-Chip nicht mehr gefiltet werden müssen. Das macht das ganze dann sehr, sehr, sehr viel schneller.

Und natürlich kann man die WLAN-Dinger auch umprogrammieren, so dass sie z. B. die WPA2-Verschlüsselung aktivieren. Eine Google-Suche hilft. Und Bluetooth-Chips die ab Werk alle die gleiche PIN haben sind ungefähr genauso sicher wie unverschlüsseltes WLAN...

[GcAsk]

Klar, dennoch erfordert es halt das Schreiben eines komplett neuen Codes. Dies wird sicherlich irgendwann auch unterstützt werden.

@eriksson25 WOW! Thank you so much! So many detailed pages - unbelievable. Thank you!

Das Ladesäulen-Finder-Update erscheint in den nächsten Tagen als Early-Access. Es werden noch nicht alle Funktionen implementiert sein, viele weitere, nützliche Funktionen, wie etwa Favoriten, die Kartenansicht und mehr, werden folgen.

Im Anhang ein kleiner Teaser.
Bezüglich des Ladelogs: Ich habe @Remus gefragt - mal sehen, ob und wie wir uns das Ladelog teilen können oder ob ich eine eigene Check-In Funktion machen werde.