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.
Logging out from your session

Looks like you make an HTTP DELETE call to /Logout with the _s_portal_session and user_credentials cookies set to logout:

Code:
var logoutAddress = new UriBuilder(baseAddress) { Path = "/logout" };
var httpClientHandler = new HttpClientHandler();
httpClientHandler.CookieContainer.Add(logoutAddress.Uri, new Cookie("_s_portal_session", sessionCookie));
httpClientHandler.CookieContainer.Add(logoutAddress.Uri, new Cookie("user_credentials", token));

var httpClient = new HttpClient(httpClientHandler);
var response = await httpClient.DeleteAsync(logoutAddress.Uri);
response.EnsureSuccessStatusCode();
 
Streaming API Security Tokens

I think I have figured out the way the streaming API and the tokens work. I was trying to figure out how long it took for the tokens to expire and I kept getting different values. Then I noticed that they always expire at one of 4 times corresponding to the top of the hour :)00), or in 15 minutes increments thereafter :)15, :30, :45).

New tokens are generated at these 15 minute intervals. Even if you query the REST API for /vehicles and get no tokens (i.e. tokens: [] ), a call to /wake_up will reveal the latest two active tokens (not new ones as I had originally thought).

So in summary:
  • every HTTP Long Poll will timeout in ~2 minutes (121.5 seconds give or take a few milliseconds)
  • if you get a token it will be good for somewhere between 15-30 minutes depending on what time of day it was when you started
  • if you check every 15 minutes for a new token then you should see your old one listed as the the second in the token list and you can switch the first token in the list for another 15 minutes.
  • if you ever get undefined tokens, or get an HTTP 401: Unauthorized return code, then call REST API /wake_up, followed by /vehicles, and the last two active tokens will be once again revealed

If anyone sees any different behavior let me know.
 
Last edited:
So I'm a bit late to the party here, but anyone got any advice? Here's what I'm using:

curl -c cookies.txt -d "user_session={my email}&user_session[password]={my password}" https://portal.vn.teslamotors.com/login
curl -b cookies.txt https://portal.vn.teslamotors.com/vehicles

I then get back the typical JSON reply with all the vehicle info in it, most importantly {"vehicle_id":XXXX}

I'm then using:
curl -b cookies.txt https://portal.vn.teslamotors.com/vehicles/XXXX/command/honk_horn

But instead of honking the horn, I get back in the terminal window:
<html><body>You are being <a href="https://portal.vn.teslamotors.com/">redirected</a>.</body></html>

I checked my cookies.txt file, and it has a value for both user_credentials and _s_portal_session (or so it seems).

Any ideas?

[ATTACH=full]17216.vB[/ATTACH]
 

Attachments

  • b7e.jpg
    b7e.jpg
    57.3 KB · Views: 808
Here's what I'm using:

curl -c cookies.txt -d "user_session={my email}&user_session[password]={my password}" https://portal.vn.teslamotors.com/login
curl -b cookies.txt https://portal.vn.teslamotors.com/vehicles

I then get back the typical JSON reply with all the vehicle info in it, most importantly {"vehicle_id":XXXX}

I'm then using:
curl -b cookies.txt https://portal.vn.teslamotors.com/vehicles/XXXX/command/honk_horn
[/QUOTE]

Wrong id. The vehicle id you are using is only for the streaming interface. The one you want for the REST API is just called {"id": 123}
 
Wrong id. The vehicle id you are using is only for the streaming interface. The one you want for the REST API is just called {"id": 123}

Ha ha! Most excellent. I figured it was something super simple like that. I had tried replacing the "vehicle_id" part with the "user_id", but that (clearly) didn't work. I didn't even notice the "id" tag.

Thanks, hans!!
 
I discovered a new value for the streaming api.

I noticed that "est_heading" in the streaming api does not always match "heading" in the REST api (returned from GET /drive_state). So I added "heading" AND "est_heading" as values to the streaming api, drove around the block and compared the two.

They are often off by a few degrees either way and sometimes by a lot (like 180 degrees).

I suspect that Tesla is getting heading information from two different sources. Perhaps from the GPS hardware and the 3G mobile network or an embedded compass.

If a reliable heading value is not available, then that might explain why the navigation map is set to always point north.
 
Hans, if it helps the roadster heading comes from the GPS. No inbuilt compass. Same in a couple of other car systems we've looked at for OVMS, so maybe common. The GPS chipsets give you heading for free, but require some forward movement.

Perhaps 'heading' is the raw value from the GPS, and est_heading is smoothed?
 
I have a user reporting an issue with my app in which the HVAC systems turns off about 1 minute after remotely turning it on. Does the API need to ping the car every one often while remotely running the HVAC?

nope. 10 minutes and it's still on. I even went out to the car and verified the climate control was on.

[examples] $ teslacmd -t
{ inside_temp: 27.5,
outside_temp: 13,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: false,
is_front_defroster_on: 0,
is_rear_defroster_on: false,
fan_status: 0 }
[examples] $ date
Mon Mar 4 18:16:30 PST 2013

[examples] $ teslacmd -A on
{ reason: '', result: true }

[examples] $ teslacmd -t
{ inside_temp: 27,
outside_temp: 13,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: true,
is_front_defroster_on: 0,
is_rear_defroster_on: false,
fan_status: 1 }

[examples] $ teslacmd -t ;date
{ inside_temp: 26.5,
outside_temp: 13,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: true,
is_front_defroster_on: 0,
is_rear_defroster_on: false,
fan_status: 1 }
Mon Mar 4 18:26:28 PST 2013


I have a few ideas.

- It's possible the car is going to sleep, or otherwise conserve power.
- It's possible the car shuts HVAC off once the target temperature is reached.
- It's possible there is a problem with the temperature sensor. I get erratic reading from it all the time.

Look at this sequence. Outside temp is 13C, then "null", then 20.5C. HVAC goes from on, to "null", to off.

[examples] $ teslacmd -t ;date
{ inside_temp: 25.5,
outside_temp: 13,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: true,
is_front_defroster_on: 0,
is_rear_defroster_on: false,
fan_status: 1 }
Mon Mar 4 18:45:08 PST 2013

[examples] $ teslacmd -t ;date
{ inside_temp: 26.5,
outside_temp: null,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: null,
is_front_defroster_on: null,
is_rear_defroster_on: false,
fan_status: null }
Mon Mar 4 18:52:38 PST 2013

[examples] $ teslacmd -t ;date
{ inside_temp: 26,
outside_temp: 20.5,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: false,
is_front_defroster_on: 0,
is_rear_defroster_on: false,
fan_status: 0 }
 
Last edited:
I have a user reporting an issue with my app in which the HVAC systems turns off about 1 minute after remotely turning it on. Does the API need to ping the car every one often while remotely running the HVAC?

One more observation. I have seen { is_auto_conditioning_on: false } when { fan_status: 1 }. Like so:

{ inside_temp: 23.5,
outside_temp: 15.5,
driver_temp_setting: 23.1,
passenger_temp_setting: 23.1,
is_auto_conditioning_on: false,
is_front_defroster_on: 0,
is_rear_defroster_on: false,
fan_status: 1 }

When I checked on my Android phone, it showed the climate control as being "on" with the blue cooling arrows in the GUI. I think that technically, the Air Conditioning is not on, but the car is recycling outside air to cool the cabin so the climate control is on. When heating, I also see { is_auto_conditioning_on: false }

If you are using { is_auto_conditioning_on } in your app to check if the climate control is on or off you may not be getting the correct value. Seems more accurate to check if { fan_status: 0}. At least that appears to be what the Android app is doing. I don't have a sniffer/proxy to check for sure. Someone else might.