Model S REST API

[markb1]

Some recent software update (presumably) on my Model S has broken my streaming script. Now, when I send a subscribe message, I simply get no response. It doesn't seem to matter if the car is asleep or awake. It seems much like how it behaves for Model 3, which I don't think anyone has figured out, so I don't have a lot of hope. But does anyone have any ideas?

 

[Dan203]

Does anyone know what the end point...

/api/1/users/command_token

does?

I figured out that if you send it your user name and password as JSON, like the auth function, you get a 200 OK with this...


{
"response": "ReallyLongStringThatIAssumeIsAKeyToSomething"
}

I tried using the returned string as an auth token and it wasn't valid. Not sure what it's for

 

[pjw65]

As of Tesla JSON API there a some other "users" commands like "Powerwall order", "Service scheduling", "Referral data", "Roadside Assistance". What do they have in common?
From the "Endpoints File" of the link above:

 "POWERWALL_ORDER_SESSION_DATA": {
    "TYPE": "GET",
    "URI": "api/1/users/powerwall_order_entry_data",
    "AUTH": true
  },
  "POWERWALL_ORDER_PAGE": {
    "TYPE": "GET",
    "URI": "powerwall_order_page",
    "AUTH": true,
    "CONTENT": "HTML"
  },
  "ONBOARDING_EXPERIENCE": {
    "TYPE": "GET",
    "URI": "api/1/users/onboarding_data",
    "AUTH": true
  },
  "ONBOARDING_EXPERIENCE_PAGE": {
    "TYPE": "GET",
    "URI": "onboarding_page",
    "AUTH": true,
    "CONTENT": "HTML"
  },
  "SERVICE_SELF_SCHEDULING_ELIGIBILITY": {
    "TYPE": "GET",
    "URI": "api/1/users/service_scheduling_data",
    "AUTH": true
  },
  "SERVICE_SELF_SCHEDULING_PAGE": {
    "TYPE": "GET",
    "URI": "service_scheduling_page",
    "AUTH": true,
    "CONTENT": "HTML"
  },
  "REFERRAL_DATA": {
    "TYPE": "GET",
    "URI": "api/1/users/referral_data",
    "AUTH": true
  },
  "REFERRAL_PAGE": {
    "TYPE": "GET",
    "URI": "referral_page",
    "AUTH": true,
    "CONTENT": "HTML"
  },
  "ROADSIDE_ASSISTANCE_DATA": {
    "TYPE": "GET",
    "URI": "api/1/users/roadside_assistance_data",
    "AUTH": true
  },
  "ROADSIDE_ASSISTANCE_PAGE": {
    "TYPE": "GET",
    "URI": "roadside_assistance_page",
    "AUTH": true,
    "CONTENT": "HTML"
  },
 "AUTH_COMMAND_TOKEN": {
    "TYPE": "POST",
    "URI": "api/1/users/command_token",
    "AUTH": true
  },
  "SEND_DEVICE_KEY": {
    "TYPE": "POST",
    "URI": "api/1/users/keys",
    "AUTH": true
  },

 

[Dan203]

I think they are things linked to the user and not a specific device.

 

[m3-ricardo]

I have created a wall gauge that shows the estimated cost of my vehicle's last home charge. The Pic below is from last nights charge process. It is showing an estimated cost of $7.75 for yesterday’s driving. I get the cost information from the response.charge_energy_added value. This is the amount of DC kilowatt hours it took to charge the battery. Once I have the kWh it is a simple matter of multiplying it by my home kWh cost of 13 cents to get the charge cost.

The gauge works great. In the morning we can see the cost of yesterday’s drive. However, this is not the true cost. If I understand things correctly the response.charge_eneregy_added value is only the DC current (after it has been rectified by the car’s charger) and doesn’t take into account the rectification process or any power it takes to manage the batteries temp during charge. My question is this. Does anyone have a feel or a guideline for the efficiency of the charge process? I would like to add that to my cost estimate for my gauge.

View attachment 486084

I love the idea of using a real-world analog gauge for this .

you can figure out the actual power used by logging the charging_state.charger_power field.

