Model S REST API

[darth_vad3r]

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!

Agreed (for us)!

For them, for the official app, they probably want to keep it awake every time the user does something on the app so it doesn't go to sleep on them and take forever to do the next action.

It's already bad as it is, imagine this ... sleep timer is at T minus 15s to sleep. User opens app and sees current state. User tries to do an action but the car is asleep. Doh! (actually this sounds about how it seems to work today anyways LOL )

But ya, if they made it an option to do a 'peek' type API call that would be cool for non-official-app use.

 

[John Rucker]

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?

Yep you were right the car will set speed = null even if you're still in the car. My poller now keys on:

is_user_present == false && locked == true && charger_actual_current == 0.​

It will then go to a "let car goto sleep" poll cycle.

Ever since the last update (about 4 days ago) the car has not slept one time. I haven't seen this before. My "let car goto sleep" poll is 30 minutes where 12 minutes use to be long enough. Still not sleeping. I think I will reboot the car and see if that helps.

Thanks again for the input!!

 

[Chetanh]

Ahh I would've never guessed the endpoint, fair enough.

-

Seat Heater

Endpoint: api/1/vehicles/{vehicle_id}/command/remote_seat_heater_request
Request Body:

{
"heater":1,
"level":1
}

Where heater is one of the following values:

SeatHeaterFrontLeft: 0,
SeatHeaterFrontRight: 1,
SeatHeaterRearLeft: 2,
SeatHeaterRearLeftBack: 3,
SeatHeaterRearCenter: 4,
SeatHeaterRearRight: 5,
SeatHeaterRearRightBack: 6,
SeatHeater3rdRowLeft: 7,
SeatHeater3rdRowRight: 8

Looks like remote heating can be disabled in the car? One error I've seen is cabin comfort remote settings not enabled.

Low state of charge and door open are other errors that will prevent the command from working.

-

Steering Wheel Heater

Endpoint: api/1/vehicles/{vehicle_id}/command/remote_steering_wheel_heater_request
Request Body:

{
"on": true
}

Hello,
Just started playing around with the TESLA API's.
I was able to use https://owner-api.teslamotors.com/api/1/vehicles/XXXXXXXXX/command/auto_conditioning_start
and
https://owner-api.teslamotors.com/api/1/vehicles/XXXXXXXXX/command/auto_conditioning_stop command to turn the remote climate ON and OFF.
I verified that it worked by looking at the Controls section of the app.

However when i try to turn driver seat heating on remotely, i get the result = true but the seat heater does not turn on (no red bars on the app) Any clues?


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

https://owner-api.teslamotors.com/api/1/vehicles/XXXXXXXXXXXXXX/command/remote_seat_heater_request

heater = 0
level = 3



I was also able to validate that its not on using the data_request/climate_state command (here is the output):

"response": {
"battery_heater": false,
"battery_heater_no_power": null,
"climate_keeper_mode": "off",
"driver_temp_setting": 22.5,
"fan_status": 2,
"inside_temp": 22.9,
"is_auto_conditioning_on": true,
"is_climate_on": true,
"is_front_defroster_on": false,
"is_preconditioning": true,
"is_rear_defroster_on": false,
"left_temp_direction": 45,
"max_avail_temp": 28.0,
"min_avail_temp": 15.0,
"outside_temp": 24.0,
"passenger_temp_setting": 22.5,
"remote_heater_control_enabled": true,
"right_temp_direction": 48,
"seat_heater_left": 0,
"seat_heater_right": 0,
"side_mirror_heaters": false,
"smart_preconditioning": false,
"timestamp": 1569608883890,
"wiper_blade_heater": false
}
}

 

[Gesteur]

Hi guys,

did anyone success using websockets with java for tesla summon?
I tried different java classes but can't seem to get it working, always get code 401 (Unauthorized).
While I have no issues in connecting using node.js

@SG57
any ideas?

 

[darth_vad3r]

Hi guys,

did anyone success using websockets with java for tesla summon?
I tried different java classes but can't seem to get it working, always get code 401 (Unauthorized).
While I have no issues in connecting using node.js

@SG57
any ideas?

Try different tokens from the vehicles response, they seem to rotate them frequently? EDIT: Oh wait, it works with node not java? Hmm, dunno.

 

[John Rucker]

