Model S REST API

[darth_vad3r]

I guess the command is geo-fenced. Possibly safety related. The easy way is to use the lat/long from the drive_state, but surely it is your phone/watch GPS location that is meant to be used...

Ha, perhaps if you are across the country they figure you shouldn’t vent the windows since you don’t know if it’s pouring rain . ... I may play with this today and report my findings if lat/long matter.

Tried it and window_control worked just fine with only command=[vent|close] with no lat/long specified or included at all.

e.g.
open: /window_control?command=vent
close: /window_control?command=close

... but as actual form data, not in the URL. It does seem to pass it along in the URL to the mothership though, as evidenced by error responses when there are timeouts:

e.g. https://mothership.prd.sjc.vnet:5678/vehicles/<vehicle_id>/user_command/window_control?command=vent&slow_query_time=15

 

[KlokkProjects]

Tried it and window_control worked just fine with only command=[vent|close] with no lat/long specified or included at all.

e.g.
open: /window_control?command=vent
close: /window_control?command=close

... but as actual form data, not in the URL. It does seem to pass it along in the URL to the mothership though, as evidenced by error responses when there are timeouts:

e.g. https://mothership.prd.sjc.vnet:5678/vehicles/<vehicle_id>/user_command/window_control?command=vent&slow_query_time=15

Hmm, that's strange. A lot of reports on Reddit that the lat/lon is needed. The decompiled app also contains an error type to match:
case C.WindowCommandErrorTypes.TOO_FAR_FROM_VEHICLE=(0,N.translate)('window_error_too_far_from_vehicle');break;
Well, if it works, it works. I never tried it without ...

New API Endpoints for V10 Features (Tesla app 3.10.0) : teslamotors

 

[darth_vad3r]

Hmm, that's strange. A lot of reports on Reddit that the lat/lon is needed. The decompiled app also contains an error type to match:
case C.WindowCommandErrorTypes.TOO_FAR_FROM_VEHICLE=(0,N.translate)('window_error_too_far_from_vehicle');break;
Well, if it works, it works. I never tried it without ...

New API Endpoints for V10 Features (Tesla app 3.10.0) : teslamotors

¯\_(ツ)_/¯

Maybe something to do with form data vs JSON command? I'm just using curl with form data. Just tried it right now, vent, close, vent, close ... all worked. Window status changed as per fd_window, etc. in vehicle_state.

 

[ACDriveMotor]

That sounds cool. Have you thought about doing it with Node.JS on a Raspberry Pi? That way your Pi could set at home and monitor everything unattended. If you do it on your phone the app will have to be running all the time in background.

It would be cool if you could trigger a charge from a home automation app like SmartThings.

Just brain storming I know that is not what you asked. Sounds like a fun project.

If you want to do something with NodeJS take a look at my TeslaJS lib.

 

[John Rucker]

If you want to do something with NodeJS take a look at my TeslaJS lib.

Well done sir! Here is a link to ACDriveMotors TeslaJS library. 345 weekly downloads is impressive!! Great documentation! Would have been helpful to have your code as a reference earlier. My node app is about 90% done (just added encryption for the OAuth key based on Amazon KMS). Next on the list is a method to renew my OAuth key in 45 days.

In case your interested my Tesla app is pretty custom, it is designed to run on a WallGauge.com Gauge Data Transmitter (GDT). The GDT is a Raspberry Pi Zero W that functions as a gateway between IOT data sources (in this case my Model X) and a battery powered analog gauge that can hang on the wall. The battery powered gauge I'm working on will show battery charge percentage, projected range, kilowatt hours used to charge battery, estimated cost of the last charge, charge rate in MPH, and time to complete the current charge.

Been working on it for about a month and so far working with the Tesla API has been pretty straight forward. The one thing I would like to improve is detecting when the vehicle would like to sleep. I'm currently using charge current = 0, doors are locked and user not present to trigger a long poll cycle (poll every 12 minutes instead of every minute) to let her sleep. It works pretty good but every now and then the car doesn't go to sleep right away and I can miss the start of a charge cycle because I'm only polling every 12 minutes. It's rare that I miss a charge but it can happen. If you have any input would love to hear it.

Thanks again for reaching out.

 

[ACDriveMotor]

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.



Seems to be for all cars, S/3/X.

I can confirm that the option_codes are now no longer correct or reliable. I've had to update Tesla Control to use VIN decoding for model and options.

 

[TimK]

Maybe this has been mentioned in the previous 138 (!) pages but I've not noticed. I've just grabbed the latest vehicle_data off my car (wanted to check that FDS had been applied) and whilst I'm getting the correct vehicle VIN, my car is now reporting as a Model 3 - Black, with LHD and rear-wheel drive.
The reason this is odd is that I've a Model S 75D Red.
My codes are list as: 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

Anyone else getting weird data today?

 

[markb1]

