stimme mit @Landmatrose überein.
Trotz nachlassender Sehleistung 
Eindeutig Variante Eins !
Oder, noch eine andere Idee (weil du danach gefragt hast):
Für jede Ansicht ein Symbol, aber alle Symbole sind gleichzeitig sichtbar, nur das, was der aktuellen Ansicht entspricht, ist in irgendeiner Form hervorgehoben, entweder selbst als Symbol, oder zB ein kleiner Punkt daneben oder eine Linie oder Umrandung oder „Füllung“, welches eben die jeweils aktuelle Ansicht „markiert“.
Oder/und die inaktiven Symbole etwas in den Hintergrund bringen/abdunkeln oder so.
Platz wäre vielleicht vertikal links oder rechts. Oder es entsteht durch ein angepasstes Arrangement irgendwo neuer horizontaler Platz…
1 „Gefällt mir“
Absolut der Wahnsinn wäre ja, wenn man einfach jede Ansicht nach rechts durchwischen könnte.
Manueller Trip → nach rechts wischen → Monatstrip → nach rechts wischen → automatischer Trip…
Aber ich träume halt auch manchmal am Montagmorgen.
5 „Gefällt mir“
Ich kann mit beiden Varianten gut leben. Eins ist etwas schöner, aber man müsste schauen wie das dann auf dem echten CD bei zB Sonne aussieht - in ggf den Kontrast anpassen.
Aber wischen @Enso wäre wirklich ein Traum!
Ich stimme ebenfalls für Variante 1. Optisch ansprechend und, meines Erachtens, auch wegen der Größe selbst bei halbtransparenter Darstellung ausreichend gut erkennbar. Danke für Deine Arbeit, @Ixam97 !
Bist Du mit Deinem Vorhaben schon weiter gekommen? Ich habe die gleiche Herausforderung.
Setting: IoBroker auf NAS im Container, MQTT als Kommunikation und evcc zum Laden
Nein, zu viele andere Baustellen 
Ich bin ein Stück weiter gekommen.
Ich hab das PHP-Script von http://mypolestar.de auf meinem Server installiert und dort auch Daten empfangen.
Habe bisher 3 Probleme identifiziert:
- Der csv hört kurz nach verlassen des Fahrzeugs auf, Daten zu übermitteln. Das wäre wichtig, um Ladevorgänge zu übermitteln.
- Das PHP-Script hängt die neuesten Datensätze immer unten an die Seite an. Das macht das Parsen mühselig, um den letzten Eintrag ( also den neuesten) zu finden
- Mein Regex für das Parsen im IoBroker-Adapter macht auch noch nicht das, was er soll.
Da lässt sich auch nichts dran Rütteln. Sobald das Android-System nach dem abstellen deaktiviert wird, kann die App in logischer Konsequenz nichts mehr erfassen und senden.
Macht Sinn, ist für den Use-Case aber leider schlecht.
Ein Workaround könnte sein, in evcc das manual SOC Feature zu nutzen. Da benötigt man den Anfangswert und evcc rechnet dann selber weiter.
Man kommt immer wieder zum gleichen Schluss: Die API-Strategie von Polestar ist zum Kotzen…
Dem Product Owner dieses Entwickler Teams gehört mächtig der A… versohlt.
Kurze Frage, weil ich’s nicht gefunden habe:
Warum ist der Durchschnittsverbrauch in der Grafik unten anders als rechts oben abgegeben?
Du meinst mit der Grafik das Diagramm? Dort ist der Durchschnitt immer nur auf den im Diagramm sichtbaren Bereich beschränkt. Oben rechts der Wert bezieht sich auf die gesamtstrecke des Trips. Auch wenn das Diagramm in der Zusammenfassung die gesamte strecke anzeigt, kann es zu leichten Abweichungen kommen. Das liegt an der Art, wie das Diagramm mit Daten gefüttert wird und daraus den Durchschnitt berechnet. Wir sind im Moment am überlegen, wie man das konsistenter hin bekommt, aber groß sollte die Abweichung in dem Fall nicht sein.
1 „Gefällt mir“
Eine kurze Info für alle, die den HTTP-Webhook von CSV nutzen:
Aufgrund der recht umfangreichen Änderungen an der Datenstruktur beabsichtige ich auch die von CSV verschickten Daten daran anzupassen. Das neue Datenformat wird dann wie folgt aussehen:
data class HttpDataSet(
val apiVersion: Int = 2,
val appVersion: String,
val timestamp: Long, // ms epoch time
val speed: Float, // m/s
val power: Float, // mW
val selectedGear: String,
val ignitionState: String,
val chargePortConnected: Boolean,
val batteryLevel: Float, // Wh
val stateOfCharge: Float, // 0.0 - 1.0
val ambientTemperature: Float, // °C
val lat: Float?,
val lon: Float?,
val alt: Float?,
// ABRP debug
val abrpPackage: String? = null
)
Rausgeflogen ist alles, was mit einem speziellen Trip zu tun hatte, da das Werte waren, die Abhängig vom in der App ausgewählten Trip waren. Das sollte einen Server aber nicht wirklich interessieren.
Die Änderungen treten dann mit v0.25.0 in Kraft. Wer möchte kann sich schon mal darauf vorbereiten. Der Parameter „apiVersion“ dient zukünftig der Unterscheidung verschiedener Formate.
Vermisst da jemand irgendwas spezielles?
4 „Gefällt mir“
Danke für die Info. apiVersion ist wichtig. 
PS: Für alle von uns, die etwas langsamer denken:
val latitude: Float?,
val longitude: Float?,
val altitude: Float?,
Und jetzt die Sonderwünsche. Hast Du
- Türstatus (verriegelt/entriegelt)
- Klimastatus (läuft, Restlaufzeit)
- Ladestatus (wenn
chargePortConnected=true) - Ladeleistung (nur wenn geladen wird)
- maximaler SOC bis zu dem geladen wird
- Ladeabschluss (prognostizierte Zeit)
Aber nur, wenn es keine Mühe macht. 
- Türstatus
- Klimastatus
Dafür sind mir keine VehicleProperties bekannt, auf die ich zugreifen kann.
- Ladestatus
- Ladeleistung
Geht implizit aus den vorhandenen Parametern hervor: Wenn der Ladeanschluss angeschlossen ist und die Leistung negativ ist, wird geladen.
- maximaler SoC
- Ladeabschluss
Ich habe grade mal nachgesehen, da wurde die Dokumentation erweitert:
Bis auf PORT_CONNECTED und PORT_OPEN sind das neue Vehicle Properties. Allerdings erst ab API-Level 33 verfügbar (Android 13). Der Polestar 2 hat aktuell API-Level 30 (Android 11). OEMs können die zwar auch schon früher implementieren, aber das müsste man dann ausprobieren. Ich schätze aber das wird bei Polestar aktuell anders umgesetzt sein.
1 „Gefällt mir“
Ich habe in der 0.24er Version deutlich öfter das Thema, dass CSV im Hintergrund nicht das Service startet, auch ohne Userwechsel.
Ist das sonst noch jemand aufgefallen?
Hab alle Schieber auf ja, bis auf dynamische Push Meldung. Ging mit 0.23 stabiler.
3 „Gefällt mir“
Jep, das passiert bei mir regelmäßig. Die Benachrichtigung kommt auch nicht immer zuverlässig.
Der Service selbst kann auch nicht alleine im Hintergrund starten. Das ist eine Limitierung von Android. Die Benachrichtigung, die ich dafür eingerichtet habe, ist eine Art Workaround. Mit 0.25 wird diese auch noch mal deutlich zuverlässiger, da der dahinter liegende Watchdog nicht mehr selber regelmäßig einzelne „Alarme“ setzt, sondern beim Starten ein wiederkehrender Alarm beim OS registriert wird. Der bleibt dann auch bei einem App-Absturz garantiert aktiv. Nach spätestens einer Minute sollte dann auf jeden Fall eine Meldung kommen, wenn die App abgestürzt sein sollte. Auch nach Updates sollte die Benachrichtigung dann zukünftig zuverlässig angezeigt werden.
Ich beobachte leider auch gelegentliche Abstürze, ohne dass ein Crash Log erzeugt wird. Bei euch kann ich so pauschal natürlich nicht sagen, wo der Fehler liegt. Dafür ist die Fehlerbeschreibung „App läuft nicht“ zu pauschal 
Schaut mal in den Debug Log (in den Einstellungen auf die Versionsnummer tippen), ob da Fehler geloggt wurden. Über das Zahnrad könnt ihr den logging level auf „Warning“ oder „Error“ stellen, um den Rest auszublenden.
Es kann allerdings passieren, dass die App abstürzt, wenn man versucht, zu lange Logs zu laden (das wird mit 0.25 auch behoben).
Allgemein fließen in 0.25 eine Menge Änderungen ein, die auch tief in die Datenstruktur eingreifen. Von daher ist es gut möglich, dass von euch beobachtete Fehler nach dem nächsten Update ohnehin nicht mehr auftreten.
5 „Gefällt mir“
