Model S REST API

[mnno]

Use command "CHARGING_AMPS" with parameter charging_amps=value (where value = between 5-32 (EU)).

I've been playing with this and I can even set the charging amps to 1. Interestingly, values between 1 and 3 amps get bumped to a value 1 amp higher than requested (Model 3 with 2021.36.5.5)

$ python3 ./cli.py -g|grep current
2021-11-09 11:23:08,946 - root - INFO - 1 product(s), 1 selected
        "charge_current_request": 3,
        "charge_current_request_max": 16,
        "charger_actual_current": 4,
        "charger_pilot_current": 16,
            "current_limit_mph": 71.329838,
$ python3 ./cli.py -g|grep current
2021-11-09 11:23:24,458 - root - INFO - 1 product(s), 1 selected
        "charge_current_request": 2,
        "charge_current_request_max": 16,
        "charger_actual_current": 3,
        "charger_pilot_current": 16,
            "current_limit_mph": 71.329838,
$ python3 ./cli.py -g|grep current
2021-11-09 11:23:42,536 - root - INFO - 1 product(s), 1 selected
        "charge_current_request": 4,
        "charge_current_request_max": 16,
        "charger_actual_current": 4,
        "charger_pilot_current": 16,
            "current_limit_mph": 71.329838,

 

[KlokkProjects]

Hi. Does anyone know the correct parameter for the set_cabin_overheat_protection command? I know the values are On, FanOnly and Off, but can't seem to find the correct parameter name.
Second question; How do I detect vehicles equipped with the bioweapon defence filter from the Tesla API response? I need it to hide the bioweapon command on vehicles that do not have this feature. Thanks...

 

[gravastar]

Second question; How do I detect vehicles equipped with the bioweapon defence filter from the Tesla API response? I need it to hide the bioweapon command on vehicles that do not have this feature. Thanks...

I get the following from carson when I dump it on my MS. My M3P doesn't have the attribute at all so I guess if bioweapon_mode exists at all??? Just a guess.

