Model S REST API

[PCMc]

I have my refresh token logic fully integrated into my overall routine with it tracking token expiration and automatic renewal.

Does anyone know of any reason to save the short refresh token that is provided in Step 4 along with the access token?

For my current implementation I'm saving the full step3 response/token information to a separate file so it can be read back in when needed to do Step 5/Step 4 to get new access token. I'm already saving the full token response from Step 4 to a file so I can reuse it any time I need to stop and restart the program.

I've debated replacing the unused Step 4 short access token in the Step 4 response with the Step 3 long refresh token. This way I'd have just a single token file saved that has everything, current access token, created and expires in timestamps, along with the long refresh token. Each time I refresh Step 4, I'd just transfer the Step 3 long access token over. The purist in me would say this is more efficient, eliminates one set of file read/writes and one file to access, but the other side of me says 'what difference does it make, don't mess with it' given it works.

 

[apacheguy]

One thing that I found a bit puzzling is that you often have to retry step 2 multiple times in order to retrieve the code. I see @PCMc has an automatic retry loop that I’ll need to implement in my code. Anyone understand why Tesla’s API can‘t simply respond on the first try?

 

[apacheguy]

I'm using the above PHP code which has been updated for the new SSO auth scheme. It fails on Step 2 (obtain auth code). As far as I can tell, it correctly retrieves the "hidden" form inputs and cookie value, but a subsequent call to the /oauth2/v3/authorize endpoint returns HTTP 403 (forbidden) instead of HTTP 302 (redirect).

Several other users commented on github that it recently stopped working for them so I guess I'm not alone. Anyone figure out a fix?

*** SOLVED ***

Things I learned:
1. There are multiple cookie values that are passed to the client in step 1. All cookie values must be set for subsequent requests.
2. It is helpful to have a retry loop on step 2 as you will often receive HTTP 403 for no apparent reason.
3. The cookies must be passed in steps 3 and 4. For some reason, the individual who wrote the PHP code I referenced only decided to pass the cookie in step 2.

 

[markb1]

*** SOLVED ***

Things I learned:
1. There are multiple cookie values that are passed to the client in step 1. All cookie values must be set for subsequent requests.
2. It is helpful to have a retry loop on step 2 as you will often receive HTTP 403 for no apparent reason.
3. The cookies must be passed in steps 3 and 4. For some reason, the individual who wrote the PHP code I referenced only decided to pass the cookie in step 2.

I didn't find it necessary to pass any cookies for step 3 and 4, though I suppose something could have changed since I did my initial login.

 

[goRt]

I didn't find it necessary to pass any cookies for step 3 and 4, though I suppose something could have changed since I did my initial login.

I generate my tokens away from where I refresh and therefore also have no cookies in play

 

[PCMc]

I have a question about anyones experience with a couple of the values returned by the charge state API call.

I logged data today for a charging session with my Gen1 UMC at 240V / 40 amp. Everything with the actual charging worked fine and I logged basic charging parameters through my charge such as SOC, reported rated miles, etc.

One looks odd are the values returned for "charge_energy_added" and "charge_miles_added_rated". Both values report 0 for about the first 20 minutes. At that point both values start counting up, with the miles_added value tracking 1:1 with the incremental range reported through the end of the charging session. Net of this is that when charging completes both values are under reported by the amount of miles/energy added over that first 20 minutes of charging.

Anyone else ever notice anything like this? As I've commented in other posts, I'm converting over from VisibleTesla finally, gradually building up my own logger to capture similar data. That's where I was looking at the "charge_energy_added" value today to see how it equates to the value that VT would report when I'd generate a charging sessions report.

Probably be about a week before I'd plan to charge again and have another dataset to see if today's experience is consistent or a fluke.

Thanks!

I'm still curious if anyone has ever paid attention to the "charge_energy_added" and "charge_miles_added_rated" values from the call for the charge data.

I've continued to notice that the values do not increment until partway through my charging session.

For reference, I have my charge routine set to start charging at SOC = 51 and stop at SOC=70. It's done this multiple cycles now over the past month. The data is very consistent that the values only start to increment when SOC reaches 65. From 65 to 70 the charge_miles_added_rated matches with increase in the Range value.

What I just realized is the value of 65 just happens to match the ending SOC from the last time I supercharged in early January.

Anyone else noticed behavior like this? I won't be back in the US for over a month so am not able to test it out to see if I go supercharge to a different value is the parameter somehow resets.

 

[JDOhio]

I posted a Postman solution for Step 1 to 4 (outlined excellently here). The Postman collection and environment are here. Reviewing the repository README.md is recommended. Feedback welcome!

