Neues Plugin für Tesla mit Vehicle Command API

[Jan W.]

Es gibt eine neue Version mit einigen Verbesserungen: https://github.com/Jan21493/LoxBerry...ases/tag/0.7.0

mno: Danke. Was meinst Du mit 'lange' ? Vom Senden des HTTP Befehls mit 'send.php? ...' kann einige Sekunden dauern. Es hängt von der Bluetooth Verbindung ab und ob das Fahrzeug antwortet. Bei mir dauert es i.d.R. 1 Sekunde. Über die neue Settings Seite kann man jetzt die Timeouts gut anpassen. Die Werte hängen von der Qualität der Bluetooth Verbindung ab. Ich habe das 'Connect Timeout' bei mir auf 10 Sekunden reduziert. Damit die Überprüfung, ob mein Fahrzeug da ist, 24x7 mit einem Abfrageintervall von 30s zu 100% funktioniert, habe ich eine Wiederholung eingestellt. Ein Abfrageintervall sollte so gewählt werden, dass die Befehle nicht schneller gesendet werden, als diese abgearbeitet werden können. Wenn das Fahrzeug nicht da ist, dauert es länger!

Die Werte sind nach der Abfrage sofort im MQTT Broker unter "Incoming Overview" sichtbar. Mit einem Filter auf body_controller_state_sentAtTimeLox solltest Du sofort die gesendete Zeit sehen. Alternativ auch mit dem Filter <MY-VIN>_body_controller_state der alle Parameter und Werte anzeigt, die mit diesem Befehl übermittelt werden. Ich habe die Zeit vor längerer Zeit sowohl im Klartext, als auch als "LoxTime" hinzugefügt, so dass man den Zeitstempel im MQTT Broker, als auch im MS (Darstellung als v.u) gut sehen kann.

Es ist wichtig, dass man weiß, dass MQTT nur geänderte Werte versendet! Einmalig kann man das Senden z.B. über den Menüpunkt "Delete cache" forcieren. Der bessere Weg, damit Werte nach einem Neustart des MS wieder übertragen werden, ist ein einmaliger Trigger auf einen Ausgang "Neustart", der den "Reconnect" Befehl auslöst. Siehe hier: https://wiki.loxberry.de/konfiguration/widget_help/widget_mqtt/mqtt_gateway/mqtt_schritt_fur_schritt_loxone_mqtt#beispielnach_ einem_miniserver-neustart_das_%C3%BCbermitteln_der_aktuellen_daten_ forcieren

[mno]

Hallo Jan, es hat bei mir erst akzeptabel funktioniert nachdem ich die Command und Connect Timeout Zeit auf 100 Sekunden erhöht habe. Ebenfalls musste ich die Abfrage- und Sendezyklen in der Loxone Config-Datei entsprechend erhöhen. Im schlimmsten Fall dauert es also jetzt vom Senden eines Befehles bis die neuen Werte wieder in Loxone sind 200 Sekunden also ca. 3 Minuten. Der Durchschnitt liegt bei mir derzeit bei ca. 1,5 Minuten.

Damit kann ich aber leben und möchte mich für deine detailierte Antwort und für dein tolles Plugin bedanken.

Nur zur Information:
Ich habe auch noch folgenden Foreneintrag zur Tesla PV-Ladung über BLE gefunden.

https://tff-forum.de/t/pv-management-und-ueberschussladen-ueberblick/230117/465

Dort wird auf ein interresantes Github Projekt verwiesen.

https://github.com/tesla-local-control/tesla_ble_mqtt_docker/issues/66

https://github.com/tesla-local-control/tesla_ble_mqtt_docker/blob/main/INSTALL.md

[Jan W.]

Hallo mno
Aktivitäten zur Nutzung der BLE Schnittstelle z.B. über andere Hausautomationssysteme habe ich auch wahrgenommen. Mit dem Plugin-Projekt war ich ja quasi live dabei, als Tesla die BLE Schnittstelle auch für Statusabfragen erweitert hat, so dass man dafür nicht mehr die Owner's oder Fleet API benötigt. Das Tempo und die Offenheit von Tesla, dass z.B. der Code in Github veröffentlicht wird, finde ich schon bemerkenswert. Im TFF Forum hatte ich mehrere Beiträge zum Tesla Vehicle Command SDK verfolgt, aber die Menge der Beiträge ist schon sehr hoch, d.h. man muss schon viel Zeit haben, um die alle zu lesen.

