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.
Hi folks, I'm a bit baffled here at the information coming in for my cars from the API. When I ask for vehicle information from the API, I'm getting a bogus set of option codes from the API.

Both my midnight silver Model S and our signature red Model X return the same option_codes for a black Model 3 ?!

Code:
  option_codes: 'AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0',


The mobile app visualizes our cars correctly, so is the option_codes information now just placeholder stuff?

Maybe this is addressed somewhere else, but I didn't find it in a quick search... anyone else see this?

(It's been a really long time since I posted. :) )

-c
 
Hi folks, I'm a bit baffled here at the information coming in for my cars from the API. When I ask for vehicle information from the API, I'm getting a bogus set of option codes from the API.

Both my midnight silver Model S and our signature red Model X return the same option_codes for a black Model 3 ?!

Code:
  option_codes: 'AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0',


The mobile app visualizes our cars correctly, so is the option_codes information now just placeholder stuff?

Maybe this is addressed somewhere else, but I didn't find it in a quick search... anyone else see this?

(It's been a really long time since I posted. :) )

-c

*Every* Model 3 seems to report the same option_codes. It seems they've deprecated that method for Model 3.

I get the same thing on my API call.

The app probably gets the car info from the vehicle_config section.

Nah, stuff like paint colour isn't there. It must get the info out of band from the API based on query to mothership from VIN. Or there's something else in the API we don't know about.
 
I get the same thing on my API call.

The app probably gets the car info from the vehicle_config section.

Ok, so at least I know I'm not going nuts. So it seems every car via the old API is a black Model 3. It messes with my TeslaMS logging.

*Every* Model 3 seems to report the same option_codes. It seems they've deprecated that method for Model 3.

Seems to be for all cars, S/3/X.
 
Hmm, are your S/X cars that used to return correct option codes, or newer (Raven?) that maybe had a newer change that rolled off the line reporting as a "Black 3" from day 1?

Both (2016 sig X with MCU1/AP1, 2018 S with MCU2/AP2.5) used to return correct option codes. Last timestamp I have of the correct option codes was August 8, 2019:
"option_codes" : "RENA,AF02,APF2,APH3,APPB,AU01,BCMB,BP00,BR00,BS00,BTX6,CDM0,CH04,PMNG,CW02,DCF0,DRLH,DSHG,DU00,DV4W,FG02,FMP6,FR04,HC00,HP00,IDCF,INFBP,IX00,LLP1,LP01,ME02,MI03,PF00,PI01,PK00,PS01,PX00,QTFP,RFP2,S32P,SC04,SP00,SR07,ST01,SU01,TIG4,TM00,TR00,UTSB,WTAS,X001,X003,X007,X011,X013,X021,X025,X027,X028,X031,X037,X040,X043,YFCC,MDLS,COUS"

next timestamp I have of the Model 3 replacement was September 13, 2019:
"option_codes" : "AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0"

These are from the same Model S. Not even an id_s change between those two.

An identical option_codes is used on our Model X as well (the model 3 set, post Sept 13).
 
Last edited:
  • Informative
Reactions: darth_vad3r
Both (2016 sig X with MCU1/AP1, 2018 S with MCU2/AP2.5) used to return correct option codes. Last timestamp I have of the correct option codes was August 8, 2019:


next timestamp I have of the Model 3 replacement was September 13, 2019:


These are from the same Model S. Not even an id_s change between those two.

An identical option_codes is used on our Model X as well (the model 3 set, post Sept 13).

I'm also seeing the exact same option code string as you for my 2013 S.
 
I found the option_codes to be untrustworthy a year or two ago. I think they broke sometime and they didn't bother fixing it.

Interesting - mine was pretty reliable until this most recent change between Aug-Sept, on all the cars... ah well, it really didn't do much except to allow for visualization of the car when I went back to look up stuff from my TeslaMS installation.
 
Color is there, as well as everything else needed to render the car images.

Well there you go, even wheel type. For some reason I never noticed it had exterior colour.

Appearance-ish fields of vehicle_config:
Code:
    "vehicle_config": {
      "car_special_type": "base",
      "car_type": "model3",
      "charge_port_type": "US",
      "eu_vehicle": false,
      "exterior_color": "SolidBlack",
      "rear_seat_type": null,
      "rhd": false,
      "roof_color": "Glass",
      "seat_type": null,
      "spoiler_type": "None",
      "sun_roof_installed": null,
      "third_row_seats": "<invalid>",
      "use_range_badging": true,
      "wheel_type": "Pinwheel18"
    },
 
Yep my car's ID changed as well yesterday (2019 Model X). I now lookup the Tesla Car ID based on my VIN every time my node app starts. That should address future changes.

I want to say thanks to @KWReid for the shift_state = Null (car wants to sleep). I implemented that yesterday and it appears to be working well.

My polling logic:
  • If car is asleep poll ever two minutes and check if on-line by reading the /api/1/vehicles endpoint.
  • When car is awake poll every minute and read the charge status from the /api/1/vehicles/mycarid/data_request/charge_state endpoint
    • Also in the same poll cycle check and see if the shift_state = null (indicating the car would like to sleep) at /api/1/vehicles.
    • If it is null change to a 15 minute poll cycle to let the car sleep.
I will be testing this over the next few days. From looking at the Tesla app on my phone it looks like it is updating every five or so seconds. I'm basing this on the little spinning icon that appears in the header right next to my Wi-Fi signal strength icon on my iPhone when I have the Tesla app open. So my once a minute polling shouldn't be a big load I wouldn't think. I can back it off it will not cause a problem. But from what I have been reading on this forum my polling logic seems to be inline with others. Any concerns?

Just as an FYI; My Node.JS app monitors the charging progress and sends it to a physical gauge that hangs on the wall. The gauge displays Battery Charge, Charge Rate, and Time to Full Charge.

With the latest update that came out around 9/22/19. I can no longer depend on the shift_state = null trick to detect when my model X would like to sleep. I know this API is not officially supported by Tesla. But if anyone could suggest they add a "desired_state" to the API that would be fantastic. Something like desired_state = sleep would make it easy to know when we need to backoff the polls. There are a ton of people using this API and we all have to come up with little tricks to figure out when the car would like to sleep.

I'm now using speed = null to determine if the car would like to sleep. All ears if anyone has a reliable way to detect when a vehicle would like to sleep..
 
Last edited:
With the latest update that came out around 9/22/19. I can no longer depend on the shift_state = null trick to detect when my model X would like to sleep. I know this API is not officially supported by Tesla. But if anyone could suggest they add a "desired_state" to the API that would be fantastic. Something like desired_state = sleep would make it easy to know when we need to backoff the polls. There are a ton of people using this API and we all have to come up with little tricks to figure out when the car would like to sleep.

I'm now using speed = null to determine if the car would like to sleep. All ears if anyone has a reliable way to detect when a vehicle would like to sleep..

Doesn't it pretty much always want to sleep 10-12 minutes after you leave and lock the car?

I think there might be times speed is null when your butt is in the seat and you are just waiting for a passenger to get in or out, and might resume driving shortly. I would check if the user is present and the car is locked as a hint.

e.g.
If (not charging) and (user not present) and (car is locked), then try to let it sleep (switch to 'vehicles' monitoring to see if online -> asleep or offline within ~12 minutes).

At least if you check if the user is gone and the car is locked, it's less likely you'll start driving again within the 12 minutes you back off polling vehicle_data?
 
With the latest update that came out around 9/22/19. I can no longer depend on the shift_state = null trick to detect when my model X would like to sleep. I know this API is not officially supported by Tesla. But if anyone could suggest they add a "desired_state" to the API that would be fantastic. Something like desired_state = sleep would make it easy to know when we need to backoff the polls. There are a ton of people using this API and we all have to come up with little tricks to figure out when the car would like to sleep.

I'm now using speed = null to determine if the car would like to sleep. All ears if anyone has a reliable way to detect when a vehicle would like to sleep..

I feel like the most beneficial change Tesla could make to the API is to add a way to query the car without resetting the sleep timer!