it gives you the instant power being drawn from the wall . you have to do some math to figure out the actual kwh that were drawn over time .. you can then do chaging_state.charge_power_added / power_used to get efficiency if you care for that.. or calculate your costs for power using the power drawn rather than power added.

 

[John Rucker]

I love the idea of using a real-world analog gauge for this .

you can figure out the actual power used by logging the charging_state.charger_power field.

it gives you the instant power being drawn from the wall . you have to do some math to figure out the actual kwh that were drawn over time .. you can then do chaging_state.charge_power_added / power_used to get efficiency if you care for that.. or calculate your costs for power using the power drawn rather than power added.

Yep I can also get access to the charger's instant voltage and current. This is on the AC side and if I use Volts times Current = Power I get the same number as charger_power. The problem with this is I poll the car for that data ever minute and that only gives me a snap shot of the AC voltage and current at that moment. I could just assume that the current and voltage was the same for the time period between polls and could probably get pretty close. But at best it is still a guess of what is going on between my poll cycles.

So that is why I was looking for some percentage of overhead I could just add to the DC kWh being added to the battery. When I installed my home charger I put it behind a dedicated (calibrated) power meter. So what I did for about a month was just recorded the kWh readings from my dedicated meter and compared it to the DC kWh reported by my model X. Turns out there is an 8 to 10% overhead (90% to 92% efficiency ). So I just add 10% to my calculations to get my meter closer to really what is being used.

It is cool having the information displayed on a wall gage. Every morning we take a quick peek at the gauge and see what it cost to drive the car the previous day. A trip to WallMart and back in the winter can cost $1.25 but in the summer it is $0.75.

Just a FYI
We have a 7kW solar system at home and the next gauge I want to make will compare our solar generated kWh to the Tesla kWh used for charging. Our local electric here in down state Illinois is from coal & natural gas. It would be cool to know if I'm driving on sunshine or coal.

Thanks for the input!!

 

[scottmbritton]

Looking for some assistance with API commands to start and stop charging. I have tried a tasker plugin and also home assistant Tesla integration and everything seems to work except starting and stopping charging. I have been able to unlock doors, honk the horn, turn on and off climate control, adjust charge limit (set to max and set from 50% to 90%). When I send the commands to stop charging I get a 200 response and "result": true response but the charging does not stop.

Instead of using the apps I mentioned before I ended up doing some tests with Tesla Owner JSON API · Apiary and have the same results. I have been able to get everything to work except for stopping and starting charging. As a work around if I set the charge limit to the lowest it will go, which looks like 50% and the car has charged past that limit already it will stop charging. When I set the limit higher than what it is at it will start charging again but this isn't the best solution because if it is less than 50% charged it will continue charging.

Using the Tesla android app I am able to stop and start charging so it works from there but not using any API calls. In searching and talking to the Tasker plugin author, I seem to be the only person that has this issue. Does anyone have any suggestions? Thanks.

I have a 2016, MS 90D.

 

[scottmbritton]

Looking for some assistance with API commands to start and stop charging.

After setting up a packet capture I noticed that the Tesla App isn't actually working either. Commands are sent and the app looks like it stopped charging but after a minute the Tesla app updates and says it is still charging. Watching the car when I try to stop charging using the Tesla App, the charging is never actually interrupted at all. So I'll have to work with Tesla on why their Android app isn't working for me. I'm sure after that is resolved the API calls will work as well. Thanks

 

[EdouardGT]

Your request likely looks like:

POST /api/1/vehicles/zzzzzzz/command/actuate_trunk?which_trunk=rear HTTP/1.1
User-Agent: yyyyy
Authorization: Bearer xxxxx
Host: owner-api.teslamotors.com
Connection: close
Content-Length: 0

with your values for x,y,z....

I duplicated your current result of:

{"response":{"reason":"invalid_value","result":false}}

Instead of passing the commend as parameter on the url just pass them as value in the body. Note the additional Content-Type header and its value to indicate the type of data you are passing in the body for the POST request

