Tagelang ans Auto geklopft — aufgemacht hat am Ende ein Fremder
Die Aufgabe klang nach einem Nachmittag: Der Ladestand des Mazda 6e soll in Home Assistant stehen. Prozentzahl, Reichweite, lädt gerade ja/nein. Damit die Wallbox-Steuerung weiß, ob sich das Laden überhaupt lohnt, und nicht nur stur auf den Solarüberschuss starrt.
Es wurden Tage. Und die Lösung kam am Ende von jemandem, der von dem Problem gar nichts wusste.
Das Auto ist nicht das Auto, das draufsteht
Erste Erkenntnis, und sie hat gleich die halbe Recherche entwertet: Der 6e ist ein umgelabelter Changan. Vorn klebt das Mazda-Logo, hinten hängt die Changan-IoV-Cloud.
Das bedeutet: Sämtliche etablierten Mazda-Integrationen sind wertlos. Die bekannten Forks — runDMCA/homeassistant-mazda, bdr99/pymazda und Verwandtschaft — sprechen seit Jahren zuverlässig mit den Mazda Connected Services. Nur redet dieses Auto kein Wort mit ihnen. Es meldet sich bei einer völlig anderen Plattform an, unter einem völlig anderen Protokoll.
Man kann das eine halbe Stunde lang nicht glauben und Repositories durchsuchen, in denen der 6e nirgends auftaucht. Ich empfehle, diese halbe Stunde zu überspringen.
Die Mauer: verschlüsselte Zugangsdaten
Es gab eine passende Integration: fano0001/home-assistant-mazda-6e, damals bei Version 0.13.9. Jung, wenig verbreitet, aber sie zielte auf die richtige Cloud. Installiert, Konfigurationsdialog geöffnet, E-Mail und Kennwort eingetragen — und dann: nichts. Kein Login, keine Entitäten, nicht einmal ein brauchbarer Fehler im Log.
Der Grund stand im Quelltext. Die App schickt Zugangsdaten nicht im Klartext, sondern RSA-verschlüsselt an den Server; im Code stecken ein fest hinterlegter Public Key und zwei Felder, in die Kennung und Kennwort nur vorverschlüsselt hineingehören. Ohne die korrekte Verschlüsselung der Anmeldedaten kommt man nicht einmal bis zum ersten Handschlag. Und genau dieser Teil war im vorliegenden Stand der Integration nicht funktionsfähig.
Das ist eine unangenehme Sorte Sackgasse: Es liegt nicht an der Konfiguration, nicht am Netzwerk, nicht an fehlenden Rechten. Es liegt daran, dass ein kryptographischer Baustein fehlt. Da hilft kein Herumprobieren.
Plan B: es selbst bauen
Also der Versuch, die Integration zu umgehen und direkt mit der Changan-Cloud zu sprechen. Das klang zunächst vielversprechend, denn der Ablauf ist erfreulich schlicht: anmelden, Gerät per Mail-Code verifizieren, /vehicle/vehicles für die Fahrzeugliste, /vehicle/condition/v2 für den Zustand. Vier Aufrufe, fertig.
Die Server von iov.changanauto.com.de waren problemlos erreichbar, Antwortzeiten um 90 Millisekunden. Alles bereit.
Und dann stand ich vor exakt derselben Mauer. Das Login ist der erste Schritt, und das Login ist verschlüsselt. Ein eigener Abfragedienst scheitert an genau der Hürde, an der die fertige Integration scheitert — nur dass ich dafür zusätzlich noch alles andere hätte selbst schreiben dürfen.
Lehre: Wenn eine fremde Implementierung an einer bestimmten Stelle scheitert, lohnt vorher die Frage, ob der eigene Nachbau an derselben Stelle scheitern wird. Bei Krypto lautet die Antwort fast immer ja.
Plan C und D: Umwege, die keine waren
evcc bringt Fahrzeugprofile mit, 69 Vorlagen. Für Mazda existiert genau eine: mazda2mqtt — als deprecated markiert, ein reiner MQTT-Adapter zum Drittprojekt C64Axel/mazda2mqtt, dessen Repository mittlerweile schlicht 404 liefert. Und selbst wenn: Es zielt auf die alte Mazda-API, nicht auf die chinesische Cloud. Nach Changan, Deepal oder Avatr gesucht: null Treffer.
Nebenbefund derselben Suche — evcc lief auf dem Zielsystem überhaupt nicht mehr. Irgendwann im Sommer verschwunden, Port 7070 tot, niemandem aufgefallen. Man findet auf solchen Streifzügen erstaunlich viel kaputtes Zeug, nach dem man gar nicht gesucht hat.
Dann Tibber. Die Grid-Rewards-Integration legt tatsächlich einen Sensor mit Ladestand an. Sah nach der Rettung aus. Ist aber ein Wert, den man in der Tibber-App von Hand einträgt. Es besteht keinerlei Verbindung zum Fahrzeug. Später im direkten Vergleich: Der eingetragene Wert stand bei 65 Prozent, während das Auto tatsächlich bei 91 lag. Ein Sensor, der aussieht wie Telemetrie und in Wahrheit eine Notiz ist.
Plan E war von vornherein unmöglich
Der letzte naheliegende Gedanke: Das Auto hängt doch an der Zaptec Go 2 — die muss den Ladestand doch kennen.
Nein. Und zwar grundsätzlich.
Wechselstromladen kommuniziert nach IEC 61851 über ein einziges pulsweitenmoduliertes Signal auf der Control-Pilot-Leitung. Die Aussage dieses Signals lautet vollständig: „Du darfst maximal so und so viele Ampere ziehen.” Mehr Kanal gibt es nicht. Die Box weiß nicht, welches Auto dranhängt, wie voll es ist oder wie lange es noch braucht. Der Ladestand, den man an Schnellladesäulen auf dem Display sieht, kommt aus DIN SPEC 70121 bzw. ISO 15118 auf der Gleichstromseite — ein völlig anderes, deutlich aufwendigeres Protokoll.
Es gibt eine theoretische Ausnahme: ISO 15118 über AC, Stichwort Plug & Charge. Das braucht ein PLC-Modem auf beiden Seiten, und der Ladestand ist dort ein optionales Feld. Die HA-Zaptec-Integration hat folgerichtig keinen einzigen fahrzeugseitigen Sensor.
Diese Sackgasse war die lehrreichste. Die vier davor waren Software — hätte man mit genug Ausdauer knacken können. Diese hier ist Physik. Kein Aufwand der Welt holt Daten aus einer Leitung, über die keine Daten laufen.
Aufgemacht hat jemand anderes
Der Stand nach all dem: kein Weg, dokumentiert warum, abgehakt. Als Ersatz war bereits OBD-Hardware im Gespräch — ein WiCAN Pro im Diagnoseanschluss, am CAN mitlesen, Cloud komplett umgehen. Für den 6e existiert allerdings kein fertiges Profil, die SoC-PID hätte man sich per Mitschnitt selbst suchen dürfen.
Und dann, wenige Tage später, hat MTrab — bekannt unter anderem von der Landroid-Cloud-Integration — in Issue #1 des Repos die Login-Verschlüsselung geknackt und den fehlenden Baustein als PR #4 eingereicht. Kein Trick mehr nötig, kein MITM-Proxy: E-Mail und Kennwort im Klartext eintragen, eine neue credential_crypto.py erledigt die Verschlüsselung intern, die DeviceID wird automatisch erzeugt, dazu ein Verifizierungscode per Mail. Fertig.
Auf v1.0.2 aktualisiert, neu gestartet, angemeldet. 25 Entitäten: Ladestand, Reichweite, Kilometerstand, Ladestatus, Reifendruck aller vier Räder, Innenraumtemperatur, sämtliche Türen und Fenster, eingesteckt ja/nein. Schreibender Zugriff fehlt weiterhin — Klimatisierung und Verriegelung gehen nicht —, aber alles, worum es ursprünglich ging, steht jetzt da.
Ein hübscher Stolperstein noch zum Schluss: Die verbleibende Ladezeit meldet bei pausiertem Laden 8191 Minuten. Das sind zwei hoch dreizehn minus eins — der klassische Platzhalter für „kein Wert”. Wer den ungefiltert in eine Automatisierung schreibt, wartet rechnerisch fünfeinhalb Tage.
Was bleibt
Tage Arbeit, fünf Wege, vier Sackgassen. Gelöst hat es am Ende ein Fremder, der dasselbe Problem hatte und mehr Ausdauer an der richtigen Stelle.
Das ist kein bequemes Fazit, aber ein ehrliches: Bei jungen Integrationen für exotische Hardware ist der Blick in den Issue-Tracker manchmal mehr wert als der eigene dritte Lösungsversuch. Ich habe den Zustand damals sauber dokumentiert und zur Seite gelegt — deshalb war das Update eine Viertelstunde Arbeit und kein Wiedereinstieg bei null.
Ein Restrisiko bleibt: Laut einem Hinweis im selben Issue soll Changan den 6e an Mazda übergeben. Wechseln dabei die App- und Update-URLs, ist die Integration wieder tot. Der OBD-Weg ist deshalb nicht vom Tisch, nur vertagt.
Sackgassen aufschreiben lohnt sich. Man weiß nie, wann jemand anders die Tür öffnet.