Kann ich so bestätigen. ABRP zeigt aktuell sehr viel Quatsch an.
Dann lasst uns die Sachen wieder etwas auseinander nehmen und das Problem der „irren“ Datenauslesung entsprechend der App/Anwendung weiter diskutieren, sonst wird’s hier plötzlich völlig off topic 
, und schliesslich wollen wir dem CSV Team nicht noch die Verantwortung für Fehlleistungen des ABRP Teams zuschanzen - oder ist am Ende doch alles in der Verantwortung des Polestar IT Teams, welches neuerdings schlicht falsche Daten an den Schnittstellen zur Verfügung stellt?
So wie ich es beobachtet habe, sind die Abweichungen nicht so hoch wenn es warm ist.
Den höheren Anfangsverbrauch beobachte ich beim BC eher bei kälteren Temperaturen.
Ich vermute, dass die Verbräuche der Batterieheizung nicht an den CSV weitergegeben werden.
Ich denke schon, dass die Android-API auch die Akkuheizung mit berücksichtigt, das sieht man ja eigentlich auch ziemlich deutlich an der Momentanleistung, wenn man im Klima-Menü die Heizung ausschaltet. Ich kann mir kaum vorstellen, dass die Innenraumheizung allein bis zu 7kW zieht 
. Diese Starken Abweichungen hatte ich auf sehr kurzen Strecken auch bei warmem Wetter
Hmm… ja stimmt schon. Evtl. gibt es noch andere elektrische Verbraucher die unmittelbar nach dem Start aktiv werden und nicht über die API übermittelt werden. Eine Art Systemcheck…
Aber das sind nur wilde Theorien.
BTW: Wie wird der Verbrauch im CSV gebildet? Über die Leistung?
Vermutlich sinkt der SoC dann später, wenn der Wagen ein Weilchen stand. Lies mal hier die folgenden Beiträge. Das passt zu dem, was Du schreibst….
Laut API wird die Leistung zurückgegeben, die in den Akku verlässt oder herein geladen wird. Für Die Akkutemperierung muss der Strom da ja erst mal raus. Lediglich der Innenwiderstand der Batterie ist nicht nachvollziehbar. Jedenfalls ist das so meine Einschätzung. Dass die API und der BC unterschiedliche Sensoren nutzen, halte ich für unwahrscheinlich. Lediglich am Ladeport scheint noch mal separat gemessen zu werden, denn da weicht CSV nach unten ab.
Die Leistung wird mehrfach pro Sekunde erfasst und anschließend numerisch integriert. Genauso die Geschwindigkeit zum errechnen der Distanz. Da das ja sehr präzise klappt denke ich nicht, dass es ein mathematischer Fehler ist.
Hier vermute ich eher, dass Verbraucher vorher bedient werden und somit weniger in den Akku geht. Dadurch ist CSV mit niedrigeren Werten, da die API diese Werte dann gar nicht erhält. Polestar kann diese Verbräuche wohl abfangen und zur Ladeleistung hinzurechnen.
Ich habe dann heute auf dem Weg zur Arbeit (2 km) mal was ausprobiert:
Klimaanlage komplett aus, beim reinsetzen als aller erstes D eingelegt, damit CSV rechnet. Abweichung waren nun „nur“ 1 kWh/100km (16,7 vs. 17,7 im BC). Vorher war das etwas mehr. Nun ist die Frage: Lag es am frühen Schalten in D, oder an der ausgeschalteten Klimaanlage?
Eine Vermutung wäre, dass die Anzeige im BC etwas träge ist: Es wird nur bei vollen 100m oder vollen Minuten der Wert aktualisiert. Das passiert beim CSV sekündlich. Zumindest auf sehr kurzer Strecke würde das Abweichungen im Bereich von +/- 2 kWh/100km erklären. Da reicht ja ein Bremsvorgang, um diese Schwankungen zu erzeugen.
Dagegen spricht jedoch, dass auch mein TM abdriftet. Den habe ich kurz vor dem Trip nach Frankfurt (ca 600km) zurückgesetzt. Nach dem Trip stimmten die Werte überein. Mittlerweile, vermutlich durch die vielen Kurzstrecken, ist aber eine Abweichung von 0,5 kWh/100km zusammen gekommen. Außerdem hatte ich ja auch Abweichungen, die nicht mit dieser niedrigen Rate neuer Werte erklärbar sind, z.B. 33 vs. 26 über vergleichsweise lange Strecke und Zeit.
Es ist und bleibt also erst mal ein Rätsel.
Aus meiner Perspektive der 5 sekündlichen Information über den WebHook ist das eigentlich ziemlich klar, was da vor sich geht. In den 5 Sekunden passiert da alles mögliche und was man dann sieht, ist ein Momentanwert.
Schwankungen von angeblich 10 auf 400 kWh /100km und zurück innerhalb solcher Intervalle sind technisch wenig glaubhaft. Jedenfalls macht die Elektro-Mechanik des Autos sowas nicht.
Es sei denn, ich würde Jojo mit dem Auto fahren. Mache ich aber nicht.
Gestern war es exemplarisch: nur ein paar 100m in der Stadt: Fußgängerzone, Ampel.
Die ersten paar Kilometer scheint es ohnehin viele diffuse Werte zu geben.
Um so länger die Strecke, desto glatter wird es und die zappeligen Anfangswerte fallen im Durchschnitt dann einfach weg.
Das auszugleichen und eine einigermaßen sinnvolle Anzeige zu zaubern, da werden die Göteborger ein paar Tricks anwenden - so, wie du das auf deinem CSV ja auch machst. Spikes wegkappen z.B.
Wo nimmst du die konkreten Zahlenwerte her? Der Momentanverbrauch ist durchaus extrem wechselhaft. Im Stillstand ist er ja quasi Unendlich hoch. Grade bei dem 5-Sekunden-Intervall erwischt man gerne mal astronomische Werte, da das ja, wie du bereits sagst, Momentaufnahmen sind. Grade beim Anfahren sind Werte > 400 kWh/100km als Momentanwert absolut möglich und plausibel (Beispiel: Beschleunigung mit 20kW Leistung, Momentaufnahme bei 5km/h → 400 kWh/100km). Solche Betriebszustände sind natürlich ein absoluter Bruchteil der gesamten Betriebszeit. Im Durchschnitt ist das dann glatt gebügelt.
CSV schneidet auch keine Werte ab, in der Datenerfassung wird alles so verarbeitet, wie es das Auto meldet. Lediglich die Anzeige wird in Gewissen grenzen gehalten, um die Leserlichkeit zu verbessern. Die dargestellten Zahlenwerte unterliegen aber keiner Glättung und Verfälschung, mal abgesehen von den unumgänglichen Rundungsfehlern, wenn man mit Fließkommazahlen rechnet.
Sollte Polestar tatsächlich „unechte“ Messwerte zur Darstellung verwenden, um sinnvolle Anzeigen zu erhalten, dann würde ich eher erwarten, dass der BC zu wenig anzeigt. Aber das ist ja nicht der Fall. CSV zeigt niedrigere Werte an, als würde irgendwas nicht erfasst werden.
Entweder trackt der BC irgendwas, was die API nicht bereitstellt, er erfasst einen anderen Zeitrahmen und ich muss meine Trigger noch mal anpassen, oder Polestar hat einen Bock geschossen. Im Moment halte ich alles für gleich wahrscheinlich.
Na, aus deinen Daten via Webhook 
Siehe meine Tabellen.
Ist ja auch ok, nur die Erklärung ist nicht, dass sie tatsächlich existieren, sondern in den wie auch immer kurzen Intervallen nur Momentaufnahmen sind. Möglicherweise auch verfälscht, weil mit Spannungen gearbeitet wird. Eine Anzeige 400kWh/100km, die errechnet wird, ist natürlich für eine Fraktion ggf. einer Sekunde erklärungsbedürftig. Oder setzt Verständnis voraus, welches wir ja haben.
Eine Analoganzeige würde das nicht merken.
Mich wundert diese Diskussion um nicht erklärbare kW oder auch kWh, obwohl doch klar ist, dass auch der Akku sein Eigenleben führt (BMS) und je z.B. nach Temperatur und vergangener Zeit plötzlich was anderes abzulesen ist. Dass dein CSV mal mehr order weniger mitteilt, liegt daran, dass die Ing. in Göteborg an den Daten im P. etwas machen, bevor sie zur Verfügung gestellt oder sogar angezeigt werden. Ständig unerklärbare Anzeigen will auch keiner haben.
Ist doch alles i.O. und macht euch nicht so viele Gedanken um vermeintlich verlorengegangene Bits.
Ich verstehe, was du sagen willst, aber solche Kleinigkeiten sind einfach dinge, die bei mir das größte Bedürfnis auslösen, sie zu lösen. Und da ist dann mein Eifer geweckt, diese Sache aufzuklären 
Ich habe vorhin noch mal beobachtet, wie der BC so auf Änderungen reagiert. Wie bereits vermutet erfolgt ein Update des Durchschnittsverbrauchs immer dann, wenn 100m zurückgelegt wurden, oder der Timer 1 Minute hoch zählt. Dazwischen wird also kein Durchschnitt berechnet, oder zumindest nicht aktualisiert. Beim los fahren ist mir dann aufgefallen, dass der verbrauch beim schalten auf D und umspringen der Minute auf einen signifikant höheren Wert gesprungen ist. Das suggeriert mir, dass der BC doch auch ohne D den Verbrauch erfasst, aber eben kein Update der Darstellung stattfindet.
Ich werde in meinem Dev-Branch mal versuchsweise den Trigger ändern und dann schauen, wie die Differenz aussieht. Wenn es sich näher angleicht, dann werde ich das per Option einbauen (vielleicht auch unabhängig davon). Dann kann sich jeder selbst aussuchen, ob er alle Verbräuche, oder nur die während der Fahrbereitschaft in die Statistik aufnehmen will.
2 „Gefällt mir“
Ich hätte da noch einen weiteren Ansatz, aber da ich in Elektrotechnik nicht wirklich bewandert bin, bitte nicht gleich steinigen, falls es Bullshit ist 
.
Ist es wirklich korrekt, dass die in den Akku zurückgeführte Leistung beim rekuperieren in kWh/100km umgerechnet wird?
Ich habe schon mehrfach folgende Beobachtung gemacht und kann diese 100% reproduzieren.
Gefällstrecke, ca.350m Höhenunterschied, gut ausgebaut, auf 80 km/h beschränkt und Überholverbot.
Rolle ich gleichmäßig rekuperierend mit ca. 80 km/h den Berg runter, gewinne ich laut CSV ca. 0,4 bis 0,5 kWh/100 km zurück.
Schleiche ich mit 25 km/h hinter landwirtschaftlichem Verkehr her, bekomme ich eine Gutschrift von 1,2 bis 1,3 kWh/100 km.
Nur am erhöhten Luftwiderstand wirds ja nicht liegen .
Der Source Code von mypolestar.de steht nun ab sofort zur freien Verfügung bereit.
Der Code und Anleitung sind auf der Seite oben Mitte zu finden.
Ich habe es so einfach, wie (mir) möglich gehalten und so hoffe ich, dass es einigen auf die Sprünge helfen wird.
An die Experten: erwartet nicht zu viel, denn ich bin ein einsamer Wanderer im Software-Nirvana.
Absichtlich habe ich alles weggelassen, was man machen könnte.
Eigentlich würde ich es mit einer mySQL Datenbank und viel Javascript machen. Beides und andere Techniken sind hier nicht zu finden, so dass auch ein Ungeübter Veränderungen vornehmen kann.
Mit verschiedenen Webseiten habe ich den Source getestet. Es funktioniert.
So wünsche ich dann also starke Nerven und viel Spass.
3 „Gefällt mir“
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“?
Bei einem Premium-Account hast du dafür die Möglichkeit, verschiedene Konfigurationen anzulegen.
Den Feed temporär zu trennen reicht, da wird nichts gepuffert.
ABRP läuft definitiv nicht im Hintergrund mit - sonst bräuchte es CSV ja nicht.
2 „Gefällt mir“
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
15 „Gefällt mir“
Mein Testtrack (de.pschlosser.carStatsViewer) habe ich auf 0.24.1 hochgezogen.
der Test Track ist leider auch demnächst voll…
Installationen/Anmeldungen: 56/80
2 „Gefällt mir“
Auch mein Track ist auf 0.24.1
5 „Gefällt mir“
