Car Stats Viewer | 0.22.x

Grundsätzlich keine Schlechte Idee. Allerdings sind die Werte in so einem Fall wie oben Beschrieben ja nicht immer identisch. Zudem gibt es Events wie das einstecken des Ladekabels oder das ändern des Zündungs-Status, die nur sehr sporadisch auftreten und nicht laufend ihren Status melden. Wenn da aus irgendwelchen Gründen irgendwas verloren geht oder verworfen wird, dann erhält man wieder ungewolltes Verhalten.

Ein Event gibt es dafür meine ich nicht, die App wird einfach wieder zum Leben erweckt. Ggf. könnte man den Zündungsstatus „OFF“ dafür missbrauchen → Solange die Zündung aus ist werden keine Werte erfasst :thinking:

Ich werde denke ich mal eine Kombination aus beidem ausprobieren.

1 „Gefällt mir“

Dieses kranke Verhalten kenne ich auch von Java Swing Events :roll_eyes:

Ich habe jetzt in dem speziellen Fall eine „Sonderbehandlung“ eingebaut, damit das nicht mehr passiert. Dabei wird kein neuer Punkt zur Ladekurve hinzugefügt, wenn das timeDelta über einem Threshold liegt. Da die Ladekurve die Zeiten unabhängig berechnet entsteht nach wie vor die gewünschte Lücke, aber diese Fantasiewerte werden dann hoffentlich verworfen.

Das ist erst mal nur im DevBuild eingebaut, um zu schauen, ob das effektiv ist und nicht andere Fehler verursacht :upside_down_face:

3 „Gefällt mir“

Hallo zusammen,

Ich habe Track #5 aufgemacht. Wenn ihr dort rein wollt, dann teilt mir bitte eure Google-E-Mail Adresse über folgendes Formular mit:

(Edit: Gelöscht!)

Mindestens einmal am Tag werde ich die Adressen in den Track übernehmen.
Wenn das erfolgt ist, könnt ihr die App über folgenden Link installieren:

https://play.google.com/apps/internaltest/4701262890306276341

Gruß,
-Guido

Update: 5.2.2023 - 18:00 Uhr - 100/100

Der Track ist voll. Wer macht #6? :slight_smile:

12 „Gefällt mir“

So, ein Update steht zwar noch nicht in den Startlöchern, aber dank eines netten Belgiers aus dem internationalen Forum, der mir ein paar Testdaten aus meinem Dev-Build hat zukommen lassen, konnte ich die weiter oben von mir beschriebenen Bugs (hoffentlich) ausmerzen.

Nebenprodukt des ganzen ist eine simple SMTP-Implementierung, um E-Mails direkt aus der App verschicken zu können. Die angestrebte Lösung mit Google Mail/Drive werde ich erst mal nicht weiter verfolgen. Bei nicht geprüften Apps gibt es bei der API wieder eine Testerliste, die auf 100 User beschränkt ist. Das Setup dafür ist nicht wirklich trivial und jeder Track-Anbieter müsste selber noch ein mal so einen API-Zugang mit der eigenen App-Signatur erstellen. Das ist mir alles im Moment zu viel Aufwand.
Aktuell habe ich ein eigenes Postfach in meinem Dev-Track fest eingebaut, um darüber Mails zu verschicken. Ob ich das so lasse und man nur die Ziel-Adresse eingeben muss, oder ob jeder sein eigenes SMTP-fähiges Postfach angeben kann, muss ich mir noch überlegen. Da spielen dann auch Datenschutzaspekte rein. Das Postfach ist so angelegt, dass es sowohl eingehende als auch ausgehende Mails verwirft. Es wird also nichts gespeichert und, solange nicht meine Mail als Ziel ausgewählt ist, kann ich nicht sehen, welche Daten das Auto aufgezeichnet hat. Ich weiß nur noch nicht, ob ich mich in den Public-Tracks damit wohl fühlen würde, wenn alles über mein Postfach läuft, auch wenn ich es extra für diesen zweck angelegt habe :sweat_smile:

4 „Gefällt mir“

„Haushaltsprivileg“ nach Art. 2 Abs. 2 lit. c DSGVO i.V.m. § 1 (1) S. 2 BDSG könnte ein Ausweg sei…

Nur weil ich das theoretisch vielleicht dürfte, möchte ich gar nicht erst in die Situation kommen, ungewollt Daten anderer Leute zu speichern.
Und es geht auch etwas um meine eigene Datensicherheit. Ich will den Polestarfahrern nichts unterstellen, aber überall gibt es schwarze Schafe, und auch wenn das Postfach ausschließlich für die App existiert möchte ich das trotzdem keiner unnötigen Gefahr durch Dritte aussetzen :sweat_smile:

2 „Gefällt mir“

Sehe ich auch so.
Gut, dass du da ja zumindest in die Richtung gehst. Wenn es mal ernst wird, dann wird das auch irgendwie gehen. Beim Range-Assistant geht es ja auch :slight_smile:

