v0.22.1
Nur ein kleiner Fix für die norwegischen Nutzer, dürfte hier wohl kaum wen betreffen 
@mbuehler @itsjsf
So, ich möchte euch dann auch mal an meiner Investigativen Bug-Suche teilhaben lassen. Interessiert sicher nicht alle, aber vielleicht hat ja jemand noch einen klugen Einfall 
Es geht um die Ladekurve und die zuverlässige Erfassung von Fahrzuständen:
Wie ihr seht sind in meinem Dev-Build bereits die gestrichelten Linien für die Bereiche, in denen keine Werte erfasst wurden, integriert. Die Linie des SoC ist aber trotzdem horizontal. Ich habe mir selber die Möglichkeit eingebaut, die JSON-Files im Log anzuzeigen. Das sieht dann z.B. so aus:
Das ist auch der kritische Punkt: „BEGIN_SESSION“ ist der erste Datenpunkt, der durch ein Event an die App gesendet wird, nachdem das CD nach dem Schlummern wieder aktiv wird. Das Fahrzeug hat zu dem Zeitpunkt bereits seit ca. 20 min das Ladelimit von 90% erreicht. Dennoch wird zu dem Zeitpunkt die alte Ladeleistung mit 10kW und der alte SoC von 52% angezeigt. 3,5 Sekunden später passiert ein Event mit den aktuellen Werten.
In der Zusammenfassung sieht man dann auch die vertikale Verbindung:
Und genau da liegt der Hase im Pfeffer: Diese alten, falschen Werte sorgen dafür, dass die Verbindungslinien horizontal erscheinen.
Zudem wurde die Ladekurve nicht in die Historie übernommen, als ich das Kabel abgezogen habe. Da wurde also das „Charge port connected“-Event nicht sauber getriggert. Die Gründe dafür sind für mich im Nachhinein leider nicht mehr nachvollziehbar.
Nun werde ich einen Versuch starten, dass die VHAL-Events nur noch eine Funktion triggern, die sich selber dann die Aktuellen Werte holt und nicht die, die die Events selber liefern. Damit erhoffe ich mir, dass ausschließlich aktuelle Werte herangezogen werden und da immer alle Werte abgefragt werden auch Events sauber getriggert werden. Selbst wenn mal ein Ereignis verschluckt wird, dann folgt einfach einige Millisekunden später der nächste Aufruf.
Soweit zur Theorie. Jetzt gilt es herauszufinden, ob das wirklich die gewünschte Besserung bringt und vor allem, ob das ganze keine negativen Performance-Auswirkungen hat.
Für diese Dev-Version habe ich einen eigenen Track, den derzeit nur ich alleine Nutze. Dabei handelt es sich um wirklich experimentelle Builds, die gerne mal schwerwiegende Bugs, undokumentierte Änderungen oder kaputte Features haben. Falls jemand Interesse daran hat, einen „echten“ internen Test durchzuführen, der kann sich gerne bei mir per PN melden. Das würde das Sammeln von Daten und das „entschlüsseln“ des Fahrzeugverhaltens sicher beschleunigen Den Dev-Track kann man auch parallel zum „stable“ installieren.
Ansonsten kann ich vermelden, dass der Umbau der Datenstruktur recht reibungslos funktioniert hat. Auch der Erfassung, in welchem Zustand sich das Fahrzeug befindet ist (mit Ausnahme des angesteckten Kabels) sehr präzise. Am ende des Heutigen Tages war die Zeiterfassung im CSV und im Manuellen BC bei gleichzeitigem Reset auf die Sekunde identisch. 
1 „Gefällt mir“
Wie wäre es stattdessen mit einer Funktion, welche
a) die Werte vergleicht ob diese identisch sind
und
b) die time stamps vergleicht
Wenn die Werte identisch sind und die Time Stamps mehr als… kA sagen wir 60 sec auseinander liegen, wird der Eintrag geskipped.
Wie sich das auf die Performance auswirkt, wenn da immer ne kleine If Schleife läuft… kA.
Alternative, wenn es denn ein solches Event gibt… könntest du die If Abfrage nur dann triggers, wenn vorher das FromSleep Event ausgelöst wurde. Im wachen Zustand gibt es diesen Fehler ja nicht.
2 „Gefällt mir“
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 
Ich werde denke ich mal eine Kombination aus beidem ausprobieren.
1 „Gefällt mir“
Dieses kranke Verhalten kenne ich auch von Java Swing Events 
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 
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? 
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
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
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
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
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
- 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?
Und schau mal in die Ladekurven, was die App sagt, was da nachgeladen wurde
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?