I'm trying to understand what drives the charge rate in MPH used by Tesla. I have been recording charge cycles from my model X when it is connected to my Level 2 home charger (48 amps). It looks like there is a rough average of 355 watts of power per MPH of charge. I'm guessing this may change based on various factors. I expected it to change as the battery was getting close to being full but it didn't as you can see from the light blue line (Watts per MPH of charge) at the top of the graph. Other than the obvious peak it stayed between 300 to 350 watts. Will this ratio of watts per MPH change with temperature? Will it change if the car is deeply discharged? I wonder what the differences are between a model 3, X, and S? I have been searching on google but can’t come up with any numbers??

 

[Gesteur]

Hi guys,

did anyone success using websockets with java for tesla summon?
I tried different java classes but can't seem to get it working, always get code 401 (Unauthorized).
While I have no issues in connecting using node.js

@SG57
any ideas?

found the issue, apparently providing the username:token in the URL doesnt work in Java like it works in JS.

the URL needs to be

"wss://streaming.vn.teslamotors.com/connect/" + vid

i'm using OkHttpClient to open the websocket and the authentication needs to be defined as following:
the details of how to define wss can be found in timodor's JS repo.

OkHttpClient wsClient = new OkHttpClient.Builder().authenticator(new Authenticator() {
    public Request authenticate(Route route, Response response) throws IOException {
        String credential = Credentials.basic("username", "token");
        return response.request().newBuilder().header("Authorization", credential).build();
    }
}).build();

 

[FlasherZ]

I'm trying to understand what drives the charge rate in MPH used by Tesla. I have been recording charge cycles from my model X when it is connected to my Level 2 home charger (48 amps). It looks like there is a rough average of 355 watts of power per MPH of charge. I'm guessing this may change based on various factors. I expected it to change as the battery was getting close to being full but it didn't as you can see from the light blue line (Watts per MPH of charge) at the top of the graph. Other than the obvious peak it stayed between 300 to 350 watts. Will this ratio of watts per MPH change with temperature? Will it change if the car is deeply discharged? I wonder what the differences are between a model 3, X, and S? I have been searching on google but can’t come up with any numbers??

Model X uses 340 Wh/mi as the power efficiency standard for Model X (or did, back in 2016, prior to the new drivetrain).

 

[darth_vad3r]

Model X uses 340 Wh/mi as the power efficiency standard for Model X (or did, back in 2016, prior to the new drivetrain).

@John Rucker ... This ^^^ ... It is a constant depending on your model and trim. E.g my Model 3 SR+ uses 219 Wh/mi

Charger voltage * current / (219 Wh/mi) == charge ‘speed’ in mph

EDIT: No, that’s wrong for the API. The API’s charger voltage is the AC side. Above is correct for the DC side, but there’s about a 5% loss of power from the AC -> DC, and then there is (for model 3) about 250 W of overhead just to have the car ‘on’. The charge speed is the net power charging the battery after all these other factors are considered. If you look at the charge power, it will be the AC-side VxA, if you look at the drive state power (negative while charging) that number matches the DC-side.

Play with the amp setting in the car a bit and you can see various transition points like for example, where the charge power is 6, but drive state power is -5.

 

[John Rucker]

Model X uses 340 Wh/mi as the power efficiency standard for Model X (or did, back in 2016, prior to the new drivetrain).

@John Rucker ... This ^^^ ... It is a constant depending on your model and trim. E.g my Model 3 SR+ uses 219 Wh/mi

Charger voltage * current / (219 Wh/mi) == charge ‘speed’ in mph

EDIT: No, that’s wrong for the API. The API’s charger voltage is the AC side. Above is correct for the DC side, but there’s about a 5% loss of power from the AC -> DC, and then there is (for model 3) about 250 W of overhead just to have the car ‘on’. The charge speed is the net power charging the battery after all these other factors are considered. If you look at the charge power, it will be the AC-side VxA, if you look at the drive state power (negative while charging) that number matches the DC-side.

Play with the amp setting in the car a bit and you can see various transition points like for example, where the charge power is 6, but drive state power is -5.

Love this forum!

In going to fuel economy.gov (EPA site for fuel economy) I can see the advertised MPGe for my X is based on 35kWh/100 mi or 350 watts per mile. See this link at fuel economy.gov. That is what I was looking for I can now lookup various models and years and get their target MPGe.

Darth, thanks for the info on the drive state power. That brings everything together. Now I can see what is going into the battery vs what is being used by other loads in the car like the CPU and HVAC. I have added that to my logging. This should help me find my answer.

 

[markb1]

I thought the MPH charge rate was some sort of average, and not very useful. But maybe something has changed?

 

[darth_vad3r]

Love this forum!

In going to fuel economy.gov (EPA site for fuel economy) I can see the advertised MPGe for my X is based on 35kWh/100 mi or 350 watts per mile. See this link at fuel economy.gov. That is what I was looking for I can now lookup various models and years and get their target MPGe.

