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.
the negative value for charger_power (-52kW) maybe was what they saw, or 0/0A. I guess fast_charger_present means to look at different values

Supercharging bypasses the onboard charger because its already a DC source.

That means that "charger_actual_current" and "charger_pilot_current" are meaningless values.

The phone apps and console display the "battery_current" value as Amps during supercharging. The negative value for "charger_power" seems accurate when checked against the values for current and voltage so the negative number must indicate the charger bypass somehow.

I display the absolute value of charger_power and battery_current when supercharging.

What is interesting is that the phone apps never display "battery_current" during AC charging. I think it still shows a meaningful value, which is how much DC current the battery is getting after the loss from going through your onboard charger.
 
I got 4.5 today and while I was in my server code fixing the door ajar alerts (now 0 instead of false), I decided to play around a bit with the charge limit.

There appears to be a 'command/set_charge_limit' that is accepted and sets the charge limit to the min of 50. I'm assuming that it takes an argument of some sort to set the value, but my first dozen or so guesses didn't work. Just putting this out there in case someone else is clever enough to guess the parameter name :)

Edit: OK, I wasn't willing to quite leave it there. I tried [ "soc", "limit", "state", "value", "charge", "level", "max", "percent", "percentage" ] individually and in all combinations with an underscore in a script and none seemed to work...
 
Last edited:
OK, I wasn't willing to quite leave it there. I tried [ "soc", "limit", "state", "value", "charge", "level", "max", "percent", "percentage" ] individually and in all combinations with an underscore in a script and none seemed to work...

"daily" maybe?

What are you calling exactly?

../command/set_charge_limit?percent=80

or something like the sunroof "move" commands like this...

../command/set_charge_limit?state=max&percent=80
 
@Banahogg - Let me know if you have any luck with the amperage limit (for the currently plugged in charging location). I was going to write an app (still might write it) that would be "much improved" or "worth doing" (still haven't decided) once/if I get a way to manipulate that via REST.
 
"daily" maybe?

What are you calling exactly?

../command/set_charge_limit?percent=80

This form. I'll have to try the other one.

@Banahogg - Let me know if you have any luck with the amperage limit (for the currently plugged in charging location). I was going to write an app (still might write it) that would be "much improved" or "worth doing" (still haven't decided) once/if I get a way to manipulate that via REST.

I believe this is for the maximum charge percentage for the slider that replaced standard/range, not for charge amperage. You may have some luck poking around for other set_ endpoints with similar names to returned state values (seems to be 404 if the endpoint doesn't exist but 302 redirecting to the top if you use it wrong)
 
Crap - 302 actually means "stupid typo in testing script making all the URLs malformed"...

- - - Updated - - -

OK, after fixing my script and following hans' suggestion, I have it:

command/set_charge_limit?state=set&percent=#{charge_limit_percent}

It appears to be reflected correctly in the charge_state query, but I haven't confirmed in the car that it changes the UI correctly.

And to confirm the error handling:

- Bad endpoint (command/set_charge_monkey) - 302 redirect to the top-level page
- Bad arguments (command/set_charge_limit&monkey) - returns success and sets the charge limit to 50
 
Thanks for the update, but now I'm confused. In your bad argument example, it sounds probing can be "dangerous" meaning you don't have a way to probe with invalid arguments to test whether an API is exists without actually triggering it to invoke.

- - - Updated - - -

I opted to abort any probing involving the word "range". I haven't done phrase combination building yet, but just from probing names, names with set prefix, word from name, and word from name with set prefix only yielded one positive hit so far:

Probing names:
...
command/charge_port_door_open?abc=123
-> OK
{"reason":"charging","result":false}
...

"Names" is all the names coming from the name-value pairs returned from known queries (charge_state, climate_state, etc.).
 
Two word phrase-building discovered (on its own) "set_charge_limit" that you already found. And, sure enough, "abc=123" as the parameters was interpreted as "set to 50%".

?percent=xx works.

191:~>tesla set_charge_limit\?percent=80
{
"reason": "",
"result": true
}

From the output of charge_state:
"charge_limit_soc": 80,

And it immediately started charging.

I've noticed odd interactions with charge_standard, though -- if charge_limit_soc > charge_limit_soc_standard, then calling charge_standard will result in the car setting charge_limit_soc to the standard threshold. However, if charge_limit_soc < charge_limit_soc_standard, then calling charge_standard will fail with reason "already_standard" and it will not raise the threshold. I'm guessing this will eventually be removed anyway, just noting the odd interaction.

- - - Updated - - -

Here's another caveat... setting the percentage to anything over 90 results in the car setting it to 100 (full range). You are not permitted to specify a percentage greater than 90, if you do it goes into range mode.
 
I've limited my probing to these words:
charging
state
charge
limit
min
max
to
battery
power
fast
charger
level
current
time
rate
enable
setting
auto
status
hour

Three word phrase probing is 20% done after a few minutes. No hits yet.

Update: 100%, no hits.

- - - Updated - - -

Beginning 3 word probe with all 92 words.
 
Last edited:
What platform are you running this on? I had to workaround an issue on windowsphone and the streaming api when the car is not moving (no data + not providing a content-length) which results in an out of memory exception you can't catch. The non-phone http stacks don't have the bug.

- - - Updated - - -

- - - Updated - - -

Does anyone have a snapshot of charge_state data while supercharging? I had a report from someone that they data looked wrong from my app while supercharging... There is a supercharger somewhat near me now, but 2 hours driving to get there and back to collect this is a little out of the way :)

I'm using Windows Phone. I seem to get the issue you describe above. How did you fix?

EDIT:
I switchted to using StreamSocket and that seems to work.
 
Last edited:
I updated my teslams javascript library on GitHub and added the capability to set the charge limit from the command line using "teslacmd -R <percent limit>".
Excellent. Thanks for that. I love the library and am using it for my personal web portal project. Tracking location and other stats - visualizing them on a map.
I'm not planning to turn this into a public site because of the user credential concern... but I might put my code up on github as well once it's cleaned up a bit more... I'm not exactly a JS developer - much more a C programmer :) ... maybe this will get some people with better JS skills interested in helping me drive this further.
 
Quick question: how long can you stream from the streaming API. For me the stream simply stops after a while. I'm wondering if I have a subtle bug somewhere in my code (based on streaming.js) or if this is a known limitation...

I stream for days and days using streaming.js. Each http long poll is 2 minutes long. The security token expires every 15 minutes so my streaming code checks for auth failures and reauthenicates to get a new token.
 
Determining whether HVAC is running

I'm trying to determine whether the HVAC system is running (heating or cooling) and have been using is_auto_conditioning_on. It seems that this only applies to cooling and doesn't indicate whether the car is being heated. Is there a reliable way to determine whether the heat is on? I suppose I could check whether (inside_temp < target && fanspeed > 0). Is there something more direct?


 
I stream for days and days using streaming.js. Each http long poll is 2 minutes long. The security token expires every 15 minutes so my streaming code checks for auth failures and reauthenicates to get a new token.
Thanks for verifying that. My code is based on streaming.js so I clearly "improved" it in a creative way. I need to compare what I have now to your original and see where I went wrong. Maybe the reauthentication after 15 minutes is what fails... I need to look at the timestamps in my log file but that sounds about right.
 
Hi all, I am just getting started playing with this stuff, using hans's library as as an entry point (THANKS, Hans!).

A question: It looks like the API, as documented by this group, only covers the functions exposed in the phone app at this point. I am wondering if there might be other functions that could be probed for by those who have built robots for the purpose. In particular, it would be cool if there was a way to remotely change charging current. Has anyone looked at that? Any other guesses people are pursuing?