Car Stats Viewer | 0.27.x

Hallo zusammen,

es ist endlich mal wieder soweit, und ein Update für den Car Stats Viewer steht vor der Tür!

Wie immer, allgemeine Informationen und eine Übersicht über alle verfügbaren Test-Tracks gibt es hier: Car Stats Viewer | Informationen

Hierbei handelt es sich erst mal um eine Vorankündigung, da ich noch auf einige Übersetzungen warte.

Ja, es hat ziemlich lange gedauert, und man sieht dem Update auch nicht auf den ersten Blick an, was alles an Arbeit dort rein geflossen ist. Denn am meisten Zeit hat die Implementierung des Automotive App Host für den Play Store Release in Anspruch genommen. Das betrifft die „Legacy“-Version, wie ich sie nun nenne, nur bedingt. Aber auch allgemein hat sich etwas getan an der App.

Zwischenzeitlich gab es auch etwas motivationsflauten und andere Hobbys, die meine Aufmerksamkeit auf sich gelenkt haben. Aber nun bin ich wieder etwas aktiver bei der Entwicklung und habe einige Ideen, die ich zeitnah umsetzen möchte.

Und keine Angst, ich habe nicht vor, funktionierende Features kaputt zu machen oder gar ganz aus der App zu entfernen :clown_face:


Update 0.27.0

  • Implementierung des Automotive App Host für einen potentiellen öffentlichen Release im Play Store (nicht in klassischen Builds enthalten).
  • Implementierung von Firebase Crashlytics. Kann in den Einstellungen deaktivert werden.
  • Die Art und Weise, wie Changelogs generiert werden, wurde überarbeitet.
  • Die Ladekurve wird in der Tripzusammenfassung nicht mehr bei 160 kW abgeschnitten.
  • Der Datenbank-Upload läuft nun in einem eigenen Dienst. Es muss nicht länger der Tripverlauf geöffnet bleiben. Eine Benachrichtigung informiert über den Fortschritt.
  • Der Datenbank-Upload enthält nun Ladekurven.
  • Der Webhook füllt nun das Feld charged_soc am Ende eines Ladevorgangs aus.
  • Datenbankzugriffe reduziert durch das verwenden der Debug-Einstellung bei der Speicherung von Logs.
  • Debug-Logs werden nach 28 Tagen ein Mal täglich gelöscht.
  • Fehler beim Anwenden des experimentellen Farbschemas behoben.

Das Thema Automotive Template Host beleuchte ich nach wie vor vor allem im Thread „Die Zukunft des Car Stats Viewer“. Dort gebe ich Statusupdates, was sich an der Front so tut, daher verzichte ich hier auf Details zu dem Thema.

Ich habe mich nun dazu entschieden, den Schritt zu gehen und Google Firebase Crashlytics in die App einzubauen. Es gibt immer mal wieder Berichte von Abstürzen ohne ersichtlichen Grund und ohne Meldungen im Log. Ich erhoffe mir damit einen besseren Überblick über die Stabilität der App zu erhalten, da ich nicht nur meine eigenen Crashes sehen kann, sondern von allen Nutzern im Feld. Es wäre mir eine große Hilfe, wenn ihr Crash Reports und Analytics in den Einstellungen eingeschaltet lasst. Die daten, die ich darüber erhalten, sind anonymisiert und dienen ausschließlich dazu, Fehler im Code nachzuvollziehen. Persönliche Daten werden dabei keine übertragen. Es steht aber jedem frei, per Opt-Out in den Einstellungen die Analysedaten aus zu schalten.

Vorerst wird Crashlytics auch nur in Tracks aktiviert sein, die ich selber manage.

Damit einhergehend habe ich einige Anpassungen an der Absturzerkennung und dem Neustartverhalten nach einer Terminierung der App vorgenommen. Davon erhoffe ich mir ein insgesamt stabileres Verhalten des Datenerfassungsdienstes, sowie weniger „Downtime“, wenn es doch mal zu einem Absturz kommt.

Ansonsten habe ich einige kleine Fehler behoben und allgemein etwas Optimierung betrieben, was den verbrauch von Speicherplatz betrifft (vor allem beim Debug-Logging).

Für 0.28 wird es dann vermutlich wieder mehr „sichtbare“ Änderungen geben, um langsam dem Ziel 1.0 näher zu kommen. Unter Anderem möchte ich die UI etwas auffrischen und fit für andere Modelle machen. Dazu aber bei Zeiten mehr.

Sobald das Update live geht, werde ich euch hier darüber informieren.

38 „Gefällt mir“

So, ich habe nun in meinem Track Version 0.27.0.0049 veröffentlicht.

