SOC BMW

[rleidner]

Das Captcha hattte ich eingegeben. Hat auch alles geklappt. Evtl ist das auch Zufall und hat nichts mit dem anderen Problem zu tun.
Modulmeldung: <class 'bimmer_connected.models.MyBMWCaptchaMissingError'> ('Missing hCaptcha token for login. See https://bimmer-connected.readthedocs.io ... ptcha.html',)

Das Problem ist bekannt.
Bei anderen hat es geholfen, den den Captcha-Prozess (vorhandenes Captcha Token durch ein Neues ersetzen) zu wiederholen, evtl. mehrfach.
Dabei darauf achten, dass nach dem Abholen und Speichern des Captcha-Token der SoC umgehend abgefragt wird (Kreispfeil!).
Hintergrund:
Wie bereits beschrieben klappt das Erneuern der vorhandenen Token in bestimmten Situationen nicht mehr.
Wenn bereits Token vorhanden sind, ist das captcha-Token nicht gesetzt - daher das "missing hCaptcha token for login".
Das vorhandene Captcha-Token würde auch nicht funktionieren, da es schon benutzt wurde.

[gpr]

Ich benutze das SOC Modul seit knapp 2 Monaten, super Arbeit.
Ich habe schon mehrfach beobachtet dass der SOC Wert (in der App wie in der openwb) nach dem Laden einen Sprung macht, bei großem Ladehub sind schon +10% vorgekommen. Der Grund ist sicherlich, dass der BMW Server zwischendurch interpoliert und nach Ladeende beim Auto nachfragt.
Ich vermute dass das SOC Modul die Interpolation besser hinbekommt da es genauere Daten zur Ladung hat. Daher scheint mir eine Konfiguration ideal, bei der während des Ladens der SOC gar nicht vom Server aktualisiert wird, dann aber direkt nach Ladestopp. Ersteres kann ich einstellen, zweiteres wäre eine Idee für einen Feature-Request, wenn das möglich ist?

[rleidner]

Ich benutze das SOC Modul seit knapp 2 Monaten, super Arbeit.
Ich habe schon mehrfach beobachtet dass der SOC Wert (in der App wie in der openwb) nach dem Laden einen Sprung macht, bei großem Ladehub sind schon +10% vorgekommen. Der Grund ist sicherlich, dass der BMW Server zwischendurch interpoliert und nach Ladeende beim Auto nachfragt.
Ich vermute dass das SOC Modul die Interpolation besser hinbekommt da es genauere Daten zur Ladung hat. Daher scheint mir eine Konfiguration ideal, bei der während des Ladens der SOC gar nicht vom Server aktualisiert wird, dann aber direkt nach Ladestopp. Ersteres kann ich einstellen, zweiteres wäre eine Idee für einen Feature-Request, wenn das möglich ist?

Danke, das ist eine interessante Beobachtung, die meine Vermutung bestätigt.
Das Feature "SoC-Abfrage nach Ladeende" ("zweiteres") müsste generell in SW2 umgesetzt werden. Innerhalb des SoC-Moduls kann man das nicht erkennen bzw. nur mit Kunstgriffen die den Review des PR nicht überstehen würden

[gdfde]

Ich glaube, es ist eher umgekehrt.
Der BMW schickt nach jedem Ladestopp den aktuellen Wert an den CD Server.

Ich hab zb. die Ladung auf 50 % eingestellt, er stoppt dann aber meistens erst bei ca. 55 %, weil die Interpolatiion/Abfrage dann doch etwas auseinanderdriftet.

[heidanei]

Hi!

@rleidner: Wird eigentlich beim Ladebeginn (bzw. Anstecken des Fahrzeugs) aktiv vom Modul der SoC abgefragt oder wird der letzte abgefragte Wert übernommen, auch wenn dieser im "schlimmsten" Fall fast eine Stunde alt ist (weil ich den Poll-Intervall bei nicht angesteckem Fzg. auf 1h eingestellt hab)?
Ich hatte in der letzten Zeit mehrfach das Problem, dass nach einer längeren Fahrt direkt nach Heimkehr eingesteckt noch ein viel zu hoher SoC in der oWB vorhanden war - von der letzten eingestellten Abfrage bei nicht angesteckem Fzg. - der natürlich viel zu hoch war und von diesem dann weiter "geladen" wurde, und somit der Ladevorgang viel zu früh beendet wird.
Früher ist mir sowas nicht aufgefallen, hat sich diesbezüglich in den letzten Versionen was geändert?

Viele Grüße, heidanei

[rleidner]

BMW (Bimmer) ist in OWB2 die aktuelle Version und wird gepflegt. Daher in OWB2 ab jetzt nur noch das BMW (Bimmer) Modul verwenden.