Wenn Du mit dem gefundenen Abfrageintervall und Timeouts gut zurechtkommst, dann möchte ich das Thema nicht unnötig stressen. Es wundert mich aber etwas, dass es bei Dir so lange dauert. Daher noch ein paar Infos dazu, die auch für andere User hilfreich sein können:

Im Gegensatz zu WLAN ist der Zugriff auf die BLE Schnittstelle im Raspberry exklusiv für den anfordernden Prozess für die Dauer der Verbindung. Der Loxberry als Webserver erlaubt mehrere gleichzeitige Verbindungen und die PHP und Perl Scripte / Plugins laufen parallel ab.

Damit es bei der Anforderung der BLE Schnittstelle nicht zu Problemen mit Abbrüchen kommt, weil die Schnittstelle bereits belegt ist, habe ich im Plugin eine Warteschlange eingerichtet. Der Aufruf der PHP Skripte des Plugins (hauptsächlich sendqueries.php und send.php) kann gleichzeitig erfolgen, aber die Abarbeitung erfolgt über einen Zeitstempel in einer Warteschlange. Die Funktionsweise ist ähnlich wie die Abreißmarken mit Nummern, die man bei einigen Behörden ziehen und warten muss, bis die eigene Nummer angezeigt wird. Wenn mehrere Anfragen fast zeitgleich ankommen, dann bekommt das erste PHP Skript die Schnittstelle und die anderen warten in einer Warteschlange.

Im MS sollte man die Abfragen daher nicht zu häufig machen. Der Trigger für virtuelle Ausgänge mit "send.php" erfolgt i.d.R. über Impulsgeber. Im Logging des Plugins kann man leicht prüfen, ob es Probleme mit der Abarbeitung gibt. Man sieht jetzt jedes PHP Skript mit Namen in der Liste und kann anhand der Zeitstempel sehen, wie häufig esAnfragen an das Plugin gibt. In dem einzelnen Log sind Details zu sehen. Hier ein Beispiel eines Logs für send.php: (Logging muss mindestens den Level "Info" haben):

INFO: tesla_shell_exec: Start to executing a shell command ...
tesla_shell_exec: command: tesla-control -ble -vin LRW3E... 2>&1
-> zeigt an, welcher Befehl mit welchen Parametern ausgeführt werden soll, i.d.R. tesla-control -ble -vin ...
INFO: tesla_shell_exec: use locking and queuing to get exclusive access to BLE device!
-> es handelt sich um einen Befehl, der exklusiven Zugriff für das BLE Interface benötigt
tesla_shell_exec: lock for: 30 seconds.
-> maximale Zeit die der Prozess das Interface blockieren darf und die pro Eintrag in der Warteschlange gewartet wird. Die Zeit wird über die Timeouts berechnet.
tesla_shell_exec: queue is empty - very good.
-> das sollte der Normalfall sein, dass kein anderer Prozess das Interface gerade belegt
INFO: tesla_shell_exec: Waiting time in queue for other BLE commands to finish: 0 seconds.
-> hier wird die Wartezeit insgesamt angezeigt, die dieses PHP Skript gewartet hat, bis es an der Reihe ist
INFO: tesla_shell_exec: execution time for shell command: 981.498073 milliseconds.
-> das ist die Ausführungszeit für den eigentlichen Befehl, der exklusiven Zugriff auf das BLE benötigt hat. Hier also knapp 1s. Danach gibt dieser Prozess die BLE Schnittstelle wieder frei. Wenn es keine Probleme mit der BLE Kommunikation zum Fahrzeug gibt, dann geht es i.d.R. schnell. Sollte das Fahrzeug allerdings nicht erreichbar sein, weil es z.B. unterwegs ist oder die BLE Verbindung nicht gut funktioniert, dann kann es bis zum Connection-Timeout plus ein paar Sekunden dauern.
OK: tesla_shell_exec: finished successfully!
-> hier wird ggf. der Fehlercode angezeigt, falls der Befehl ein Fehler zurückgegeben hat, weil z.B. die Kommunikation mit dem Fahrzeug ein Problem hatte

[blaess]

Ich weiss nicht wie es den anderen Usern geht, aber der Token wird bei mir nie erneuert. Grundsätzlich egal, denn die BLE Befehle funktionieren ja auch ohne.
Jan W., was meinst Du dazu?

[mno]

Schau dir mal auf der ersten Seite den Post 9 an.

https://www.loxforum.com/forum/projektforen/loxberry/plugins/437633-neues-plugin-für-tesla-mit-vehicle-command-api?p=438848#post438848

[blaess]

Perfekt, merci für den Hinweis!
War sogar in meiner Config drin, nur die Abfrage war deaktiviert. Ich Depp!

[Jan W.]

Kleine Ergänzung: die GUI benötigt noch das Token, damit man das Fahrzeug in Testqueries und Settings per selbst definiertem Namen auswählen kann. Leider kann man diese Infos nicht über BLE abrufen. send.php sollte ohne Token funktionieren, aber ich habe es noch nicht intensiv getestet.

Mein mittelfristiges Ziel ist es, dass das bzw. die Fahrzeuge auch ohne Eingabe eines Tokens, z.B. über einen Scan gefunden werden können und man VIN als auch Name manuell ergänzt oder man den Token nur einmalig zum Finden der Fahrzeuge benötigt.

Aus Kompatibilitätsgründen soll es aber weiterhin mit Token funktionieren, der natürlich für die verfügbaren anderen Befehle der Owner's API benötigt wird.

[creativo]

Nutzt jemand das Plugin zusammen mit einer Tesla Powerwall 2?

Leider lässt sich die Powerwall mit dem Loxone Tesla Plugin nur lesen und nicht schreiben.

Könnten mit dem Plugin auch Daten/Befehle von Loxone zur Powerwall geschickt werden?

[Jan W.]

creativo: ich habe nur ein Fahrzeug und kann daher keine Praxiserfahrung mit einer Powerwall. Das Plugin ist so ausgelegt, dass es auch mit einer Powerwall kommunizieren kann (via Owner's API / Fleet API, Energy Endpoint https://developer.tesla.com/docs/fle...dpoints/energy), allerdings sind die bisher im Plugin enthaltenen Befehle (in 'tesla_commands.json') nur zur Statusabfrage und nicht zur Steuerung.

Ich hatte mal einen kurzen Blick in die Doku geworfen, aber Funktionen wie "Backup Reserve" oder "Storm Mode" sind wohl eher für die USA gedacht / geeignet, als für Mitteleuropa. Bei anderen Funktionen, wie "time_of_use_settings" sendet man einmal ein komplettes JSON Formular mit vielen Parametern an die Powerwall, die dann die eigentliche Steuerung übernimmt. Lt. Beschreibung beinhaltet diese Funktion nur für die USA / Kalifornien die Anbieter von dynamischen Stromtarifen.

In den Beschreibungen finde ich weder etwas zu dynamischen Stromtarifen, wie Tibber oder Low-Level Funktionen, wie "lade die Powerwall jetzt aus dem Grid". Ich hatte den Eindruck, dass Tesla keine Anbindung an externe Steuerungssysteme wie Loxone vorgesehen hat, sondern die Steuerung ausschließlich über Powerwall und Cloud erfolgt und per App (oder API) nur die Parameter für so eine Steuerung definiert werden.

Wenn Dir ein konkreter API Befehl fehlt und Du einen Link mit den genauen Parametern sendest, dann kann ich versuchen, den Befehl zu integrieren.

[blaess]

Ja, leider ist das API leider sehr eingeschränkt. Trotzdem wäre es super wenn man die Backup Reserve einstellen könnte.
Man könnte die PW forcieren in der Nacht nachzuladen oder den aktuellen SoC zu halten wenn man nachts das Auto lädt.
Ich habe auch eine PW2. Testen wäre also kein Problem.

[Jan W.]

Ist das der Befehl "POST /api/1/energy_sites/{energy_site_id}/backup", der in https://developer.tesla.com/docs/fle...dpoints/energy beschrieben ist? Als Input gibt man "backup_reserve_percent": XX an?

[blaess]

Ja, genau dieser Wert. Kann man auch via App anpassen.

[Jan W.]

blaess: Ich habe eine neue Version erstellt und die in https://developer.tesla.com/docs/fle...dpoints/energy beschriebenen Befehle implementiert.

Abfragen für Powerwall / Energy Site

LIVE_STATUS	Retrieves current system information (e.g. solar production, grid export/import, home consumption, etc.).
SITE_INFO	Returns information about the site. Things like assets (has solar, etc), settings (backup reserve, etc), and features (storm_mode_capable, etc).
SITE_STATUS	Retrieves general system information.
SITE_PROGRAMS	Retrieves energy site program information.
SITE_TARIFF_RATE	Retrieves the user defined Utility Rate Plan used for Time-Based Control mode. It looks like this endpoint is updated every 30 minutes.
BACKUP_HISTORY	Returns the backup (off-grid) event history of the site in duration of seconds.
CHARGE_HISTORY	Returns the charging history of a wall connector.
ENERGY_HISTORY	Returns the energy measurements of the site, aggregated to the requested period.

Befehle für Powerwall / Energy Site

BACKUP	Adjust the site's backup reserve.
GRID_IMPORT_EXPORT	Allow/disallow charging from the grid and exporting energy to the grid.
OFF_GRID_VEHICLE_CHARGING_RESERVE	Adjust the site's off-grid vehicle charging backup reserve.
OPERATION	Use autonomous for time-based control and self_consumption for self-powered mode.
STORM_MODE	Update storm watch participation.
TIME_OF_USE_SETTINGS	Update the time of use settings for the energy site.

Neben den Befehlen musste ich im Code vom Plugin die Angabe von Parameter bei Abfragen ergänzen, denn die wurden bisher nicht benötigt. Die Anzeige der Energy Sites in Index.php, die Auflistung aller Befehle in Queries.php und das interaktive Testen / Ausführen von Befehlen in TestQueries.php habe ich erweitert, so dass das Plugin hoffentlich mit Powerwalls funktioniert.

Leider habe ich selbst keine Powerwall und konnte daher nur anhand von Beispielausgaben zu dem Befehl PRODUCT_LIST, die ich im Internet fand, den JSON-Output und die Parameter erahnen. Testen konnte ich natürlich auch keinen der neuen Befehle zum Abfragen der Powerwalls bzw. Ändern von Parametern. Ich bitte Euch daher, die Befehle intensiv zu testen und Fehler (die nicht unwahrscheinlich sind) mit Log-Datei im Debug-Level und einer kurzen Beschreibung z.B. per PN zuzusenden.

Vom alten Plugin übernommene Befehle wie SITE_STATUS und SITE_PROGRAMS scheint es in der neuen API von Tesla nicht mehr? zu geben. Dafür sind in https://tesla-api.timdorr.com/energy...nergy/commands diese noch vorhanden, aber einige der neuen Befehle als "undokumentiert" aufgeführt. Gebt mir gerne Feedback dazu.

[Daniel.weinrich]

Guten Abend,

gibt es das Plugin auch als einfache Lösung?
ich habe mit Putty nach der Anleitung mit Copy Paste alles installiert aber ein paar befehle führt er scheinbar nicht aus.

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

Keine Ahnung was man da machen soll. Die Anleitung nochmal anwenden hilft auch nicht, da er viele Befehle nicht ausführt, weil die Ordner bereits vorhanden sind und Daten haben.

Was muss man machen damit das Plugin einfach funktioniert wie alle anderen Plugins? oder gibt es eine andere Möglichkeit Loxone und einen Tesla z.b. via Bluetooth kommunizieren zu lassen?

Vielen Dank

[Jan W.]

Hallo Daniel.weinrich,
wenn Du ein Raspberry PI mit Bookworm (64-Bit) verwendest, dann ist es ganz einfach: das Plugin wird in der GUI des Loxberry wie jedes andere Plugin installiert und man benötigt SSH seit Version 0.5.0 nicht mehr, um Schlüssel zu erstellen, d.h. alle Funktionen sind über die GUI einfach aufzurufen.

Im Gegensatz zu vielen anderen Plugins benötigt dieses Plugin zwei Tools (Binärdateien) aus dem Vehicle Command SDK, die von Tesla als Quellcode zum Compilieren zur Verfügung gestellt werden. Die Tools sind in Golang geschrieben und die verwendeten Bluetooth Bibliotheken werden leider von den Maintainern nicht mehr aktualisiert. Aus diesem Grund gibt es mit unterschiedlicher Hardware diverse Probleme, die im Github Repo unter "Issues" zu finden sind.

In der Anleitung zum Plugin sind die Schritte beschrieben, wenn Du ein abweichendes Setup als RPI mit Bookworm (64-Bit) verwendest.

Deine Fehlermeldung deutet für mich darauf hin, dass Du ein 32-Bit OS verwendest, das Tool aber nach einer 64-Bit Bibliothek sucht, die nicht vorhanden ist.

Keine Ahnung was man da machen soll. Die Anleitung nochmal anwenden hilft auch nicht, da er viele Befehle nicht ausführt, weil die Ordner bereits vorhanden sind und Daten haben.

Leider schreibst Du nicht, welches Setup Du verwendest und welche Schritte Du genau ausgeführt hast. Sofern Du kein Loxberry auf Basis eines RPI mit Bookworm (64-Bit) hast, ist die Installation deutlich aufwändiger und man muss bei jedem Schritt aufpassen, insbesondere bei der Auswahl 32- oder 64-Bit.

Die folgenden Ordner werden installiert, wenn Du nach der oben verlinkten Anleitung Golang und das SDK installiert hast. Diese kannst Du vor einer erneuten Installation löschen (ausgehend vom Ordner /opt/loxberry):

 rm -r vehicle-command
 rm -r go
 rm -r golang

Was muss man machen damit das Plugin einfach funktioniert wie alle anderen Plugins? oder gibt es eine andere Möglichkeit Loxone und einen Tesla z.b. via Bluetooth kommunizieren zu lassen?

Den Grund warum dieses Plugin anders ist, als die meisten Plugins habe ich oben erläutert. Wenn Du es Dir einfach machen möchtest, dann kauf Dir einen RPI4, ein RPI4-CM, oder evtl. einen RPI-Zero2W, installiere Diet-PI mit Bookworm 64-Bit und darauf einen Loxberry. Das erste HW Setup verwende ich, um neue Versionen für das Plugin zu erstellen. Beim 2. HW Setup kannst Du eine externe WLAN/BLE Antenne anschließen und es läuft sehr energiesparend. Das 3. ist günstig und wurde von mindestens einem anderen User hier im Beitrag erwähnt, hat aber kein LAN (Adapter für LAN mit Pogo-Pins erhältlich).

Wenn Du das vorhandene OS und HW weiter verwenden möchtest, dann musst Du Dich etwas tiefer mit Git und dem Erstellen von Binärdateien für Golang (Compile/Build) beschäftigen. Mit aussagekräftigen Infos bei Fehlern kann ich oder ein anderer User Dir wahrscheinlich weiterhelfen.

[Daniel.weinrich]

Vielen Dank

Das sind die System Informationen vom Loxberry. es ist ein PI Zero2W.
Danke für die Hinweise. Ich werde es heute ausprobieren.

Linux

Debian - 11 (bullseye)

6.1.21-v8+

192.168.x.xxx

6 Tage, 10 Stunden, 9 Minuten, 7 Sekunden; booted 02/08/25 11:29 PM (UTC)

loxberry

Apache/2.4.62 (Debian)

7.4.33

(0%) Unknown (41%) Unknown (0%) Unknown (1.02%)

10.91%

0.15 0.12 0.10

aarch64

running: 5; zombie: 0; sleeping: 80; stopped: 0; total: 144

161

[Jan W.]

Buster ist die ältere Version, aber Du hast 64-Bit (aarch64). Eigentlich sollte das Plugin ohne Erstellen von Tools auf der Kommandozeile direkt laufen. Kompiliert, erstellt und getestet habe ich alles mit der aktuellen Version Bookwork (64-Bit). Da die Unterstützung für Buster bereits im Sommer 2024 auslief (Normal Releases), empfehle ich ein Upgrade auf Bookworm.

[Daniel.weinrich]

Vielen Dank
ich habe einen neuen RPI 3B Aufgesetzt und es Funktioniert.
Leider sitzt der RPI im Keller und hat keine Bluetooth Verbindung zum Auto.
Die Distanz sind ca 10 Meter aber durch eine Stahlbeton Decke.
Gibt es einen USB Bluetooth Adapter der mit dem Plugin gut Funktioniert?
Das wäre die Einfachste Lösung, da der RPI im Keller sitzen muss um TTS via Kabel zu ermöglichen.
Alternative 2 einen RPI Zero2w näher am Auto installieren.
Aber ein RPI wäre für mich einfacher.