Ah, ok. Danke! Dann lässt sich das min/max/avg über diesen Screen eh nur für die Dashboardanzeige direkt in der App (also auf dem Smartphone) verwenden, nicht aber über Carplay/Android Auto.
Dann ist dieser Weg für mich uninteressant, und ich werde mich mit dem Set/GetVar-Thema beschäftigen.
Ich werde berichten, ob ichs hinbekomme…
Habe die Dokumentation mit SetVar, SetVarOnce und GetVar auch schon entdeckt, bisher waren meine Versuche allerdings noch erfolglos.
Meine ersten Versuche waren ebenfalls nicht sonderlich von Erfolg gekrönt. Aber vielleicht bekommen wir es ja zusammen hin!
Mein Ausprobier-Status:
- "SetVar" und "SetVarOnce" scheinen zumindest irgendwie zu funktionieren. Jedenfalls stimmt, wie es auch in der Doku steht, dass diese beiden Funktionen tatsächlich den Wert zurückgeben, den sie auch in die Variable schreiben - oder zumindest schreiben sollten, denn sicher bin ich mir da aktuell noch nicht, weil:
- "GetVar" funktioniert bei mir gar nicht, sprich gibt nicht den Variablen-Wert aus. Was zwar theoretisch natürlich auch an einem nicht erfolgten "SetVar" liegen könnte, aber im Fall des nicht erfolgreichen Schreibens durch "SetVar" müsste "GetVar" ja den Default-Wert ausgeben, weil dann ja eine Variable abgefragt worden wäre, die noch nicht mit einem Wert belegt ist. Passiert aber nicht. Es wird gar kein Wert ausgegeben - weder der Variablenwert, noch der Defaultwert.
Daher bin ich sicher, dass "GetVar" zumindest bei mir aktuell nicht funktioniert.
Was sind denn Deine aktuellen Findings?
Ich kann das Verhalten bei mir genauso nachstellen. Insgesamt wirkt das Ganze ziemlich inkonsistent und teilweise zufällig.
SetVarOnce gibt bei mir auch nach dem angeblich einmaligen Setzen weiter neue Werte im Dashboard zurück. Entweder wird hier gar kein fester Wert gespeichert, oder es wird einfach immer nur der aktuelle Ausdruck zurückgegeben, obwohl die Variable im Speicher stets den Anfangswert gespeiercht hat. Ich halte es für möglich, dass „Once“ intern gar nicht so funktioniert, wie man es verstehen würde.
Abgesehen von dem einen Doku-Artikel findet man dazu online auch nichts weiter.
GetVar liefert bei mir ebenfalls keinen sichtbaren Wert ins Dashboard zurück, weder den gesetzten Wert noch den Default.
Ich habe testweise eine Helper-PID mit
SetVarOnce(1, {[BMS] Traction battery Actual Energy})
und eine Verbrauchsformel mit
((GetVar(1,0) - {[BMS] Traction battery Actual Energy}) / 1000 / {zurückgelegte Strecke}) * 100
angelegt.
In den CSV-Exports sieht man aber, dass immer dann kurz ein Verbrauchswert abseits von 0 auftaucht, wenn sich {[BMS] Traction battery Actual Energy} ändert. Der Wert entspricht dann genau „Vorheriger Wert minus neuer Wert / 1000 usw.“.
Würde für mich bedeuten: GetVar scheint intern doch irgendwas zu liefern, nur eben nicht zuverlässig bzw. wie man es erwarten würde. Der eigentliche Fehler liegt vermutlich eher bei SetVarOnce bzw. bei der Art, wie und wann der Wert gespeichert wird.
Beim Schreiben des Beitrags kam mir noch eine Idee, wie man das Problem umgehen könnte. Und ich glaube, es könnte so funktionieren.
Mein Workaround für die komische SetVarOnce-Logik:
Ich nutze stattdessen SetVar und lasse den Wert nur in einem sehr kleinen Fenster der zurückgelegten Strecke (0,1–0,2 km) setzen, über eine If-Abfrage. So wird der Startwert einmal „eingefangen“, und danach nur noch gelesen. Damit bekomme ich erstmals plausible Werte, die wie ein realistischer Durchschnittsverbrauch für die Fahrt aussehen.
Gerne ausprobieren und rückmelden, ob die Werte bei euch auch sinnvoll aussehen.
Die Formeln:
Consumption_Helper
if({zurückgelegte Strecke}>0.1 && {zurückgelegte Strecke}<0.2, SetVar(1, {[BMS] Traction battery Actual Energy}), GetVar(1, 0))
Consumption
((GetVar(1,0) - {[BMS] Traction battery Actual Energy}) / 1000 / {zurückgelegte Strecke}) * 100
Uups. Sorry, ich hatte Deine letzten Beiträge übersehen gehabt 
Ich schaus mir an!!
Hier in der Zwischenzeit noch mein feinoptimiertes Dashboard (natürlich wieder von .txt auf .cbz umbenennen) - aktuell natürlich noch nur mit Momentanwerten... Aber so bin ich aktuell unterwegs und finde es schon mal sehr hilfreich...
USR16 Habe Carscanner jetzt entsprechend mit Deinen Formeln und ein paar weiteren „Plausibilitäts-PIDs“ „präpariert“, und werde morgen während der Fahrt testen! Bin gespannt wie Bolle! (weil so ganz habe ich noch nicht begriffen, wie Du mit Deinen Formeln jetzt plötzlich doch die GetVar zum Wert-ausgeben überredet hast).
Jedenfalls schätze ich Deine Kreativität und Sachverstand, gepaart mit einer guten Portion Experimentiergeist, sehr! (Und ausgesprochen geschickt finde ich übrigens, dass Du erst nach 100m Fahrt den Startwert „einzufangen“ beginnst!)
Sollte es klappen, würde ich überlegen, ob man den Wert wirklich gleich am Anfang der Fahrt einfangen sollte, oder evtl. erst, nachdem z.B. die 12V-Batterie fertig nachgeladen ist. Weil so würde der Durchschnittsverbrauch anfangs sehr nach oben verfälscht (mathematisch zwar korrekt, aber um den Durchschnittswert für Fahrstiloptimierungen nutzen zu können, wäre eine Messung ohne die Anfangsverbraucher evtl. besser geeignet. (und Dein „erst ab 100m“ messen geht ja auch schon in diese Richtung, so blendest Du ja das z.B. Frontscheibe-heizen vor dem Anfahren ja auch schon aus).
Oder, alternativ, mittels eines „Aktions-PID“ jederzeit dem Fahrer die Möglichkeit zu geben, während der Fahrt den Durchschnittsverbrauch zu „nullen“ (dazu währe allerdings neben einem erneuten „Helper“-Aufruf, was ja problemlos machbar wäre, auch ein Nullen der zurückgelegten Stecke notwendig - und falls es dafür kein Bordmittel gäbe, also eine 2. Helper PID für die zurückgelegte Strecke). Außerdem ginge das Nullen nicht über Carplay/AndroidAuto, sondern nur direkt am Handy-Display.
Oder, 3. Idee, resultierend aus den beiden ersten, ein automatisches Nullen alle z.B. 10 Minuten oder 10km, damit man eine bessere Idee über den Verbrauch in der aktuellen Straßen- bzw. Fahrsituation erhält?
Mal sehen! Jetzt muss es zuerst mal prinzipiell funktionieren!
Hallo zusammen, hat es jemand geschafft, die ABRP-App mit einem OBD-Gerät zu nutzen? In der App wird die OBD-Verbindung immer noch nicht angezeigt. Ich würde mich über Hilfe freuen!
Hallo zusammen, hat es jemand geschafft, die ABRP-App mit einem OBD-Gerät zu nutzen? In der App wird die OBD-Verbindung immer noch nicht angezeigt. Ich würde mich über Hilfe freuen!
Das habe ich noch nicht versucht. Aber um festzustellen, ob es der OBD-Dongle oder ABRP ist, könntest Du mal testweise versuchen, Deinen Dongle mit Carscanner zu verbinden! Dann weißt Du zumindest, woran es liegt...
Alles anzeigenBeim Schreiben des Beitrags kam mir noch eine Idee, wie man das Problem umgehen könnte. Und ich glaube, es könnte so funktionieren.
Mein Workaround für die komische SetVarOnce-Logik:
Ich nutze stattdessen SetVar und lasse den Wert nur in einem sehr kleinen Fenster der zurückgelegten Strecke (0,1–0,2 km) setzen, über eine If-Abfrage. So wird der Startwert einmal „eingefangen“, und danach nur noch gelesen. Damit bekomme ich erstmals plausible Werte, die wie ein realistischer Durchschnittsverbrauch für die Fahrt aussehen.
Gerne ausprobieren und rückmelden, ob die Werte bei euch auch sinnvoll aussehen.
Die Formeln:Consumption_Helper
if({zurückgelegte Strecke}>0.1 && {zurückgelegte Strecke}<0.2, SetVar(1, {[BMS] Traction battery Actual Energy}), GetVar(1, 0))
Consumption
((GetVar(1,0) - {[BMS] Traction battery Actual Energy}) / 1000 / {zurückgelegte Strecke}) * 100
Ich darf meinen Hut ganz tief vor Dir ziehen!
Du hast es mit diesen Formeln tatsächlich geschafft, die Variablen-Geheimnisse zu entschlüsseln!
Ja, es funktioniert hervorragend und zuverlässig - und meine oben beschriebenen Ideen sind völlig unnötig, mittels "Trennen" und dann wieder "Verbinden" startet die Berechnung neu (ganz ohne Aktions-PIDs)!
Der Wert ist auch plausibel, und mathematisch korrekt.
Inhaltlich stimmt er aus meiner Sicht trotzdem noch nicht so ganz, weil Du ja den anfänglichen Batterie-Füllstand sicherst und dann mit dem jeweils aktuellen Füllststand in Beziehung setzt.
Problem dabei: Die jeweils angezeigten kWh sind nicht fixe, absolute Werte (wie es z.B. "Liter" im Benzintank sind), sondern zumindest temperaturabhängig (sieht man daran, dass der "Capacity"-Wert (also der "Höchstfüllstand" der Batterie mit der Temperatur (und evtl. noch weiteren Parametern) signifikant volatil ist.
Er steigt mit steigender Batterietemperatur.
Wenn nun der Wagen heute morgen bei -10 Grad startete, und hierbei die aktuellen kWh der Batterie speicherte, und die während der Fahrt dann um 18 Kelvin anstieg (damit das Batterievolumen "größer" wurde), dann spiegelt die Differenz zwischen Start-kWh und aktueller kWh nicht den Verbrauch wieder, sondern täuscht einen zu niedrigen Verbrauch vor.
Ich überlege noch, wie man das korrigieren könnte: Evtl. indem man nicht den Absolutwert bei Start speichert, sondern das Verhältnis von "Capacity" zu "Actual" - also eine Art SoC.
Und während der Fahrt, bei steigender "Capacity", aus dem anfänglichen Verhältnis und dem aktuellen Verhältnis die inzwischen "fehlenden" kWh errechnet?
Wie auch immer: Ganz großes Kino, was Du da herausgefunden hast!!
Tom ate Danke dir für den Test. Genau das Verhalten habe ich auch beobachtet und das die Werte nominal noch nicht ganz hinkommen. Ich bin aktuell noch am Nachtesten, indem ich die geladenen Kilowattstunden an meiner Wallbox mit dem Werten aus dem Car Scanner vergleiche. Mein aktueller Ansatz ist auch etwas über den SOC herzuleiten. Bin da aber noch im Testing, welchen der Werte man am besten nehmen sollte. Oder ob man sich einen eigenen „SOC“ analog deiner Idee berechnen sollte.
