Model S REST API

[widodh]

Would it be a good idea to put together a simple .war or equivalent with a web frontend? We could distribute the war around here and folks can deploy in a container on their home machines if not host it publicly. My UI/UX skills are rusty but, I'll work on this too.

I'm working on a PHP-class which can do some cool stuff.

Although I don't have a car yet, the API seems very straight forward, so just some cURL magic in a PHP class should get you going pretty quickly.

I'm not so driven with JavaScript, so doing some UI stuff isn't that easy.

I agree, I don't think Tesla is that concerned about reverse engineering their mobile app's API. The legal issue here is not so much about reverse engineering, but Tesla's terms of service for their web app that is supporting the mobile apps. I don't have the mobile app yet, so I don't know if there is an accompanying "click wrap" license. But if they state that the API may only be accessed via their application, then you would be in violation of their terms of use. They have a simple remedy, which would be to just disable your account.

Until I hear otherwise, I'm treating this as an "ask forgiveness" opportunity. But I hope anyone using the API would be careful to not create headaches for Tesla (for example too many API requests, etc.) that could quickly bring this little "experiment" to an end.

Tesla would be very cool if they kept the API up and just placed a rate limiter should people start hammering it.

 

[aviators99]

Very cool. Would you mind posting your script - this would save me some time. Thanks!

curl --cookie cookie.jar -c cookie.jar -k "https://portal.vn.teslamotors.com/vehicles/xxx/command/charge_start"

 

[ahimberg]

