Car Stats Viewer - Bordcomputer, aber viel besser!

Das klingt doch gar nicht so schlecht :innocent:

Das permanente Aufzeichnen einer Ladekurve über Stunden hinweg wäre einfach der Wahnsinn! :star_struck:

Wäre es eigentlich grundsätzlich denkbar die App in der aktuellen Version öffentlich anzubieten? Oder widersprichst du aktuell irgendwelchen Design und anderen Guidlines?

Inwiefern sollte es sinnvoll sein, die Sekundenzählung abzuschneiden? Wer es nicht sehen will, kann sicher bald :shushing_face: über einen Button auswählen, ob er exakte oder unpräzise Daten bevorzugt.

Ich bin ja jetzt mal so gar nicht vom Fach. Aber ich finde die App klasse, hat schon ziemliches Suchtpotential.
Eine Trip-Zusammenfassung fände ich sehr interessant, auch wenn ich jetzt kein „berufliches“ Interesse daran hätte.
Ich wäre auch gerne bereit, meine Daten für eine solche Auswertung zur Verfügung zu stellen, dadurch kann man ja nur noch mehr über das Auto lernen.

Aktuell nutze ich ja den selben Update-Kanal wie ihr, um die App auf das Auto zu bekommen. Ich werde mich demnächst mal damit auseinandersetzen, ob und wie ich die App für mich (und ggf. beteiligte Entwickler) in einem eigenen Kanal hochladen kann. Vorher möchte ich den aktuellen Stand aber noch etwas aufpolieren. Sobald ich die App guten Gewissens „stable“ nennen kann, wird das auch im Update-Zyklus entsprechend umgesetzt :wink:

Ich habe auch darüber nachgedacht, die Daten binär zu speichern. Allerdings halte ich das (nicht zuletzt aus Debug-Gründen) für nicht unbedingt notwendig und sinnvoll. Ich werde mal ergründen, wie stabil Gson (Googles Library zum umwandeln von Datenklassen in Json und umgekehrt) ist, wenn es darum geht, Json-Dateien zu laden, die nicht mehr zu 100% der Datenstruktur der Datenlasse entspricht, z.B. nach Updates.
Dass der Speicher knapp wird glaube ich kaum. Ich meine der Polestar hat 32GB internen Speicher und 4GB RAM. Da kann man viele Kilometer fahren, bevor der Speicher der limitierende Faktor wird. Aber ich werde mal Tests durchführen, wie viel Speicher x km benötigen.

Google erlaubt (aktuell) nur Medien-, Navi-, POI- und Messaging-Apps für AAOS. Und auch dann sind die Regeln sehr strikt.

1 „Gefällt mir“

Ich sehe das eher etwas skeptisch. Technisch wäre das bestimmt machbar, aber ob da eine Integration in die App sinnvoll ist, weiß ich nicht.

Da wäre es denke ich einfacher, wenn man sowas separat aufbaut und seine Fahrdaten dann in form der exportierten Daten einreicht. Da braucht man dann auch nicht unbedingt permanente Hosting-Kapazitäten, um die Daten entgegen zu nehmen.

Es geht ja nicht nur um das Speichern sondern auch um das einlesen der Daten und ob dann die CPU irgendwann schlapp macht wenn ein 3 Gig File eingelesen und geparst werden muss :smiley: Und wie man die Integrität überprüfen kann, kenne mich mit JSON Datenstrukturen nicht aus.
Aber Geilomat was du da auf die Beine gestellt hast. Schläfst und isst du denn auch genug meen Jung? :smiley:

War etwas missverständlich. Natürlich nicht als Feature innerhalb des Viewers, sondern außerhalb der App als externer Webservice. Die Frage richtete sich auch gar nicht an dich als Entwickler, sondern eher an die Testergemeinde hier im Sinne der Akzeptanz Daten zur Verfügung zu stellen bzw. ob überhaupt Bedarf bestünde. Im Anschluss an die App dann insofern relevant, welches Fileformat dann eben am ehesten in Frage käme.

Es gibt ja so ein ähnliches Projekt mit dem Journey Log.

Wer scharf auf Auswertungen ist da bestünde ja dann die Möglichkeit die Daten anonymisiert zu übersenden. Muss ja nicht Webbasiert sein, vielleicht findet sich wer der einen Parser bastelt, die Daten sammelt und auswertet und daraus Graphen erstellt und die dann in einem Thread hier regelmässig postet, einmal im Monat oder so.

Das wiederum ist natürlich ein berechtigter Einwand und auch ein Punkt, über den ich mir aktuell Gedanken mache. Daher ja auch die Absicht, das vorher gründlich zu testen.

1 „Gefällt mir“

Alles in ein File zu speichern macht meines erachtens keinen Sinn. Evtl. pro Trip/Ladung ein File das man dan ähnlich dem Journey Log auflisten kann. In den Details kann man dann eine Zusammenfassung und den Plot des Trips/Ladung nachsehen.

Kompremiert man diese JSON Files evtl noch etwas, sollte es wohl kein Problem sein.

2 „Gefällt mir“

Alles in eine Datei ist auch nicht der Plan. Der aktive Trip bekommt ein File und soll dann nach x Stunden oder manuell gesichert werden können, um ihn später betrachten oder exportieren zu können :thinking:

Ich habe den Emulator jetzt mal etwas über 800km „fahren lassen“ und die Daten als Json gespeichert und wieder geladen: Es scheint so, als würden ca. 2,1kB pro Kilometer anfallen. Speicherprobleme sollten also keine Auftreten. Selbst ein Trip von 10.000km wäre dann nur etwas über 20MB groß. Das einlesen der etwa 1,8MB großen Datei und das Parsen zurück in eine Datenklasse hat in einem Asynchronen Thread zwischen 90 und 130ms gedauert. Sollte diese Zeit ebenfalls linear mit der Dateigröße zusammenhängen, dann wären bei 10.000km etwas über 1 Sekunde Ladezeiten zu erwarten. Ich werde mal schauen, ob man das noch optimieren kann, aber ich denke, dass sind Werte, mit denen man durchaus leben kann. So ein Ladevorgang findet ja nur bei einem „Kaltstart“ der App statt oder wenn man einen Älteren Trip betrachten möchte.

Zudem scheint das lesen der Json-Dateien recht robust gegenüber Änderungen der Datenklasse zu sein: Sind im Json keine Daten zu einer Variable vorhanden, wird sie null gesetzt, was man beim einlesen entsprechend abfangen kann, wenn in späteren Updates daten hinzukommen sollten. Umgekehrt werden zu viel vorhandene Daten einfach ignoriert.

7 „Gefällt mir“

Frage: Ich bin heute mit 100% Akku weggefahren, am Ziel mit 50% angekommen, beim Energieverbraucht stand 35823Wh(100% wären folglich ca. 71646) → Heißt das, dass mein Akku schon ein geringeres SoH hat? oder fehlen bei der Angabe Verbraucher?

Bei der 0.19.2 sind die Menüeinträge für Verbrauchs- und Ladekurve ausgegraut. Ist das Absicht?

Habe CSV heute mal genutzt, um die immer wieder aufkommenden Hypothese ‚der Wagen verbraucht etwas beim Segeln‘ zu überprüfen:

Segeln bei 80 auf der ebenen Autobahn bei Windstille:
image

Kurz danach an der Ampel bei 1° und 21° Heizung:
image

q.e.d.

1 „Gefällt mir“

Nur während des Fahrens. Im Stillstand gehts prima.

1 „Gefällt mir“

Wenn das Auto nicht in P steht, ja. Aber Villeicht ändere ich das noch so, dass der Trigger auf Stillstand, und nicht auf P reagiert :stuck_out_tongue:

Man liest ja ab und an von Leuten, die sich ablenken lassen, da habe ich mal angefangen ein paar Sicherheitsmaßnahmen zu ergreifen :sweat_smile:

1 „Gefällt mir“

was genau wurde bewiesen?
Dass du beim Segeln weniger Heizleistung brauchst?
Dass du nicht konkret das Gefälle messen kannst, so dass der „Segel“-Screenshot durchaus eine Rekuperationskomponente beinhalten könnte?
Dass die Heizung ggf. während der Fahrt keine Leistung ziehen muss, da die Abwärme von 1.8kW Entnahme bereits ausreicht um den Heizkreislauf zu stützen und erst im´Stand der Zuheizer notwendig wird?

Ich habe heute früh folgende Erfahrung gemacht: gestern nach der letzten Fahrt die Werte in der App resettet, dann nochmal Spotify aufgehabt und dann den Wagen verschlossen.
Heute früh mit Spotify offen losgefahren, nach ca 2 km die CSV App geöffnet. Bis zu diesem Zeitpunkt war die App im Hintergrund nicht mitgelaufen sondern hat erst Werte gemessen und gezeigt, nachdem ich sie geöffnet habe.
Das gehört so?

Kann’s an der Rekuperation liegen?