Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Model S REST API

This site may earn commission on affiliate links.
Came here to see if anybody else is having a "Error parsing response to oauth token request Error: login failed" with the teslacmd scripts. Been working for the last year and suddenly stopped working at 2:45pm (central) August 29th.

graph_image.png


Anybody else?
 
First, many thanks to SG57 for posting the info on the new 'actuate_trunk' command for Model 3. For the life of me I could not figure out why 'trunk_open' would not work (error 400), and that new command did the trick.

Related, in the 'vehicle_state' query, is there a meaning for the 'ft' (front trunk) and 'rt' (rear trunk) numeric values? For my Model 3, these values are 0 when the trunks are closed. But when open, 'ft' = 16 and 'rt' = 32. Being both powers of 2, that looks like something perhaps bit-mapped. Not sure why the numbers are different for trunk and frunk. Does anyone have an idea of what the bits (or numbers) mean?
 
  • Like
Reactions: SG57
Came here to see if anybody else is having a "Error parsing response to oauth token request Error: login failed" with the teslacmd scripts. Been working for the last year and suddenly stopped working at 2:45pm (central) August 29th.

View attachment 335591

Anybody else?

I pulled the latest teslams.js from github and it's working now... Not sure why my npm update didn't update that package.
 
Hi foks,
I am a owner from Austria and I used the API with php for many months without a problem now. Since a while I do not get any response back but the text "our servers are waiting for a supercharger spot.."
I dug through the forum and found only the possible solution by adding "headers". But unfortunately I am no programmer and only used the standard php codes shown on Apiary. I don't know who to do this. Can someone please tell or explain what I have to change to make this working for me again?

Greetings
Gert
 
My id, id_s, and vehicle_id are all different.

Interestingly, id_s = str(id + 1)

If you're using JavaScript, which uses double-precision floating-point format, Number.MAX_SAFE_INTEGER is 9007199254740991, so if your vehicle's ID exceeds that, your ID might become misrepresented, and has to defer to the String format as a fallback, i.e. id_s will always work.

For example, in node REPL or browser console, try putting something like

[1,2,3,4,5,6,7,8,9].map(n => n + Number.MAX_SAFE_INTEGER)

Hope that made some sense!
 
Hi foks,
I am a owner from Austria and I used the API with php for many months without a problem now. Since a while I do not get any response back but the text "our servers are waiting for a supercharger spot.."
I dug through the forum and found only the possible solution by adding "headers". But unfortunately I am no programmer and only used the standard php codes shown on Apiary. I don't know who to do this. Can someone please tell or explain what I have to change to make this working for me again?

Greetings
Gert

post some of your code minus any sensitive information (tokens)

I was able to get my javascript client to work by adding a User-Agent to the request header. When your code makes a request, headers can optionally be sent as extra data (for example, when you use a browser and visit a website, the browser will send a User Agent header with the browser's name and version). When you make an API request via code, you have to programmatically add any optional headers. For now it seems Tesla's API doesn't care about the value of the user-agent, and is just checking for its presence.
 
UPDATE: received help from a buddy who helped me out:

The php-code of Apiary

curl_setopt($ch, CURLOPT_HTTPHEADER, array(
"Authorization: Bearer {access_token}"
));

has to be replaced by

$headers = [

"Authorization: Bearer " {access_token},

'User-Agent: Mozilla/5.0 (Linux; Android 9.0.0; VS985 4G Build/LRX21Y; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/58.0.3029.83 Mobile Safari/537.36',

'X-Tesla-User-Agent: TeslaApp/3.4.4-350/fad4a582e/android/9.0.0'

];

curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);


THAT'S WORKING FOR ME NOW
 
As always looking forward to the post from @SG57 with your findings of the new v9 firmware API endpoints. No pressure!
No pressure!

Last app update I dug into was 3.5.0 and it contained the new message center endpoints. These are important updates/notifications designated for your Tesla account, nothing too fancy.

