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.

Tesla Model S REST API Authentication Flaws

Article here: Tesla Model S REST API Authentication Flaws - Programming - O'Reilly Media

What do you programmer types think about this article?

If you are not a programmer, the takeaways are:

* If you don't use a third-party add-on application, there's nothing to see here
* Be careful about giving your email address/password to any third-party service

If you are a programmer, see the long discussion in the other thread.
 
Perhaps we should maintain a list at the top of this thread for the latest Tesla REST libraries for each programming language. Sounds like we have C#, Java, JavaScript, and Python so far. That and basic curl commands.

The API: Tesla Model S REST API
Python: PyTesla
JavaScript: TeslaMS
Java: TeslaClient
C#: ???
Perl: ???

FWIW, I finally got around to specifying the MIT license for the TeslaClient project. Until now all the sources had my default header including "all rights reserved." This change was also made to the VisibleTesla project.
 
Do we have a mapping of the 'car_version' data (i.e., build number) to the user visible number?
1.33.61 is "4.5 (build 61)
1.35.96 is "5.0 (build 96)
1.35.102 is "5.0 (build 102)

I don't believe so, at least not programmatically, you're likely going to need a mapping table of some sort to xx.yy in xx.yy.zz.
 
What do you programmer types think about this article?

>200 posts on that subject over here.

StingerBob: you don't need to be a programmer to learn this rule of thumb -- once something is written about in the media there are already over 100 posts on it in TMC (and the article probably quotes them out of context). Welcome to the source...
 
It appears that running streaming under 5.0 keeps the car always awake... does anyone know otherwise, or have a workaround?
This is what I expected as the mobile app takes a good 45 seconds to wake up when the car is asleep anyway.

I was dreading running into this problem.

My thoughts for a workaround is to have some kind of button I can press (on a web page on a phone and/or tesla browser) to turn on and off streaming so that I'm only doing it while charging or driving - but that's very far from ideal obviously. I don't think there is currently any other way to do it otherwise.
 
It appears that running streaming under 5.0 keeps the car always awake... does anyone know otherwise, or have a workaround?
This is what I expected as the mobile app takes a good 45 seconds to wake up when the car is asleep anyway.

I was dreading running into this problem.

My thoughts for a workaround is to have some kind of button I can press (on a web page on a phone and/or tesla browser) to turn on and off streaming so that I'm only doing it while charging or driving - but that's very far from ideal obviously. I don't think there is currently any other way to do it otherwise.

It probably true that continuous streaming keeps the car awake since it's necessary to call wake_up once in a while to get new streaming tokens (they expire every 15 minutes).
I am hopeful that there will be a way to check if the car is asleep and purposely avoid waking it back up.
That would mean that an intelligent streaming data collector could just pause data collection while the car sleeps and resume only after an external event causes the car to come alive again.

All I need is 5.0 firmware and some way to test if the car is asleep without walking it up.
 
All I need is 5.0 firmware and some way to test if the car is asleep without walking it up.

I believe the REST API returns a special value when it's sleeping -- at least unavailable. I just killed the streaming server so that I can get that information for you (I'll report back after it goes to sleep).
 
I believe the REST API returns a special value when it's sleeping -- at least unavailable. I just killed the streaming server so that I can get that information for you (I'll report back after it goes to sleep).

If it returns 503 Service Unavailable that would be great! If it just does an client side http timeout then it's indistinguishable from all the other times the Tesla servers are down or unresponsive for some reason.
 
If it returns 503 Service Unavailable that would be great! If it just does an client side http timeout then it's indistinguishable from all the other times the Tesla servers are down or unresponsive for some reason.

You're told if it's offline:

onyx:101:~>tesla charge_state
{
"error": "vehicle unavailable (408)"
}

...but crap, that appears to wake it up...

Next time it goes back to sleep I'll see what the /vehicles call shows for "state". That might be what we can check without waking it up.
 
You're told if it's offline:



...but crap, that appears to wake it up...

Next time it goes back to sleep I'll see what the /vehicles call shows for "state". That might be what we can check without waking it up.

and HTTP 408 is just a timeout so it doesn't even tell you the car is sleeping, just that the connection timed out. I think that could be for other reasons.
 
Ahh, there we go... Call /vehicles from the REST API...