Maybe this has been mentioned in the previous 138 (!) pages but I've not noticed. I've just grabbed the latest vehicle_data off my car (wanted to check that FDS had been applied) and whilst I'm getting the correct vehicle VIN, my car is now reporting as a Model 3 - Black, with LHD and rear-wheel drive.
The reason this is odd is that I've a Model S 75D Red.
My codes are list as: 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

Anyone else getting weird data today?

This was discussed a couple of pages back. The API now returns the same option codes for everyone. The true config data is in the "vehicle_config" section in the json returned by the "/data" endpoint.

 

[HankLloydRight]

But really, only the configuration needed to render the car images (and a few other things) is in /vehicle_config.. access to the full (original) options list via the API is gone. It's been this way for several months now.

 

[TimK]

But really, only the configuration needed to render the car images (and a few other things) is in /vehicle_config.. access to the full (original) options list via the API is gone. It's been this way for several months now.

Thanks for the info - I'd not realised this.

 

[ACDriveMotor]

Yes it is unfortunate. I was able to get what I needed from decoding the VIN. The one blind spot is now AP hw/sw. For new vehicles you can get it close to correct with model year for the hardware. But for older vehicles where it was a build option there is no reliable way to verify AP hardware.

 

[javawolfpack]

Does anyone have experience with the energy_sites endpoint? Keep getting a 400 error for history or calendar_history with the following response:

{'response': None, 'error': '`kind` is required', 'error_description': ''}

Unclear what the kind is supposed to be, or how it wants it passed. I'm currently hoping I can pull my solar data... wanting to build a tool cost-benefit analysis for a TOU plan w/ PGE if I got Powerwalls. It will be more accurate if I can get real daily data from PGE & Tesla... Unclear how the PGE API works, think I'm pending approval there currently.

 

[Klaus]

Can anyone of the experts here point me to a quick and dirty code snippet that I could use to start the AC in the Tesla? I'd like to run this triggered by a calendar event so the car warms up in the morning on days I’m working.

I used to do this with Visible Tesla which no longer runs in Mohave. Using the in car prep doesn’t work well because of my irregular work schedule.

Thanks!

 

[ACDriveMotor]

Can anyone of the experts here point me to a quick and dirty code snippet that I could use to start the AC in the Tesla? I'd like to run this triggered by a calendar event so the car warms up in the morning on days I’m working.

I used to do this with Visible Tesla which no longer runs in Mohave. Using the in car prep doesn’t work well because of my irregular work schedule.

Thanks!

If you are comfortable with NodeJS you can try the TeslaJS library. There are samples that show how to do things like turn on the AC.

 

[ACDriveMotor]

Anyone know what command changes remote_heater_control_enabled to true? I am testing seat heater adjustment but on my car remote adjustments seem to be disabled.

 

[ACDriveMotor]

Also, anyone know the command to enable dog mode?

 

[shill]

Since that's not something you can do from the app, I doubt there's an API endpoint for that.

 

[markb1]

Now that the service center updated my Model S from V8 to V10, I've noticed that my car isn't sleeping much.

For instance, this morning, it charged for an hour starting at midnight, then went to sleep soon after. At about 4:45 am, it woke up and hasn't gone to sleep, since! I haven't polled the car since about 1am, though I continue to poll the vehicle list. At about 11am, I killed my streaming script, since I thought that might have something to do with it. But no, it's still awake!

I saw the same pattern yesterday. The car was asleep for a few hour after charging, but it was awake the rest of day!

What's going on here? Has anyone else seen behavior like this?

 

[John Rucker]

Now that the service center updated my Model S from V8 to V10, I've noticed that my car isn't sleeping much.

For instance, this morning, it charged for an hour starting at midnight, then went to sleep soon after. At about 4:45 am, it woke up and hasn't gone to sleep, since! I haven't polled the car since about 1am, though I continue to poll the vehicle list. At about 11am, I killed my streaming script, since I thought that might have something to do with it. But no, it's still awake!

I saw the same pattern yesterday. The car was asleep for a few hour after charging, but it was awake the rest of day!

What's going on here? Has anyone else seen behavior like this?

Yes I have seen similar behavior with my update to V10. I have also seen this after previous updates. It seems like after an update it takes 3 or 4 days for the car to settle back down into a normal sleep cycle. What does your poller use to determine when the car would like to sleep? I had to change my logic with version 10.

What does your streaming script do? Just curious.

As an FYI I have a model x with a gen 3 cpu (I bought it in August).

 

[markb1]

Yes I have seen similar behavior with my update to V10. I have also seen this after previous updates. It seems like after an update it takes 3 or 4 days for the car to settle back down into a normal sleep cycle. What does your poller use to determine when the car would like to sleep? I had to change my logic with version 10.

What does your streaming script do? Just curious.

As an FYI I have a model x with a gen 3 cpu (I bought it in August).

The streaming script is what determines whether the car is active and should be polled. It uses the websocket streaming API. It has proved to be an extremely reliable way to prevent my polling script from keeping my car awake, but it doesn’t work reliably on all cars.