'climate_state': {'allow_cabin_overheat_protection': True,
                   'auto_seat_climate_left': False,
                   'auto_seat_climate_right': False,
                   'battery_heater': False,
                   'battery_heater_no_power': None,
                   'bioweapon_mode': False,

 

[Scelto]

Has anybody discovered whether the new(ish) Sentry video stream has been exposed in the API yet?

I found a community effort to document the streaming API but it seems dead

 

[markb1]

Has anybody discovered whether the new(ish) Sentry video stream has been exposed in the API yet?

I found a community effort to document the streaming API but it seems dead

That "streaming API" refers to the API that provides rapid updates of the car's GPS location and vital data. The issue you want to track is this:

Remote Sentry Live View · Issue #464 · timdorr/tesla-api

The Tesla app will now support streaming live video from the car's cameras. Will this api be updated to allow streaming sentry video feed?

github.com

Unfortunately, there's not much info there, at least not yet. The repo itself is not dead.

 

[KlokkProjects]

I get the following from carson when I dump it on my MS. My M3P doesn't have the attribute at all so I guess if bioweapon_mode exists at all??? Just a guess.

'climate_state': {'allow_cabin_overheat_protection': True,
                   'auto_seat_climate_left': False,
                   'auto_seat_climate_right': False,
                   'battery_heater': False,
                   'battery_heater_no_power': None,
                   'bioweapon_mode': False,

Great! Exactly what I needed. Thx!

 

[PCMc]

Great! Exactly what I needed. Thx!

I would not assume that a reply of 'bioweapon_mode': False indicates that the vehicle does not have bioweapon mode / filter installed.

My 2016 MS90D does have the HEPA filter and bioweapon mode and I see the exact same response. I think the False reply is simply indicative of it's not turned on and not necessarily indicative of whether the feature exists on the vehicle.

I think in the ideal world you would look at the option codes and check for the $AF00 / standard filter versus $AF02 / HEPA filter, but it does not appear the API is returning the true option codes any more, but provides what others have indicated are just a default, standard list of Model 3 option codes.

When I pull my true list of option codes from my on-line account page (embedded in the code behind the vehicle image), it does correctly show $AF02 for my car, but the API response incorrectly displays $AF00. Same situation for some of the other option codes, like API replying that my car is a Model 3 (MDL3) versus Model S (MDLS).

 

[KlokkProjects]

I would not assume that a reply of 'bioweapon_mode': False indicates that the vehicle does not have bioweapon mode / filter installed.

My 2016 MS90D does have the HEPA filter and bioweapon mode and I see the exact same response. I think the False reply is simply indicative of it's not turned on and not necessarily indicative of whether the feature exists on the vehicle.

I think in the ideal world you would look at the option codes and check for the $AF00 / standard filter versus $AF02 / HEPA filter, but it does not appear the API is returning the true option codes any more, but provides what others have indicated are just a default, standard list of Model 3 option codes.

When I pull my true list of option codes from my on-line account page (embedded in the code behind the vehicle image), it does correctly show $AF02 for my car, but the API response incorrectly displays $AF00. Same situation for some of the other option codes, like API replying that my car is a Model 3 (MDL3) versus Model S (MDLS).

No, that was not what gravastar meant.

1. bioweapon_mode=non existent -> bioweapon not installed
2. bioweapon_mode=False -> bioweapon mode off
3. bioweapon_mode=True -> bioweapon mode on

My Model 3 does not have the bioweapon_mode in the response at all.

 

[KlokkProjects]

Hi. Does anyone know the correct parameter for the set_cabin_overheat_protection command? I know the values are On, FanOnly and Off, but can't seem to find the correct parameter name.

I am able to turn on cabin protection mode by using argument "on" = true (or any other value actually). Value false or 0 turns it off. I'm still at a loss on how to turn on the "FanOnly" mode. I've tried key/value combination like "fan_only" = true (and FanOnly, fanonly, fan, only_fan, no_ac etc.)...

Anyone???

 

[PCMc]

Is anyone else suddenly having problems with the login / oauth process today?

I found my script today suddenly stop pulling data. I've tried restarting using my save token and not getting any response back when I try to get vehicle_dict / vehicle_id info.

Questioned whether something might have happened with my token expiring or needing to restart session. When I try doing that logging in from step 1 / user email/password, I'm running into timeout / failing after my limit of seven retries. Just wondering if something has changed again in the API authentication process like happened around this time a year ago???

 

[goRt]

Is anyone else suddenly having problems with the login / oauth process today?

I found my script today suddenly stop pulling data. I've tried restarting using my save token and not getting any response back when I try to get vehicle_dict / vehicle_id info.

Questioned whether something might have happened with my token expiring or needing to restart session. When I try doing that logging in from step 1 / user email/password, I'm running into timeout / failing after my limit of seven retries. Just wondering if something has changed again in the API authentication process like happened around this time a year ago???

Mine expired in the middle of the night (before the 45 day expiration), but my refresh script took care of this without intervention.
Something definitely happened as one of the hosted solutions reported 4k expired tokens

 

[PCMc]

Mine expired in the middle of the night (before the 45 day expiration), but my refresh script took care of this without intervention.
Something definitely happened as one of the hosted solutions reported 4k expired tokens

Thanks! I had just automatically refreshed my token 6 days ago and hadn't considered trying to refresh it again. I just manually forced the refresh and that gets me back up and running.

I've been running continuously off or automatically refreshing token for 6-7 months. Have you aware of anything in the full step 1 ~ 4 login process has changed over that time? Trying to figure out if separately I have something I need to update in those steps in case I do ever need to do the full email/password login process again.

Thanks again. You just saved me a ton of time trying to fumble some of the github sites, etc., to try and figure out what might have happened.

 

[markb1]

I ran into the same issue. Token became invalid, long before expiration. I guess I will need to update my script for this possibility.

 

[PCMc]

I ran into the same issue. Token became invalid, long before expiration. I guess I will need to update my script for this possibility.

@markb1 or @goRt - what do you anticipate looking for in a script to understand that the token has become invalid in situations like this?

Is there a specific response to the data call that you'd expect? In my case I just happened to notice that my daily wake-up first thing this morning failed to return any values. I unfortunately to not save the actual response, just parse out the specific values from inside the response that I want. While I could build in logic that after some number of repeat attempts of no data I just go ahead and renew the token just in case that's the problem, but not sure how I isolate this issue from Tesla server being down or my car being in location where doesn't have cellular connection back to Tesla server.

If not, then I'll probably just create a hook where I can manually ask the logger to refresh the token without having to manually stop and trick it like I ended up doing. I have some other switches built and adding one for this wouldn't be too difficult for me the way I've structured my python code.

Thanks again for your help. I appreciate your willingness to help out some us whose skills in this area are more than a tad rusty, nowhere up to your level, speaking as a someone that starting out programming analog computers and then programming in FORTRAN.

 

[markb1]

@markb1 or @goRt - what do you anticipate looking for in a script to understand that the token has become invalid in situations like this?

Is there a specific response to the data call that you'd expect? In my case I just happened to notice that my daily wake-up first thing this morning failed to return any values. I unfortunately to not save the actual response, just parse out the specific values from inside the response that I want. While I could build in logic that after some number of repeat attempts of no data I just go ahead and renew the token just in case that's the problem, but not sure how I isolate this issue from Tesla server being down or my car being in location where doesn't have cellular connection back to Tesla server.

If not, then I'll probably just create a hook where I can manually ask the logger to refresh the token without having to manually stop and trick it like I ended up doing. I have some other switches built and adding one for this wouldn't be too difficult for me the way I've structured my python code.

Thanks again for your help. I appreciate your willingness to help out some us whose skills in this area are more than a tad rusty, nowhere up to your level, speaking as a someone that starting out programming analog computers and then programming in FORTRAN.

When the token is expired, I get back a 401 status code from the HTTP request, which is the standard code for unauthorized. So I'll just kick off a renewal if I see that. I'll probably add some protection against trying to renew the token over and over again, if for some reason I keep getting 401 after renewal. Not sure how likely that is.

 

[markb1]

Just FYI, the legacy /data endpoint seems to be gone. I've been getting 404 on that for a few days. I switched my scripts over to the /vehicle_data endpoint (which seems to have been around for a while), and I'm back in business.

 

[PCMc]

I have commented recently about seeing quirky behavior from the values provided in the charge_state return values for ['charge_miles_added_rated'] and ['charge_energy_added']. What I'd see is these values would not start incrementing right away when charging begins, but would only start incrementing part way through the charging session. Result is that the final values when charging completes do not reflect the correct totals, e.g., miles_added values does not equal the difference in ending - starting miles.

I saw this show up again when I charged yesterday. My charging session went from 138.06 to 216.91 rated miles (78.85 RM added) yet the charge_miles_added_rated value only equals 65.0.

Now what appears to have happened is I installed a new software update a few days ago. At that time my car was sitting at 152.11 RM. So it appears that the 'zero point' for calculating the charge_miles_added_rated value seems to be from the value of 152.11 RM that existed when software update was installed. Doing the math from that point gives 216.91 - 152.11 = 64.80. That's slightly off the actual value returned by the API of 65.0, but what I've observed in the return value from the API is only returned at 0.5 mile increments.

Now the other thing I'm seeing is the energy_added value reported by the API get does not match what Tesla is reporting in the official Tesla app under charging stats. The app shows my session with a total of 22 kWh yet the value returned from the API call is 18.47 kWh.

Anyone know of new/different API GET requests that Telsa appears to be using for their App? I tend to work from what I see documented in the Tim Dorr tesla-api.timdorr.com site and getting everything from the single vehicle_data GET request to pull all the individual data groups in one call.

Anyone else looked closely at these values in the charge_state data group and noticed similar cases where they don't seem to reset correctly or the energy_added value doesn't match what you see reported in the Tesla app Charge Stats screen?

 

[focher]

There appear to be a couple of other API projects. Maybe check those to see if they cover something that the Tim Dorr documentation doesn't.

https://teslaapi.dev
https://www.teslaapi.io

 

[PCMc]

There appear to be a couple of other API projects. Maybe check those to see if they cover something that the Tim Dorr documentation doesn't.

https://teslaapi.dev
https://www.teslaapi.io

My understanding is the https://www.teslaapi.io site was the precursor to and has been superseded by the Introduction - Tesla JSON API (Unofficial) site. If you look at the teslaapi.io site you'll see it's not been updated with revised OAuth2 login process that was rolled out last year.

I've just gone through the https://teslaapi.dev site and it appears to be someone that's put their own API wrapper around Tesla's API. They refer to their system as Smartcar, so what they document is how you can ping their system for certain items. They turn around and then ping Tesla directly to return to you the few pieces of data that their calls are to provide. Some of this appears to be set up so someone using their system could write an application to work with multiple types of vehicles and not have to worry about the differences in the API for each unique manufacturer. Some of their calls, like read_engine_oil, clearly have nothing to do with a Tesla. While they document the calls to their API, I find nothing in their document which actually shows the Tesla native API calls. That's understandable as what they are trying to do is get you to buy their manufacture/platform agnostic developer kit.

Appreciate the suggestions, but don't see anything in these that give me anything more than the timdorr site which I've always viewed as the official 'unofficial' reference doc for Tesla's API.

 

[markb1]

My token renewal started failing a few days ago with an "unsupported grant type" error. It turns out, the auth sequence has been simplified, as discussed here: Auth page goes 401 · Issue #548 · timdorr/tesla-api

You no longer exchange the bearer token for the access token, and instead just use the bearer token. (If following these, skip step 4.)

That also means that you need to renew every 8 hours, rather than every 45 days.