Neues Plugin für Tesla mit Vehicle Command API

[Jan W.]

Hallo Tesla Fahrer,

da Marius H. die Arbeit an dem bisherigen TeslaConnect Plugin eingestellt hat, habe ich die Herausforderung angenommen und Unterstützung für die neue Vehicle Command API hinzugefügt sowie einige Verbesserungen innerhalb der Benutzeroberfläche zum Senden von Testabfragen vorgenommen. Die neue Version hat einen neuen Namen bekommen (und beginnt mit Version 0.1.1), da es nach der Erstveröffentlichung nicht mehr erlaubt ist, u.a. den Namen des Autors eines LoxBerry-Plugins zu ändern. Hier ist die erste Beta-Version mit dem Namen Tesla Command.

Es ist sicherlich mittlerweile jedem bekannt, dass Tesla eine neue API, die Vehicle Command API im Oktober 2023 als Nachfolger der (inoffiziellen) Owner's API veröffentlicht hat. Fahrzeuge der Modelle S und X, die vor 2021 hergestellt wurden, unterstützen nicht das neue Protokoll, aber alle anderen Fahrzeuge werden in 2024 auf das neue Protokoll umgestellt.

Das Tesla Vehicle Command SDK enthält das Tesla Control Utility über welches Befehle entweder über Bluetooth Low Energy (BLE) oder das Internet über die Tesla Fleet API an das Fahrzeug gesendet werden können. Derzeit ist für das Plugin nur BLE implementiert und es gibt derzeit keine Pläne die Fleet API zu unterstützen. BLE bietet zwar nur eine begrenzte Reichweite, hat aber den Vorteil, dass es keine Beschränkungen in der Anzahl der API Aufrufe gibt und kostenfrei ist.

Bisher (Stand Juli 2024) gibt es in der neuen API nur Befehle zum Steuern von Funktionen, wie z.B. das Ein- oder Ausschalten der Klimaanlage, das Einstellen des maximalen Ladestroms oder zum Öffnen bzw. Schließen des Kofferraumes. Die API enthält einen einzigen Befehl 'body-controller-state', um den Status für diverse Systeme abzufragen, u.a. Schlafzustand, Präsenz, Schließzustand für Türen und Kofferraum. Insgesamt gibt es 38 Befehle, die entweder neu dazu gekommen sind oder an die neue API angepasst wurden.

Diese Plugin unterstützt daher weiterhin die bisherige (inoffizielle) Owner's API für alle Befehle, die darüber noch funktionieren, um z.B. Statusinformationen zum Fahrzeug oder einer Power Wall abzufragen. In den Einstellungen kann man für jedes Fahrzeug bzw. Powerwall festlegen, welche API verwendet werden soll:

• die alte (inoffizielle) Owner's API für ALLE Befehle. Dies ist sinnvoll sofern das Fahrzeug die alten Befehle noch unterstützt oder eine Powerwall verwendet wird.
• ein Mix aus der (inoffizielle) Owner's API um Statusinformationen abzufragen und die neue Vehicle Command API, um Befehle über BLE an das Fahrzeug zu senden. Diese werden über das Tool 'Tesla Control Utility' (tesla-control) gesendet.

Alle Daten (Statusinformationen) werden vom Fahrzeug über MQTT zurück an den Loxone Miniserver übertragen. Die Subskription dafür lautet teslacmd/# und wird im MQTT Gateway Plugin automatisch eingetragen. Beim ersten Öffnen des Plugins muss die Anmeldung bei Tesla durchgeführt werden. Dazu wird bei Tesla ein Token generiert. Das Token wird anschliessend automatisch verlängert. Nach erfolgreicher Anmeldung werden möglichen Abfragen aufgelistet, welche am Miniserver als Virtuelle Ausgänge definiert werden können.

Über das Plugin können Informationen zu den verwendeten Tesla Produkten abgerufen oder Befehle an die Tesla Produkte gesendet werden. Alle Produkte, welche in der Tesla App (Android oder iPhone) angezeigt werden können abgefragt werden. Da ich selber nur ein Fahrzeug (Model 3) habe, konnte ich bisher nur die Funktionen von einem Fahrzeug testen.

Ich habe das Plugin auf einem Raspberry PI 3 mit einem neuem Diet-PI Image (Bookworm, 64-Bit) getestet. Für die Installation bitte sowohl das Readme zum Plugin, als auch das Readme in Github durchlesen. In letzterem sind die zusätzlich erforderlichen Befehle aufgeführt, um das Plugin nutzen zu können.

Da es sich noch um eine Beta Version handelt, bitte hier Rückmeldungen und Fragen stellen.