POST /api/1/vehicles/zzzzzz/command/actuate_trunk HTTP/1.1
User-Agent: yyyyy
Authorization: Bearer xxxxxx
Content-Type: application/json
Host: owner-api.teslamotors.com
Connection: close
Content-Length: 22

{"which_trunk":"rear"}

Which yields a valid response:

{"response":{"reason":"","result":true}}

Thanks, helpt me really quick and easy! Created a Postman collection if anyone is interested, I can consider to share the Postman JSON data so you can Import into your Postman.

 

[Bandit]

Thanks, helpt me really quick and easy! Created a Postman collection if anyone is interested, I can consider to share the Postman JSON data so you can Import into your Postman.

I'd find a postman collection convenient and appreciated. Saves me from crafting each call the first time I use it.

 

[miguelóy]

Does anyone know why the car's browser won't send its cookie when initiating a new WebSocket?

Just to be clear, I'm am not talking at all about Tesla's streaming endpoint. I'm playing around with a different web app. It can GET/POST just fine and sends a session cookie just as it should. But initiate a new WebSocket... not so much.

I've tried Chromium 79 on other platforms and they seem to work as expected. It's just Tesla's Chromium 79.

Example:

A normal GET request from Tesla's browser produces these headers:
GET /having/fun HTTP/1.1
Host: something
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; GNU/Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/79.0.3945.130 Chrome/79.0.3945.130 Safari/537.36 Tesla/2020.12.1-299292ad7782
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
cookie: TG9va2luZyBGb3IgU29tZXRoaW5nPw=="gAAAAABehmVJXHyjuD6oAhlOqjObu...HEeVh37uoEqGw="

But if initiated as a new WebSocket it produces this, without the cookie:
GET /no/fun HTTP/1.1
Host: something
Upgrade: websocket
Connection: upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; GNU/Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/79.0.3945.130 Chrome/79.0.3945.130 Safari/537.36 Tesla/2020.12.1-299292ad7782
Origin: https://something
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Sec-WebSocket-Key: hAt/QCfMymssL/ROvUs4FQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

 

[insaneoctane]

Anyone know how to access the firmware upgrade "queue" that TeslaFi has seemed to figure out? It would be useful for me to take some actions to ensure I am notified when I have new software available!

 

[luckyj]

Anyone know how to access the firmware upgrade "queue" that TeslaFi has seemed to figure out? It would be useful for me to take some actions to ensure I am notified when I have new software available!

If I had to guess I'd say they are looking at software_update, returns something like this {"expected_duration_sec": 3000, "status": "installing", "download_perc": 100, "version": "2019.40.1.1", "install_perc": 30}.

 

[lonertic]

Does anyone know why the car's browser won't send its cookie when initiating a new WebSocket?

pretty sure websockets by protocol definition are stateless and therefore cookieless.. they're pretty close to a direct tcp/ip connection with very little other context around the connection object itself. you'll need to manage state and session via the packet itself. Webrequest however (http/https) are stateful connections. So I'm not sure if you're referring to the same thing.

 

[BPeter]

So looks like api_version has been incremented to 8 in 2020.16
What could possibly be new here?

 

[Gwgan]

My iOS Shortcuts stopped working. Refreshing the token gives

{"error":"invalid_grant","error_description":"The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client."}

Have the client_id and or client_secret changed?

 

[Desmondo]

Something is up. My home automation system no longer works and I get the error "[DEBUG] 08:56:59: 2020-08-12 08:56:59.217434 [ error] Handshake error: certificate verify failed"

 

[focher]

My Homebridge plugin is still working fine. I also tested with Postman and didn't get any errors when grabbing the token or getting a vehicle list.

 

[markb1]

Something is up. My home automation system no longer works and I get the error "[DEBUG] 08:56:59: 2020-08-12 08:56:59.217434 [ error] Handshake error: certificate verify failed"

My script for renewing the session got this error yesterday. I had to tell it to not verify the certificate, and it worked fine. Oddly, my script for pulling the data did not have a problem with the certificate, so I'm not sure what's going on.

 

[HankLloydRight]

My tampermonkey script to generate and refresh tokens still works fine.