BMW connected drive in IPS?

noch eine Sache: wenn Du der Meinung bist, das die alte Version funktioniert hatte - die kann ich natürlich nochmal als Gegentest zur Verfügung stellen.
Ich müsste nur wissen, welche Version das war - d.h. du müsstest mir sagen, wann du das letzte Mal aktualisiert hattest.
Alternativ kannst du in einer älteren Version der settimgs.json nachschauen (wenn du da fit drin bist):

  • Suche in der alten settings.json nach ID< InstanzID der BMW-IO-Instanz> (zB ID49036)
  • innerhalb dieses Blockes gibt es eine Zeile, die in etwas so aussieht
    "UpdateInfo": "{\"Version\":\"3.7\",\"Build\":0,\"Date\":1705670418,\"tstamp\":1705670900}"

Damit könnte ich dir das Modul in der vorher eingesetzten Version als „testing“ bereitstellen

Ich habe aktualisiert auf die neue Version (3.7). Mein Eindruck ist das nun die übergeordnete „I/O“ nicht mehr „hängen“ bleibt. Die Funktion, die mir wichtige, das Einstellen der Ladeparameter, funktioniert leider nicht. Ich habe nach dem Update des Moduls als Erstes die Funktion „Zugansdaten prüfen“ probiert. Dies lief. Danach dann „SetChargingSettings“, dies funktioniert wohl nicht, im Dump findet sich:
TXT: 19.01.2024, 16:27:52 | CallAPI | quota exceeded, allowed again from=19.01.2024 16:59:58
dies sprich ja für Deine Aussage der Limitierung.

Auffällig ist noch, nachdem ich heute Vormittag mit dem Fahrzeug unterwegs war, das im Webfront alles korrekt angezeigt wird, also Restladung, Restkilometer, Türen, etc. Nur die Ladepräferenzen nicht, die vor meiner Abfahrt schon von mir verändert wurden.

Meine letzte Version war die 3.3.1, da hatten wir das letzte mal Kontakt, da war ich wohl der Erste der mit den Ladepräferenzen gearbeitet hat. Danach kein Update mehr, in letzter Zeit war es jedoch auffällig das die Einstellung öffter nicht funktionierten.

die Meldung mit dem „Quota“ besagt, das BMW genau das Problem zurück gibt. Irgendwo weiter oben im Log musst die eigentliche Meldung stehen (Out of call volume quota) …
Ich hatte gehofft, das mit meinen Änderungen die Überschreitung verhindert wird - aber Satz mit X …
Das die Instanz dabei nicht mehr auf „Unauthorized“ geht (und damit nicht mehr aktiv ist) liegt eben daran, das ich den HTTP-Error 403(Forbidden) differenziert auswerte,

naja, verwunderlich ist das nicht. Bei mir funktioniert der Datenabruf ja auch meistens … ich sag mal 2/3 der Datenabrufe gehen

ok, damit liegt es eher nicht an den letzten Änderungen und der Rückgang auf die alte Version zum Test bring auch nix.
Passt zu meinen Erfahrungen, ich habe das ja nur deswegen angefangen, weil es immer schlechter lief.

@gallo1

