‹ Zurück zum Dashboard

MG4 · KLEVE

Projekt & Verfügbarkeit

Privates Hobby- und Entwicklungsprojekt

Warum ist das hier öffentlich – und wo ist der Download?

Eine berechtigte Frage: Auf dieser Website sieht man ein umfangreiches Dashboard, Apps für Handy, Android Auto und Wear OS, eine eigene Navigation und jede Menge Servertechnik. Trotzdem gibt es keinen Knopf „App herunterladen“. Das ist kein Versehen – die Website dokumentiert ein privates Technikprojekt, kein fertiges Produkt.

öffentlich dokumentiert privat betrieben kein Downloadpaket Self-hosted denkbar

Warum ich das Projekt überhaupt öffentlich zeige

MG4 Kleve ist über längere Zeit Schritt für Schritt entstanden. Angefangen hat es mit Fahrzeugdaten und einem kleinen Dashboard. Daraus wurden Auswertungen, Ladeanalyse, Fernfunktionen, Android Auto, eine Wear-OS-App und schließlich ein eigenes Navigationssystem mit Energie- und Ladeplanung.

Vieles davon war für mich vorher Neuland. Gerade deshalb finde ich es spannend, nicht nur das Ergebnis zu benutzen, sondern auch zu dokumentieren, wie die einzelnen Teile zusammenarbeiten, welche Ideen funktioniert haben und wo Umwege nötig waren. Die Website ist damit auch ein öffentliches Projekttagebuch.

Vielleicht hilft die eine oder andere Idee anderen MG4-Fahrern, EV-Interessierten oder Menschen, die selbst mit Fahrzeugdaten, OpenStreetMap, Valhalla, Android Auto oder Wear OS experimentieren. Öffentlich dokumentiert bedeutet aber nicht automatisch öffentlich installierbar.

Keine Produkt- oder Verkaufsseite

Hier soll nichts verkauft werden. Ich zeige ein System, das ich für meinen eigenen MG4 und meine eigene technische Umgebung gebaut habe und selbst weiterentwickle. Dass es inzwischen ziemlich „fertig“ aussieht, ändert an diesem Ursprung nichts.

Kann ich MG4 Navigation selbst nutzen?

Aktueller Stand: nicht als fertiges Paket Es gibt derzeit weder eine allgemein installierbare APK noch ein komplettes Ein-Klick-Setup für fremde Fahrzeuge und Server.
PRIVATES SYSTEM

Der Grund ist weniger die einzelne Android-App als das Gesamtsystem dahinter. Die App ist nur die sichtbare Spitze. Viele Funktionen setzen Dienste voraus, die heute auf meine eigene Installation, mein Fahrzeug und meine Konfiguration abgestimmt sind.

Warum nicht einfach die APK bereitstellen?

Eine APK allein würde einen großen Teil der Funktionen gar nicht liefern. Hinter den Oberflächen arbeitet eine ganze Kette aus Serverdiensten, Datenquellen und eigener Logik:

Handy-App

Planung, Kartenansicht, Fahrzeug- und Navigationsfunktionen sowie die Verbindung zum eigenen Backend.

Android Auto

Eigene Ansichten für das Fahrzeugdisplay, Navigation, Fahrinformationen und die Integration in die Android-Auto-Oberfläche.

Wear OS

Eine eigenständige Uhr-App für Fahrzeugstatus und Fernfunktionen – technisch ein weiteres Android-Projekt, das ebenfalls konfiguriert und gepflegt werden muss.

Node.js-Backend

Verbindet Fahrzeugdaten, Auswertungen, Navigation, Ladeplanung, Traffic, Kartenfunktionen und die verschiedenen Clients.

PostgreSQL

Speichert Fahrten, Ladungen, Fahrzeugzustände, Tarife, Planungen und weitere historische Daten.

Valhalla

Ein selbst betriebener Routingdienst auf Basis von OpenStreetMap liefert Routen und viele Navigationsdetails.

Externe Datenquellen

Je nach Funktion kommen Karten-, Verkehrs-, Lade-, Wetter- oder andere Dienste hinzu – jeweils mit eigener Konfiguration und teilweise eigenen Zugangsdaten.

Fahrzeuganbindung

Die Fahrzeugdaten stammen aus der Umgebung des eigenen MG4. Zugangsdaten und persönliche Fahrzeuginformationen gehören selbstverständlich nicht in ein öffentliches Paket.

Handy · Android Auto · Wear OSOberflächen und Bedienung
Eigenes Backend & DatenbankLogik, Historie, Fahrzeug- und EV-Daten
Valhalla & DatenquellenRouting, OSM, Traffic und weitere Dienste

Was müsste für eine Veröffentlichung passieren?

