SOC BMW

[aiole]

Weiter Überlegungen:
Falls Fahrzeuge aus verschiedenen CD-Accounts vorhanden sein sollten, muss natürlich für jeden Account ein Fahrzeug mit echtem Captcha-Token konfiguriert sein.

Das entspricht der sw2-Fahrzeug-Philosophie.

In der ramdisk würde ich zusätzlich zu vin, soc, range, soc_timestamp auch noch userid und Zeitstempel der Abfrage speichern. Damit kann Plausibilität überprüft werden (userid gleich) und bei zu alter Datei eine Warnung im Log geschrieben werden.

Der Aufwand ist relativ überschaubar.
Soll ich das implementieren?

Ich habe zwar nur 1x BMW, aber macht aus BMW-Serversicht Sinn. Könnten wir im master ausprobieren.
Danke für deinen unermüdlichen Einsatz!

[heidanei]

Hi!

Eine weitere Überlegung:
Das Problem mit fehlerhaftem Token-Refresh scheint primär aufzutreten wenn es mehr als ein BMW/Mini Fahrzeug gibt.
Bei jeder Abfrage werden vom bimmer_connected die Daten für alle Fahrzeuge vom CD-Server gelesen aber wir nutzen aktuell diese Daten immer nur für die jeweilige VIN.

Genau diese Überlagung hatte ich auch schon...

Der Aufwand ist relativ überschaubar.
Soll ich das implementieren?

Von mir auch ein ganz klares JA! Die BMW-App fragt ja auch mit einer Anmeldung alle Fahrzeuge im Account ab, d.h. so würden wir noch näher an das Verhalten der App kommen. Auch wenn es bei mir jetzt schon recht stabil läuft (Hab heute Morgen übrigens die api.py aus deinem gestrigen Commit eingespielt, bis jetzt keine Probleme! <wiederaufholzklopf> ) ist jede weitere Optimierung gut!
Vielen Dank auch von mir! Ich spende gerne wieder an eine Hilfsorganisation...

heidanei

[LutzB]

So rein theoretisch wären wir da bei dem Modell, was auch für die Geräte und Komponenten genutzt wird. In diesem Kontext wäre dann das Gerät der CD-Account, jedes Fahrzeug eine Komponente.

Datentechnisch müsste es eine übergeordnete Klasse für den Account geben, die nur einmal angelegt wird (Stichwort Static). Auf diese Instanz können dann alle Zugehörigen Fahrzeuge zugreifen. Die Account-Klasse müsste dann entscheiden, ob der Wert aus dem Cache verwendet wird oder eine neue Abfrage notwendig ist.

[rleidner]

So rein theoretisch wären wir da bei dem Modell, was auch für die Geräte und Komponenten genutzt wird. In diesem Kontext wäre dann das Gerät der CD-Account, jedes Fahrzeug eine Komponente.

Datentechnisch müsste es eine übergeordnete Klasse für den Account geben, die nur einmal angelegt wird (Stichwort Static). Auf diese Instanz können dann alle Zugehörigen Fahrzeuge zugreifen. Die Account-Klasse müsste dann entscheiden, ob der Wert aus dem Cache verwendet wird oder eine neue Abfrage notwendig ist.

Danke Lutz, guter Vorschlag, muss ich mir aber erst mal ansehen.

Ich habe eine Version fast fertig, die das "old school" löst.
Das Verhalten gegen den CD-Server wäre damit schon mal vorhanden.
Diese Version würde ich erst mal von mindestens einem der betroffenen Anwender mit ssh Zugriff (heidanei?) testen lassen.
Wenn das die Refresh-Probleme löst, würde ich es auf das vorgeschlagene Modell umbauen.

[LutzB]

Bin in Python aber nicht so fit, was solche Strukturen angeht. Im Zweifel kann Lena da besser helfen, wenn Bedarf besteht.

[rleidner]

Ist jetzt in dem offenen PR implementiert.
Die Klasse ist als "singleton class" implementiert, d.h. es gibt nur eine Instanz.
Der o.g. Cache in der ramdisk ist damit nicht nötig.
Das Fahrzeug mit der numerisch kleinsten id sollte das echte Captcha-Token, d.h. den CD.-Zugang enthalten.
Das sollte dafür sorgen, dass nach Neustart die Instanz mit dem CD-Zugang zuerst initialisiert wird.
Weitere Fahrzeuge in gleichen CD-Account sollten als Cache-Token exakt den Wert "SECONDARY" enthalten (in capitals, ohne die Quotes, keine Leerzeichen davor/danach!)
Zum Test habe ich "mein" Testfahrzeug 2 mal angelegt, einmal als PRIMARY (ev4), einmal als SECONDARY (ev7).
Der SoC-Log sieht dann so aus:

Code: Alles auswählen

2025-03-01 19:19:29,843 - {modules.vehicles.bmwbc.api:210} - {INFO:fetch soc_ev4} - authenticate via current token set
2025-03-01 19:19:31,491 - {modules.vehicles.bmwbc.api:291} - {INFO:fetch soc_ev4} - PRIMARY SOC/Range: 75%/152.0KM@2025-03-01T18:10:04Z
2025-03-01 19:19:31,495 - {modules.vehicles.bmwbc.api:41} - {INFO:fetch soc_ev4} - store file action:store written
2025-03-01 19:19:31,511 - {modules.common.store._api:31} - {INFO:store soc_ev4} - Saving CarState(soc=75, range=152.0, soc_timestamp=1740849004.0)

2025-03-01 19:19:39,202 - {modules.vehicles.bmwbc.api:176} - {INFO:fetch soc_ev7} - SECONDARY: SOC/Range: 75%/152.0KM@2025-03-01T18:10:04Z
2025-03-01 19:19:39,219 - {modules.common.store._api:31} - {INFO:store soc_ev7} - Saving CarState(soc=75, range=152.0, soc_timestamp=1740849004.0)

Das UI werde ich später anpassen, d.h. die SECONDARY Option in den Instruktionen ergänzen.
BTW: Falls Fehler auftreten sollten sind diese jetzt neben dem Soc-Log auch auf der Status-Seite im entsprechenden Fahrzeug zu sehen.

[heidanei]

Hi!

Ist jetzt in dem offenen PR implementiert.

Des ging ja wahnsinnig schnell! Danke! Bin heute unterwegs, werd's am Abend einspielen und morgen dann testen.

Viele Grüße, heidanei

[aiole]

! Der ist noch nicht in den master gemerged !

[rleidner]

! Der ist noch nicht in den master gemerged !

Klar, heidanei hat ssh Zugang und holt sich die Änderungen direkt aus dem PR

[aiole]

auch gut