MG SoC

HINWEIS: Zusammenfassung aus dem alten openWB Forum

MG4 SoC Integration

Diskussion zur Integration des MG4 in openWB.

---

Aktueller Stand

Für den MG4 steht aktuell kein eigenes SoC-Modul in openWB zur Verfügung.

Eine direkte SoC-Abfrage über die MG- bzw. iSmart-Dienste ist derzeit nicht Bestandteil der Standardinstallation.

---

Mögliche Alternativen

Bis eine direkte Integration verfügbar ist, werden verschiedene Alternativen diskutiert:

• MQTT
• HTTP SoC
• Manuell + Berechnung
• externe Systeme wie Home Assistant
• eigene Skripte zur Anbindung der Fahrzeugdaten

---

Ziel

Gewünscht wird eine direkte SoC-Abfrage für den MG4 ohne zusätzliche Middleware.

Dadurch könnten Funktionen wie:

• Zielladen
• PV-Laden
• Ladeplanung

auf Basis des tatsächlichen Fahrzeug-SoC genutzt werden.

---

Herausforderungen

Die Umsetzung hängt unter anderem von folgenden Faktoren ab:

• verfügbare Hersteller-APIs
• Authentifizierung
• Stabilität der Fahrzeugdienste
• Dokumentation der Schnittstellen

---

Zwischenlösungen

Bis eine native Integration verfügbar ist, nutzen viele Anwender:

MG App / API
      │
      ▼
Home Assistant
      │
      ▼
MQTT / HTTP
      │
      ▼
openWB

oder alternativ:

Manuell + Berechnung

---

Diskussion

• Gibt es neue Erkenntnisse zu den MG APIs?
• Welche Lösungen nutzt ihr aktuell?
• Funktioniert MQTT oder HTTP zuverlässig?
• Besteht Interesse an einem nativen MG4 Modul?

Feedback und Erfahrungsberichte sind willkommen.

[Nicolas198901]

Guten Abend, ich habe seit kurzem einen MGs5 EV, lt Beiträgen gibt es noch kein SoC Modul für MG.
Aufgrund der SoC Probleme beim Hyundai Kona bin ich bei dem Auto auf den Wican Pro Dongle mit MQTT gegangen. Funktioniert dort 1a.

Nun versuche ich es am MGs5, scheitere dort jedoch an den Werten für den Abruf. Hat hier jemand Erfahrung?

[SchaafAlexander]

das würde den Zeitversatz erklären.

Ich wecke den SoC nun mal wieder auf und lasse es mitloggen.

[SchaafAlexander]

@seaspotter nun aber. VM Zeit ist UTC. Also zum Screenshot 2Std Zeitversatz.

Main Log:
https://paste.openwb.de/RaNPyxpR5ERcTPF

SoC Log:
https://paste.openwb.de/PwdWf8CnPIZ8klu

Logger Erkenntnis:

[seaspotter]

Da hat dein Agent doch quasi schon alles richtig gefunden und beantwortet :) Das das jetzt dann 3 fehlerhafte Auslesungen waren, hab ich gar nicht gesehen aber ja das erklärt dann das genau im übergeordneten Code, nicht im Modul:

if ev.data.set.soc_error_counter >= 3:
    log.debug(f"EV{ev.num}: Nach dreimaliger erfolgloser SoC-Abfrage wird ein SoC von 0% angenommen.")
    Pub().pub(f"openWB/set/vehicle/{ev.num}/get/soc", 0)

Also alles so richtig. Ich mein korrekterweise würdest du den SoC ja auch nur während der Ladung abrufen und da sollte das Fahrzeug ja auch nicht schlafen? Und wenn er dann nicht nicht lädt dann bleibt einfach der letzte ausgelesene Wert stehen. Oder gibts n besonderen Grund dafür das du alle x Stunden auch ohne Ladung den SoC abrufst?

Ein Aufwecken des Fahrzeugs aus dem Fahrzeug-SoC-Code macht kein Modul und werd ich hier auch nicht implementieren.

Rein interessehalber hast du die MCP Schnittstelle vom Logger genutzt? :)

[SchaafAlexander]

Mit einem Zurücksetzen auf 0% ist das Ganze für ein EOS Forecasting wie das EOS vom Akkudoktor nicht benutzbar. Man kann ja keine mehrtägige Optimierung machen, wenn man sich auf den Wert nicht verlassen kann.
Einmal ist der Wert des EV 50% und der zu erreichende min SoC für den morgigen Start 40% => passt es muss nicht geladen werden.
Dann verliert OpenWB den Wert aber und setzt auf 0% => Würde ja bedeuten jedes EOS Forecasting würde 40% EV Demand einplanen und ggf. die Batterie pausieren oder gar Netzladung einplanen und ggf. schon starten. Bis es dann unnötigerweise ein EV Charging starten würde, das EV aufwacht und einen neuen SoC bekommt und dann wieder stoppt. Aber das Planning ist komplett dahin.
mMn wäre es besser, wenn es dauerhaft auf dem letzten bekannten Wert bleiben würde, bis es tatsächlich einen echten neuen Wert gibt.

Naja aber openWB kann ja nicht ein Problem eines Autos/Herstellers fixen welches z.B. andere Fahrzeuge/Fahrzeugmodule überhaupt nicht haben. Verstehst du was ich meine? Nur weil MG/Saic bei einem schlafenden Autos keinen SoC liefert, ist das ja nix was openWB daher jetzt fixen sollte. Es ist ja schon eine Logik dahinter zu sagen wenn aus welchem Grund auch immer ich 3 mal nacheinander keinen SoC auslesen kann ist irgendwas nicht richtig, also setze ich den SoC mal lieber auf 0 und gebe eine Warnung aus. Gleiches gibt es / wird für alle WR/Batterie Module etc btw auch kommen, das die Leistung auf 0 gesetzt wird im Fehlerfall.
Dann muss in EOS eben nicht nur der SOC eingelesen werden, sondern auch der Fehlerstatus des SOC Moduls: Wenn Fehler, rechne bitte nicht mit dem SOC weiter. Oder wenn es EOS auch nicht einbauen will, dann über ein kleines Helferscript. Der Nächste kommt daher und wundert sich das der SoC immer gleich bleibt und würde es lieber wieder anders haben.
Alternativ musst du halt jedesmal wenn der SoC abgefragt werden soll, das Fahrzeug vorher aufwecken extern, wenn du es brauchst.
Und selbst wenn man ein Fahrzeug-aufwecken integrieren würde, kommt dann irgendein User daher und beschwert sich das aufgrund falsch-konfiguration irgendwann die 12V Batterie leer ist, weil alle x min das Fahrzeug aufgeweckt wurde

Ich hoffe du kannst nachvollziehen worauf ich hinaus will.

[SchaafAlexander]

Ja ich habe da eine Abfrage die diese Sachen genau so auch abfragt.
Aber ist halt dann für MG nur brauchbar um ggf Updates während des Ladens zu bekommen.

Ansonsten muss mit manueller SoC Eingabe gearbeitet werden.
Alles gut ;-)

Schönen Abend!

[hoppsasa]

Hallo zusammen,
interessiert lese ich hier, wie an einem SoC-Modul für MG gearbeitet wird (für alle MG-Modelle, wenn ich das richtig verstehe, da auf die API von iSmart zugegriffen wird). Ich erwarte Anfang 2027 meinen MG4 Urban. Wenn ich es richtig verstehe, werde ich aber mit einer manuellen SoC-Eingabe leben müssen. Korrekt?
Ich habe für meinen eUp einen WiCAN Pro OBD Stecker, der laut deren Autoliste nur MG5/Marvel/ZS unterstützt. Kann ich den WiCAN ggf. mit den notwendigen Daten (Stichwort PIDs) versorgen, damit ich so den SoC an die OpenWB senden kann? Komme ich irgendwie an die Daten ran, die in der WiCAN-Oberfläche hinterlegt werden müssen?
Grüße

[klefreak]

Aktuell kannst du mit dem Umweg "saicismartapi" von GitHub über einen docker Container den akkustand abfragen und an openwb senden Anleitung dafür ist bei der saicismartapi zu finden..
Läuft bei mir seit Jahren, und inzwischen sogar Recht stabil.. braucht aber zusätzlich halt Hardware die einen docker container laufen lässt (bei mir das Synology Nas...) ich hoffe es hilft dir
LG klemens

[seaspotter]

Das Modul ist bereits fertig und im aktuellen 2.3.0 Beta enthalten und damit dann auch ganz bald im Release. Insofern sollte da kein manueller SoC nötig sein und für WiCAN ist das hier der falsche Thread. Es funktioniert ja schon bei einigen Anwendern inkl. den Testdaten die ich zur Verfügung hatte.

[SchaafAlexander]

Funktionalität des Moduls kann ich bestätigen.
Limitierender Faktor ist nur das MG Auto selbst.
Ob es erreichbar sein will oder nicht.

Vg

[hoppsasa]

Wow, so schnell zuversichtliche Antworten. Dann warte ich die release 2.3.0 stable ab. Ich bin geduldig. Zumal in 2.3.0 auch das PV-Prognose-Modul drinnen sein wird, auf das ich gespannt bin. Vielen Dank.