1 Jahr Car Stats Viewer 🎉 | 0.26.x

Also wenn schon dann bitte (kg m) / sÂČ :joy:

1 Like

Mein PS verbraucht 777 J/m. :laughing:

also mein Polestar verbraucht etwa 0,04 l/100km.

Allerdings Scheibenwaschwasser (aufs Jahr gerechnet) :wink:

5 Likes

Dank @mbuehler darf ich jetzt endlich auch beim CSV mitspielen und bin sehr begeistert. Endlich werden die Verlaufswerte schön dargestellt und auch die Höheninformationen mit eingespielt. Das kannte ich vom Tesla und habe ich in der VerbrauchsĂŒbersicht wirklich vermisst.

Vielen Dank an @Ixam97 Maxi fĂŒr dieses tolle Werk. Da hast du wahrlich ein tolles Programm auf den Weg gebracht. Vielleicht bekommt es PS in 80 Jahren dann mal hin, sich daran ein Beispiel zu nehmen bzw. dort Fortschritt mit dir zu zeigen.

Bugreport: Mir ist aufgefallen, wenn ich die Leistungsanzeige ausschalte (also den Balken) und zwar fĂŒr den Verbrauch. Dann ist der Balken ebenso bei der Ladeansicht verschwunden, obwohl dort die Option aktiviert ist.

Feature request: Eigentlich ist alles nice. Was mich als „Design Monk“ etwas stört, ist das farblich unpassende Logo, dies passt zum neuen Farbdesign natĂŒrlich wunderbar und sieht wirklich gut aus. Da ich es persönlich auf dem „alten“ Farben belassen und den zweiten Graph auf Grau umgestellt habe, damit es mehr wie eine Systemapp aussieht, fĂ€llt das Logo dort natĂŒrlich auf. Ich fĂ€nde es cool, wenn das Logo sich mit dem Toogle Ă€ndert, ob man die neuen Farben will. Ein Orangenes wĂ€re cool. Dezent Schwarz Orange wie die performance app, geht natĂŒrlich auch. Nicht falsch verstehen, es sieht Top aus und ich mag auch die neuen Farben, passen aber (fĂŒr mich) nicht ins restliche Design. Daher hĂ€tte ich gern die Wahl. Wenn es sich dann auch in der App Übersicht Ă€ndert, wĂ€re es noch besser.

Nochmal, herzlichen Dank fĂŒr diese App. Daumen hoch!

4 Likes

naja, dass ist ja genau der grund warum polestar das anscheinend nicht wollte. denke also eher, die zukunft geht weg von der auswahl und nicht hin zu mehr auswahl. zumindest solange weiterhin die veröffentlichung im playstore angestrebt wird (was aus meiner sicht sinn macht).

1 Like

Moin, hab man ne blöde Frage, was bedeutet dieser Wert?

das ist die verbrauchte elektrische Energie.

Wenn Du den Wert durch die Strecke in km teilst und x100 nimmst, hast Du Deinen Durchschnittsverbrauch auf 100km.

3 Likes

Kleine KuriositÀt entdeckt!
Mein Auto stand jetzt wÀhrend der Zeitumstellung in einer Tiefgarage und damit ohne KonnektivitÀt.
Bevor ich dann wieder losgefahren bin, noch csv gestartet, um alles schön zu loggen.
Ich habe ĂŒberhaupt nicht auf die Uhrzeit geachtet, aber als ich dann nach dem abstellen die Übersicht angesehen habe, standen da plötzlich eine Fahrzeit, die genau 1 Stunde lĂ€nger schien als in Wirklichkeit.
Anscheinend habe ich also csv gestartet, als die Systemzeit noch in der Winterzeit war, und wÀhrend der Fahrt (also nachdem dann wieder KonnektivitÀt bestand) ist dann die Zeit im Auto auf Sommerzeit gesprungen und dieser Zeitsprung hat sich im csv addiert. Im BC alles wie es sein soll.
Meine Vermutung ist aber nur eine Vermutung. Ich habe nicht gesehen, ob vor dem Einlegen von D die Uhr schon auf Sommerzeit stand und ich habe auch nicht gesehen, wann sie ggf. umgesprungen ist.
Anbei die Beweisfotos:

Wohlgemerkt: Es handelt sich um dieselbe Fahrt

:smiling_face:

Entschuldige die spÀte Reaktion. In der tat sollte das so nicht sein :sweat_smile:

FĂŒr die Start- und Endzeiten wird grundsĂ€tzlich die UNIX-Zeit in Millisekunden verwendet. Daher sollte die Erfassung der Fahrzeit eigentlich unabhĂ€ngig von der Sommerzeit sein. Ich werde mir den entsprechenden Teil der Auswertung mal ansehen. Möglicherweise wird da etwas konvertiert, was Sommerzeit-AnfĂ€llig ist.

Welche Uhrzeit stet denn dort fĂŒr den Start des Trips im Trip-Verlauf? Stimmt der Überein, oder weicht der auch um eine Stunde ab?

Möglicherweise ist der Fehler auch nur in den Echtzeitdaten sichtbar, da die Fahrzeit in der Tripzusammenfassung aus der Datenbank rekonstruiert werden sollte. Da dĂŒrfte diese Fehler eigentlich nicht auftreten, außer ein falscher UNIX-Zeitstempel wĂŒrde gespeichert werden. Das sollte aber eigentlich nicht vorkommen.

Als Tipp ein Punkt auf den ich (immer 'mal wieder) reinfalle: sobald die UNIX-Zeit (t[ms] since 1.1.1970 0:00) in eine Uhrzeit (hh:mm) konvertiert wird, wird MEZ oder eben MESZ verwendet.
Vielleicht liegt es daran


Ich habe grade schon mal etwas nachgesehen. FĂŒr die Datenpunkterfassung nutze ich grundsĂ€tzlich die UNIX-Zeit. FĂŒr die Erfassung der Fahrzeit habe ich eine kleine Hilfs-Klasse geschrieben, die quasi eine Art Stoppuhr ist. Darin benutze ich die „java.util.Date“. Bei einer Instanzierung soll laut Doku die Zeit in ms genutzt werden:

Allocates a Date object and initializes it so that it represents the time at which it was allocated, measured to the nearest millisecond.

Darunter wird auch auf system.currentTimeMillis() verwiesen. Daher nehme ich an, dass das eigentlich passen sollte. Sollte die Systemzeit in irgend einer Form aus einem Klartext-Datum erzeugt werden, und damit abhĂ€ngig von der Zeitzone sein, wĂ€re das zum einen kein Fehler, den ich beheben könnte, zum anderen eine sehr fragwĂŒrdige Implementierung 
 Aber bei den ganzen Problemen mit den Lade- und Klima-Timern, die jedes mal bei der Zeitumstellung spinnen, wĂŒrde es mich auch nicht wundern :upside_down_face:

@rosboda18 Kannst du nachvollziehen, ob nur der automatische Trip betroffen war, oder ob auch die anderen Trip-Typen, de gleichzeitig aktiv waren, eine Zusatzstunde aufgebrummt bekommen haben? Im Zweifel ist das möglicherweise ĂŒber die Durchschnittsgeschwindigkeit zu erkennen, die sich dann deutlich von der Angabe im Diagramm unterscheiden mĂŒsste.
Ich werde mich demnÀchst noch mal per PN bei dir melden. Ggf. könnten Debug-Daten aus deiner Fahrdaten helfen, das Problem zu identifizieren.

Weicht auch ab. 14:11 Uhr im Tripverlauf. Bin definitiv aber kurz nach 15 Uhr MESZ losgefahren.

Journey Log hat es ĂŒbrigens auch „falsch“. Nur da beginnt diesselbe Fahrt erst um 14:14 Uhr, warum auch immer


OK, das beruhigt mich schon mal :joy: Das bedeutet entweder, dass das System irgendwas komisches macht, oder dass Polestar und ich den selben Fehler gemacht haben 
 :upside_down_face:

Kaum. Mein manueller Trip lĂ€uft schon recht lang und eignet sich dafĂŒr wohl eher nicht.
Der Monatstrip fĂŒr MĂ€rz weicht bei der Durchschnittsgeschwindigkeit um 5 kmh ab, Leider aber auch bei der km-Summe, keine Ahnung wieso. Ich hatte den TM am 29.2. zurĂŒck gesetzt.
Ich mache immer am letzten Tag im Monat Abends ein Bild vom manuellen ZĂ€hler im Auto ℱ und setze dann immer den TM zurĂŒck.
Da mal anbei die Vergleichsbilder.
TM Monat MĂ€rz:

Monatstrip fĂŒr MĂ€rz aus CSV:

btw: csv v.0.26.0.0010

Kannst du mal schauen, ob beim Zeitsprung möglicherweise ein Knick in einer der Kurven auftritt? Die Distanz wird ja aus der Programmlaufzeit in Nanosekunden und der Momentangeschwindigkeit integriert. Die Geschwindigkeitsanzeige wird dann wieder aus Zeitstempel und Distanz errechnet.

Die Zeiten vor und nach dieser „Anomalie“ sind aber soweit in Ordnung, oder?

Ich werde das Thema auf jeden Fall bei meinem nÀchsten GesprÀch mit Göteborg aufgreifen.

Bin seit dem letzten TM Reset 382km gefahren. Plus die 80km von jener Fahrt am 31.3. (das war die letzte Fahrt vor dem TM Reset Ende MĂ€rz) ergibt rund 460km „zurĂŒck“ im manuellen Trip.
Die Kurven im manuellen Trip sehen wir folgt aus, mir fÀllt da nicht wirklich was auf. Das P-Event könnte mit dem Parken in der Tiefgarage zusammen passen. Der Zeitsprung muss ja innerhalb von max. 5 Min nach diesem P-Event aufgetreten sein, als ich aus der Tiefgarage rausgefahren bin. Ich hatte sofort KonnektivitÀt.

Und hier noch ein Screenshot aus dem Automatischen Trip. Ich sehe da ganz am Beginn der Fahrt (<1km bis KonnektivitÀt vorhanden) nix auffÀlliges


Ja, da ist mir noch nie was aufgefallen.

Der Beginn einer Fahrt ist immer auf der linken Seite des Diagramms :wink:
Du kannst mit einer Zoom-Geste auch noch weiter in das Diagramm hinein Zoomen (glaube bis auf 5km Breite). Vielleicht ist dann mehr zu erkennen, wenn du „nahe“ an das Parkereignis heran gehst.

Au weh
 :blush:

Ok, verstanden. Ich schick nochmal Bilder, maximal reingezoomt.

Automatischer Trip:

Manueller Trip am P-Event bei km 460, ca:

Hi,

erstmal liebe ich die app - ich finde ja prinzipiell alles toll wo ich Daten raus bekomme :smiley:

Die neuen Farben finde ich cool!

Ich habe heute nachdem ich etwas Zeit im stehenden Auto hatte, gesehen das man die Möglichkeit hat daten zu exportieren


Ich habe einen smtp Server eingerichtet um mir diese per mail senden zu lassen. Allerdings wenn ich nun auf den Button klicke will er es auf einen Webhook laden.

In dem Screen wo man die destinations einrichten kann, kann man auch nichts weiter auswÀhlen dazu


Ich habe tatsÀchlich keine Ahnung was ein webhook ist noch wo ich mir einen dementsprechenden Server einrichten kann.
Hat jemand einen tipp?

Ich wĂŒrde das ganze gerne weiter in meinen iobroker senden um es mir visuell anzeigen zu lassen

Vielen Dank

Hi Dominik,

die SMTP-Integration dient derzeit vor allem dem Debugging. Das ist alles nicht so sauber implementiert und steht noch auf meiner Todo-Liste. Per Mail kann man nur manuell ĂŒber das Debug-MenĂŒ (10x auf die Versionsnummer tippen) Daten verschicken. Da kann ich aber nicht dafĂŒr garantieren, dass das ĂŒberhaupt klappt, da ich das selbst nur zusammen mit einem speziellen Postfach fĂŒr Debugging-Zwecke verwendet.

Live-Telemetrie (und der Datenbank-Upload) passiert nur ĂŒber die Webhook API. Wie die funktioniert, ist auf GitHub beschrieben: CarStatsViewer/docs/APIDOC.md at master · Ixam97/CarStatsViewer · GitHub

Mit Smarthome-Integration habe ich selber keine Erfahrung, weiß aber, dass das einige hier umgesetzt haben. Vielleicht kann da wer anderes helfen.

Was den Webhook angeht hat ein Forumsmitglied ein Tool ĂŒber Google Sheets realisiert, wofĂŒr man keinen eigenen Server braucht. Vielleicht ist das einen Blick wert:

2 Likes