Tesla Integration via official vehicle-command library

[lgleim]

Is your feature request related to a problem? Please describe.
Tesla has announced deprecating HTTP REST APIs, which is expected to affect owners starting in 2024 and will likely break unofficial APIs and their wrappers like the currently used https://github.com/bogosj/tesla library.

Describe the solution you'd like
Reimplement Tesla Vehicle support via the official https://github.com/teslamotors/vehicle-command library.

Describe alternatives you've considered
Continue using unofficial APIs or hope they will (or make them) update to wrapping the official Tesla API.

Additional context
https://developer.tesla.com/docs/fleet-api#2023-10-02-tesla-vehicle-command-sdk

[andig]

Afaikt using the Tesla API requires you to run your own Domain and provide a certificate. That does not sound doable for most users. Is this perception wrong?
That said, I‘ve applied for developer account but have not received approval…

If anyone has access and time to spend I‘d be happy to support a PR.

[lgleim]

It does not require Domain name nor Domain certificate unless you decided to run the included REST proxy on a public domain.

The public-private key pair talked about in the README is directly used to sign (and possibly encrypt) messages similar to how PGP uses cryptography. The library even includes its own keygen tool to make key generation (and subsequent registration in your Tesla vehicle's keychain) simple.

Some developers may be familiar with Tesla's Owner API. Owner API will stop working as vehicles begin requiring end-to-end command authentication.

Looks like Tesla is fully depreciating public REST servers in favor of their new protocol.

Tesla vehicles now support a protocol that provides end-to-end command authentication.

The https://github.com/teslamotors/vehicle-command directly implements this protocol

This Golang package uses the new protocol to control vehicle functions, such as climate control and charging.

The golang library can either be used directly, via a command-line tool, or via a local REST service (which both use the library internally).

Looks like all newer Tesla models will need to be switched to the new protocol. Only:

Pre-2021 Model S and X vehicles will continue to support the full REST API, and do not support the new protocol.

[andig]

Sounds good. Unfortunately I cannot login the developer portal. Does Tesla only allow this for owners? I would need credentials plus certificate associated with some Tesla to do some prototyping...

[andig]

It does not require Domain name nor Domain certificate unless you decided to run the included REST proxy on a public domain.

Its still unclear to me how this should work from user side. Where does the user obtain the token? Does he need to register a developer account?

Ist aber vllt. einfach wenn wir auf Deutsch reden ;)

[lgleim]

Klar. Von der Nutzerseite würde das so aussehen, dass man sich ein public/private key-pair generiert und den public key direkt in der keychain des Teslas hinterlegt. Also genauso wie man das z.B. mit einem SSH public/private keypair macht. Mit dem private key kann der lokale client dann Nachrichten signieren (und in der Theorie auch verschlüsseln, dafür würde man aber normalerweise dann aus Effizienzgründen symmetrische Verschlüsslung nutzen).

Der oauth token wird zusätzlich gebraucht. Das ist quasi unverändert genauso wie bis jetzt. Allerdings ist natürlich eine wichtige Frage ob in Zukunft nur noch Tesla's 3rd party tokens akzeptiert werden, die man über das Developer portal anlegt. Details dazu hier unter Setup.
Leider sieht das aber nach einem bevorstehenden Cash-grab auf seiten von Tesla aus.

Ich schreibe im Anschluss mal eine Mail an fleetapisupport@tesla.com und frage nach Feedback wie die in Zukunft mit open source Projekten und inoffiziellen oauth tokens umgehen wollen.

[andig]

Der oauth token wird zusätzlich gebraucht. Das ist quasi unverändert genauso wie bis jetzt.

Das klappt leider schon nicht- den "alten" access token mag er nicht:

cannot create vehicle 'tesla-vehicle-command': client provided OAuth token with invalid audiences

Mir ist unklar, wo ich ein Token mit den richtigen Audiences her bekommen würde? Falls Du irgendwas laufen hast gerne Code ;)

[lgleim]

In der Tat muss man sich leider nun einen Partner Account registrieren, bekommt dann einen partner OAuth token, und muss dann einen generierten public key unter einer eigenen (partner) domain hosten.
Zusätzlich braucht es dann noch einen mit dem partner-token erstellten client token, der dann zugriff auf die tatsächliche vehicle API gibt (dafür braucht es dann aber keinen server mehr). Im Ergebnis müsste entweder jeder User zukünftig durch den ganzen Prozess laufen, oder aber EVCC.io als Telsa Partner agieren...

[lgleim]

Konkrete Möglichkeit bei der jeder Nutzer unabhängig bleibt könnte wahrscheinlich wie folgt aussehen:

1. User registriert einen Partneraccount unter https://developer.tesla.com/ und erhält clientID und clientSecret. Zusätzlich nutzt er seinen Github Account (im Folgenden Github username "mynick").
   1. App name, Description und Purpose nach Belieben
   2. origin, redirect und return URL werden alle auf https://mynick.github.io (oder eine variation) gesetzt (dient als Domain des Partners)
   3. Als API scope wird Vehicle Charging Management ausgewählt
2. Mittels tesla-keygen create (oder ssh-keygen etc.) wird eine public/private keypair erzeugt
3. Der public key wird wie hier beschrieben auf github pages unter https://mynick.github.io/.well-known/appspecific/com.tesla.3p.public-key.pem abgelegt
4. Der User generiert nun einen partner authentication token
5. Mit dem partner token wird nun der public key (https://mynick.github.io/.well-known/appspecific/com.tesla.3p.public-key.pem) via https://developer.tesla.com/docs/fleet-api#register in der Tesla Cloud registriert.
6. Der User geht nun auf https://tesla.com/_ak/mynick.github.io was die Tesla App öffnet und um nach Bestätigung den public key von mynick in den keystore des Teslas von User importiert. Alternativ geht dies scheinbar auch lokal via Bluetooth
7. Ab dann können anscheinend mit dem lokalen private key (in Schritt 2 erstellt) Befehle per Bluetooth direkt an das Auto gesendet werden. Beispiel aus der README von vehicle-command:
   tesla-control -ble -key-file private_key.pem lock
   Falls das wirklich so funktioniert sollte der Private key in jedem Falle nicht zwischen evcc usern geteilt werden (macht auch irgendwie Sinn für einen private key)
8. Um Befehle nicht nur per Bluetooth sondern auch via IP senden zu können muss zusätzlich ein zweites customer OAuth token erzeugt werden, vermutlich mit scope vehicle_charging_cmds. Gemeinsam mit customer token und private key sollten dann endlich auch Befehle direkt Internet gesendet werden können.

Soweit die Theorie. Prinzipiell auch alles automatisierbar. Aber...

[lgleim]

Noch ein Nachtrag - meine Vermutung ist, dass per Bluetooth Key Enrollment & Kontrolle komplett ohne Cloud und ohne PartnerID möglich ist. Das ist neu und wäre ebenfalls eine interessante Alternative.

[RTTTC]

Sounds like a nightmare..
I hope it will be much simpler and easier in the end.

[andig]

Ich glaube (tm) das geht einfacher. Nur der Partner braucht die keys. Ich bin beim Partnerseite einrichten und roundtrip bauen. Leider harte Hürde von Tesla- einmal eingerichtet lässt sich GAR NICHTS mehr ändern.

Depends on teslamotors/vehicle-command#11

[vtml]

It looks like the new Tesla vehicle command sdk can send commands via Bluetooth if the hardware is close enough to the car.