„Den Code hochladen“ wäre der einfache Teil. Damit andere das System wirklich sinnvoll benutzen könnten, müsste aus der heutigen persönlichen Installation eine reproduzierbare und verständlich konfigurierbare Software werden. Dazu gehören unter anderem:

Der Aufwand steckt also vor allem in der Produktisierung: Ein System, das in einer bekannten eigenen Umgebung funktioniert, muss so umgebaut werden, dass es auch in einer unbekannten Umgebung verständlich, sicher und wartbar bleibt.

Drei sehr unterschiedliche Arten von „veröffentlichen“

1 · Quellcode für Bastler

Code und Beispielkonfiguration veröffentlichen, aber Installation, Server und Anpassungen bleiben Sache des Nutzers. Das wäre die kleinste und am ehesten überschaubare Variante.

2 · Saubere Self-hosted-Version

Ein nachvollziehbares Setup, mit dem technisch versierte Nutzer ihre eigene Instanz betreiben können. Dafür müssten Installation, Updates, Konfiguration und Dokumentation deutlich robuster werden.

3 · Fertige App für alle

Installieren, anmelden und losfahren – ohne eigenen Server. Dafür wären Multiuser-Betrieb, sichere Konten, Skalierung, Store-Veröffentlichung, deutlich breitere Tests und dauerhafter Betrieb nötig.

Der eigentliche Unterschied

Zwischen „Code zeigen“ und „für jeden zuverlässig betreiben“ liegt sehr viel Arbeit, die mit den sichtbaren Navi-Funktionen selbst nur teilweise zu tun hat.

Ein zentraler Dienst für alle?

Technisch wäre auch denkbar, einen gemeinsamen Server für viele Nutzer zu betreiben. Das wäre aber noch einmal eine andere Größenordnung. Dann müssten Fahrzeug- und Bewegungsdaten verschiedener Nutzer sicher voneinander getrennt, Zugänge verwaltet, Kapazitäten überwacht und der Dienst dauerhaft betrieben werden. Dazu kämen laufende Kosten, Backups, Updates und Support.

Für ein privates Hobbyprojekt wäre das ein großer Schritt weg vom eigentlichen Tüfteln und hin zum dauerhaften Betrieb eines Dienstes.

Wäre eine Self-hosted-Version realistischer?

Ja – zumindest grundsätzlich. Eine mögliche Zwischenstufe wäre irgendwann eine Version für technisch interessierte Nutzer, bei der jeder seinen eigenen Server, seine eigenen Zugangsdaten und seine eigene Valhalla-Instanz betreibt. Damit blieben persönliche Fahrzeugdaten beim jeweiligen Betreiber und es wäre kein zentraler MG4-Kleve-Dienst nötig.

Aber auch dafür müssten Installation, Konfiguration, Updates und Dokumentation zuerst deutlich aufgeräumt und verallgemeinert werden. „Self-hosted denkbar“ ist daher keine Ankündigung und kein Terminversprechen.

Traue ich mir eine Veröffentlichung zu?

Die spannende Frage ist für mich weniger, ob die einzelnen technischen Probleme lösbar wären. Viele komplizierte Bausteine funktionieren im eigenen System bereits. Die größere Frage ist, ob ich aus dem Hobbyprojekt wirklich ein Projekt machen möchte, das auch für fremde Installationen verständlich, sicher und dauerhaft wartbar sein muss.

Das ist eine andere Art von Arbeit als das Experimentieren am eigenen System: weniger „Kann ich das irgendwie bauen?“ und mehr „Kann jemand anderes es ohne mein Wissen über diese Installation zuverlässig betreiben?“. Ob ich diesen Schritt irgendwann gehe, lasse ich deshalb bewusst offen.

Vielleicht irgendwann – aber ohne Versprechen

Im Moment bleibt MG4 Kleve ein privates Entwicklungsprojekt, das öffentlich dokumentiert wird. Einzelne Bestandteile oder eine aufbereitete Self-hosted-Version sind für die Zukunft nicht ausgeschlossen. Der Spaß am Ausprobieren, Lernen und Weiterentwickeln steht aber weiterhin vor dem Ziel, daraus ein Produkt zu machen.

Und genau deshalb ist die Website trotzdem öffentlich

Ein Projekt muss nicht als fertiger Download enden, um interessant oder nützlich zu sein. Ich möchte zeigen, was sich mit einem MG4, offenen Kartendaten, eigener Servertechnik und einer Menge Neugier bauen lässt. Die Website hält diesen Weg fest – einschließlich der Ideen, der funktionierenden Lösungen und der Dinge, an denen noch getüftelt wird.

Stand dieser Seite: August 2026. Der Funktionsumfang des Projekts entwickelt sich weiter; die Aussage zur öffentlichen Verfügbarkeit kann sich deshalb irgendwann ändern.