Darth, thanks for the info on the drive state power. That brings everything together. Now I can see what is going into the battery vs what is being used by other loads in the car like the CPU and HVAC. I have added that to my logging. This should help me find my answer.

Remember that the EPA site is all AC-out-of-the-wall power. The car consumption numbers on the trip meter are all DC-out-of-the-battery power. The API numbers let you see AC-into-the-charger (which should essentially match AC-out-of-the-wall) and DC-into-the-battery (which may not match DC-out-of-the-battery power). There seem to be some losses/adjustments the car uses internally when ticking down the battery gauge that looks like it might be for DC-into-the-battery vs DC-out-of-the-battery, but it could also just be other fudge factors going on, or a combination of things.

e.g. the speed (charge rate) matches 219 Wh/mi for me, but consumption is closer to 209 Wh/mi (for "mi" here being rated miles).

I thought the MPH charge rate was some sort of average, and not very useful. But maybe something has changed?

Ya, I've read that it used to be that, but it changed before I got my 3. It's been instantaneous rate and not average for at least 6 months.

 

[darth_vad3r]

Darth, thanks for the info on the drive state power. That brings everything together. Now I can see what is going into the battery vs what is being used by other loads in the car like the CPU and HVAC. I have added that to my logging. This should help me find my answer.

Specifically for logging, the charge rate in mph is much more accurate than drive state power. It has one decimal place while power has none.

If you log both while charging, and divide the mph by the constant Wh/mi for your trim, you'll find that you get a number with more precision, and that it should ALWAYS round to the no-decimal-place drive state power (if you have your constant correct).

I made some charts for charging efficiency based on this. I used the more-granular charger voltage and amps for the charge power, and I used the more granular charge rate mph than the drive state power.

Roughly speaking for the Model 3, it fits a model pretty well of ~5% AC to DC loss + ~250W overhead (DC). The difference in overhead of car locked with user not present, screen off, is quite significant as well. When I was in the car with screen on the overhead was closer to 350W than 250W (with HVAC, radio, etc all off, just screen on the charge screen).

 

[darth_vad3r]

Anyone know the new API command to open/close the windows?

I see the window state is there now in vehicle_state as fd, fp, rd, rp_window = 0|1.

Same question for climate_state.defrost_mode = 0|1

EDIT:
ps. I randomly tried...

window[s]_vent
vent_window[s]
actuate_window[s]
open_window[s]
close_window[s]
window[s]_[open|close]

No luck.

 

[darth_vad3r]

Anyone know the new API command to open/close the windows?

I see the window state is there now in vehicle_state as fd, fp, rd, rp_window = 0|1.

Same question for climate_state.defrost_mode = 0|1

EDIT:
ps. I randomly tried...

window[s]_vent
vent_window[s]
actuate_window[s]
open_window[s]
close_window[s]
window[s]_[open|close]

No luck.

Ooohhh... instead of "invalid_command" I get unsupported_command for "window_control" hmmm.

 

[luckyj]

Not sure if this has already been pointed out, but I noticed some additional information in the vehicle state regarding software update status/progress:

"software_update": {"expected_duration_sec": 3000, "status": "installing", "download_perc": 100, "version": "2019.32.11.1", "install_perc": 60}

 

[KlokkProjects]

Ooohhh... instead of "invalid_command" I get unsupported_command for "window_control" hmmm.

Open/close windows:
url : teslaAPIcommand + "window_control",
data : {
lat : latitude,
lon : longitude,
command : vent/close
}

Max defrost:
url : teslaAPIcommand + "set_preconditioning_max",
data : {
on : true/false
}

Hope this helps..

 

[darth_vad3r]

Open/close windows:
url : teslaAPIcommand + "window_control",
data : {
lat : latitude,
lon : longitude,
command : vent/close
}

Max defrost:
url : teslaAPIcommand + "set_preconditioning_max",
data : {
on : true/false
}

Hope this helps..

Awesome. So I had the command URL guessed, but they’ve got a few extra params in there in addition to ‘command’. Oh, and I tried vent/close ... but with ‘state’ not ‘command’. I was THIS close

What’s the purpose of lat/long? Does it store location-based memory of the setting??

 

[KlokkProjects]

Awesome. So I had the command URL guessed, but they’ve got a few extra params in there in addition to ‘command’. Oh, and I tried vent/close ... but with ‘state’ not ‘command’. I was THIS close

What’s the purpose of lat/long? Does it store location-based memory of the setting??

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...

 

[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.

Thanks again!