Model S REST API

[hans]

Looks like the new fields in V4.5 are:

battery_heater_on
charge_limit_soc
charge_limit_soc_max
charge_limit_soc_min
charge_limit_soc_std
not_enough_power_to_heat

 

[brianman]

Looks like the new fields in V4.5 are:

battery_heater_on
charge_limit_soc
charge_limit_soc_max
charge_limit_soc_min
charge_limit_soc_std
not_enough_power_to_heat

Agreed (with typo correction).

- - - Updated - - -

Random observation:
It's odd that heading and est_heading mismatch by 2 degrees for a stationary vehicle.

• https://portal.vn.teslamotors.com/vehicles/<id>/command/drive_state

heading=338
gps_as_of=1369722789

• https://streaming.vn.teslamotors.com/stream/<vehicle_id>/?values=est_heading

1369722772908,336

 

[brianman]

Note that 4.5 changes much of the API used. Door open/closed now is an integer instead of boolean.

For the following fields, values are now 0/1 rather than false/true:

• df
• dr
• pf
• pr
• ft
• rt

From...
https://portal.vn.teslamotors.com/vehicles/<id>/command/vehicle_state

 

[hans]

For the following fields, values are now 0/1 rather than true/false:

• df
• dr
• pf
• pr
• ft
• rt

From...
https://portal.vn.teslamotors.com/vehicles/<id>/command/vehicle_state

Looks like values greater than 1 as well. Not sure what that indicates. Will experiment

{ df: 0,
dr: 0,
pf: 2,
pr: 0,
ft: 0,
rt: 0,
car_version: '1.33.44',
locked: false,
sun_roof_installed: true,
sun_roof_state: 'closed',
sun_roof_percent_open: 0,
dark_rims: false,
wheel_type: 'Silver21',
has_spoiler: false,
roof_color: 'None',
perf_config: 'Base' }

 

[brianman]

So far my logging app hasn't needed any changes with the shift to 4.5 firmware. Kudos to Tesla for not introducing breaking changes. No new cookie format or URL changes, etc.

As far as data interpretation, that stuff will naturally "break" as new data is provided and old data is restructured. I haven't started that part of development yet in part because it's far less urgent than getting reliable logging.

 

[hans]

Thanks for the heads up on est_range. Added it to my logging.

[...]

Update:
The average for the last 30 mi was 400 Wh/mi. Using that number, the Rated Wh/mi is in the 307 range in the middle of the pack and 304 at the 93-94% charge state. That starts to make sense. I thought the old projected was the last 15 miles, but maybe I'm misremembering and it was the last 30 miles. The stray from 304 (i.e. 307) might be explainable by the integer rounding of the range and est_range data.

The est_range number is definitely based on some dynamic level of previous use. You can see on a graph of my homemade log data app that the spread between "range" and "est_range" changes as I drive the car harder.

 

[hans]

Looks like values greater than 1 as well. Not sure what that indicates. Will experiment

Ok I figured this out. At first I thought that values greater than 1 were some kind of indication of how far open the door was. 1 for ajar, 8 for wide open, etc. However, each door will only ever show two values, Either 0 (closed) or a power of 2 (for open).

All doors and trunks open yields the following:

{
df: 1,
dr: 4,
pf: 2,
pr: 8,
ft: 16,
rt: 32
...}

So this is just a bug. The car is sending back a bitmap where each bit indicates a true/false for one of the doors. Version 4.4 handled this correctly but Version 4.5 does not.

The bitmap is clearly rt, ft, pr, dr, pf, df (32:16:8:4:2:1). When all doors are open the bitmap is 111111 = 63

 

[Cashoverass]

This seems interesting but it's 31 pages long. Anyone want to provide a brief recap or a TL;DR?

 

[hans]

Today I noticed that the sunroof's 'vent' position reports 12% open in the car but 6% if you query using the REST API. I tried so see if there was a difference but I could see it.

Also noticed that the 'comfort' position reports 80% in the car but 72% from the REST API.

Not sure if these differences are new to V4.5 or not because I didn't pay that close attention before.

 

[brianman]