1 „Gefällt mir“

Ja, grundsätzlich ist das machbar. Die Verflechtung mit Google ist aber auch wieder an Ansprüche an die App gekoppelt, zusätzlich zu den Ansprüchen für die bloße Veröffentlichung. Wenn’s ernst wird ist mir das dann vielleicht den Aufwand wert. Aber bis dahin sollte es denke ich nicht zu viel verlangt sein, den User ein mal SMTP-Login-Daten eingeben zu lassen, um das eigene Postfach für den Datenexport zu benutzen.

Das Debugging ist auf jeden fall schon deutlich effizienter geworden, seit ich mir selber Daten zuschicken kann. Zu spekulieren, was das Auto macht, ist eines. Die aufgezeichneten Daten dann auch wirklich zu sehen, bietet noch mal ganz andere Möglichkeiten :sweat_smile:

3 „Gefällt mir“

Ich hab jetzt nicht alle 170 Einträge dieses Threads gelesen und aber einen Großteil des alten. WAs ich nicht weiß, ist, warum ist mein Speichern Butten immer ausgegraut?

Aktuell wird nur der laufende Trip zwischengespeichert. Das manuelle speichern eines Trips beim reset geht noch nicht. Darum ist der Knopf ausgegraut.

wie ich dachte, habe auch in den Berechtigungen geschaut, ob der Zugriff auf das Google Konto noch nicht gegeben wurde.
Danke für die schnelle Klärung.

Habe eine Reise mit 510 km hinter mir. Nun hab ich mal versucht, die Daten ein wenig zu vergleichen, um es besser zu verstehen :grin:

  • Losgefahren mit 100%
  • bei 38% nachgeladen auf 58%: 20% = 18.2 kwh nach Ladesäule
  • bei 28% nochmal 20% nachgeladen auf 48% = 18,7 kwh nach Ladesäule
  • bei 29% auf 81% geladen (52%) = 45.2 kwh nach Ladesäule
  • mit 24% angekommen

Im der Summe ergibt das quasi 130% SoC für die 510km (62% + 20% + 20% + 52% - 24%)
Um nun daraus die benötigten kwh zu berechnen, benötigt es Annahmen darüber, wieviel für die 62% zu Beginn und die 24% Restladung anzusetzen sind. Ich komme aber irgendwie immer in Summe auf einen Wert zwischen 110 und knapp 120 kwh. Je nach Annahme über Verlustleistung.

CSV gibt die Tripsumme mit 127,2 kwh an
Bei den zwei kurzen Pausen sind wir im Auto sitzen geblieben. Heizung lief, aber Parkbremse gesetzt.
Ist das alles irgendwie plausibel? Wo kommt der Unterschied her? Hab ich was falsch gerechnet?
Der aufsummierte Verbrauch ist doch die Summe aus allem, was aus dem HV Akku entnommen wird, oder?

Edit: Bilder eingefügt. Hatte ne Dachbox drauf, Schnitt 85kmh, max 120kmh wo möglich.

1 „Gefällt mir“

Ja. Bei diesem Rechenweg musst du mit den 100% am Anfang rechnen, ergibt also 168% SoC. Und das wiederum ergibt bei einer angenommenen Nettokapazität von 75 kWh einen Verbrauch von 126 kWh.

Passt!

Was sagt denn der BC beim Durchschnittsverbrauch? :thinking:

Und schau mal in die Ladekurven, was die App sagt, was da nachgeladen wurde :thinking:

BC: 25,1 kWh

Ladekurven aus CSV muss ich morgen mal nachsehen.

Da hab ich noch nen Knoten im Kopf… Warum mit 100%? Auf dem ersten Abschnitt wurden doch nur 62% verbraucht….
Und der Faktor 0,75 ist doch ohne Ladeverluste, oder?

Also dein Rechenweg ist an sich schon richtig. Ich komme auch auf 116 „geladene“ kWh für die 130% verfahrenen SoC. Eigentlich müssten die geladenen kWh größer sein als die verfahrenen kWh bei selbem SoC. Da der BC aber nur minimal nach oben Abweicht, was den verbrauch betrifft (da kommen mit dem nächsten Update noch verbesserungen :wink: ), denke ich aber dass die App grundsätzlich korrekt mitgezählt hat.

Sicher, dass nicht irgendwo ein SoC nicht ganz passt oder doch mehr geladen wurde?

Edit: Moment, ich glaube ich habe auch einen Knoten im Kopf :joy:

Du hast insg. 92 % nachgeladen. Das ist rechnerisch dasselbe, als wenn du mit 192% SoC losgefahren wärst. Und wenn du mit 24% SoC ankommst ergibt die Differenz 168 %.
Die Verbrauchsangaben im BC und von CSV sind ja ohne Ladeverluste. Insofern ist es bei meiner Rechnung oben richtig mit den 75 kWh Nettokapazität zu rechnen.

1 „Gefällt mir“

… sind bei 510 km = 128,01 kWh … passt :wink: