BMW: Fahrzeug über API zuverlässig aufwecken

[BrickTop87]

Is your feature request related to a problem? Please describe.
Beim BMW i4 (evtl. sind auch andere Derivate betroffen) gibt es seit einem kürzlichen Fahrzeug-Update einen Spielschutz, der bei zu häufiger Unterbrechung des Ladevorgangs den Wakeup über das CP-Signal sperrt.
Hier hat es ein User bereits etwas näher untersucht: Link i4Forum
Bei mir trat das Problem nun auch auf trotz großzügig gewählter guardDuration: 15m.

Describe the solution you'd like
Wenn ich das Fahrzeug in diesem Zustand anderweitig aufwecke, z.B. in der App durch Senden des Kommandos "Fzg. zusperren", dann erkennt es die mögliche Ladung und setzt den Ladevorgang fort. Vermutlich geht es auch mit dem Kommando "Laden starten", muss ich aber noch ausprobieren.
Ist es möglich, eine Option anzubieten, bei der evcc immer beim Statusübergang von "Wallbox zum Laden gesperrt" zu "Wallbox zum Laden freigegeben" über die API zusätzlich einen der oben genannten Befehle schickt, damit das Fzg. sicher aufwacht?
Bei der bimmer_connected Library gibt es die entsprechenden Routinen, also sollte es grundsätzlich möglich sein (CHARGE_START oder DOOR_LOCK): Link

Describe alternatives you've considered
Eine Alternative wäre die Abwicklung über ein messaging event, das ein Shell-Script aufruft, welches z.B. über bimmer_connected den Befehl an das Fzg. absetzt.
Würde das event start hier zum Erfolg führen?
Oder wird das nur getriggert, wenn auch wirklich eine Ladung zustande kommt, sprich das Fzg. aufwacht und zu Laden beginnt? In diesem Fall würde das event hier nicht helfen.

Vielen Dank vorab für eure Bemühungen!

[andig]

Wir könnten mal probieren, das door_lock als Wakeup zu benutzen.

[mfuchs1984]

Als die Sonne im Oktober noch schien, hatte ich das Problem auch. Am Wochenende soll es wieder schön werden, sofern ich wieder ein diesem Zustand lande, probiere ich mal aus, das Laden per Home Assistant Connected Drive Integration zu starten, die diese API Befehle absenden kann. Notfalls versuche ich es manuell zu reproduzieren.

[BrickTop87]

Vielen Dank, das klingt ja schon mal gut!
Mangels Sonne bei uns werde ich es auch nochmal manuell versuchen, ich hoffe ich komme dazu in den nächsten Tagen.

[mikeungers]

Selbes Problem mit dem i4 auch bei mir. Heute zweimal aufgetreten...

Ich dachte die Option "Ausstecken simulieren" in der App vom go-eCharger sollte das verhindern?

[mfuchs1984]

Das kann sein, aber nicht jeder hat einen go-eCharger ;).

[mikeungers]

Das stimmt wohl ;)
Aber ich dachte man könnte das eventuell auch darüber lösen. Zumindest in meinem Fall.

[andig]

Hier gehts nicht um den Go-E Charger sondern um das BMW API. Um das zu testen bräuchte ich einen Account, bitte per Mail an [email protected]

[BrickTop87]

Selbes Problem mit dem i4 auch bei mir. Heute zweimal aufgetreten...

Ich dachte die Option "Ausstecken simulieren" in der App vom go-eCharger sollte das verhindern?

Ich denke in diesem Zustand reagiert das Fzg. einfach gar nicht mehr auf alles was sich an der Ladedose abspielt. Dann ist es egal was die Wallbox macht, es kommt einfach nicht durch. Wenn du die Option aktiviert hast und das Problem trotzdem auftritt, scheint es ja offensichtlich so zu sein.

Ich habe gerade meinen BMW-Account per Mail geschickt, bin gespannt :)

[mikeungers]

@BrickTop87 Ich probiere es die Tage einfach mal mit manuellen Ausstecken an der Wallbox aus.

Ansonsten, hast du schon den BMW Kundenservice kontaktiert? Ich wollte denen mal eine Mail schreiben. Wenn sich das häuft kümmert sich vielleicht jemand um einen Fix im nächsten Update.

[BrickTop87]

Ich probiere das nächste Woche über direktere Kontakte in die BMW-Entwicklung.
Dass sie das nachträglich reingebracht haben deutet aber darauf hin, dass es einen guten Grund dafür gegeben haben muss. Das schmälert natürlich die Hoffnung auf ein schnelles Zurückdrehen auf die ursprüngliche Funktionalität ohne Spielschutz.

[andig]

Ein leerer POST request so wie ich den aus dem bimmerconnected Sourcecode raus lesen scheint nicht zu reichen:

POST /eadrax-vrccs/v3/presentation/remote-commands/***/door-lock?apptimezone=120&appDateTime=1700984619602 HTTP/1.1
Host: cocoapi.bmwgroup.com
User-Agent: Go-http-client/1.1
Content-Length: 0
Authorization: Bearer xx
Bmw-Vin: ***
Content-Type: application/json
X-User-Agent: android(SP1A.210812.016.C1);bmw;99.0.0(99999);row
Accept-Encoding: gzip

HTTP/1.1 400 Bad Request

Könnte mal jemand versuchen, die Verbindung von bimmerconnected mittels MITM Proxy mit zu tracen damit ich sehe, was da "wirklich" verschickt wird?

[lemny]

Hab grad auch mal getestet, da mein BMW i4m50 den Ladevorgang nicht gestartet hat. Erneutes Abschließen über die App hat den Vorgang nun ausgelöst, der Ansatz funktioniert.

Der Node-Red Node: https://github.com/krauskopf/node-red-contrib-car-bmw
kann allerdings auch direkt "start charching" senden. Evtl. ist der API Call im Code ersichtlich.

[BrickTop87]

Mit bimmerconnected funktionieren die Befehle auch. Ich habe gestern mit MITM Proxy die Kommunikation mitgeschnitten und an @andig geschickt. Er hat auch schon meinen Account. Denke wir müssen uns nur etwas gedulden, bis er wieder Zeit findet, um es sich anzuschauen.

[lemny]

Ich werde mir solang über den BMW-Node helfen. Da ich die Ladesteuerung eh von dort aus optimiert habe, kann ich auch dort das Laden nochmal zusätzlich triggern.
Ich steuere EVCC über Node-Red in soweit, dass ich beim anklemmen unter 20% SOC sofort mit voller Leistung bis 20% lade und ein zweiten einstellbaren Schwellenwert habe, welcher jeden Morgen zur Verfügung stehen soll (In der Regel ca 40% für den Alltag). Dieser Ladevorgang wird nach Sonnenuntergang mit voller Leistung gestartet, damit vorher noch maximal Sonne in den Akku kommt. Alles darüber kommt dann im besten Fall aus der Sonne.

Die zwei zusätzlichen Schwellenwerte wären eigentlich auch ein cooles Feature für EVCC. Man kann zwar etwas ähnliches schon einstellen, aber dann wird immer sofort geladen und ich möchte gern noch vorher die Sonne des Tages mitnehmen. Und der Abfahrt SOC, den man einstellen kann, tut dieses zwar auch, aber muss halt jedes mal eingestellt werden und bildet dann den Maximalwert, welcher wiederum das Solarladen unterbindet.

Jetzt im Winter ist das Laden mit Threshold übrigens ne super Sache... Ich starte mit erlaubten 500W Netzbezug und breche erst über 700W Netzbezug wieder ab. so geht nichts mehr ins Netz und wir haben fast 100% Eigenverbrauch auch ohne Hausspeicher.

[andig]

@lemny du beschreibst eigentlich den minsoc aus Plan->Arrival?

[lemny]

@andig Unter Anderem, Arrival entspricht in meinem Beispiel dem 20% critical Wert. Tritt im Alltag aber nur selten auf. Interessanter finde ich den „Next Morning Minimal“ Wert. Dieser stellt halt sicher, dass der Wagen morgens immer mindestens über X% Ladung verfügt, wartet dabei aber ähnlich wie „Abfahrt“ erstmal noch den verfügbaren Solarstrom ab und startet einfach bei Sonnenuntergang, aber ohne dass man einen Plan erstellen muss und ohne dass dabei weiteres Laden durch Solarstrom unterbunden wird weil der Maximalwert überschritten würde. Der Maximalwert kann auf 80% oder was auch immer bleiben, um weiterhin natürlich verfügbaren Solarstrom zu verwerten.

Dieser „Morning SOC“ bestimmt bei uns eigentlich in der dunklen Jahreszeit das alltägliche Laden. Ankunft und Abfahrt werden nur Ausnahmefällen genutzt.

[BrickTop87]

Auch wenn es hier Off Topic ist: Für mich wäre eine Logik wie im vorherigen Post auch optimal.
Edit: Ich hätte aber gedacht, dass das durch die in Entwicklung befindlichen persistierten Ladepläne mit erschlagen werden würde.

[lemny]

ah, mein Vorschlag wurde schon mal gemacht:
#3530 (reply in thread)

[andig]

Man kann zwar etwas ähnliches schon einstellen, aber dann wird immer sofort geladen und ich möchte gern noch vorher die Sonne des Tages mitnehmen.

@lemny Du redest vom Planner. Genau so macht der das- und zwar CO2- oder Preisoptimiert. Ansonsten gerne neue Discussion, wir sind wirklich arg OT :)

[lemny]