[
{
"color": null,
"display_name": null,
"id": "(suppressed so the 'spectacular' API failure can't steal my car)",
"option_codes": "MS01,RENA,TM02,DRLH,PF01,BT85,PPSR,RFPO,WT21,IDCF,IZMB,TR01,SU01,SC01,TP01,AU01,CH01,HP01,PA00,PS01,AD02,X001,X003,X007,X011,X013,X024,X019",
"state": "asleep",
"tokens": [],
"user_id": "(suppressed so the 'spectacular' API failure can't steal my car)",
"vehicle_id": "(suppressed so the 'spectacular' API failure can't steal my car)",
"vin": "(suppressed so the 'spectacular' API failure can't steal my car)"
}
]

...and the car remains asleep...

- - - Updated - - -

and HTTP 408 is just a timeout so it doesn't even tell you the car is sleeping, just that the connection timed out. I think that could be for other reasons.

Well, it comes back instantly with that 408, so it's not like it even tries... and it should be made clear that's a JSON-formatted error reply from Tesla's API server, that's not an HTTP error from cURL.
 
Last edited:
Nice! I'm pretty sure I've seen that "asleep" state as well before. But couldn't remember where I saw it.

- - - Updated - - -

I think the teslams streaming program needs a governor of sorts that checks the car state every so often (once every minute or two maybe?) and if it is not moving and in park for a certain amount of time, it stops streaming, and resorts to just checking the car state in a little bit longer polling loop - then if the state goes into "asleep" that longer polling loop maybe gets even longer, and then goes back to streaming if it goes out of the asleep mode.


Or something along those lines.

Since I have 5.0 I can tinker with it and try and come up with something.
 
...and if it's not charging / charger isn't active...
Yes of course. So to summarize, it's just an extra thing that watches at a higher level and stops streaming when it's asleep and starts again when it's not asleep.

Well maybe slightly more complicated than that, as it has to stop streaming presumably to enable the car to go to sleep in the first place.
 
Yes of course. So to summarize, it's just an extra thing that watches at a higher level and stops streaming when it's asleep and starts again when it's not asleep.

Well maybe slightly more complicated than that, as it has to stop streaming presumably to enable the car to go to sleep in the first place.

It doesn't need to stop streaming, just stop calling wake_up to get new tokens. Sounds like a race condition. How long does it take for the car to go to sleep?
 
It doesn't need to stop streaming, just stop calling wake_up to get new tokens. Sounds like a race condition. How long does it take for the car to go to sleep?

Haven't timed it specifically, but you can see that it's less than 25 minutes - my post at 6:31 pm was when the car woke up from my calling charge_state, and my post at 6:54 had it asleep again. I suspect it's 15 or 20 minutes but haven't timed it. I'll start that now and edit this when I get it done.

Just for reference, there is another state called "waking" that is reported as the car is requested to wake up...

Thu Aug 29 20:39:17 CDT 2013
"state": "asleep",
Thu Aug 29 20:39:48 CDT 2013
"state": "waking",
Thu Aug 29 20:40:19 CDT 2013
"state": "online",

- - - Updated - - -

The car still hasn't gone to sleep, but the tokens have expired. So it is likely that the streaming server is going to have to do some data comparisons to determine whether to keep the tokens refreshed or not... or the car will never go to sleep. That also presents a problem for collecting charging data, as charge_state wakes the car up and/or keeps it awake.

Thu Aug 29 21:06:31 CDT 2013
"state": "online",
"tokens": [],
 
The car still hasn't gone to sleep yet. I'll keep watch over it and see if I can figure out some type of pattern.

EDIT: My wife left the key in the car, so all of my experimentation should be thrown out.
 
Last edited:
Lullaby, and good night, you are daddy's delight
I'll protect you from harm, and you'll wake in my driveway

Go to sleep, little car, think of AC and DC.
Go to sleep, little car, think of supercharging fast.
Go to sleep, little car, think of free solar energy.
Hush, darling one, sleep through the night
Sleep through the night
Sleep through the night
 
Lullaby, and good night, you are daddy's delight
I'll protect you from harm, and you'll wake in my driveway

Go to sleep, little car, think of AC and DC.
Go to sleep, little car, think of supercharging fast.
Go to sleep, little car, think of free solar energy.
Hush, darling one, sleep through the night
Sleep through the night
Sleep through the night

Ahem... Can one say Intervention?! :biggrin: