Rund um das Telemetriemodul: Infos, Nutzen, Hacks...

[Pfriemler]

Heute auf einer Fahrt in die Innenstadt vom dicken B hatte ich am Ziel einen SoC von 92% in der App. Das war in etwa der Stand beim Losfahren GPS-Position war von der letzten Kreuzung, ca 300 Meter entfernt vom Abstellort, nach 15 km Fahrt. Während des gesamten Aufenthalts dort (im Freien!) gab es keinen Connect (Meldung in der App: "seit mehr als 15 Minuten keinen Aktualisierung"). Später zu Hause angekommen, war der SoC in der App noch immer auf 92% - aber ODO stimmte! Die mit dem Handy geloggten Telemetriedaten wiesen aber eindeutig (klarschriftlich als auch im SCUTUM S01:Report) 61% (wie auch auf dem Display) aus. Das hatte sich dann seltsamerweise eine Viertelstunde später auch in der App ergeben.
Ich hatte erst an einen Absturz des Moduls nach BT-Benutzung gedacht, aber offenbar arbeitete das Modul die ganze Zeit einwandfrei - stattdessen gab es irgendeinen Knoten in der App-Infrastruktur. Das hat nicht zufällig auch jemand beobachtet? Zeitspanne ~14.55 bis 21.45.

Nachtrag: Es ist wieder passiert.

1. Bild: nach der Fahrt abends in die Innenstadt: SoC und km korrekt
Ich kann mich erinnern, nach der Rückfahrt nachts kurz die Werte nach der Ankunft verglichen zu haben und meine mich erinnern zu können, dass sowohl SoC als auch km in App und Tacho übereinstimmend 15% und 2026 km waren (und 12 Restkilometer), deswegen habe ich keinen Screenshot gemacht.
(nach insgesamt 98 Silence- bzw. 85 echten Kilometern bin ich recht zufrieden damit übrigens)
2. Bild: am nächsten Morgen meckert der Roller über fehlenden Kontakt: km stimmt, SoC ist auf dem Stand vor der Heimfahrt, aber die Restkilometeranzeige zeigt (offenbar) den Vorabendwert!
3. Bild: drei Minuten später, nach dem Empfang des ersten Datentelegramms, hat sich die Restkilometerzahl korrigiert, SoC ist weiterhin falsch!
4. Bild: wiederum drei Minuten später stimmt auch der SoC wieder.

Es hat den Anschein, als hätte sich nur der SoC über Nacht "zurückgesetzt" und wurde erst im zweiten Anlauf korrigiert, nachdem zuvor nur die Restkilometeranzeige aktualisiert wurde.
Übrigens hatte das Telemetriemodul auch dieses Mal korrekte "SCUTUM S01"-Reports gesendet.

[blackblade]

Nö, alles ok. Habe allerdings einen S01.

Ich hatte erst an einen Absturz des Moduls nach BT-Benutzung gedacht, aber offenbar arbeitete das Modul die ganze Zeit einwandfrei - stattdessen gab es irgendeinen Knoten in der App-Infrastruktur. Das hat nicht zufällig auch jemand beobachtet? Zeitspanne ~14.55 bis 21.45.

[Pfriemler]

danke und sorry - wegen der offensichtlich teilinterpretierten Daten dürfte das Problem nur SEAT betroffen haben, bzw. ich rechne gar nicht damit, dass es mit Silencerollern ein Problem gab.

Oder aber am Ende läuft doch alles inklusive Datenauswertung auf dem gleichen Server und Silence unterscheidet nur anhand der VIN, welche App koppeln darf...

Egal: wenn noch irgendjemand nur halb richtige Daten in der App findet, wäre ein Austausch vielleicht nützlich.

[blackblade]

Ich finde es schon sehr interessant, was ihr hier so treibt. Vielleicht findet jemand noch einen Weg in die API für die App, so wie das bei meinem Niu möglich war.

[Gerold]

Auf die API wurde schon mehrfach zugegriffen. So wird sie z.B. von der evcc und der homeassistant Integration des S01 genutzt. @michael1 hat darüber hinaus ein Tool entwickelt, das auch auf der API aufsetzt.

[blackblade]