Hier noch ein paar Hinweise für User, die bereits das alte TeslaConnect Plugin verwendet haben:

• Im Menüpunkt 'Settings' wählt man die gewünschte API aus.
• Die URLs haben sich alle verändert - siehe Menüpunkt 'Queries', aber sind sehr ähnlich zu den bisherigen URLs. Bei einigen Befehle wurden von Tesla die Parameter verändert - bitte daher alle Befehle einzeln überprüfen.
• Die neuen Befehle sind ähnlich zu den bisherigen Befehlen und erfordern weiterhin die ID für das jeweilige Fahrzeug. Das Plugin merkt sich die VIN und verwendet diese beim Senden über BLE.
• Über den Menüpunkt 'Test Queries' kann man die Befehle testen. Das integrierte Aufwecken funktioniert derzeit noch nicht (es werden nur die erforderlichen Befehle angezeigt), als einzelner Befehl aber schon.

Viel Spass damit,

Jan

[Erdloch]

Cool, hört sich spannend an - danke schonmal für die Arbeit!

Blöde Frage noch: Wie funktioniert das mit der Hardware zu BLE? Wird da automatisch das Bluetooth-Modul vom Raspberry Pi genommen, oder brauch ich da was extra?

[Jan W.]

Das eingebaute BLE 'Modul' im Raspberry PI reicht aus. Man kann optional eine externe Antenne verwenden, aber das erfordert einen Umbau und etwas handwerkliches Geschick - siehe z.B. https://geeks-r-us.de/2019/02/03/ras...-wlan-antenne/. Mein Raspi 3B+ ist Luftlinie ca. 8m entfernt, hat keine Sichtverbindung und es funktioniert mit der eingebauten Antenne auf der Platine zuverlässig.

[Prof.Mobilux]

Hi,

hast Du das Repo noch auf Privat? Ich bekomme beim Zugriff auf https://github.com/Jan21493/LoxBerry-Plugin-TeslaCmd ein 404 Error...

[Tico]

Hello Jan W. I have the same problem as Prof.Mobilux . The link to the zip download reports a 'Not Found' error.

[Jan W.]

Sorry, jetzt sollte das Repo sichtbar sein.

[Jan W.]

Ich habe die Anleitung zur Installation ergänzt: https://wiki.loxberry.de/plugins/tes...t#installation

Neben der Installation des Plugins werden zwei Tools aus dem Tesla Vehicle Command SDK benötigt. Für Raspberry PI, 64-Bit (Bookworm) werden die beiden Binärdateien bereits fertig mitgeliefert - für andere OS müssen die Tools zunächst compiliert und erstellt werden.

Zusätzlich muss noch ein Schlüsselpaar mit einem privaten und einem zugehörigen öffentlichem Schlüssel erstellt werden. Der Letztere muss dann im Fahrzeug autorisiert werden.

Alle Schritte sind mit Bildern in der neuen Anleitung enthalten.

Es gibt auch eine neue Version: https://github.com/Jan21493/LoxBerry...tags/0.1.3.zip

[blaess]

Sali Jan W.

Vielen Dank für Deine Arbeit. Ich habe heute ein Pi Zero 2 frisch mit LoxBerry aufgesetzt und danach Dein Plugin installiert. Dieser Loxberry ist nur für Tesla Command und hängt in der Garage.

Grundsätzlich hat die Installation gut funktioniert, als ich nach ein paar Stunden herausgefunden habe, dass bei DietPi Bluetooth standardmässig ausgeschaltet ist. Als ich dann Bluetooth einschalten konnte, lief auch das Pairing ohne Probleme durch.

Jetzt kann ich mein ChargePort wieder via Taster an der Wand öffnen bzw. entriegeln. Cool!

Wenn ich ein Problem finde, melde ich mich gerne.

[Jan W.]

Eine Frage zu deinem PI Zero 2: welche OS Version hast Du verwendet? Bullseye mit 32 oder Bookworm mit 64 Bit? Ich denke, dass der PI Zero 2 für einen eigenen Loxberry in der Nähe des Autos gut passt. Ich habe bisher nur mit einem PI 3B+ getestet und daher würde mich interessieren, wie gut bzw. stabil BLE und das Plugin mit dem Zero 2 läuft.