BMW (ohne Bimmer) ist die migrierte Version des OWB1 "BMW&Mini" Moduls, wird in OWB2 nicht mehr gepflegt und unterstützt das neue Captcha-Verfahren nicht. Das Modul sollte in der nächsten Zeit entfernt werden.
Sollten wir dann das "BMW (Bimmer)"-Modul in der Konfiguration in "BMW&Mini" umbenennen? Meinungen?

Ich habe einen PR erstellt, der das "alte" Modul "BMW" entfernt: https://github.com/openWB/core/pull/2135
In der nächsten Version wird das Modul "BMW (Bimmer)" dann in "BMW & Mini" umbenannt werden.

Ist jetzt im Master gemerged.

[rleidner]

Hi!

@rleidner: Wird eigentlich beim Ladebeginn (bzw. Anstecken des Fahrzeugs) aktiv vom Modul der SoC abgefragt oder wird der letzte abgefragte Wert übernommen, auch wenn dieser schon eine Stunde alt ist (weil ich den Poll-Intervall bei nicht angesteckem Fzg. auf 1h eingestellt hab)?
Ich hatte in der letzten Zeit mehrfach das Problem, dass nach einer längeren Fahrt direkt nach Heimkehr eingesteckt noch ein viel zu hoher SoC in der oWB vorhanden war - von der letzten eingestellten Abfrage bei nicht angesteckem Fzg. - der natürlich viel zu hoch war und von diesem dann weiter "geladen" wurde, und somit der Ladevorgang viel zu früh beendet wird.
Früher ist mir sowas nicht aufgefallen, hat sich diesbezüglich in den letzten Versionen was geändert?

Viele Grüße, heidanei

Das SoC-Modul kann den Zeitpunkt der Abfrage nicht beeinflussen.
Das Modul wird m.W. vom "core" entsprechend der eingestellten Intervalle oder ausgelöst durch Bedienung (per Kreispfeil) aufgerufen.

Ansonsten wäre das ein Feature Request an die openWB Entwicklung, z.B. nach An- oder Abstecken den SoC des am LP zugewiesenen Fahrzeugs abrufen zu lassen, sofern das Fahrzeug ein SoC-Modul konfiguriert hat.

Möglicher Workaround:
Ich habe in meiner Testumgebung Scripts/Kommandos, die die "Kreispfeil-Aktion" per MQTT auslösen, z.B.:

Code: Alles auswählen

mosquitto_pub -t openWB/set/vehicle/4/get/force_soc_update -m true

4 ist dabei die id des Fahrzeuges.
Das geht auch von einem anderen Rechner auf dem der mosquitto Client installiert ist (dann zusätzlich -h ip_der_openwb) oder von einer der vielen Home Automation Systeme. Dort könnte man auch auf das Anstecken "hören" und darauf reagieren.

[rleidner]

Ich habe jetzt für OWB2.x PR https://github.com/openWB/core/pull/2152 erstellt.
2 Änderungen:
- Bestimmte im Dialog mit dem CD-Server benutzte IDs (session_id, gcid) werden jetzt dauerhaft benutzt.
Bisher wurden diese IDs für jeden Abruf neu vergeben.
Damit wird hoffentlich die Notwendigkeit neuer Anmeldungen per Captcha entfallen oder zumindest deutlich abnehmen.
- Das Modul wird in der SoC-Auswahl der Fahrzeug-Konfiguration als "BMW & Mini" angezeigt.

[gdfde]

cool, @rleidner , vielleicht verbessert das das Verhalten.

bei mir ist leider wieder (trotz Erhöhung der Abfrageintervalls - 15/60 min) das Problem wieder gekommen und ich hab die captcha Abfrage heute wieder neu starten und eingeben müssen...sind jetzt ca. 7 Tage gewesen seit dem letzten renewal...
Ich hab das Auto auch die letzten paar Tage nicht angesteckt gehabt, d.h. es war die meiste Zeit das 60 min Intervall aktiv.

[rleidner]

Ich habe jetzt für OWB2.x PR https://github.com/openWB/core/pull/2152 erstellt.
2 Änderungen:
- Bestimmte im Dialog mit dem CD-Server benutzte IDs (session_id, gcid) werden jetzt dauerhaft benutzt.
Bisher wurden diese IDs für jeden Abruf neu vergeben.
Damit wird hoffentlich die Notwendigkeit neuer Anmeldungen per Captcha entfallen oder zumindest deutlich abnehmen.
- Das Modul wird in der SoC-Auswahl der Fahrzeug-Konfiguration als "BMW & Mini" angezeigt.

Ist jetzt im Master gemerged.