Eine Frage an @Ixam97 und natürlich alle anderen, die es wissen könnten:
Ich habe CSV mit ABRP verbunden, um den ABRP-Referenzverbrauch mit CSV-Daten zu füttern.
Jetzt möchte ich aber nicht, dass bei meinen „Sonderfahrten“ z.B. mit Anhänger der Referenzverbrauch für „Normalfahrten“ total verfälscht wird.
Würde es genügen die Verbindung von CSV und ABRP bei einer „Sonderfahrt“ vor dem losfahren zu trennen und erst bei der nächsten „Normalfahrt“ wieder zu verbinden? Oder werden die Daten auch ohne Verbindung gesammelt und dann nach erneuter Verbindung quasi enbloc an ABRP hochgeladen?
Außerdem: Wie es denn sicher gestellt, dass ABRP NICHT im Hintergrund mitläuft. Schliesst sich ABRP bei Benutzung nach jeder Fahrt automatisch, oder muss man die App „Zwangsstoppen“?
So, leider hat es wieder länger gedauert als gehofft, aber nun ist 0.24.1 endlich verfügbar
Die Changelogs stehen bereits im Anfgangspost.
@Enso Wärst du so freundlich im Anfangspost das Datum von heute bei „(tba)“ zu ergänzen? Der letzte Edit ist zu lange her und ich darf den Beitrag selber nicht mehr bearbeiten
So, die letzten Tage bin ich nun endlich mal wieder dazu gekommen, an der App etwas zu schaffen. Der Umbau der Datenstruktur geht also langsam voran (zur Erinnerung: Ich möchte die bisher verwendeten JSON-Files für die Speicherdaten los werden und alles in einer Datenbank unterbringen. Zudem werden Daten zur Anzeige in der App über effizientere Wege an die UI übergeben bzw. generell in der App zur Verarbeitung bereitgestellt).
Ich habe nun den Teil der App, der den Verbrauch betrachtet, weitestgehend Fertig. Hinzugekommen ist auch endlich die Reichweitenprognose, basierend auf dem Verbrauch des ausgewählten Trips.
Darüber hinaus erlaubt es die Datenbank, dass nach einem Reset alte Trips erhalten bleiben, bis man sie löscht. Die Daten werden Fortlaufend in die Datenbank geschrieben und haben nicht wie bisher einen Anfang und ein Ende. Die unterschiedlichen Trips referenzieren nur die fortlaufenden Daten und speichern für sich die Gesamtstatistik ihres jeweiligen Erfassungszeitraumes.
Als nächstes kommt dann die neue Umsetzung der Ladestatistiken.
Die grafische Darstellung fehlt noch komplett. Das wird dann auch noch mal eine etwas aufwändigere Aufgabe, da hier die Daten nicht mehr gänzlich kompatibel sind. Aber da wird sich auch ein Weg finden und am Ende hoffentlich alles besser und stabiler laufen als bisher.
Bis 0.25 kommt wird es also noch eine ganze weile dauern. Vor allem da ich sicher gehen möchte, dass die Datenbank fehlerfrei die Daten speichert und wiedergibt und keine Alten Fehler durch den Umbau zurück kommen. Denn unter der Haube ist so gut wie alles neu. Bis dahin sollte 0.24 aber eine recht stabile Experience bieten denke ich.
Mich würde mal eure Einschätzung zu den Symbolen links interessieren. Ich habe mich bemüht, etwas heraus zu suchen, was die verschiedenen Trip-Arten möglichst gut widerspiegelt. Ist mir das gelungen?
Außerdem noch die Frage: Welche Daten wären euch am Wichtigsten, um sie auf einen Blick zu sehen? Aktuell sind es Strecke, genutzte Energie, Durchschnittsverbrauch und Fahrzeit, die in der Historie und auf der Hauptseite der App angezeigt werden.
Monatlich und seit letzter Ladung ist denke ich selbsterklärend. Den Finger habe ich als Symbol gewählt, da dieser im Ansatz andeutet, dass eine manuelle Eingabe für einen Reset notwendig ist. Den Kalender mit einem Punkt für den Automatischen Reset nach 4 Stunden Inaktivität, da damit häufig ein einzelner Tag dargestellt wird.
Cleverere Symbole sind mir leider bisher nicht eingefallen (bzw. habe ich bei Google Fonts nicht gefunden). Aber vll hat da wer schlaue Ideen, oder ich baue einen kleinen Hilfe-Dialog ein, der die Symbole erklärt.
Mir wäre z.B. die Durchschnittsgeschwindigkeit wichtiger als die Fahrzeit, da verbrauchsrelevant. Die reine Fahrzeit hingegen, gerade bei kumulierten Fahrten
Durchschnittsgeschwindigkeit finde ich wichtig, da sonst der Verbrauch deutlich schwerer einzuordnen ist für mich. Die restlichen Symbole sind völlig ok für mich.
Da ich grade ein wenig an der Reichweitenprognose bastle habe ich mir im Log den SoC ausgeben lassen. Und dabei ist mir folgendes über den Weg gelaufen:
Der VHAL liefert ja einen Float für den Battery Level, der in 804 Wh-Schritten aktualisiert wird (LRDM). Damit ergeben sich eigentlich immer Runde werte für den SoC. Offenbar gibt es da aber bei 54 und 53% eine Abweichung von 0,000004%. Ich weiß nicht, ob es sich dabei um einen komischen Wert vom VHAL handelt (das habe ich leider nicht mit geloggt), oder ob das auf mangelnde Präzision bei der Float-Berechnung zurückzuführen ist.
Jedenfalls habe ich bisher die Kotlin-Funktion toInt() benutzt. Diese schneidet einfach alles nach der Dezimalstelle ab. Das heißt, auch eine 52.999996 wird auf 52% abgerundet. Das werde ich dann zukünftig ändern und roundToInt() benutzen. Damit sollten wir dann in Zukunft Ladekurven ohne hässliche Knicke im SoC haben
Nice find Seltsam, dass es überhaupt zu den Dezimalen kommt für solch einen Wert… wäre an deiner Stelle auch nie darauf gekommen, diesen Wert zu runden statt logischerweise einfach nur abzuschneiden. Ob die bei PS grundsätzlich runden und damit hier zufällig das richtige getan haben?
Seltsam, dass es überhaupt zu den Dezimalen kommt für solch einen Wert… wäre an deiner Stelle auch nie darauf gekommen, diesen Wert zu runden statt logischerweise einfach nur abzuschneiden. Ob die bei PS grundsätzlich runden und damit hier zufällig das richtige getan haben? 