Looks like 3.6.0 has a few more endpoints here:
  • Media Player
    • Toggle Playback
    • Previous/Next Track
    • Previous/Next Favorite
    • Volume Up/Down
  • Schedule / Cancel Software Update

  • Navigation Request
I can dig into the technical details on these here soon, but they're all pretty straight forward.
 
Well, since I can't edit the OP anymore, I guess I'll throw this down here in thread...

I renamed my repo to the more broad and generic tesla-api: timdorr/tesla-api

I'm also moving my docs over to Gitbook. This is so they can be plain Markdown, not the somewhat confusion API Blueprint format. Those are now available here: Introduction - Tesla JSON API (Unofficial)

I'm going through and filling them out now. I'll be doing my best to keep things up to date in the future. As per usual, everything is open on GitHub, so if you want to contribute to the documentation effort, feel free!
 
I've noticed this, too. Did you ever find any solution? What does that app do in this situation?
Unfortunately no. My work around so far is to cache every single streaming token received then attempt to use each as needed, pruning ones that are invalid from the cache and refreshing to get the latest tokens as a last resort. This actually works quite well reducing errors dramatically.

Still, the streaming tokens served 4 months ago were very reliable, not sure what happened but definitely Tesla server-side since the official Tesla app can break quite easily on its own due to this. The official app just uses the first streaming token blindly. If it receives an unauthorized response it retries immediately. It does try to refresh streaming tokens as well but that's not doing anything special either just calling the '/data' endpoint to get the latest tokens.

-

On this topic of streaming tokens, curious if anyone has a Model 3 can you confirm you've gotten the telemetry/location streaming connection to work lately?

Normally an invalid streaming token will return a data error "client_error" "Can't validate password. " A successful streaming token would return a data update with data. For model 3s (maybe others?) when using what I expect to be a valid streaming token for an awake vehicle I'm only ever seeing a data error "vehicle_disconnected" "disconnected". Makes me think the streaming token is valid but it immediately closes the connection?
 
Last edited:
Error parsing response to oauth token request
Error: login failed
at /usr/local/lib/node_modules/teslams/examples/teslacmd.js:241:12
at report (/usr/local/lib/node_modules/teslams/teslams.js:25:13)
at Request._callback (/usr/local/lib/node_modules/teslams/teslams.js:83:105)
at Request.self.callback (/usr/local/lib/node_modules/teslams/node_modules/request/request.js:185:22)
at Request.emit (events.js:182:13)
at Request.<anonymous> (/usr/local/lib/node_modules/teslams/node_modules/request/request.js:1161:10)
at Request.emit (events.js:182:13)
at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/teslams/node_modules/request/request.js:1083:12)
at Object.onceWrapper (events.js:273:13)
at IncomingMessage.emit (events.js:187:15)


Every time
 
This is a bit off topic but does anyone know the format of the message the Tesla Mobile app receives from Google Maps via the Share feature?

For Android, my guess is that the Tesla activity is started with a "geo" URI. That's at least how you share a location to Google Maps, so it's probably similar the other way around. You could easily verify by writing a simple app, share a location from Google Maps to it, and see what you get. (I'm sure it's documented somewhere, too!)
 
  • Informative
Reactions: Deslah and aesculus
This is a bit off topic but does anyone know the format of the message the Tesla Mobile app receives from Google Maps via the Share feature?
Staring at the official app's Android source, they use the common Map intent filter with the "geo" URI scheme.

Looks like they also listen for plain-text/v-card under the SEND action as well, perhaps parsing plain text or v-card contact addresses for navigating to.
 
Thanks @markb1 and @SG57. This looks solid. Now I guess I will have to wait and see if you can send any more than one destination at a time. Not sure if V9 has the promised waypoints or not.

Personally it still looks like stacking the calendar with locations is a better route than the direct feature, at least for multi-stop trips. And of course the route you choose on the map may not be the route the car picks either.