Ach nee... und ich dachte, ich hätte alle relevanten Threads hier gesehen. Vielen Dank. Das Tool von @michael1 scheint aber umgezogen sein.

Auf die API wurde schon mehrfach zugegriffen. So wird sie z.B. von der evcc und der homeassistant Integration des S01 genutzt. @michael1 hat darüber hinaus ein Tool entwickelt, das auch auf der API aufsetzt.

[Pfriemler]

Von dem Tool hatte ich schon weit vor meinem Mo gelesen - nun wäre es interessant herauszubekommen, ob es auch eine Chance als Mo-Besitzer gibt, die ganz offensichtlich gesammelten Daten am Stück gelegentlich vom Server zu ziehen, weil das für die nämlich die einzige Möglichkeit wäre, überhaupt an die Daten zu kommen. Leider fehlt mir wirklich auf längere Dauer die Zeit für weitere Investigationen dazu. Das erste Problem ist schon die andere Struktur der Zugangsdaten.

Inzwischen hat mich noch die Frage umgetrieben (Gerold hat das sicher längst geklärt für sich ), wie es zu den zusätzlichen Befehlen in unseren Telematikmodulen kommt (die ja in keiner sonstigen Doku auftauchen) und auch zu den speziellen Reports. Zu den ominösen "Protocol X" habe ich mit ein bisschen G*e noch nix gefunden, aber das würde sicher auch nicht erklären, warum das Modul z.B. auch detaillierte Informationen über Motor, Inverter und vor allem der Batterie liefert, die es sich nach meiner Vermutung aus den CAN-Daten selbst generiert. Dafür nutzt Silence wohl das Astra Telematics SDK (hier ein PDF zu den Nutzungsvoraussetzungen), um die Firmware in erheblichem Maße anzupassen. Da ich irgendwann mal gelesen hatte, dass Astra für seine Module regelmäßig Firmwareupdates anbietet, die mit einem einfachen Befehl OTA gezogen werden können, verbietet sich so etwas natürlich für unsere Module, da sie damit für die Server- und App-Funktionalität unbrauchbar werden. Sollte es von Silence selbst mal Updates geben, könnte man die gleichwohl OTA aufspielen, wenn es dafür einen eigenen Server gibt.

[Gerold]

Die Firmware des Moduls verwendet ein Protokoll Z ($PROT,19,...), welches laut Commandref ein modulares "Private client protocol" ist und mit Sicherheit eine Erweiterung von Protokoll X ist. Interessant ist hier noch, dass in der neueren Firmware von @Pfriemler eine andere Report Mask (55968794727) als in Meiner (4496296074) verwendet wird. Über die Report Mask wird gesteuert, welche Daten vom Modul gesendet werden. Die Report Mask dient dabei als binärer Schalter, welcher die im Protokoll festgelegten Module auswählt. Ich vermute mal, das mit der neueren Firmware deutlich mehr Daten gesendet werden als mit Meiner. In @Pfriemler's Log sieht man dazu die Meldung "Sending data: 200 bytes", mein Modul sendet dagegen nur 105 ("writing 105 bytes to socket 0").

Die SCUTUM S01 Daten enthalten bis auf den ominösen Zähler nur Daten, die über CAN-Bus vom BMS, der ECU und dem Display gesendet werden. Den Zähler habe ich bisher im CAN Bus nicht gefunden. Eine Besonderheit gibt es bei der Motor- und Invertertemperatur. Diese tauchen in den CAN-Bus Daten zweimal auf. So werden sie einmal vom Sevcon mit der ID 0x411, zum Anderen wahrscheinlich von der ECU mit der ID 0x301 verschickt. Im Gegensatz zu den Sevcon Werten, welche direkt in °C ausgegeben werden, sind die ECU Daten noch mit einem Faktor 10 versehen. Diesen Faktor findet man auch in den SCUTUM S01 Daten, ich gehe daher davon aus, dass hier die ECU Daten genommen werden. Das könnte auch erklären, weshalb bei beiden Temparaturen gelegentlich 0°C angezeigt wird. Das Astra Modul versendet immer die letzten Werte, die es von BMS, ECU und Display erhalten hat, d.h. nach dem Ausschalten des Rollers werden immer die Werte zum Zeitpunkt des Ausschaltens im Minutentakt gesendet. Eine Ausnahme hiervon bildet das BMS. Dieses befindet sich in einer Art Standbye, aus dem es im Halbstundentakt für kurze Zeit aufwacht und aktualisierte BMS Daten über den CAN Bus sendet. Beim Laden des Akkus im Roller sind nun BMS, ECU und Display aktiviert, der Sevcon aber nicht. Die ECU erhält deshalb keine aktuellen Motor- und Invertertemperaturen und setzt diese auf 0°C. Diese Werte werden dann vom Astra Modul auch nach Beendigung des Ladevorgangs solange gesendet, bis der Roller wieder eingeschaltet wird.