Ich habe die Änderungen vorerst noch nicht in den master-Branch bei Guthub gemerged, da ich die Änderungen erst mal an einer kleineren Gruppe testen möchte. In letzter Zeit kam es bei mir leider durchaus gelegentlich zu „Shadow Crashes“, und bevor ich jetzt etwas instabiles in die breite Masse entlasse, sind die Leute in meinem Track erst mal Versuchskaninchen :stuck_out_tongue:

Ach ja, eine Änderung habe ich euch vorenthalten: Ich habe vorerst das alte Icon wieder eingesetzt. Das dient erst mal zur leichteren Unterscheidung zwischen „Legacy“ und „Play Edition“. Vielleicht ändere ich das später wieder, schauen wir mal.

7 „Gefällt mir“

Ich habe den Update gleich gestern Abend noch gemacht.
Heute ist mir beim Starten aufgefallen, dass die App automatisch gestartet worden ist - also so wie ich ihn gestern Abend „ausgeschalten“ haben.
Ich hatte in der Vergangenheit öfters Probleme, dass sich der Service nicht starten lies bzw. die Meldung öfters erschienen ist.
Auch hatte ich früher das Problem, dass sich die App nach ein paar Sekunden plötzlich beendet hat. Ich würde vermuten immer dann wenn das erste mal einen Linie gezeichnet hätte werden sollen. Das ist heute auch nicht mehr aufgetreten.
Von daher nicht nur eine super App sondern auch ein super Release :+1:

1 „Gefällt mir“

Ich kann nicht versprechen, dass das alles mit dem aktuellen Release besser geworden ist.
Aber durch die Implementierung der Analysetools bekomme ich bereits jetzt Crash-Reports aus dem Feld, mit denen ich zukünftig an weiteren Stabilitätsverbesserungen arbeiten kann.

2 „Gefällt mir“

Um einmal einen kleinen Einblick zu geben, was ich mit Google Crashlytics so für Daten bekomme:

Das ist ein Problem, das mir durchaus bekannt war ( Bug: Concurrent Modification Exception when writing trip data ), aber bisher habe ich nur von einem einzelnen Nutzer (@CONSULitAS ) im Dev-Branch eine Meldung über den Fehler im Log gesehen. Bei mir selber ist er nie aufgetreten, und ich konnte daher nicht einschätzen, wie schwerwiegend das Problem ist.

Durch Crashlytics bekomme ich da wesentlich mehr Insights und kann besser beurteilen, wie hoch ich die Priorität für jeweilige Probleme legen muss. Dieser Spezielle Bug steht nun weit oben auf der To-Do-Liste

Und in der Play Edition konnte ich auch schon zwei spezifische Bugs dank dieses Features fixen :grin:

7 „Gefällt mir“

Wie können wir dir da behilflich sein bzw. habe ich irgendwo was überlesen, wie ich gezielter (technische)Bugs erkennen und melden kann?

Was ich bis jetzt bemerkt habe:
Das System startet jedes Mal beim einsteigen neu, manchmal zwei mal, ich bin bis jetzt davon ausgegangen, dass das an der Instabilität von AAOS liegt.
Während des Benutzens, habe ich eigentlich noch keine Crashes erlebt.

Beachten musst du selber eigentlich nichts. Crashlytics ist ein Tool von Google, das jetzt in der App integriert ist, und autmoatisch Crash Reports an mich weiterleitet, wenn die App abstürzt.

Die Option ist standardmäßig aktiviert, kann aber auf Wunsch im Einstellungsmenü deaktiviert werden.

1 „Gefällt mir“

Na dann solltest Du von mir mehr Daten bekommen als Dir lieb ist :grimacing:. Ich schaffe es auch nach dem Update nicht mehr die App zum Laufen zu bekommen. Jedes Mal wenn angefangen wird aufzuzeichnen stürzt sie ab. Ok, die lästige Meldung von früher ist weg. Ist schon was. Aber eigentlich wäre mir die App lieber :joy:

So könnte man es auch ausdrücken :sweat_smile:

Es ist immer schwierig, solche Fehler ausfindig zu machen, die nur bei manchen Leuten auftreten. Ich vermute, dass da irgendwo kaputte Daten mit rein spielen könnten.

Inzwischen 28 mal aufgetreten, aber nach wie vor nur bei 6 verschiedenen Nutzern:

image

Mir ist aufgefallen, dass die Zeilennummern bei den Crash Logs nicht 100%ig passen, weil sie wegoptimiert werden beim Kompilieren. Ich habe grade einen Patch hochgeladen, damit ich da etwas genauer rein schauen kann, sowie ein Versuch, den Fehler zu fixen.

Schau mal bei Gelegenheit, ob die App mit 0.27.1 immer noch sofort abstürzt. Wenn nicht, achte mal darauf, ob irgendwo unplausible Werte in den Daten auftauchen. Es ist nie ausgeschlossen, dass ein Fix alles nur noch schlimmer macht. :sweat_smile:

Ggf. muss ich den Code an der Stelle auch noch mal umfangreicher umbauen. Wäre dann zwar wieder ne größere Aufgabe, aber das ein oder andere entspricht da nicht mehr ganz meinen Coding-Standards. Auch wenn ich das schon mal komplett neu geschrieben habe vor einiger Zeit. :sweat_smile:

2 „Gefällt mir“

Nachdem ich einen manuellen Trip mit 55000 km gelöscht habe, bei dem die Zeit und Durchschnittsgeschwindigkeit völlig murks war lief die App wieder. Jetzt mit dem Update auf 27.1 scheint sie wieder normal zu funktionieren. Die alten Trips haben noch ein paar Murksdaten aber die lösche ich morgen einfach mal. Danke für die Mühe - ich. In froh das die App wieder läuft :wink:

Ich glaube mit so hohen Kilometerleistungen habe ich auch noch keine Trips gesehen bei sonst jemandem

Kann durchaus sein, dass das Laden aus der Datenbank da Probleme macht und noch optimierungspotential besteht :sweat_smile:

Wäre interessant gewesen, da mal einen Test Case zu haben. Aber solange du mit dem Datenverlust leben kannst, und die App wieder ordentlich funktioniert, ist das auch gut :sweat_smile:

Vielleicht finden sich ja noch die anderen 5 Betroffenen, und die haben ähnlich hohe Kilometerzahlen. Dann ist das jedenfalls ein Anhaltspunkt, von dem aus ich auf Ursachenforschung gehen kann.

1 „Gefällt mir“

Ich habe noch direkt Patch 0.27.2 hinterher geschoben. Darin wird jetzt ein Fehler abgefangen, der bei einem Tripwechsel auftreten kann:

Der Fehler ist damit nicht wirklich behoben. Aber die App stürzt nicht mehr ab und ich erhalte etwas mehr Kontext, wenn der Fehler erneut auftritt. Bisher ist er im Track nur bei einem Nutzer aufgetreten, aber da war auch @CONSULitAS von betroffen. Ggf. besteht da ein Zusammenhang mit dem vorher beschriebenen Fehler, und er tritt gar nicht mehr auf.

Denkbar wäre, dass sehr lange Trips so lange zum Lesen/Schreiben brauchen, dass sich beide Funktionen in die Quere kommen.

2 „Gefällt mir“

So, und hier kommt nun der Release 0.27.3 im master-Branch:

Der Patch steht ab sofort im Track 1 zu Verfügung, der Rest wird dann hoffentlich Zeitnah folgen.

3 „Gefällt mir“

Ich hatte den Fehler jetzt nicht spezifisch. Manchmal braucht er mehrere Starts bis er aufzeichnet, aber bisher ging es dann immer irgendwann. Bei mir hat der Trip jetzt knapp 40.500 km mit einer Durchnittsgeschwindigkeit von 15936 km/h :joy:

Falls ich mit den Daten irgendwie helfen kann, gib gerne Bescheid.

Irgendein Problem gibt es mit dem Neustart der Tripzeit.

Ich musste natürlich CSV gleich mal im P4 ausprobieren. Das Programm startet korrekt, zeigt Geschwindigkeit und Akkustand an, kann aber leider nicht auf die Leistungsdaten zugreifen. Da sieht vielleicht das API leicht anders aus.


2 „Gefällt mir“

So etwas habe ich leider schon befürchtet. Beim Polestar 3 und Volvo EX30 sieht es ähnlich aus. Ich habe da aber in ein paar Tagen gespräche mit Polestar, wo es unter anderem genau darum gehen wird.

Was ich so höre, ist der Journey Log von genau dem gleichen Problem betroffen :crazy_face:

3 „Gefällt mir“

kann man eigentlich seine ladedaten auch vom ps2 mittels CSV runterladen ? habs noch nicht gefunden wie das geht .?

Aktuell nur, wenn du einen eigenen Server-Endpoint für den Webhook eingerichtet hast.

Es gibt noch den E-Mail-Versand. Der ist aber nur für Debugging-Zwecke gedacht und nicht sehr zuverlässig.

Für die nächste Version plane ich aber, einen richtigen Export einzubauen, der dann über meinen eigenen Server läuft (Solange der Traffic nicht irgendwann zu groß wird und für mich keine zusätzlichen Kosten entstehen :stuck_out_tongue: ). Ich kann aktuell aber kein Datum geben, ab wann das gehen wird.

2 „Gefällt mir“