Neues Plugin für Tesla mit Vehicle Command API

[Jan W.]

Hallo Christian_90 ,
das Plugin verwendet zur Kommunikation via BLE mehrere angepasste Tools (im Binärformat) aus dem Tesla SDK. Da ich als Entwicklungsplattform ein Raspberry mit Bookworm (64-Bit) verwende, kann ich nur die Binärdateien für diese Plattform / Prozessor erstellen und zum Plugin hinzufügen.

Da Du eine andere Plattform verwendest, muss Du das selbst machen und natürlich das Know-How dafür mitbringen. Die grundlegenden Schritte sind in der Anleitung beschrieben, siehe
https://wiki.loxberry.de/plugins/teslacmd/start#installation_der_tools_aus_dem_tesla_vehicle _command_sdk

Die Kommunikation über Bluetooth erfordert entsprechende Treiber, die an die jeweilige Hardware angepasst und von der Platform bereitgestellt werden müssen. Hierzu kann ich leider nichts sagen, da ich weder Erfahrung mit Proxmox allgemein und in Verbindung mit BLE habe.

[Christian_90]

Okay, danke erstmal für deine schnelle Antwort. Ich werde einfach mal n Pi aufsetzen mit Loxberry / dem Plugin und es nochmal versuchen, vielen Dank.

Update:
Es lag / liegt an Proxmox.
Mit dem Pi ging es sofort.

[Grzesiek Gik]

Guten Abend. Ich versuche gerade, Tesla Command zu integrieren, aber es ist schwierig. Könnte mir jemand eine Testkonfiguration geben, damit ich sehen kann, wie es in der Praxis aussieht? Mich interessiert vor allem die Tesla-Wellenform und der SoC-Pegel. Den Rest finde ich selbst heraus. Ich wäre für jede Hilfe sehr dankbar. Entschuldigung, ich benutze Übersetzer. Wahrscheinlich verstehe ich das deshalb nicht so gut. Viel Spaß und beste Grüße.

[MartinS]

Hallo allerseits,

Lieber Jan, erstmal wirklich vielen herzlichen Dank für deine Super-Arbeit und das tolle Plugin!

Ich bin über zwei Fragen gestolpert als ich meine Loxone aufgeräumt habe:

Ich habe in der Vergangenheit ein ganz einfaches Geofencing mit der Loxone gemacht um zu detektieren, wenn mein Tesla nach Hause kommt (im Wesentlichen, um das Licht im Carport einzuschalten, weil der Bewegungsmelder sonst erst sehr spät reagiert). Dazu habe ich den Befehl Location_data gemacht (der noch remote mit der alten API läuft). Da die alten Befehle aber fast alle nur noch ein sehr generisches Statuspaket liefern, kann ich damit keine Koordination mehr bekommen. Der Nachfolge-Befehl (state --> location) gibt mir zwar Koordinaten, aber eben nur über BLE. Das ist dann ja witzlos ;-)

Also hab ich die ganzen Abfragen aus der Loxone rausgeschmissen und das Geofencing zurückgebaut. Nun ist mir heute morgen mein Tesla-Token abgelaufen. Das hat mich überrascht, weil das schon ewig nicht mehr passiert ist. Der Tesla war nicht angesteckt und hat dadurch auch keine Charging-Kommunikation, aber Body Controller State ist ganz sicher gesendet worden.

Das bringt mich zu meinen zwei Fragen:
1. Gibt es eine alternative Möglichkeit, die Location über Netzwerkverbindung auszulesen (also entweder die Owners-API oder die Fleet-API) oder ist es mittelristig eine Option solche Befehle auch ota zu unterstützen?
2. Wann und wie genau funktioniert die Verlängerung des Tokens? In einem Beitrag von August 24 hast du mal beschrieben, dass man regelmäßig einen Befehl absetzen muss. Stimmt das so noch? Und falls ja: Bei welchen Befehlen passiert das dann und bei welchen nicht?


Vielen Dank für eure Unterstützung!
liebe Grüße
Martin

[Jan W.]

Hallo MartinS,
nach meinem Verständnis können die Befehle für die Tesla Vehicle Command SDK / API sowohl über BLE, als auch über das Internet ausgeführt werden. Das SDK wurde wohl primär entwickelt, um auf einem sicheren Weg (mit OAuth 2.0 Token via Internet bzw. signiert mit private Key über BLE) Befehle an das Fahrzeug senden zu können. Die Befehle "body-controller-state" und danach "state" sind später hinzugefügt worden, um Statusinformationen auszulesen. Parallel hat Tesla die Fleet API weiterentwickelt, damit Telemetrie Daten per API effizent von Partnern / Drittanbietern abgefragt werden können. Ein ständiges Polling verursacht eine hohe Last auf den Tesla API Servern.

Ich hatte bei der Entwicklung des Plugins nur den Weg über BLE berücksichtigt. Es sollte aber möglich sein, den CLI Befehl "tesla-control" ohne die Option "-ble" zu verwenden. Der Aufwand liegt hierbei in der Authentifizierung. Hierfür muss "man" ein OAuth Token bereitstellen (siehe README im SDK), was aber voraussetzt, dass man einen vom Internet erreichbaren Webserver betreiben muss, dessen URL man im Authorize Request angibt. Dafür benötigt man ein Tesla Developer Account , ein öffentliches Zertifikat und muss den Callback verarbeiten. Lt. Tesla Webseite kostet die Nutzung für Personal Use mit moderatem Volumen an API Requests nichts, aber man muss evtl. Kreditkarte hinterlegen. Es kann sein, dass es im Internet mittlerweile Anbieter gibt, die so etwas übernehmen, aber denen muss man dann vertrauen und evtl. kostet es etwas.

Mir waren diese Schritte für eine Verbindung über das Internet zu aufwändig, denn mein Fokus lag darin, das Laden für mein Tesla zu optimieren. Die Verbindung über BLE bietet eine relativ sichere Kommunikation, ist dauerhaft kostenfrei und reicht dafür aus. Außerdem ist die Nutzung des Plugins ohne großen Aufwand möglich. Entweder müsste ein Nutzer des Plugins, der die API über das Internet nutzen möchte, die oben genannten Anforderungen erfüllen oder ich müsste dies für andere Nutzer über meinen Account bereitstellen. Mir fehlt die Zeit, das Plugin entsprechend zu erweitern, kann aber gerne unterstützen.

Zu Deinen konkreten Fragen:
1. Nach meinem Verständnis gibt es über das Internet nur den o.a. Weg mit OAuth 2.0, um Informationen über den Standort auszulesen. Die Owners-API wird primär noch für alte Fahrzeuge und "unkritische" Informationen bereitgestellt. Der notwendige Aufwand ist für "Personal-Use" recht hoch, aber die Fleet API ist eher für kommerzielle Nutzung von Partnern etc. ausgelegt. Für mich ist der Schritt von Tesla zu den neuen API's nachvollziehbar, denn mit dem neuen Verfahren kann die Nutzung der API auf Bereiche (scopes) beschränkt werden und auch ein Widerrufen (revoke) ist möglich. Wenn Dir der Aufwand zu hoch ist oder die Skills fehlen, gibt es vielleicht im Internet ein Service, der so etwas bietet? Viele Informationen zu dem Thema findet man im TTF Forum.

2. Ja, das stimmt noch. Das Plugin besteht aus Code, der auf einem Webserver läuft. Ohne aktive Anfragen von Clients via HTTP wird auf dem Server nichts ausgeführt. Man muss daher vor Ablauf des Tokens irgendein Befehl an das Plugin senden, damit das Plugin überprüft, ob der Token verlängert werden muss. Die genauen Zeiten habe ich nicht im Kopf. Den Code hatte ich von mariushh 1:1 übernommen. Die Kommunikation via BLE verwenden kein Token, aber die wenigen Befehle aus der alten Owners API benötigen ein Token. Die GUI des Plugins verwendet in den Tabs "Queries" und "Test queries" intern den Befehl "product_list", um die ID und VIN aller zugeordneten Fahrzeuge auszulesen. Ich bin mir nicht sicher, ob der Token noch benötigt wird, wenn per "send.php" (mit VIN) Befehle an das Fahrzeug gesendet werden.

Ich hatte schon mal überlegt, ob ich das Plugin erweitere, so dass der Token optional wird. Statt die Fahrzeuge über den o.a. Befehl auszulesen, müsste man dann die VIN manuell eingeben oder könnte über BLE nach Fahrzeugen in der Nähe suchen. Das Plugin müsste sich die einmal gefundenen bzw. eingegebenen Fahrzeuge merken, wenn man die GUI später wieder aufruft, um in den Tabs "Queries" und "Test queries" spezifische URLs zu sehen bzw. Befehle zum Test auszuführen. Ein Löschen von VINs müsste dann in der GUI natürlich auch möglich sein. Technisch benötigt die Kommunikation via BLE zwingend die VIN. Früher war bei der API nur die ID möglich. Da man über die ID per Owners-API die VIN bekommt, hatte ich im Plugin beide Varianten erlaubt. Ohne Token wäre die VIN beim "send.php" Befehl erforderlich, aber wahrscheinlich verwenden viele Nutzer des Plugins mittlerweile die VIN bei den API Aufrufen.