Die vom Tesla SDK verwendete go-ble Bibliothek scheint wohl nicht ganz so gut gepflegt zu sein. Vielleicht ist der BLE Code im SDK selbst nicht so gut? Ich hatte zumindest ein Problem mit dem Binary (siehe Post #9 fast am Ende).

[blaess]

Bookworm 64 Bit
Letzte Nacht hatte ich ein Problem und der Loxberry hat sich verabschiedet. Der Log Level war aber auf Debug.
Behalte es weiter im Auge.

[blaess]

Ich habe bereits zwei Feedbacks.
1) Der Token war heute Morgen schon expired (ERROR: No valid token, please login.) Eventuell wegen dem Update auf 0.1.7 letzte Nacht. Werde es weiter beobachten.
2) &force=true hinter dem Befehl funktioniert nicht um den Wage aufzuwecken (ist ja auch so dokumentiert). Was wäre echt gut wenn das auch gehen würden. Also Workaround wecke ich nun den Wage mit ble_wake auf und warte ein paar Sekunden bis der Wagen online ist.

[Jan W.]

Hallo blaess ,

danke für Dein Feedback.

Der Token war heute Morgen schon expired

Damit der Token aktualisiert wird, muss man regelmäßig Abfragen an das Plugin senden, z.B. so:

Der Impulsgeber kann z.B. auf 3600 Sekunden eingestellt werden und im virtuellen Ausgangsbefehl
/admin/plugins/teslacmd/send.php?action=vehicle_summary&vid=92XXXXXXXXXXX97
eingetragen werden. Dann sollten die Meldungen, dass der Token abgelaufen ist, nicht mehr kommen. Bin mir nicht sicher, ob das beim alten Plugin auch so war. Vielleicht ändere ich das noch, so dass ein Refresh des Tokens automatisch erfolgt. Bei einem Update sollten eigentlich alle Einstellungen inkl. eines bereits eingetragenen Tokens übernommen werden.

&force=true hinter dem Befehl funktioniert nicht um den Wage aufzuwecken (ist ja auch so dokumentiert).

Das wird noch zeitnah kommen.

Ein paar Neuerungen habe ich noch in die seit heute verfügbare Version 0.1.8 eingebaut: ich habe zu dem Befehl 'body-controller-state', der via Bluetooth mehrere Zustände des Tesla's abfragt, ein weiteres Attribut vehicleNearby hinzugefügt. Genau gesagt fügt das Plugin mehrere Attribute hinzu und wandelt Statustexte sogar in Nummern für eine einfache Weiterverarbeitung in Loxone um (Beispiele sind die u.a. Statusinformationen für Schlafmodus, Präsenz oder Schließzustand).

Hier der Output des Befehls im JSON Format:

{
  "result_code": "0",
  "result_msg": "Done.",
  "error_msg": "",
  "vehicleNearby": true,
  "vehicleLockState": 1,
  "vehicleSleepStatus": 2,
  "userPresence": 1
}

Im Menü 'Test Queries' vom Plugin kann man sich den Flow und das Ergebnis grafisch anzeigen lassen. Den Unterschied kann man gut sehen, wenn man den angezeigten 'BLE'-Befehl direkt auf der SSH Shell des Loxberrys ausführt.

Das o.a. Attribut vehicleNearby ist true, wenn das Fahrzeug in der Nähe ist und false, wenn das Fahrzeug nicht mehr via Bluetooth erreichbar ist. Der Befehl funktioniert sogar, wenn sich das Fahrzeug im Schlafmodus befindet! Tesla ist auf Github ziemlich aktiv und der Befehl 'body-controller-state' wurde erst vor wenigen Wochen zum SDK bzw. zu dem Utility 'tesla-control' hinzugefügt. Es bleibt also sehr spannend und hoffentlich fügt Tesla noch Befehle zum Abfragen des SoC (State of Charge, d.h. Ladestand des Akkus) und Status des Ladekabels hinzu. Diese können derzeit über die Owner's API weiterhin abgefragt werden, aber es wäre schön, wenn man alles über Bluetooth realisieren könnte, so dass man die alte API nicht mehr benötigt.

Da es für Abfragen über BLE kein Limit gibt, sende ich den Befehl 1x pro Minute und verarbeite das Ergebnis in einem Tracker und Status:

Der Impulsgeber triggert den 'virtuellen Ausgangsbefehl'
/admin/plugins/teslacmd/send.php?action=body_controller_state&vid=92XXXXXX XXXXX97
einmal pro Minute. Als Eingang definiert man einen 'virtuellen Eingang' mit der Bezeichnung
teslacmd_92XXXXXXXXXXX97_body_controller_state_veh icleNearby

Der Name sieht zwar etwas kryptisch aus, kommt aber durch die ID des Fahrzeuges, den verwendeten Befehl und den Parameter im JSON-Output zustande. Er wird im MQTT Gateway angezeigt, so dass er mit 'copy' leicht in die Loxone Config kopiert werden kann (evtl. mit Filter auf 'tesla' oder 'body', um den Parameter schnell zu finden):



Die Datenübertragung über MQTT ist etwas, was ich wirklich genial finde: Werte werden in die passenden Eingänge ohne umständliches Parsen übernommen! Das MQTT Gateway ändert automatisch die Werte true und false auf 0 bzw. 1 (optional), wie man in dem Beispiel gut erkennen kann, so dass die Werte im MS ganz einfach weiterverarbeitet werden können.

Man kann dem 'virtuellen Eingang' noch eine anwenderfreundlichere Bezeichnung angeben, aber ich verwende den Eingang nicht in der Visu, sondern nur den Status und daher ist das egal. Wichtig ist der Haken bei 'als Digitaleingang verwenden', damit der Tracker auf 1 und 0 reagiert. Sonst werden Werteänderungen nur als 'Analogwertänderung' angesehen und dann taucht nur die Meldung bei 'EIN' im Tracker auf.

Im Tracker sieht das Ergebnis dann so aus:



Ich hatte mit meinem Raspberry PI noch ein Problem, dass der vom Plugin verwendete Befehl 'tesla-control'' bei Abwesenheit des Fahrzeugs nach einer kurzen Zeit mit einem Fehler unbrauchbar wurde, weil das Bluetooth Interface auf dem Raspberry belegt war. Ich bin mir nicht sicher, ob nur ich das Problem hatte, denn in den 'Issues' im Tesla Github gab es keine Hinweise auf ein generelles Problem. In v0.1.8 ist ein angepasstes Binary für Raspberry PI, OS Bookworm mit 64-Bit enthalten. Ansonsten könnt Ihr das Binary auch selber neu mit diesen Infos erstellen. Bei mir läuft der Status nur im Testbetrieb, aber Ideen für eine sinnvolle Nutzung habe ich schon.

Was auch mit MQTT gut funktioniert ist die Verwendung eines 'virtuellen Texteinganges', den ich mit der Bezeichnung
teslacmd_92XXXXXXXXXXX97_vehicle_summary_state
hinzugefügt habe. Nachfolgend ist der Output aus dem o.a. Statusbaustein (Standort) sichtbar und darunter der Status als Texteingang.


So können Textmeldungen, die nur der Anzeige dienen, sehr einfach realisiert werden. Man kann den englischen Text (die Statusmeldung) sogar noch im MQTT Gateway über das Menü 'Gateway Conversions' übersetzen lassen. In diesem Fall nicht in einen Wert, sondern in die eigenen Sprache.

[Jan W.]

wegen der Beschränkung auf 5 Bilder kommt der Rest als neuer Post:

Der Loxberry bietet wirklich viele Möglichkeiten, die mit dem Miniserver (ich habe Gen 1) gar nicht oder nur sehr umständlich realisiert werden können. Einen großen Dank noch mal an die Entwickler des Loxberrys!



Damit wird die Meldung sofort konvertiert und das Ergebnis sieht so aus:



Sinnvollerweise fügt man noch ein online=wach in der Konvertierung hinzu. So jetzt reicht es mit der Werbung für den Loxberry und einigen Anwendungsbeispielen des Plugins. Der Status ist zwar noch "Prerelease", aber insbesondere Tesla Fahrer, bei denen die alte API nicht mehr für das Senden von Befehlen funktioniert, können gerne das neue Plugin verwenden und testen.

Viel Spaß dabei,
Jan

[Erdloch]

Hab das Plugin heute mal installiert und aktiviert, sieht sehr gut aus und die Kommandos funktionieren wieder, danke dafür!
Wenn die Wake up (force) Funktion dann wieder kommt, bin ich wunschlos glücklich - das Auto schläft doch sehr oft ein

[PatrickS]

Hi

Zu Beginn mal ein Danke für das neue Plugin. Ich habe es die Woche erst entdeckt und wollte es direkt ausprobieren.

Allerdings bereiten mit die Dependencies Kopfzerbrechen.

tesla-control -h

tesla-control: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by tesla-control)
tesla-control: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by tesla-control)

Dachte in Update auf Bookworm könnte helfen (DON't DO IT), da ich zu spät gesehen habe (RTFM), dass LB aktuell noch auf Debian 11 läuft und auf 12 nur in Beta und danach quasi nichts mehr lief. Habe es dann per dietpi wiederhergestellt. Jetzt bin ich wieder zurück auf Anfang.

ldd --version
ldd (Debian GLIBC 2.31-13+rpt2+rpi1+deb11u11) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Auch ein lokaler build (dietpi) schlägt fehlt: _cgo_export.c:3:10: fatal error: stdlib.h: No such file or directory

Und bevor ich jetzt weiter experimentiere, dachte ich frage mal den Experten.

Grüße
Patrick

[Jan W.]

PatrickS: Welche Hardware verwendest Du? Ich hatte ein neues DietPI Image mit Bookworm V9.7 sowohl auf einem Raspberry PI 3B+, als auch einem Orange PI zero 3 installiert. Ich hatte zwar auf dem OPI Probleme mit BLE, aber das ist eine andere Sache. Lief das Loxberry Skript bei Dir ohne Probleme durch? Bei mir klappte das erst im 2. Anlauf. Hattest Du schon versucht Golang und das Tesla SDK zu installieren, um die beiden Befehle neu zu erstellen?

[PatrickS]

Jan W. Raspberry Pi 4, installiert ursprünglich via DietPi Bullseye (Debian 11). Golang ist installiert und geht. die beiden Tesla binaries lassen sich auch nicht lokal kompilieren. _cgo_export.c:3:10: fatal error: stdlib.h: No such file or directory.
Wenn ich das richtig gesehen habe, bräuchte man für GLIBC_2.34 Booksworm (Debian 12) dann müsste ich aber auf die LB Beta setzen. Hast du dann die LB Beta bei dir im Einsatz?

[Jan W.]

Ich habe das SDK sowohl auf einem älteren Loxberry v2.2.2.2 mit Buster (32-Bit) auf Basis eines Raspberry PI 3B+ installiert, als auch auf zwei neu installierten Loxberries auf Basis eines DietPI v9.7.1 und Loxberry v3.0.1.2 mit Bookworm (64-Bit). Das eine System ist ein Orange PI zero 3, das andere ein Raspberry PI 4B+.

Sowohl auf dem alten, als auch auf den neuen Loxberries habe ich die aktuelle Version von Golang (v1.23.2) neu installiert, dann das Tesla SDK installiert. Anschließend habe ich die beiden Tools aus dem SDK ohne Fehler kompiliert.

Die Anleitung habe ich etwas überarbeitet, da man 32- und 64-Bit unterscheiden muss, um später keine Fehler beim Kompilieren zu bekommen: Installation der Tools aus dem Tesla Vehicle Command SDK

PatrickS : Der Pfad "aarch64" sieht nach 64-Bit aus, d.h. Du verwendest ein 64-Bit System und hast Golang mit 64-Bit installiert? Ich empfehle Dir, auf Deinem Loxberry Golang und das Tesla SDK neu zu installieren und der Anleitung Schritt für Schritt zu folgen. Wenn Du Fehler oder Unklarheiten findest - pass die Anleitung gerne an oder füge Hinweise hinzu.

Die Wake-Up Funktion ist übrigens im Plugin mittlerweile enthalten, allerdings habe ich die noch nicht intensiv getestet, weil ich diverse Probleme mit der Stabilität auf dem Orange PI hatte. Das liegt aber nicht am Loxberry oder Plugin, sondern aus meiner Sicht an den Treibern für BLE.

Auf dem alten Loxberry mit Buster habe ich diverse Plugins im Laufe der Jahre installiert, außerdem Node-Red und Homebridge. Da auf dem System etliche Plugins produktiv laufen, plane ich kein Upgrade, sondern eine Migration der Plugins auf den neu installierten RPI 4. An der Installation wurde schon ziemlich viel herumgespielt. Trotzdem ließen sich die Tools aus dem SDK installieren und kompilieren:
ldd --version
ldd (Debian GLIBC 2.28-10+rpi1) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
...

[PatrickS]

Habe es heute nochmal getestet.

apt install --reinstall build-essential hat die Fehlermeldung (_cgo_export.c:3:10: fatal error: stdlib.h: No such file or directory
3 | #include <stdlib.h>) beim lokale build behoben. Habe jetzt beide Binaries lauffähig.

Habe aber noch ein anderes Problem. Wenn ich einen Token und Refresh Token angebe und speichere, lädt danach das Plugin nicht mehr. Lädt sich zu Tode, scheinbar immer so lange bis der Token irgendwann ausgelaufen ist, dann kann ich einen neuen eingeben. Hatte diesen noch über evcc generieren lassen. Versuche beim nächsten Mal eine andere Methode.

Grüße

[Jan W.]

Ich verwende den Access Token Generator for Tesla (Chrome Web Store), der auch im Plugin verlinkt ist. Hatte damit bisher keine Probleme. Ansonsten den Log-Level auf "Debug" stellen und die Logs prüfen und ggf. anonymisiert mit einer genauen Beschreibung des Problems zusenden.