-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for vehicle command proxy / FleetAPI #546
Conversation
Just to clarify, this still requires a public endpoint and developer account for each user, correct? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relieved to see that the diff is so small. Thanks for putting this together.
A Tesla developer account is needed to register the app with Tesla. During this process the public key for the app is loaded from a public website. So there will be a shakeout of home use of the API because this is certainly not for everyone. |
Yes, this surprised me as well. The Fleet API is basically the same as the Owner API except it needs a token approved by both Tesla (by registering an app) and the user (by using the Tesla app). The Vehicle Command protocol is hidden away behind a proxy which understands the Fleet API. A real elegant solution that makes the transition quite easy. |
Just to clarify, I would need to set up a public facing website hosted on my Raspberry Pi, open appropriate ports for said website, and hope my home network is not compromised by the onslaught of attacks? Are there any guides you can suggest for users to safely do the above? I'm not sure if I understand how to host a public key.
Agreed... Although any assistance/guidance would be appreciated to do this with minimum 'exposure'. |
Many thanks for this @RichieB2B Just one concern around the certificate verification logic. If using the local proxy, I think this could be easily fixed with using this instead:
I believe Tesla are actively disabling segments of the owner-api as we speak, in particular the vehicles endpoint. |
You're right. The default should be |
|
|
It seems on the Owner API |
No, you just need to host the generated public key (a text file) on a public website. There is absolutely no need to run TWCManager on the public internet.
I have recorded all the steps during registration. I'll make a write up when I have more time. |
One thing nagging at me is whether we can auto-detect the best URL to use. We'll soon be forced to move all API calls over to this API and having people hardcode their geo DNS entry just feels a bit messy (and who knows what will happen down the track when Tesla changes their minds) If we were to do it, any thoughts how? I had one or two - calling a geolocation API based on source IP or maybe a DNS lookup that could be used, but an even easier option might be to make HTTPS calls to a list of the API endpoints and see which one responds fastest? Just some thoughts. |
To use the Fleet API (for older Model S/X without using a proxy) you still need to register an app with Tesla and fill in the |
One way to automate setting the correct region URL is to decode the API token using PyJWT. |
Decoding the token is not very helpful:
|
Or maybe the
|
The device publishing the key need not be the same device running TWCManager, they just need to have the same key. You could host the key on any Internet-facing device or service, so long as the domain name you use resolves to that endpoint. (A dynamic DNS name from afraid.org or similar might be sufficient, for example.) Static hosting of one file isn't exactly a big attack surface. |
According to their documentation Tesla does the verification on TLD only, not FQDN. I would not recommend using a domain name you do not own. OTOH only you have the private key so there is little chance of abuse. |
I set up a developer account (and hosted the public key on my public server) using this tutorial |
I've created an application that can help with this, for anyone comfortable spinning up a Docker container. Anyone willing to take https://github.com/MikeBishop/fleetapi-tokens for a spin and give me suggestions, I'd appreciate it. |
I would love to help but I still can't get an account set up on the Developer portal. Has anyone had issues? I usually get 'Can't onboard app'. Any suggestions? |
When you're trying to register an app, or earlier? |
At the screen where the API & Scopes is checked (Profile Information, Vehicle Information, Vehicle Commands etc.). The Submit button results in an instantaneous message - 'Unable to onboard app'. |
I've found that it rejects certain app names - try something that doesn't include the word Tesla? |
Yes, I've given that a go without success. What are you selecting from the options - 'Authorization Code and Machine-to-Machine' or 'Machine-to-Machine only'? |
That doesn't ring a bell. For scopes, I'm selecting everything. Maybe send a screenshot? If you'd prefer DM, I'm on Discord as @evequefou. |
The options - 'Authorization Code and Machine-to-Machine' or 'Machine-to-Machine only' appear if USA is selected as the country. My country selection (Australia) doesn't offer the option. |
When you click submit it tries to download the public key from your website. But I think the error message was different when it is missing. I have read somewhere the app names must be the unique. |
With this merged, are we able to update to latest version and behaviour is returned or are we required do something else in order to restore API functionality? |
No,this enables the option to use the new Fleet API. To keep using the old Owner API we need to merge #548 as well. |
My TWCManager has stopped working for API control and I hope someone could provide guidance on where to go from here... Option 1: 'Authorisation Code and Machine-to-Machine'. Option 1: Requests a domain name and callback URL. I've set up a web-server with the public key com.tesla.3p.public-key.pem being available at my domain. I can successfully test retrieve the key. I get variations of 'Unable to onboard app' or 'Unable to fulfil request, try again later' when I try to set up an account. I've done this dozens of times over a few weeks. Option 2: I appear to have had success using the option 'Machine-to-Machine'. In the Tesla Developer portal, it provides details of OAuth 2.0 Client ID and Client Secret. What I don't yet understand is whether the OAuth 2.0 Client ID and Client Secret is sufficient to continue? Is the Option 1 method with public key retrieval absolutely required? |
@ChutneyMary Here is a nice tutorial that can be used: https://shankar-k.medium.com/tesla-developer-api-guide-account-setup-app-creation-registration-and-third-party-da24aba1bddd |
Can someone provide advice on how I can point my TWCManager to a working fleet API that I'm hosting. I have set up access to fleet API through home assistant and it is now working for the home assistant integration. I have done a TWCManager/etc/twcmanager/config.json Lines 139 to 159 in f4dcb13
|
The legacy OwnerAPI will soon be dropped by Tesla. Newer cars will support only signed commands using the Vehicle Command protocol. Pre-2021 Model X/Y will move to the FleetAPI. This PR supports both. For the Vehicle Command protocol it uses the proxy supplied by Tesla.
This PR adds 3 new configuration settings:
teslaApiUrl
with as default the FleetAPI URL for North America. If this setting is missing in the config, the old OwnerAPI URL is used. This ensures that TWCManager keep working as-is with existing configurations.teslaApiClientID
is theclient_id
of the app registered with Tesla. This is needed to refresh the tokens.httpProxyCert
should point to the certificate of the proxy ifteslaApiUrl
is set to a proxy URL.Fixes #545