slight annoyance for Windows store (& WindowsPhone) apps -- they do not have access to cookie data that is httponly, which the auth sessions cookies are.
That means restarting the app will always have to login again and not be able to make use of the 3month cookie session timeout. That's good if you're worried about changing your password not being reflected fast enough by the app, bad in the app is a little slower after every restart (and Tesla's login server has a handle a little more traffic).

I originally hoped to not need to save a password and just the cookie (even though they're basically the same security wise so the cookie would still need to be secured if saved), and force the user to re-enter the pw every 3 months. Instead I do have to store the password, but just like the cookie would have needed to be, encrypt it in local storage with the per-application-install-session encryption key, so someone can't dump isostore off your phone and see it.

 

[PureAmps]

Decoding Vehicle Option Codes

The JSON description for the vehicle returns a list of "option_codes". They may or may not be useful, but I was trying to decipher them. The list for my car was "MS01,RENA,TM00,DRLH,PF01,BT85,PMMB,RFBC,WT21,IDOG,IZMT,TR00,SU01,SC01,TP01,AU01,CH00,HP00,PA01,PS01,AD02,X024,X001,X003,X007,X011,X013,X021".

The codes all seem to be 4-digits, where the first two digits are the code "type", and the last two digits are the "value". They seem to be using a value of "00" and "01" for boolean values.

So far my interpretation is:

• MS01 - Model S - true
• RENA - ??
• TM00 - Tesla Motors owned vehicle?
• DRLH - Drive Side - Left Hand
• PF01 - Performance - true
• BT85 - Battery Type - 85
• PMMB - ??
• RFBC - Roof - Body Color (RFPO - seems to be pano roof)
• WT21 - Wheel Type - 21"
• IDOG - Interior - obeche gloss?
• IZMT - ??
• TR00 -- ??
• SU01 - Air suspension?
• SC01 - Super charger access?
• TP01 - Tech package?
• AU01 - Audio package?
• CH00 - child seats?
• HP00 - ??
• PA01 - paint armor?
• PS01 - ??
• AD02 - ??
• Xxxx - Other specific options? Could be grey wheels, spoiler, etc....

Anybody want to take a guess at the meanings? I noticed tim's example had some different options codes including "PBCW", "IBMB" (related to "PMMB"?).

I figure the paint color, seat color/type, and single/twin chargers are encoded in there somewhere. I have blue paint, tan leather, and a single charger.

 

[ahimberg]

there are some comments in the apiary.io doc for most of them.

 

[PureAmps]

there are some comments in the apiary.io doc for most of them.

Thanks, I hadn't noticed the comments. How did they decode all of the X??? options?

 

[ahimberg]

that I have no idea about, but they seemed to be right, all the things that differed for me seemed to line up

 

[AnOutsider]

Some of these codes also showed up in the design studio back when I was sniffing the data there

 

[aviators99]

Some of these codes also showed up in the design studio back when I was sniffing the data there

Bingo. Still do.

 

[timdorr]

Would it be a good idea to put together a simple .war or equivalent with a web frontend? We could distribute the war around here and folks can deploy in a container on their home machines if not host it publicly. My UI/UX skills are rusty but, I'll work on this too.

*shudder*. Sorry, I have an internal hatred of Java

I think a npm or Ruby gem would be good to have as well. They are using those on the backend, after all! (portal.vn is Rails and streaming.vn is nodejs/Express).

 

[Alpha]

This is really cool stuff. I personally could make a lot of use out of the REST API -- I just hope Tesla doesn't get all upset about people doing this... best possible thing would be for them to publish this on their own. And maybe they will eventually.

 

[widodh]

*shudder*. Sorry, I have an internal hatred of Java

I think a nodejs or Ruby gem would be good to have as well. They are using those on the backend, after all! (portal.vn is Rails and streaming.vn is nodejs/Express).

What's wrong with Java? (Don't start!! ) I write in it every day.

Anyway, I don't think JavaScript will work since it doesn't allow HTTP calls to other domains then where you are in.

My PHP class is going nicely, I'll do a pull request on Github when it's ready so it can go into the repo with a couple of examples.

 

[Alpha]

Nice thing about a REST api - easy to implement in any language.

 

[finout]

Well in case anyone wants to actually implement the commands (in addition to the basic vehicle status resources mentioned at http://docs.timdorr.apiary.io/), I mucked around with mine and found the commands I could do (when not plugged in)

auto_conditioning_start
auto_conditioning_stop
charge_max_range
charge_standard
charge_port_door_open
door_lock
door_unlock
flash_lights
honk_horn
set_temps?passenger_temp=22.222223&driver_temp=22.222223
<note: temps obviously converted from F in interface to C>

These are all in the same REST format as in the timdorr site (but must include the specified cookies). e.g.:

https://portal.vn.teslamotors.com/vehicles/[I]<vehicle id>[/I]/command/[B]auto_conditioning_start[/B]

 

[PureAmps]

They are using those on the backend, after all! (portal.vn is Rails and streaming.vn is nodejs/Express).

I hadn't seen the reference to streaming.vn, so that peaked my interest this morning. Now that I have the iPhone app, I was able to watch the traffic via a proxy this afternoon.

It is really quite impressive what they've done. Through their streaming API they are providing real-time telematics updates every 250ms. I tested this while driving around with my daughter watching the speedometer and the mobile app at the same time, and the latency appears quite low (well less than 1 second). Considering the data is coming from my vehicle over AT&T's 3G network to some Tesla data center and then sent back over Verizon's LTE network (in my case) to my phone, it is pretty amazing!

I think nodejs was a good choice on Tesla's part for this application, a pretty good match for the problem they are solving, and should scale well.

I noticed the authentication used for the streaming API is using one of the two "tokens" provided in the vehicle's JSON description. It kind of make me wonder what the other token is for....

 

[timdorr]

Anyway, I don't think JavaScript will work since it doesn't allow HTTP calls to other domains then where you are in.

Those restrictions come from the browser, whereas nodejs is a backend server application and can do whatever the heck you want. It's the v8 engine from Chrome stripped out and hooked up to run as a server. Check it out, if you haven't heard of it: node.js

 

[Alpha]

How do you know what they are using on the backend?

I hadn't seen the reference to streaming.vn, so that peaked my interest this morning. Now that I have the iPhone app, I was able to watch the traffic via a proxy this afternoon.

It is really quite impressive what they've done. Through their streaming API they are providing real-time telematics updates every 250ms. I tested this while driving around with my daughter watching the speedometer and the mobile app at the same time, and the latency appears quite low (well less than 1 second). Considering the data is coming from my vehicle over AT&T's 3G network to some Tesla data center and then sent back over Verizon's LTE network (in my case) to my phone, it is pretty amazing!

I think nodejs was a good choice on Tesla's part for this application, a pretty good match for the problem they are solving, and should scale well.

I noticed the authentication used for the streaming API is using one of the two "tokens" provided in the vehicle's JSON description. It kind of make me wonder what the other token is for....

 

[PureAmps]

How do you know what they are using on the backend?

The HTTP Server header in the responses coming back from their servers indicates the server type.

 

[Alpha]

The HTTP Server header in the responses coming back from their servers indicates the server type.

Oh I see now that chromeo is rails app... Assumed it was something proprietary.

- - - Updated - - -

I wish I could participate - can't do much until I get my car :-(
the app pretty much stops me at signon saying no car registered.
really exciting to hear about it though...

 

[Banahogg]

FWIW, the curl -u that I mentioned worked for me before seems to have stopped working, so I guess it's back to the cookies.