Joe

 

[brianman]

Step 1 just seems to time out for me no matter what I throw at it.

Using C#.

Postman requires a login now so I haven't looked at Joe's sample yet.

 

[brianman]

Step 1 just seems to time out for me no matter what I throw at it.

Using C#.

Postman requires a login now so I haven't looked at Joe's sample yet.

Update: Well that's interesting. My latest change adjusted the base64 encoding code_challenge to be "url friendly" and suddenly I'm getting html back instead of non-response. FYI for others that run into this.

Update: Well. It worked once. Timing out again on 2nd+ attempts. Sigh.

 

[PCMc]

Update: Well that's interesting. My latest change adjusted the base64 encoding code_challenge to be "url friendly" and suddenly I'm getting html back instead of non-response. FYI for others that run into this.

Update: Well. It worked once. Timing out again on 2nd+ attempts. Sigh.

If you've pinged it too much in a short period of time it will lock you out. That can be a problem when you're trying to debug. You may find you need to wait 30 minutes after a failed attempt before you try it again. I recall there being comments about this earlier in this thread.

 

[brianman]

If you've pinged it too much in a short period of time it will lock you out. That can be a problem when you're trying to debug. You may find you need to wait 30 minutes after a failed attempt before you try it again. I recall there being comments about this earlier in this thread.

Stage 1 is slow but seems to be finally working. Stage 2 is giving me the connection closed issue. I'm trying switching to the TeslaAuth nuget package, but it's failing as well.

It's starting to feel like I may be better off seeing a full Fiddler trace of a valid interaction rather than shooting in the dark.

If Tom Hollander is on here, I'm seeing "A task was cancelled" from TeslaAuth. Not super helpful information.

using TeslaAuth;

...
   
var authHelper = new TeslaAuthHelper("MyApp");
var tokens =
    await authHelper.AuthenticateAsync(email, pass, null, TeslaAccountRegion.USA);

Update: Adding these 4 lines (copied from the test in the repository) seems to make it work:

        ServicePointManager.FindServicePoint(new Uri("https://auth.tesla.com")).ConnectionLeaseTimeout = 60 * 1000;
        ServicePointManager.FindServicePoint(new Uri("https://auth.tesla.com")).ConnectionLimit = 10;
        ServicePointManager.FindServicePoint(new Uri("https://owner-api.teslamotors.com")).ConnectionLeaseTimeout = 60 * 1000;
        ServicePointManager.FindServicePoint(new Uri("https://owner-api.teslamotors.com")).ConnectionLimit = 10;

 

[JDOhio]

Greetings!

When I refresh my token, the information returned says its valid for 8 hours. Is that a change? Do I have to run the whole authentication process to get a token that is valid for 45 days?

Thanks!
Joe

 

[goRt]

Greetings!

When I refresh my token, the information returned says its valid for 8 hours. Is that a change? Do I have to run the whole authentication process to get a token that is valid for 45 days?

Thanks!
Joe

That sounds like the bearer token that then needs converting into a refresh token

 

[markb1]

That sounds like the bearer token that then needs converting into a refresh token

It needs converting into an access token, which comes along with its own (useless) refresh token.

Specifically, step 4 needs to be done after refreshing: Authentication

 

[goRt]

It needs converting into an access token, which comes along with its own (useless) refresh token.

Specifically, step 4 needs to be done after refreshing: Authentication

The refresh token is no t useless, I use it in step 3 every 45 days

 

[markb1]

The refresh token is no t useless, I use it in step 3 every 45 days

There are two things labelled as refresh tokens, and the one from the owner api server has no use that I’m aware of.

 

[goRt]

There are two things labelled as refresh tokens, and the one from the owner api server has no use that I’m aware of.

So the refresh token in step 4 (the point we were discussing) remains correct and can be used at any point in step 3

 

[markb1]

So the refresh token in step 4 (the point we were discussing) remains correct and can be used at any point in step 3

Per Authentication :

This uses the SSO refresh_token from Step 3 above to do an OAuth 2.0 Refresh Token Grant. This does not work with the refresh_token provided by the Owner API. Those have no use currently and should be discarded.

The refresh token received in step 3 is the useful one. The one received in step 4 is not.

 

[brianman]

TeslaAuth nuget package

Well, that was working for about a month and a half. Sometime yesterday HTTP403 became the apparently permanent respond from login attempts. Sigh.

 

[GPinzone]

I was using an User-Agent string that was causing issues like that. You might want to see if changing that will help.