BMW connected drive in IPS?

ja ok, dann bin ich auf den Debug des Vehicle gespannt.
Denn eigentlich wird“roofState“ bereits ausgewertet und dir Variable wird beim ersten Empfang eines solchen Wertes angelegt

anbei Dump:

vehicle.txt (156,9 KB)

richimaint

Hmm, bei mir hat das mit diesen Daten eine Variable „Schiebedach“ ( ident RoofTop ) angelegt und gefüllt.
Du bist auf der aktuelle Version? Beta am besten?
Und es gibt unterhalb der Instanz keine Variable mit diesem Ident?

Ich frage so blöde, aber wie gesagt, ein Problem sehe ich gerade nicht …

1 „Gefällt mir“

Ja bin aktuell auf Beta

Habe auf Variablen neu anlegen gedrückt und nun gibt es die Variable und das Bild vom Auto ist auch zu sehen.

richimaint

Kurze Frage, wie kann ich die Daten der Instanz per PHP-Skript aktualisieren?

Edit: In der Doku finde ich was von BMW_GetRawData, hier im Forum was von BMW_Update und BMW_UpdateRemoteServiceStatus (die mir aber nicht angeboten werden)

Die public-Funktionen zum Datenabruf werden nicht mehr angeboten, da es ja innerhalb der Instanz eine differenzierte Logik hat, um gezielt bestimmte Daten zu holen und damit die Anzahl der API-Abrufe so gering wie möglich zu halten.
Grund ist die immer wieder zu Nachfragen führende „Out of quota“-Meldung der BMW-API. Die blockiert nach internen Regeln den Datenabruf, wann immer die API glaubt, das es zu häufig erfolgt ist.

So können die internen Funktionen abgerufen werden (<instID> ist die ID der Vehicle-Instanz)

IPS_RequestAction(<instID>, 'UpdateVehicleData', '');
IPS_RequestAction(<instID>, 'UpdateRemoteServiceHistory', '');
IPS_RequestAction(<instID>, 'UpdateRemoteServiceStatus', '');
IPS_RequestAction(<instID>, 'UpdateChargingSessions', '');

Diese Funktionen werden automatisch zyklisch aufgerufen in den Intervall wie angegeben

Hallo @demel42
vielen Dank, das funktioniert.

1 „Gefällt mir“

Hallo zusammen.
Wie schwierig wär es, einen Check auf die Login Autorisierung regelmässig zu machen?
Frage deshalb, da ich viel eingefrorene Daten hab, wenn mal wieder dieses Neulogin notwendig ist.
Eine Statuswarnung wäre doch was?

Bau dir doch etwas mit dem Event Control (Kern-Instanz).

Sie BMW I/O-Instanz eintragen und ein Skript ablaufen lassen. Wenn der Instanz-Status >= 200 ist, gibt es ein Problem.

210 (unautorisiert) bzw 217 (nicht angemeldet) zeigen an. das man sich wieder anmelden muss.

Es gibt hier einen Hinweis auf die entsprechende Status-Variable ($_IPS[‘STATUS’]), die den neuen Instanz-Status enthält.

Danke. Das ist eine gute Idee. Muss ich gleich mal probieren.

Hallo Leute! :slight_smile:

Mal eine ganz allgemein Frage zu “BMW Connected Drive”: Selbst wenn ich es aus der BMW-App bediene ist die Reaktionsgeschwindigkeit sehr enttäuschend. Als Beispiel: Ich möchte aus der App heraus das Fahrzeug öffnen - gefühlt ist eher der ADAC da um das zu machen… :wink:

Muss ich vielleicht in der App ein Abo für “Connected Package Professional” abschließen, damit eine Aktion deutlich schneller laufen zu lassen und auch mehr Daten geliefert werden?

Joachim

Bei mir auch … da finde sind die heimischen Hersteller gefühlt in der Vorzeit … und den SOC kann man beim ix3 auch nicht einstellen um das Laden Remote zu beeinflussen ( Absicht?).

Ich möchte das ja nicht stressen, aber ich hole mir den SOC inzwischen parallel über HASS und per MQTT ins Symcon … das ist etwas schneller…

Gruß Michael

Ohne das ich die Internas von BMW kenne, rein durch Beobachtung und aufgeschnappten Informationen …

Nein, da hilft m.E. auch kein anders Package.

