Model S REST API

Prefect · Sep 10, 2016

dpskipper said:
Nevermind, I somehow figured it out with trial and error. Pretty cool to make my car honk

It would maybe help me if you told me what you did wrong initially. I also can only get requests to work, but none of the commands work for me (they all respond with 404).

icdevin · Sep 11, 2016

Not super on-topic, but I finally got my Model S so I can finally derp around with the API!

Prefect · Sep 14, 2016

Here is something strange we just figured out.

I can't get any commands to the tesla API to work and respond with anything different than just "404" als long as the call comes from a server in Europe. The same script immediately works if I put it on a server in the US.

I tried four different servers in Europe. Completely different datacenters, different peerings, different machines. They all just get 404 back for all commands.

But everything works for the requests. So if you are just reading data there is no problem. But when you want to issue a command to the car, it only seems to work from servers in the US.

There might be something else responsible for this than geographic location, maybe different time zones or something.

HankLloydRight did help a ton with testing this out, thanks again!

This is just something very strange and id did cost me about 20 hours in testing and asking for help in this thread

wayner · Sep 15, 2016

Wouldn't this affect every third party program that uses the API, like VT, Remote S, etc? Is everyone in Europe having this problem?

Prefect · Sep 15, 2016

That's what I thought too. But maybe these apps route the commands trough their own server?

Or maybe there is some other factor that affects all my four servers? This is just very strange..

If you want to test, here is a php file you can put on your server. Just fill in a valid token and your "id" from the vehicles list:

Code:

<?php

$TESLA_API_URL = "https://owner-api.teslamotors.com/";
$token = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
$VEHICLE_ID = "XXXXXXXXXXXXXXXX";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://owner-api.teslamotors.com/api/1/vehicles/".$VEHICLE_ID."/command/flash_lights");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_POST, TRUE);

curl_setopt($ch, CURLOPT_HTTPHEADER, array(
"Authorization: Bearer $token"
));

$response = curl_exec($ch);
curl_close($ch);

var_dump($response);

fact200 · Sep 15, 2016

Prefect said:
That's what I thought too. But maybe these apps route the commands trough their own server?

Or maybe there is some other factor that affects all my four servers? This is just very strange..

If you want to test, here is a php file you can put on your server. Just fill in a valid token and your "id" from the vehicles list:

This probably warrants a little more research. It's highly doubtful 3rd party clients use a proxy server as that defeats lots of the advantages; not having to deal with backend security and scale.

Will spin up an EU sever and give it a try...

HankLloydRight · Sep 15, 2016

It's a really strange problem.

The GET data requests work fine.

The POST commands return 404 from @Prefect servers, the exact same code works for me from the US.

fact200 · Sep 15, 2016

Here's my quick test from an AWS server in eu (Frankfurt) server:

First few traceroute hops verify it's going through the EU.

1 ec2-54-93-0-20.eu-central-1.compute.amazonaws.com (54.93.0.20) 1.146 ms ec2-54-93-0-22.eu-central-1.compute.amazonaws.com (54.93.0.22) 1.154 ms ec2-54-93-0-20.eu-central-1.compute.amazonaws.com (54.93.0.20) 1.198 ms
2 54.239.5.135 (54.239.5.135) 1.896 ms 54.239.5.175 (54.239.5.175) 1.939 ms 1.989 ms
3 54.239.107.138 (54.239.107.138) 15.111 ms 54.239.107.160 (54.239.107.160) 2.907 ms 54.239.107.116 (54.239.107.116) 8.358 ms
4 54.239.107.77 (54.239.107.77) 2.160 ms 54.239.107.163 (54.239.107.163) 2.258 ms 54.239.107.165 (54.239.107.165) 2.301 ms
5 212.119.27.169 (212.119.27.169) 2.596 ms 3.067 ms 2.907 ms
6 ae-6.r20.frnkge04.de.bb.gin.ntt.net (129.250.6.248) 2.743 ms ae-2.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.217) 1.871 ms 2.174 ms
7 ae-8.r22.asbnva02.us.bb.gin.ntt.net (129.250.4.96) 90.335 ms 86.936 ms 89.652 ms
8 ae-0.r23.asbnva02.us.bb.gin.ntt.net (129.250.3.85) 92.492 ms 87.984 ms 90.489 ms
9 ae-10.r22.snjsca04.us.bb.gin.ntt.net (129.250.6.237) 157.833 ms 160.673 ms 158.063 ms
10 ae-40.r02.snjsca04.us.bb.gin.ntt.net (129.250.3.121) 162.755 ms 156.507 ms 162.801 ms
11 xe-0-7-0-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.186) 157.838 ms 160.547 ms 157.851 ms
12 205.234.0.178 (205.234.0.178) 156.963 ms 155.982 ms 155.992 ms

