SOC BMW

[rleidner]

Seit gestern um ca. 19:25 sind beide Soc wieder auf 0% gefallen.
Im Gegensatz zu sonst hat aber auch ein neues Capcha-Erzeugen nicht geholfen, ich bekomme den Soc nicht mehr abgefragt.
Bin auf der aktuellen 2.1.7 Beta. Ist das bei euch auch so?

Gruß,
Chris

Funktioniert hier normal, sowohl mit vorhandenen Token als auch mit neuem Captcha.

[Frizzel]

Ich habe es wohl mit der Abfrage übertrieben:

Modulmeldung: <class 'bimmer_connected.models.MyBMWAuthError'> ("HTTPStatusError: Client error '429 Too Many Requests' for url 'https://customer.bmwgroup.com/gcdm/oaut ... cate'\nFor more information check: https://developer.mozilla.org/en-US/doc ... Status/429",)

Mich stört halt dass er sonst immer 30min wartet bis er beim Heimkommen merkt dass der niedrige SOC ein Laden auslösen soll. Und dann ist die Sonne weg. Daher habe ich auch bei nicht-laden ein recht geringes Intervall…

[LutzB]

Wenn das Auto angesteckt wird, sollte eigentlich direkt der SoC abgefragt werden. Unabhängig von den konfigurierten Intervallen.

[Frizzel]

Das tut er bei mir nicht, zumindest war das meine Erfahrung vor dem Runtersetzen des Intervalls. Kann exht sein dass das seit einiger Zeit geht und ich es einfach nie herausgefunden habe Ich habe jetzt das Intervall wieder hochgesetzt und beobachte das Verhalten beim Anstecken.

[Johnny79]

Das tut er bei mir nicht, zumindest war das meine Erfahrung vor dem Runtersetzen des Intervalls. Kann exht sein dass das seit einiger Zeit geht und ich es einfach nie herausgefunden habe Ich habe jetzt das Intervall wieder hochgesetzt und beobachte das Verhalten beim Anstecken.

Was spricht dagegen ein 10-Minuten Abfrageintervall zu nutzen? So handhabt es zumindest die restliche Menscheit und es funktioniert.

[heidanei]

Was spricht dagegen ein 10-Minuten Abfrageintervall zu nutzen? So handhabt es zumindest die restliche Menscheit und es funktioniert.

Nein, nicht die gesamte. Ich lasse bei nicht angestecktem Fahrzeug seit einiger Zeit gar nicht mehr pollen, weil das IMO vollkommen unnötig ist.

@rleidner: Inzwischen läuft's mit der api.py aus dem (immer noch offenen) PR #2208 bei mir sehr stabil. Seit 17.2. kein neues Token mehr erforderlich! - <aufholzklopf>

heidanei

[rleidner]

@rleidner: Inzwischen läuft's mit der api.py aus dem (immer noch offenen) PR #2208 bei mir sehr stabil. Seit 17.2. kein neues Token mehr erforderlich! - <aufholzklopf>

heidanei

Danke für die Rückmeldung - ich klopfe mal mit
Evtl. ist der proaktive Token-Refresh doch der "Trick".
Ich habe übrigens heute eine weitere Korrektur in dem PR committed.

[Frizzel]

Ich habe ja zwei BMWs die ich parallel abfrage. Evtl. Ist der Server bei mir schneller beleidigt weil es von der selben ip kommt? Oder ist das kürzeste Intervall tatsächlich VIN-selektiv?

[rleidner]

Ich habe ja zwei BMWs die ich parallel abfrage. Evtl. Ist der Server bei mir schneller beleidigt weil es von der selben ip kommt? Oder ist das kürzeste Intervall tatsächlich VIN-selektiv?

Wie verhält sich das genau, wenn der Fehler 429 auftritt.
Kommt der dann für beide Fahrzeuge oder nur für eines?
Das sollte man im SoC-Log sehen können.

[rleidner]

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.
Dieses Verhalten entsteht durch die Fahrzeugorientierung in 2.x, man könnte es aber auch optimieren.

Ich kann das Modul wie folgt ändern:
- Im Einstellungs- UI kann als Captcha-Token alternativ ein fester Wert z.B. "SECONDARY" eingegeben werden.
- Das Modul für das Fahrzeug mit "echtem" Captcha-Token (!="SECONDARY") fragt alle Fahrzeuge des Accounts ab und speichert die relevanten Daten (soc, range, soc_timestamp) für jede gefundene VIN in der ramdisk.
- Das Modul für Fahrzeuge mit Captcha-Token = "SECONDARY" liest die Werte aus der ramdisk und übergibt diese an openWB.

Vorteile:
- aus CD-Server Sicht gibt es je Account nur noch eine aktive openWB-Instanz/Session/Token-Set
- es muss vom Nutzer nur eine aktive Instanz mit Captcha-Token gepflegt werden
- es finden deutlich weniger Abfragen auf dem CD-Server statt.

Nachteil:
Nach Neustart kann es vorkommen, dass die Datei in der ramdisk für ein SECONDARY Fahrzeug noch nicht existiert.
In dem Fall würde eine entsprechende Meldung im Status/Log angezeigt und als soc/range 0 übergeben werden.

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.

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?