This seems interesting but it's 31 pages long. Anyone want to provide a brief recap or a TL;DR?

Read the first post, click the links.

 

[Stoneymonster]

Just a note to let folks know that the pytesla python module works on pythonista for the iPad. Was a bit of a pain to install (not the module's fault), but it's fun to mess around with all this on a tablet!

 

[vlsidude]

Has anyone figured out if there is a way to set 'charge_limit_soc' via the REST API?

 

[brianman]

Has anyone figured out if there is a way to set 'charge_limit_soc' via the REST API?

I would expect 90 and 100 are reachable via ...

• /vehicles/{id}/command/charge_standard
• /vehicles/{id}/command/charge_max_range

... but I haven't and don't plan to verify.

You could try a few variants like "charge_soc/80" and "charge_limit_soc/80" to see if that does anything.

 

[hans]

I would expect 90 and 100 are reachable via ...

• /vehicles/{id}/command/charge_standard
• /vehicles/{id}/command/charge_max_range

... but I haven't and don't plan to verify.

You could try a few variants like "charge_soc/80" and "charge_limit_soc/80" to see if that does anything.

I have verified that /charge_standard is now 90% and /charge_max_range is still 100%.

I expect that when we get the new phone apps with a slider there will be a /charge_limit?value=80 or some such URL that looks a lot like the way you can set the sunroof to any % level of openness with today's REST API.

 

[EdA]

In the phone app thread, someone mentioned that you should be able to set an alert if the car is not plugged in at a certain time. Here's a bourne shell script to do that. You must fill in the 4 variables at the top.

#! /bin/sh

HOME_DIRECTORY="HOMEDIR"
TM_USERNAME="USERNAME"
TM_PASSWORD="PASSWORD"
ALERT_EMAIL="EMAILADDRESS"
   :

Thanks so much for this script. Again (2nd time since January) I forget to charge and have to WFH. I now have a cron job at 9:30pm to text me...

Note, I had to use single = on the "if" statements, e.g.

   if [ "$ps" = "" ]; then

+ ps=40
+ [ 40 == ]
./charge_monitor.sh: 21: [: 40: unexpected operator

Linux Mint Nadia (14)

Also, I had to use my email address, not my teslamotors.com "id" before it would work.

 

[aviators99]

I have verified that /charge_standard is now 90% and /charge_max_range is still 100%.

I expect that when we get the new phone apps with a slider there will be a /charge_limit?value=80 or some such URL that looks a lot like the way you can set the sunroof to any % level of openness with today's REST API.

I am guessing that actually charge_standard and charge_max_range don't *have to be* 90 and 100. I only say that because there are three new fields that appeared for 4.5 in charge_state:
"charge_limit_soc_std":90,
"charge_limit_soc_min":50,
"charge_limit_soc_max":100

- - - Updated - - -

Thanks so much for this script. Again (2nd time since January) I forget to charge and have to WFH. I now have a cron job at 9:30pm to text me...

Note, I had to use single = on the "if" statements, e.g.

   if [ "$ps" = "" ]; then

+ ps=40
+ [ 40 == ]
./charge_monitor.sh: 21: [: 40: unexpected operator

Linux Mint Nadia (14)

Also, I had to use my email address, not my teslamotors.com "id" before it would work.

Glad it's working for you. Weird about the = vs ==. I can't keep up with all of the versions of UNIX these days, but it's hard to imagine differences in /bin/sh.

- - - Updated - - -

Thanks so much for this script. Again (2nd time since January) I forget to charge and have to WFH. I now have a cron job at 9:30pm to text me...

Note, I had to use single = on the "if" statements, e.g.

   if [ "$ps" = "" ]; then

+ ps=40
+ [ 40 == ]
./charge_monitor.sh: 21: [: 40: unexpected operator

Linux Mint Nadia (14)

Also, I had to use my email address, not my teslamotors.com "id" before it would work.

Here's a new version of the script with your fixes. I tested it on my system and it works.

#! /bin/sh

HOME_DIRECTORY="HOMEDIR"
TM_USERNAME="EmailOnFileAtTesla"
TM_PASSWORD="PASSWORD"
ALERT_EMAIL="EMAILADDRESS"

curl -s --cookie $HOME_DIRECTORY/cookie.jar -c $HOME_DIRECTORY/cookie.jar -X POST -F "user_session[email]=$TM_USERNAME" -F "user_session[password]=$TM_PASSWORD" -k "https://portal.vn.teslamotors.com/login" > /dev/null 2>&1

vehicle=`curl -s --cookie $HOME_DIRECTORY/cookie.jar -c $HOME_DIRECTORY/cookie.jar -k "https://portal.vn.teslamotors.com/vehicles" | awk -F, '{for(i=1;i<NF;i++){if($i ~ /"id":.*/) {print substr($i,6)} }}'`

if [ "$vehicle" = "" ]; then
   echo "Could not communicate with vehicle"
   exit 0
fi

ps=`curl -s --cookie $HOME_DIRECTORY/cookie.jar -c $HOME_DIRECTORY/cookie.jar -k "https://portal.vn.teslamotors.com/vehicles/$vehicle/command/charge_state" | awk -F, '{for(i=1;i<NF;i++){if($i ~ /".*pilot_current":.*/) {print substr($i,25)} }}'`

if [ "$ps" = "" ]; then
   echo "Could not communicate with vehicle"
   exit 0
fi

if [ "$ps" = "0" ]; then
   echo "Not plugged in"
   Mail -s 'Car not plugged in!' $ALERT_EMAIL < /dev/null
   exit 1
else
   echo "Plugged in"
   exit 1
fi

 

[Banahogg]

I am guessing that actually charge_standard and charge_max_range don't *have to be* 90 and 100. I only say that because there are three new fields that appeared for 4.5 in charge_state:
"charge_limit_soc_std":90,
"charge_limit_soc_min":50,
"charge_limit_soc_max":100

I'd been assuming that those fields were parameters for the mobile apps to match the settings slider to what shows in the car even if the ranges change in the future (possibly even with different batteries or whatnot)

 

[hans]

I'd been assuming that those fields were parameters for the mobile apps to match the settings slider to what shows in the car even if the ranges change in the future (possibly even with different batteries or whatnot)

I have changed my charge limit "slider" to 80% in the car so that clearly effects the value reported as charge_limit_soc.
It's possible that charge_limit_soc_max is what limits the 40kWh cars to 67% of their 60kWh pack. Would be fun to try on a S40 vid to see what is different.
The charge_limit_soc_std value is what the charge_limit_soc reverts to when the phone app sets a "standard" range or the REST API /vehicles/{id}/command/charge_standard URL is used. Again I would think it's .9 * .67 = 60% on a 40kWh car.

charge_limit_soc: 80,
charge_limit_soc_std: 90,
charge_limit_soc_min: 50,
charge_limit_soc_max: 100,

 

[Andy Black]

I have changed my charge limit "slider" to 80% in the car so that clearly effects the value reported as charge_limit_soc.
It's possible that charge_limit_soc_max is what limits the 40kWh cars to 67% of their 60kWh pack. Would be fun to try on a S40 vid to see what is different.
The charge_limit_soc_std value is what the charge_limit_soc reverts to when the phone app sets a "standard" range or the REST API /vehicles/{id}/command/charge_standard URL is used. Again I would think it's .9 * .67 = 60% on a 40kWh car.

charge_limit_soc: 80,
charge_limit_soc_std: 90,
charge_limit_soc_min: 50,
charge_limit_soc_max: 100,

Hi,

I have a 40 and here's what I get for the charge_status:

charge_limit_soc:72,
charge_limit_soc_std:72,
charge_limit_soc_min:50,
charge_limit_soc_max":72,

--Andy

 

[hans]

Hi,

I have a 40 and here's what I get for the charge_status:

charge_limit_soc:72,
charge_limit_soc_std:72,
charge_limit_soc_min:50,
charge_limit_soc_max":72,

--Andy

Thanks Andy. Looks like a standard range charge and a max range charge are the same on a 40. If we can figure out how to set charge_limit_soc_max to 100, you'll have a 60 ;-)