Die Kommunikation geht ja (via Mobilfunk) immer vom Fahrzeug zu der BMW-Cloud und wird da von der App / via API abgeholt. Bei Befehlen an das KFZ ist das so, das (von der App / via API) dieser an die BMW-Cloud geschickt wird und wenn das KZF das nächste Mal wach wird und kommuniziert, bekommt es die Information über den Befehl, führt den aus und kommuniziert den Status danach (also deutlich zeitverzögert) zurück an die Cloud, von der die App das dann wiederum abholt.

Die Intervall sind zum Strom-sparen da - immerhin muss ein KFZ ja wochen- oder monatelang unbenutzt stehen können, ohne das die Batterie alle ist.

Je älter das Fahrzeug ist, umso länger sind die Intervalle. Ich hatte einen X5 mit BJ 2014, da waren Befehle per Handy (Klimatisierung) eher zufällig erfolgreich. Mit meinem aktuellen X5 aus 2024 klappt es bisher immer und zügig.

Auch im Bereich von stromsparenden Mobilfunk-Verbindungen hat sich in den letzten Jahren auch viel getan. Und das ich m.E. auch der Grund, warum aktuelle BMW da geschmeidiger sind.

Wie andere Hersteller das realisieren, kann ich nicht sagen.

Bei Autos mit Elektroantrieb kann der Umgang mit Stromverbraucher eventuell großzügiger sein, da die Batterie im Vergleich zu einem klassischen Verbrenner um ein vielfaches größer ist.

Interessant, denn die HomeAssist-Integration basiert auf den Arbeiten von GitHub - bimmerconnected/bimmer_connected: 🚘 Library to query the status of your BMW or Mini from the ConnectedDrive portal und auch meine Informationen des IPS-Moduls basieren im Wesentlichen darauf - natürlich von python in php übertragen.

Die Batterie für das fahren ( Hochvolt) hat nichts mit der Batterie für die Funkanbindung zu tun (12 V).

Ja, die Fahrzeuge sind schlafen und müssen bei einem Signal erst aufwachen um Strom zu sparen. Das dauert. Können andere ggf. besser.

Ich kann nicht sagen, wie das bei anderen Modellen ist.

Bei meinem X5 (Hybrid) ist das so, das die Fahrbatterie von der Hochvoltbatterie nachgeladen wird. Information von BMW, weil ich Probleme mit der Fahrbatterie hatte.

Habe daher angenommen, das das bei alle E-Autos von BMW so ist. Will ich aber nicht verallgemeinern, weil ich dazu zuwenig von den Autos verstehe.

Doch, die 12V Batterie kann nur über die Hochvoltbatterie geladen werden. Dies geschieht über einen DC/DC-Wandler. Es gibt sonst keine andern Möglichkeit in einem elektrischen Fahrzeug.

Das ist ja auch so, nur eben nicht, wenn das Auto schläft.

By the way …

letzthin gab es neue Erkenntnisse im bimmerconnected-Git, die ich vor ein paar Tage umgesetzt habe.

Und zwar geht es um die leidige Quota-Meldung. Die kommt ja kaum nachvollziehbar und selbst bei langen Intervallen ist man davor nicht sicher.

Nun gab es folgende Idee: im Header der Abrufe gibt es den sog. “x-user-agent”, der bisher auf einem festem Wert stand; der Wert, den jemand bei Analysieren der Verbindung gesehen hat.

Es wurde nun versucht, diesen Wert doch mal dynamischer zu bilden und es scheint zu funktionieren - ich hatte in den letzten 3 Tagen zwei BMw jede Minute abgerufen und war erst nach 3 Tagen auf ein Quota gestossen.

Für den, den Details interessieren: Out of call volume quota · Issue #740 · bimmerconnected/bimmer_connected · GitHub

Wer das testen möchte … ich habe das, weil es ja vermutlich auch nicht funktionieren kann, als Testing eingereicht - für die Nutzung des Testing eines Moduls muss mal ja einen Link habe (oder per Mail / Username eingeladen werden … ). Der Link ist hier zu finden.

Nur zur Information:

es gibt nun eine offizielle BMW-API ( CarData Customer Portal ), Hintergrund ist vermutlich:

Die Dokumente sind zT noch nicht verfügbar, soweit ist folgendes absehbar:

  • es ist eine Read-Only-Schnittstelle, keine Befehle (derzeit?) vorgesehen
  • der aktive Datenabruf ist auf 50 Calls/Tag sehr limitiert
  • es gibt aber angeblich eine n Daten-Stream, der alle Änderungen automatisch kommuniziert - da die Dokumentation aber derzeit eben nicht lesbar ist, ist es unklar, ob die hilft
1 „Gefällt mir“