[Rudi Ratlos]

Hi Junx,

heute hab ich nun meinen Mo bekommen (freu), eine kleine Probefahrt gemacht (grins) und schon mal am Diagnoseport mit einem OBDLink gelauscht. Sieht erfolgversprechend aus.

Nennt es Paranoia, aber dieses Telemetriemodul ist mir immer noch suspekt; dass ich es einfach abklemmen kann, hab ich hier schon erfahren. Trotzdem meine Frage an Euch Erfahrene: Wie sicher ist es, dass meine Daten wirklich nur an den Server in $IPAD1 gesendet werden? Könnte es nicht sein, dass da noch ein anderer "hardcoded" vorhanden ist?

Andererseits habe ich schon Interesse an all den Daten - brauche die aber nicht unbedingt an (m)einen Server versendet, sondern mir würde eine mitgeführte Log-Mimik genügen. Alle Daten müssten doch über den CAN-Bus verfügbar sein, oder? Gibt es schon irgendwo eine Zusammenfassung der bekannten CAN-IDs oder einen Thread dazu (den ich dann auch gerne mit meinen Erkenntnissen ergänzen würde)?

Danke für Eure Antworten, Grüße vom Rudi aus Freiburg. Außer meinem Mo hab ich übrigens hier in der Gegend noch keinen - und auch keinen Silence gesehen...

[Pfriemler]

Junx ist auch gut
Einem anderen S01 oder Mó bin ich auch noch nie begegnet.

Nennt es Paranoia, aber dieses Telemetriemodul ist mir immer noch suspekt; dass ich es einfach abklemmen kann, hab ich hier schon erfahren. Trotzdem meine Frage an Euch Erfahrene: Wie sicher ist es, dass meine Daten wirklich nur an den Server in $IPAD1 gesendet werden? Könnte es nicht sein, dass da noch ein anderer "hardcoded" vorhanden ist?

Ich glaube wirklich nicht. Vielleicht noch an Astra Telematics ein paar Basics zur Nutzung ihrer Module (also Daten zum Modul, aber keine Nutzdaten).

... schon Interesse an all den Daten ... mitgeführte Log-Mimik (würde) genügen. Alle Daten müssten doch über den CAN-Bus verfügbar sein, oder?

Die und noch mehr, aber die Datenflut ist schon beeindruckend, da ist das Telematikmodul ja regelrecht leise. Ohne vernünftige Vorprozessierung geht da nichts. Das ist ja gerade das Charmante an den SCUTUM-Reports: die kommen nur in einstellbaren Abständen und beschränkt auf das Wesentliche.

Gibt es schon irgendwo eine Zusammenfassung der bekannten CAN-IDs oder einen Thread dazu (den ich dann auch gerne mit meinen Erkenntnissen ergänzen würde)?

Gerold hat hin und wieder ein paar Infos gestreut, auch und besonders im Blinker-Thread, aber auch bei Akku-Fragen. Er hat da ja schon ein paar bemerkenswerte Sachen zusammenbekommen. Die CAN-Daten versuche ich gerade zu verifizieren (Abweichungen habe ich schon gefunden). Ich würde lieber einen neuen Thread aufmachen , Arbeitstitel "Lauschangriff am CAN-Bus - Theorie und Praxis" oder irgendwas nicht ganz so trockenes, im ersten Beitrag ein paar Basics (oder die kommen gleich in den Sammelhread, ähnlich wie hier).