ich habe in den letzten Tagen einiges versucht und geändert. U.a. die aktuelle Änderungen an der BMw-API nachgezogen und ansonsten versucht, die komischen „Quota“ abzufedern. Komisch, weil weder eine Systematik zu erkennen ist noch (mal schon bei 5 Abrufen in der Stunde) noch weil die Rückmeldungen schlüssig sind (da wird was gemeldet, das für 30m Ruhe ist, aber manchmal kommt man schon nach 5m wieder klar.

Was habe ich sonst noch gemacht:

  • wenn ein Quota-Fehler von BMW zurückgeliefert wurde, schicke ich solange, wie die Quota-bedingte Sperre gemäß der Meldung in der API besteht, keine API-Aufrufe Richtung BMW (damit sich das ganze beruhigt).
  • die Instanz geht dann auch nicht in einen Fehlerzustand
  • in der IO-Instanz gibt es ein Panel „Modul-Aktivität“, da kann man sehen, was von welcher Instanz diesbezüglich ausgelöst wurde.
  • es ginübtnhier auch eine Funktion, um die Quota-Einschränkung zu ignorieren - das unterdrückt das im ersten Punkt geschilderte Verhalten / der nächste Abruf geht dann wieder raus und möglicherweise kommt er auch durch.
  • in der Vehicle-Instanz gibt es jetzt nicht nur eine Intervall-Angabe sondern getrennt für VehicleData, RemoteHistory und ChargingSessions. Ich habe das mal auf 10m für Data, 60m für RemoteHistory und 6h für Charging eingestellt und habe seit einigen Stunden kein Quota-Problem mehr (klopf auf Holz). Kleine Zusatzinfo: wenn ein Ladevorgang auf inaktiv geht, wird automatisch eine ChargingSession-Abruf gemacht.
  • ob das Setzen der Ladestomstärke nun funktioniert, kann ich nicht sagen, weil meine das nicht unterstützen.

Ich habe das erstmal nur in den Testingzweig des Moduls eingestellt - Zugriff über diesen Link: Symcon Kontoverwaltung

bin mal sehr gespannt, ob das was gebracht hat

Hallo,
also bei meinem i4 gibt es leider auch mit der neuesten Version Probleme. Bspw. Klima starten klappt nicht, es passiert einfach nichts. Keine Fehlermeldung und auch kein Eintrag in der remote service history. Im Anhang mal das Debug Log, falls das dir irgendwie hilft.

VG Thorsten
dump(6).txt (53,1 KB)

nein, nicht wirklich. Das ist das Debug der Vehicle-Instanz, wenn, würde man was in der IO-Instanz sehen können.

was ist deine neustes Version? (Konfiguration → Information)?

ansonsten habe ich gerade die Änderung aus „Testing“ auch in „Beta“ übernommen.

Problem ist bisher, das permanent die API dicht gemacht wird, aufgrund von „Quota“ - dabei ist völlig unklar, was das Problem ist, passiert manchmal schon nach 5 Aufrufen/Stunde, manchmal tagelang nicht.

Wird auf jeden Fall nun im IO-Modul auch unter „Modul-Aktivitäten“ noch aufbereitet angezeigt

Also ich habe jetzt auf 3.8 (29.1.) erhöht.
In der IO Instanz sehe ich im Debug nun 01/02/2024, 10:44:51 | CallAPI | quota exceeded, allowed again from=01.02.2024 11:00:00

Anbei das aktuelle Debug.
dump(8).txt (4,4 KB)

Ich werde es auch mal beobachten, vielleicht erkenne ich ja ein Muster.

quota exceeded ist genau die Meldung, die das besagt.
Dann ist (gemäß Rückmeldung in der API) bis zur nächsten vollen Stunden gesperrt - ggfs. geht es auch früher, wird aber vom Modul verhindert (ausser man betätigt Instanz → Export → „Quota-Behandlung zurücksetzen“).
Nur das Ignorieren des Quota scheint (manchmal) die Sperre zu verlängern.

Hey,

ich bekomme diese Fehlermeldung, mit der letzten Beta:


Mag sein, dass es daran liegt, dass es ein Benziner ist :slight_smile:
Mic

soisses - versuch mal die beta von gerade (3.8.1)

1 „Gefällt mir“

@demel42
Sorry für die lange Pause die ich gemacht habe. Bin nun auf Deiner Version 3.9 unterwegs. Vielen Dank dafür. Bei den letzten Versuchen gab es keine „Aussetzer“. Sprich ich konnte die Ladeleistung sehr kurzfristig anpassen, alles nur mit der auch in der BMW-App vorhandenen Latenz. SUPER!

Beim Einstellen der Ladeleistung bekommst Du ja einen Return vom Server. Ist es möglich, wenn dieses Feedback Positiv war, die „Ladepräferenzen“ upzudaten. Dies tust Du glaube ich z.Z. nur beim zyklischen Update.

Das ist korrekt, aber das ist - im positiven Fall - nur die Angabe, welcher „Event“ im BMW-Server angelegt wurde. Der wird dann verzögert an das Fahrzeug übertragen und wenn das Fahrzeug das bestätigt hat, kann dieser Event abgerufen werden.
Dann kann die RemoteService-History angerufen werden.

Es gibt auf jeden Fall ein Delay unbekannter Länge zwischen der Auslösung und der realen Umsetzung. Die Dauer scheint u.a. vom Alter des Modells abzuhängen, die älteren Modelle reagieren eventuell gar nicht oder eventuell erst nach einigen Minuten.
Das ist bei neueren Modellen schon anders, aber es ist trotzdem keine synchrone Kommunikation.

Um die HTML-Box mit den Ladepräferenzen zu aktualisieren müsste ich den Status aktualisieren, was wiederum Ärger mit den Quotas bedeuten kann.
Echt ein saublödes Problem.

ich habe mal etwas „gebastelt“ → siehe aktuelle Beta des Moduls

Versuch ist folgender: ich Polle (wie bei anderen Kommandos) den RemoteService-Status, ist kein Kommando mehr PENDING, werden die Fahrzeugdaten abgerufen. Dann sollte (auch) der Ziel-SoC korrekt sein

Ich habe den Update auf 3.10 (15.02.24) durchgeführt. Die Änderung der Ladeleistung wird durchgeführt, in der BMW-App ist dies zu erkennen. Die HTML-Box mit den Ladepräferenzen wird jedoch nicht aktualisiert.

er zeigt ja direkt wieder den quota-error → also kein abruf möglich.

keine ahnung, was man da noch machen kann.