MG4 · KLEVE
FAQ
Ein privates Telemetrie-Dashboard für einen MG4 Electric Luxury, der in Kleve am Niederrhein zu Hause ist. Die Seite liest den aktuellen Fahrzeugstatus und einige langfristige Statistiken direkt aus der SAIC-Cloud (demselben Dienst, den auch die offizielle iSmart-App nutzt) und stellt sie hier öffentlich einsehbar dar – ganz ohne kommerziellen Hintergedanken, einfach aus Freude an Daten.
Der ursprüngliche Plan war, direkt per OBD2-Adapter Daten vom Fahrzeug abzugreifen. Das funktionierte technisch, hatte aber einen Haken: aktives Abfragen über den CAN-Bus bei verriegeltem Fahrzeug kann die Alarmanlage auslösen – ein bekanntes Problem in der MG4-Community, nicht nur bei diesem Fahrzeug. Nach einigem Testen wurde klar, dass der zuverlässigere Weg über die Cloud-API des Herstellers führt, dieselbe Schnittstelle, die auch die offizielle App nutzt. Passives Auslesen, kein Eingriff am Fahrzeug selbst nötig.
Von dort aus ging es Schritt für Schritt weiter: ein eigener Server, eine Datenbank, ein Hintergrunddienst, der die Cloud-API in sinnvollen Abständen abfragt (schnell während der Fahrt, sparsam im Ruhezustand, um die 12V-Batterie zu schonen), und ein Admin-Bereich für alles, was nicht öffentlich sein soll. Viele der Rohdaten-Felder, die die API liefert, sind nirgends offiziell dokumentiert – die genauen Umrechnungsformeln (z.B. wie aus einem rohen Sensorwert eine Leistung in kW wird) wurden über echte Test-Fahrten und -Ladevorgänge nach und nach verifiziert, teils durch Gegenrechnen mit unabhängigen Werten wie dem Ladestand-Verlauf.
Gebaut wurde das komplette Projekt – Server-Aufsetzung, Backend, Datenbank-Design, der komplette Admin-Bereich und dieses Dashboard – in Zusammenarbeit mit Claude, dem KI-Assistenten von Anthropic, ganz ohne vorherige Programmiererfahrung. Jede API-Formel wurde dabei gegen echte Fahrzeugdaten getestet, nicht nur behauptet.
Ein kleiner Server (Hetzner Cloud) betreibt vier Docker-Container: eine PostgreSQL-Datenbank, ein Node.js-Backend, einen Python-Hintergrunddienst (den "Poller", der die Fahrzeugdaten holt) und Caddy als Reverse-Proxy für HTTPS. Der Poller fragt die SAIC-Cloud-API adaptiv ab – alle 30 Sekunden während der Fahrt, dynamisch beim Laden, aber nur alle 24 Stunden, wenn das Fahrzeug längere Zeit ruht, damit die 12V-Batterie nicht unnötig belastet wird. Ein zweiter, sehr günstiger Abruf prüft trotzdem alle 90 Sekunden auf neue Fahrzeug-Nachrichten (Fahrt-/Ladestart), damit der Wechsel in den aktiven Modus nicht erst nach 24 Stunden bemerkt wird.
Nichts hiervon ist offiziell von MG/SAIC dokumentiert. Alle Formeln unten wurden entweder aus einer quelloffenen Referenz-Implementierung übernommen (siehe Credits) oder durch eigene Testfahrten und -ladungen verifiziert – z.B. durch Gegenrechnen der geschätzten Energie gegen den tatsächlichen Ladestand-Verlauf.
Der Ladestand (SoC) am Fahrtanfang und -ende wird verglichen, die Differenz
mit der Netto-Akkukapazität multipliziert: Verbrauch (kWh) =
(SoC_Start − SoC_Ende) ÷ 100 × 61,7 kWh. Das ist der
Netto-Verbrauch, Rekuperation ist darin schon
automatisch berücksichtigt (sie füllt den Akku ja wieder etwas auf).
Die Fahrzeug-Cloud liefert nur alle 30 bis 70 Sekunden einen neuen
Messpunkt – einzelne Bremsvorgänge (die oft nur 2–5 Sekunden dauern)
lassen sich damit nicht einzeln erfassen. Stattdessen wird für jedes
Poll-Intervall die Batterieleistung geprüft: ist der Durchschnitt aus
Anfangs- und Endwert negativ (Energie fließt in den Akku), wird die
Energie für dieses Intervall grob draufgerechnet:
Energie ≈ |Ø Leistung| × Zeitdifferenz. Das ergibt einen
brauchbaren Trend, aber keine exakte Messung einzelner
Bremsungen. Zusätzlich wird jedes Intervall über die GPS-Geschwindigkeit
grob als Stadt (<50 km/h), Außerorts (50–100 km/h) oder Autobahn
(>100 km/h) eingeordnet – kein Kartenabgleich, nur ein
Geschwindigkeits-Schwellwert.
Für jeden Ladevorgang wird die tatsächliche Netz-CO₂-Intensität zum Ladezeitpunkt abgefragt (ElectricityMaps, deutscher Strommix – schwankt je nach Wind-/Solaranteil im Tagesverlauf teils erheblich). Multipliziert mit den geladenen kWh ergibt das die CO₂-Emissionen dieser Ladung. Ohne verfügbaren Live-Wert (z.B. wenn kein API-Key hinterlegt ist) greift ersatzweise ein Jahres-Durchschnittswert des deutschen Strommixes (aktuell 344 g CO₂/kWh, Umweltbundesamt 2025). Für die Ersparnis wird das mit einem realistischen Vergleichswert für einen Benziner im echten Fahrbetrieb verglichen (180 g CO₂/km – die offiziellen Prüfstand-Werte liegen niedriger, real aber üblicherweise 15–20% höher):
CO₂-Ersparnis = (Strecke × 180g/km) − Σ(geladene kWh × Netz-Intensität zum Ladezeitpunkt)
Kleine technische Randnotiz, falls es jemanden interessiert: Die
ElectricityMaps-API bietet sowohl einen latest- als auch
einen past-Endpunkt für historische Werte an – letzterer
braucht aber einen bezahlten Zugang. Deshalb fragt der Poller den
kostenlosen latest-Wert live ab, genau in
dem Moment, in dem eine Ladung als bestätigt erkannt wird, statt es
nachträglich zu rekonstruieren.
Das Fahrzeug selbst meldet einen Zeitstempel für Ladebeginn/-ende (nicht nur unsere eigenen Abfrage-Zeitpunkte) – darüber lassen sich alle Messpunkte eines Ladevorgangs zuverlässig gruppieren, auch über Poll-Lücken hinweg. Kurze, folgenlose "Selbstprüfungs-Blips" der Ladeelektronik (z.B. beim Abschalten, ganz ohne echten Energiefluss) werden über eine Mindestenergie-Schwelle herausgefiltert. AC/DC wird nicht über das naheliegende Statusfeld unterschieden (das ist mehrdeutig), sondern über die Kombination zweier Steckdosen-Statusfelder, die sich als zuverlässiger herausgestellt hat.
Das MG4 liefert intern gleich drei parallele Reichweiten-Schätzungen (vom Kombiinstrument, vom Batteriemanagementsystem, und vom Ladesteuergerät) – die meistens leicht auseinanderlaufen. Hier wird einfach die durchschnittliche Abweichung zwischen ihnen über die Zeit gemessen, aus reiner Neugier.
Es gibt kein offizielles Feld für den Batteriezustand (State of Health). Als grobe Ersatz-Kennzahl wird die angezeigte Reichweite bei (nahezu) 100% Ladestand über die Zeit getrackt – ein sinkender Wert über Monate hinweg wäre ein Hinweis auf nachlassende Kapazität. Weil Weil oft empfohlen wird, aus Langlebigkeitsgründen nur bis 80% statt 100% zu laden (technisch können MG4-Akkus natürlich auf 100%), gibt es hier nicht für jeden Monat einen Datenpunkt.
Ein paar weitere Berechnungen, die es gibt, aber aus Datenschutzgründen nicht auf dieser Seite auftauchen.
Manche Ladeanbieter bieten Abos an: ein reduzierter Preis pro kWh gegen eine monatliche Grundgebühr (z.B. "0,42 €/kWh statt 0,55 €/kWh, dafür 12,90 €/Monat"). Der Haken dabei: der tatsächliche Preis pro kWh hängt davon ab, wie viel in diesem Monat überhaupt geladen wurde – bei wenig geladenen kWh dominiert die Grundgebühr den Preis, bei viel geladenen kWh lohnt sich das Abo deutlich. Gelöst wird das über eine laufende Abrechnungsperiode pro Kalendermonat:
Effektiver Preis = Abo-Preis pro kWh + (Grundgebühr ÷ bisher geladene kWh in diesem Monat)
Während der Monat noch läuft, ist dieser Preis vorläufig (im Admin-Bereich mit einem "~" markiert) und wird nach jeder weiteren Ladung neu berechnet – meist günstiger, je mehr in diesem Monat schon geladen wurde. Erst nach Monatsende wird er final eingefroren, zusammen mit der tatsächlichen Ersparnis gegenüber dem Standardpreis ohne Abo:
Ersparnis = geladene kWh × (Standardpreis − effektiver Abo-Preis) − Grundgebühr
Wurde in einem Monat wenig geladen, kann diese Ersparnis auch negativ ausfallen – dann hätte sich das Abo in dem Monat schlicht nicht gelohnt. Das ist bewusst so gebaut: die Zahl soll ehrlich zeigen, ob sich ein Abo wirklich rechnet, statt es künstlich schönzurechnen.
Ladekosten werden über obiges Abo-Amortisierungsmodell berechnet. Kosten/CO₂ für eine einzelne Fahrt sind dagegen eine gröbere Näherung – ein gewichteter Durchschnittspreis aus allen bisherigen Ladevorgängen, multipliziert mit dem Verbrauch dieser Fahrt, kein exaktes Energiekonto, das nachverfolgt, welche konkrete Ladung welche konkrete Fahrt "bezahlt" hat. Start-/Zieladressen von Fahrten und Ladepunkt-Adressen werden per Reverse Geocoding aufgelöst (siehe Nominatim in den Credits), mit Datenbank-Cache, weil der Dienst nur eine Anfrage pro Sekunde erlaubt.
Acht zusätzliche Auswertungen für alle, die es genau wissen wollen – aus denselben Daten berechnet, die ohnehin schon da sind, keine neue Datenquelle außer beim letzten Punkt (Wind). Jeder Abschnitt lässt sich einzeln aufklappen.
Verbrauch aufgeschlüsselt nach Geschwindigkeitsband (0–30, 30–50, 50–70, 70–100, 100–130, 130+ km/h) – der "Sweet Spot" der Effizienzkurve. Nutzt dieselbe Trapez-Integration wie die Rekuperations-Schätzung (siehe oben), nur über die gesamte Leistung statt nur negative Werte: pro Poll-Intervall wird die gefahrene Distanz (Geschwindigkeit × Zeit) und die dabei verbrauchte Energie (Leistung × Zeit) dem Band der jeweiligen Durchschnitts- geschwindigkeit zugerechnet, über alle Fahrten aufsummiert.
Die letzten 20 DC-Ladesessions als Leistung-über-SoC-Kurven übereinandergelegt – der typische Taper (die Ladeleistung sinkt mit steigendem Ladestand), wie man ihn von EV-YouTubern kennt. Interessant vor allem im Zeitverlauf: eine sich verändernde Kurvenform über Monate hinweg wäre ein früher Hinweis auf Zellalterung, noch bevor sich das im groben Reichweiten-Trend zeigt.
Vergleicht für dieselbe Ladesession zwei Rechenwege: unsere Standard-Methode (SoC-Differenz × Kapazität) gegen eine Zeit-Integration der Pack-Leistung über die gesamte Ladedauer. Bewusst nicht "Ladeeffizienz" genannt – beide Wege nutzen letztlich dieselben BMS-Rohmesswerte (Strom, Spannung, SoC), sind also nicht unabhängig im messtechnischen Sinn. Eine echte Effizienzmessung bräuchte einen Vergleich mit der vom Ladepunkt oder Stromzähler gemessenen Energie, die wir nicht haben. Was die Zahl trotzdem ehrlich zeigt: wie sehr unsere ~30–70s-Poll-Auflösung bei der Zeit-Integration von der SoC-Snapshot-Methode abweicht – bei einer schnell wechselnden DC-Ladekurve kann das durchaus im zweistelligen Prozentbereich liegen.
Das Fahrzeug schätzt selbst eine Restladezeit (ein Feld, das die SAIC-API mitliefert). Wir merken uns die früheste Schätzung pro Ladesession und vergleichen sie mit der tatsächlichen Ladedauer bis zum Ladeende – eine kleine, aus reiner Neugier gebaute "Prognosegüte"-Statistik für die fahrzeugeigene Schätzung.
Zählt Leistungssprünge über 30 kW zwischen zwei aufeinanderfolgenden Polls als grobe Tendenz für Beschleunigung (Sprung nach oben) oder Bremsung/Rekuperation (Sprung nach unten). Bewusst keine präzise Einzelereignis-Erkennung – unser Poll-Abstand von rund 30 Sekunden während der Fahrt kann keine echten Sekundenbruchteil-Ereignisse auflösen, wie es ein Beschleunigungs- sensor könnte. Die Zahl ist eher ein grober Fahrstil-Indikator über viele Fahrten hinweg als eine verlässliche Zählung einzelner Vorfälle.
Reifendruck ändert sich physikalisch mit der Temperatur (näherungsweise das ideale Gasgesetz: gleiches Luftvolumen im Reifen, aber bei Kälte übt die Luft weniger Druck aus). Ein simples Streudiagramm aus Ø Reifendruck (alle vier Räder) über der jeweils gemessenen Außentemperatur – aus reiner Neugier, ob sich das bei uns auch so zeigt.
Eine Meta-Statistik über den Poller selbst statt über das Fahrzeug: durchschnittliches tatsächliches Poll-Intervall der letzten 7 Tage, Anzahl der Datenlücken über 30 Minuten (außerhalb des erwarteten 24h-Ruhemodus-Intervalls), und wie oft sich der Poller neu einloggen musste, weil die SAIC-Session abgelaufen war. Letzteres meldet der Poller inzwischen aktiv als Ereignis ans Backend, statt nur in seinen eigenen Logs zu stehen.
Für die letzten 15 Fahrten wird über die Open-Meteo Historical Weather API (kostenlos, kein API-Key nötig) die historische Windgeschwindigkeit und -richtung zum jeweiligen Fahrtzeitpunkt abgefragt und dauerhaft gecacht – historische Wetterdaten ändern sich ja nicht mehr, ein einmaliger Abruf reicht für immer. Die grobe Fahrtrichtung wird als Peilung von Start- zu Endpunkt berechnet (nicht die tatsächliche, evtl. kurvige Strecke), daraus die Gegenwind-Komponente:
Gegenwind = Windgeschwindigkeit × cos(Windrichtung − Fahrtrichtung)
Positiv = Gegenwind (Widerstand), negativ = Rückenwind (Unterstützung).
Zusätzlich wird geschätzt, wie viel Energie allein für die Überwindung des Luftwiderstands draufging:
Leistung = 0,5 × Luftdichte × Cw × Stirnfläche × Geschwindigkeit³
Die effektive Geschwindigkeit ist Fahrzeugtempo plus Gegenwind- Komponente, die Luftdichte wird aus der echten gemessenen Außentemperatur berechnet (ideales Gasgesetz, Standard-Luftdruck angenommen – keine Live-Druckmessung verfügbar). Zwei Annahmen bewusst offengelegt: MG nennt keinen offiziellen Cw-Wert, deshalb 0,278 als fester Mittelwert (der MG4 hat eine aktive Kühlerjalousie, die den Cw vermutlich zwischen ~0,27 und ~0,287 verändert, aber kein API-Feld verrät deren Zustand). Die Stirnfläche (≈2,35 m²) ist ebenfalls kein Herstellerwert, sondern über die übliche Faustformel Breite×Höhe×0,85 geschätzt (die Maße 1,836 m × 1,504 m selbst sind aus dem MG-Datenblatt bestätigt).
Die eigentlich interessante Kennzahl ist nicht der gesamte Luftwiderstand-Anteil (der wäre bei starkem Gegenwind sogar über 100% des Verbrauchs möglich, weil das physikalische Modell unabhängig von der echten SoC-Messung rechnet), sondern die Differenz: derselbe Leistungswert einmal mit dem gemessenen Wind, einmal bei angenommener Windstille und sonst identischem Tempo. Diese Differenz, als Prozentsatz vom tatsächlichen Gesamtverbrauch der Fahrt, isoliert gezielt, was der Wind speziell beigetragen hat – getrennt von der Grundlast, die allein durch das Fahrtempo entsteht.
Was hätte dieselbe Strecke mit einem vergleichbaren Benziner/Diesel gekostet, verglichen mit den tatsächlichen Ladekosten (nicht nur einer Näherung über den Ø-Preis)? Ergänzt die schon bestehende CO₂-Bilanz um die Geld-Seite. Ø-Verbrauch (Standard: 6,5 l/100km) und Kraftstoffpreis (Standard: 1,75 €/l) sind über die Server-Konfiguration frei anpassbar – anders als bei physikalischen Konstanten gibt es hier keinen "richtigen" Wert, das hängt vom gewünschten Vergleichsfahrzeug und den aktuellen Preisen ab.
Zeigt, an welchen Wochentagen und zu welchen Uhrzeiten typischerweise gefahren bzw. geladen
wird – z.B. "meistens werktags morgens gefahren" oder "fast nur nachts geladen". Alle
Zeitstempel werden dafür von der intern gespeicherten UTC-Zeit auf deutsche Lokalzeit
umgerechnet (AT TIME ZONE 'Europe/Berlin'), inklusive korrekter Behandlung von
Sommer-/Winterzeit-Umstellungen.
Ergänzt den bestehenden "Reichweite bei 100% SoC"-Trend (siehe oben, Batterie-Alterung) um eine einfache lineare Hochrechnung (kleinste Quadrate) 6 und 12 Monate in die Zukunft. Erst ab mindestens drei verschiedenen Monaten mit Daten verfügbar – bei weniger Punkten wäre jede Gerade nur Rauschen, kein echter Trend. Bewusst nur eine Fortschreibung des bisherigen Trends, keine Prognose der tatsächlichen, meist nicht-linearen Batteriealterung (die verlangsamt sich in der Praxis oft mit der Zeit, statt linear weiterzugehen).
Ø Verbrauch je Kalendermonat, alle bisherigen Jahre zusammengefasst (z.B. alle Januare gemeinsam) – zeigt den typischen Winter/Sommer-Unterschied. Anders als die bestehende Wetter-Korrelation (die einzelne Fahrten gegen die jeweils gemessene Temperatur stellt) hier eine echte Monats-Aggregation über die komplette Fahrzeug-Historie.
Typische Ladedauer (Durchschnitt und Median – der Median ist bei Ladedauern oft aussagekräftiger, da einzelne sehr lange Sessions den Durchschnitt stark verzerren können), häufigste Startzeit, und der Anteil "über Nacht" geladener Sessions. "Über Nacht" ist dabei grob als Sessionstart zwischen 20 und 7 Uhr (deutsche Zeit) definiert – eine Näherung, keine exakte Nacht-/Tag-Grenze.
Kombiniert zwei Teilwerte pro Monat zu einer einzigen Kennzahl (0–100), um einen Trend über Zeit verfolgbar zu machen:
Der Gesamt-Score ist das Mittel beider Werte. Bewusst transparent gemacht: das ist eine selbst gewählte Gewichtung, keine wissenschaftliche oder objektive Messung – andere Gewichtungen wären genauso legitim. Der reine Verbrauch fließt bewusst nicht ein, da der zu stark von Außenfaktoren (Route, Wetter, Geschwindigkeit) abhängt, um fair als "Fahrstil" gewertet zu werden.
Bewusste Entscheidung: Kein Standort, keine Fahrten-Karte, keine Verriegelungs- oder Alarm-Zustände, keine Kosten. Diese Seite ist öffentlich einsehbar, und nichts davon soll erkennen lassen, wo das Fahrzeug gerade ist, ob es zu Hause steht, oder ob es gerade unverschlossen ist. Was hier steht, sind bewusst nur aggregierte, technisch interessante Werte (Gesamtstrecke, Verbrauch, Rekuperation, CO₂-Bilanz) und der aktuelle Fahrzeugzustand ohne Ortsbezug (Akkustand, Reifendruck, Temperaturen). Alles mit Orts- oder Kostenbezug bleibt im passwortgeschützten Admin-Bereich.
Alle Datenquellen und die Software-Grundlage dieses Projekts, thematisch gruppiert und mit Lizenzangaben, stehen auf der eigenen Seite Quellen & Credits.