And my curl request looks good (note I substituted anything that looks like an id with XYZs):

curl -XPOST -v https://owner-api.teslamotors.com/api/1/vehicles/XXXXYYYZZZ/command/sun_roof_control -H "Authorization: Bearer XXXXYYYYZZZZ" -d "state=vent&percent=13"
* Trying 209.10.208.22...
* Connected to owner-api.teslamotors.com (209.10.208.22) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
* subject: CN=owner-api.teslamotors.com,O="Tesla Motors, Inc.",L=Palo Alto,ST=California,C=US
* start date: Apr 16 00:00:00 2014 GMT
* expire date: Apr 20 12:00:00 2017 GMT
* common name: owner-api.teslamotors.com
* issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> POST /api/1/vehicles/XXXYYYZZZZ/command/sun_roof_control HTTP/1.1
> User-Agent: curl/7.40.0
> Host: owner-api.teslamotors.com
> Accept: */*
> Authorization: Bearer xxxxyyyyyzzzzzz
> Content-Length: 21
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 21 out of 21 bytes
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 15 Sep 2016 17:02:03 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 40
< Connection: keep-alive
< Status: 200 OK
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-TXID: 12345
< ETag: W/"xyz"
< Cache-Control: max-age=0, private, must-revalidate
< X-Request-Id: 12345
< X-Runtime: 4.154172
< X-Frame-Options: SAMEORIGIN
<
* Connection #0 to host owner-api.teslamotors.com left intact
{"response":{"reason":"","result":true}}

Prefect · Sep 15, 2016

I think Tesla employees are reading this thread

So I ran the same code again today on my main server. And... it worked!! What? It did return 404 for the past 5 months!! And now it just works?

It did not work on four servers. The same file. It then worked on one server in the US. Then I posted the problem. And now it works on my server in Switzerland too?

Did they fix the API firewall since last night??

I will continue testing. But if it works from now on, then they are definitively reading this thread

Thanks guys! :-D

dpskipper · Sep 15, 2016

Prefect said:
I think Tesla employees are reading this thread

So I ran the same code again today on my main server. And... it worked!! What? It did return 404 for the past 5 months!! And now it just works?

It did not work on four servers. The same file. It then worked on one server in the US. Then I posted the problem. And now it works on my server in Switzerland too?

Did they fix the API firewall since last night??

I will continue testing. But if it works from now on, then they are definitively reading this thread Thanks guys! :-D

Interesting. Maybe Tesla is doing maintenance/upgrading. my biggest dislike of the API is its lack of consistency. I very often get Bad Gateway and Timeout errors.

Sergii · Sep 20, 2016

Hello guys.
I see the same problem on my EU located server. I've read your last posts and installed a new server in US. Moved all my code there and I see the same behaviour.
Sometimes I can't even get an access token. It replies with some error page with code 404, sometimes with 500.
first few hopes in trace to owner-api.teslamotors.com:

1 216.182.236.114 (216.182.236.114) 0.648 ms 216.182.236.112 (216.182.236.112) 0.636 ms 216.182.236.114 (216.182.236.114) 0.629 ms
2 72.21.222.18 (72.21.222.18) 2.251 ms 2.326 ms 72.21.222.16 (72.21.222.16) 2.117 ms
3 54.240.243.26 (54.240.243.26) 14.110 ms 14.165 ms 14.038 ms
4 54.240.242.13 (54.240.242.13) 2.369 ms 54.240.243.9 (54.240.243.9) 2.887 ms 54.240.242.113 (54.240.242.113) 2.450 ms
5 ae-52.r01.snjsca04.us.bb.gin.ntt.net (128.241.219.17) 3.037 ms ae-5.r06.plalca01.us.bb.gin.ntt.net (140.174.21.181) 5.030 ms ae-9.r05.plalca01.us.bb.gin.ntt.net (129.250.194.121) 3.125 ms
6 ae-15.r02.snjsca04.us.bb.gin.ntt.net (129.250.4.119) 4.507 ms 3.627 ms ae-42.r02.snjsca04.us.bb.gin.ntt.net (129.250.6.157) 2.287 ms
7 ae-15.r02.snjsca04.us.bb.gin.ntt.net (129.250.4.119) 2.998 ms 4.480 ms xe-0-7-0-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.186) 2.935 ms
8 xe-0-7-0-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.186) 3.306 ms * 205.234.0.178 (205.234.0.178) 3.408 ms
9 205.234.0.178 (205.234.0.178) 3.476 ms * *

I checked all these servers and they are US-located.
Can't figure out what else can I check and change to make it working.

May be Dear "Perfect" could share a hosting company name, that I could buy a new server from them? Excuse me in advance about this personal question, but I'm fighting with this problem several hours and I can't find a solution.

thanks to anyone for any helpfull info

fact200 · Sep 20, 2016

Lately it seems one possibility is that Tesla's servers are down (which seemed to occur last night...).

I've setup a mock Tesla service in order to get basic stuff working before hitting the real Tesla production servers:
Tesla API Simulator

Otherwise, it' really difficult to help without code examples. Helps to also use a very basic HTTP tool like curl because other languages/environments have different ways of handling headers, POST requests, message bodies, JSON, etc...

Dylan Diamond · Sep 20, 2016

Any idea how this happened? First Tesla Model S remotely controlled by hackers, Tesla already pushed a fix

You certainly cannot control the windshield wipers through the main API...

HankLloydRight · Sep 20, 2016

Existing thread: Car Hacking Research: Remote Attack Tesla Motors by Keen Security Lab

They hacked the CAN bus.

SG57 · Sep 24, 2016

My Model S just received the 8.0 update, I ran some quick smoke tests and identified 5 new fields in climate state:

Code:

{
   "response":{
      "inside_temp":22.6,
      "outside_temp":18.5,
      "driver_temp_setting":20.9,
      "passenger_temp_setting":20.9,
      "left_temp_direction":9,
      "right_temp_direction":9,
      "is_auto_conditioning_on":true,
      "is_front_defroster_on":3,
      "is_rear_defroster_on":false,
      "fan_status":4,
      "is_climate_on":true,
      "min_avail_temp":15.0,
      "max_avail_temp":28.0,
      "seat_heater_left":1,
      "seat_heater_right":0,
      "seat_heater_rear_left":0,
      "seat_heater_rear_right":0,
      "seat_heater_rear_center":0,
      "seat_heater_rear_right_back":0,
      "seat_heater_rear_left_back":0,
      "smart_preconditioning":false
   }
}

The 5 new ones would be:

left_temp_direction - no idea
right_temp_direction - no idea
is_climate_on - duplicate of is_auto_conditioning in my brief testing
min_avail_temp - celsius, min temp capable of being set
max_avail_temp - celsius, max temp capable of being set.

Any other 8.0 discoveries feel free to share

SG57 · Sep 24, 2016

Small update, discovered a new summon/autopark message the server sends on initial connect and on change.

Code:

{"autopark_style":"standard","msg_type":"autopark:style"}

autopark:style - the message type
autopark_style - either "standard" (continuous mode OFF) or "dead_man" (continuous mode ON)

Previously you could only get this autopark_style through the vehicle state data request.

tliving · Sep 26, 2016

I found 6 new fields on my classic S:

rear_seat_type
left_temp_direction
max_avail_temp
is_climate_on
right_temp_direction
min_avail_temp

Hadn't seen the rear seat type one reported yet.

dpskipper · Oct 1, 2016

tliving said:
I found 6 new fields on my classic S:

rear_seat_type

left_temp_direction

max_avail_temp

is_climate_on

right_temp_direction

min_avail_temp

Hadn't seen the rear seat type one reported yet.

Does the new is_climate_on variable actually work? In my testing the is_auto_conditioning would always say false and never seemed to work. Is this a working replacement?

dpskipper · Oct 1, 2016

On another note, is max_range_charge_counter broken? I was of the impression it counted how many times the car was charged to 100%. I have never gone to 100% yet the API returns "2".

AllenWong · Oct 2, 2016

dpskipper said:
On another note, is max_range_charge_counter broken? I was of the impression it counted how many times the car was charged to 100%. I have never gone to 100% yet the API returns "2".

Mine has always said 0 even though I've charged to 100% at least once. Either it doesn't mean what you think it means or it's broken. is_auto_conditioning might mean the status of the AC setting because I don't find it reliable to reflect whether HVAC is on or not. is_climate_on might be more reliable for HVAC, but I haven't tested it yet. But I have another way of reliably testing if HVAC is on or not after some trial and error that worked prior to is_climate_on.

Model S REST API

Member

Member

Member

Active Member

Member

Member

No Roads

Member

Member

Developer

New Member

Member

Member

No Roads

Former Vendor

Former Vendor

Member

Developer

Developer

Member

Similar threads