ja, sorry :-) etwas OT, aber ist ja eh closed.
Den Planner (Abfahrt) muss man ja immer wieder einstellen und man muss die Maximalschwelle drosseln, was weiteres Solarladen verhindert. Ansonsten ja, er lädt so spät und sparsam wie möglich.
Der Planner (Ankunft) lädt ja zur kritischen Schwelle (bei mir 20%) welche zu keinem Zeitpunkt unterschritten werden soll und somit auch tagsüber mit Volllast.
Der neue Vorschlag wäre eine dauerhaft einstellbare zweite Schwelle, welche nicht nach Ankunft, sondern mit Volllast nach Sonnenuntergang, sobald kein Solarertrag mehr zu erwarten ist, oder wie der Abfahrt-Planner mit einer festen Zielzeit (z.b. 5:00 Uhr / SOC 40%) jeden Tag automatisch ohne zusätzlichen Eingriff lädt.

[BrickTop87]

A propos closed: Habe die Änderung heute über den Tag verteilt ein paar mal mit dem Nightly getestet. Weil wir heute einen halben Meter Neuschnee haben mit manuellem Starten und Unterbrechen des Ladevorgangs.
Das Fzg. war dauerhaft in besagtem Zustand, da kommt es wahrscheinlich erst mit Ladekabel ab- und anstecken wieder raus.
Der Wakeup über den door-lock wurde jedes mal nach 30 Sekunden getriggert, hat das Fzg. aufgeweckt und dann hat es geladen. Also Umsetzung perfekt!

Was mich noch interessieren würde: Beim Rumspielen mit bimmerconnected ist mir aufgefallen, dass hin und wieder die Befehle fehlschlagen (z.B. 429: Too Many Requests, aber habe auch schon andere Fehler gesehen).
Wie würde sich evcc in diesem Fall verhalten? Nach einer Zeit erneut versuchen? Oder versucht er den Wakeup nur genau einmal?

[lemny]

429: Too Many Requests bekomme ich in Node Red auch ab und zu... der nächste Request 5 Sek später ging aber immer durch. Ich denke das aktuelle Abfragen des SOCs trifft auf die selben Probleme und wiederholt einfach seine Anfragen bis es klappt.

[andig]

Den Planner (Abfahrt) muss man ja immer wieder einstellen und man muss die Maximalschwelle drosseln, was weiteres Solarladen verhindert

Punkt 1 steht auf der Todoliste, Punkt 2 ist ab heute im Nightly behoben- das sind jetzt unterschiedliche Limits. Siehe #10335.

[BrickTop87]

Nochmal On Topic: Hab heute die Info bekommen:
Ab 03/24 wird das Problem entschärft mit höherer Anzahl zulässiger Ladeunterbrechungen.
Ab 07/24 wird es gelöst, dann kann unbegrenzt oft unterbrochen werden.

Dank evcc haben wir aber schon jetzt einen super Workaround, um nicht den halben Sommer zu verlieren 👍

[RandomRam2023]

Hallo community,
mal Lob an alle, ich finde es super, wie wir mit Leuten , die z.b. Traces schneiden oder Accouts zur Verfügung stellen, hier Weiterentwicklungen ermöglichen.
Direkter Draht zu Fahrzeugentwicklern ist auch nicht zu verachten, ich bin selbst bei so einem Club, aber "nur" bei den Autos mit >160kW DC Ladeleistung, die stehen eher nicht privat zuhause und bei 22kW AC bedauern wir die 20h Ladezeiten (LOL)
Und leider hab ich als Benzler hier garkeine Plattform, die Sternleute wollen wohl keine brauchbare API bieten :(
Weiter so (thumbsup)

[TheTrueRandom]

Ich steuere meine Wallbox nicht über evcc und war schon am Verzweifeln, was ich falsch mache, dass der BMW i4 nach kurzen Ladepausen nicht wieder weiterlädt.. Super, dass ihr das Issue gefunden habt, der Workaround funktioniert auch bei mir.
Ist es bekannt, ob nur der i4 dieses Problem hat? Scheint ja schon ein kritisches Issue zu sein, damit kann niemand (der nicht evcc nutzt) mit einem BMW (i4) Solarüberschuss laden.

[BrickTop87]

Kann ich leider nicht sagen ob andere Modelle das gleiche Thema haben.

Ganz so extrem wie du es beschreibst ist es aber bei mir und den bisherigen Diskussionsteilnehmern nicht. Etwa 7 Unterbrechungen pro Ladevorgang sind bei mir ohne Workaround möglich. Darüber hinaus hilft entweder der Workaround oder Ab- und Anstecken und dann geht es wieder 7-mal.
Wenn man also etwas Hysterese einbaut geht schon ein Tag Überschussladen ohne in das Problem zu laufen. Erst bei mehreren Tagen am Stück wird es eng.

[emmix71]

Hallo, mein ix3 hat dasselbe Problem.

[mfuchs1984]

Beim i4 funktioniert es mit der hier implementierten Lösung hervorragend.