Model S REST API

[green1]

2 new fields turned up today in vehicle_state after a software update:
spoiler_type
autopark_state_v2

Neither apply to my pre-AP car so values not valid.

likely spoiler_type is really for MX (fixed on the lower end ones, adjustable on the higher tier cars)
Autopark state v2... no idea...

 

[FlasherZ]

likely spoiler_type is really for MX (fixed on the lower end ones, adjustable on the higher tier cars)
Autopark state v2... no idea...

I don't see autopark_state_v2, I still have just autopark_state:

{
        "vehicleState" : {
                "api_version" : 3,
                "autopark_state" : "standby",
                "spoiler_type" : "Active",
        }
}

 

[TitanP90D]

Trying to get summon to work with the NodeJS sdk. Any ideas?
Summon · Issue #100 · hjespers/teslams · GitHub

I tried Allen's suggestion of latitude/longitude to lat/lng still getting same error.

 

[AllenWong]

Trying to get summon to work with the NodeJS sdk. Any ideas?
Summon · Issue #100 · hjespers/teslams · GitHub

I tried Allen's suggestion of latitude/longitude to lat/lng still getting same error.

Your error message still suggests that your Lat/Lon info is wrong. Are you sure your "yourlat" and "yourlong" variables are correct? Try hard-coding your car's GPS coordinates, straight from Tesla's query on the car's location just to test if it works in the first place.

 

[TitanP90D]

Your error message still suggests that your Lat/Lon info is wrong. Are you sure your "yourlat" and "yourlong" variables are correct? Try hard-coding your car's GPS coordinates, straight from Tesla's query on the car's location just to test if it works in the first place.

Thanks for the suggestion. That's exactly what I tried directly from the -d command that pulls car location.
I'm thinking maybe some sender Lat/lng is needed?

even checked the lat/lng on google maps zooms right spot on to my garage. LTE reception maybe?

 

[thimel]

One button climate control turn on

Has anyone developed or is willing to develop a simple web site that just turns on the climate control when one goes to that site. That allows one to put a bookmark icon on the home screen and turn on the climate control with a single button press. Someone did this for the LEAF and it avoids having to wait for the Nissan app to start up and log n. While the Tesla app is faster than Nissan's, it would still be nice to have this most used feature available with a single button press and no waiting. For the LEAF, the person who did it was willing to put the script on his own server if you were willing to trust him with your login credentials or he gave clear directions about how to install it on your own server. If this already exists, I'd appreciate a pointer to it. If someone is willing to write it, I can find amd give a pointer to what was done for the LEAF, if that would help.

I found a way to make a single button press on an Android phone turn on the climate control. I use the Tasker app that I already owned and then the AutoInput plug-in for it that cost less than $2. Basically I use them to start the Tesla app and then "press" the necessary buttons. AutInput is smart enough to wait until the right screen shows up before trying to press a button. For me, this was much easier to implement than writing an app or setting up a server using the REST API.

 

[wayner]

What's the best practice around managing your token when making API calls?

So far I have just been hardcoding the token into my Python files but this isn't the best way to do it. Should I store it in a text file and just read the text file whenever I need it?

And what is the best way to test to see if the token is still good? Should I put some error trapping around each call to the tesla API server or should I just do a test call at the top of my code and then retrieve a new token if the old one has expired?

Or should I just run a cron job every day to test the token and then update it if it has expired?

 

[tliving]

What's the best practice around managing your token when making API calls?

So far I have just been hardcoding the token into my Python files but this isn't the best way to do it. Should I store it in a text file and just read the text file whenever I need it?

And what is the best way to test to see if the token is still good? Should I put some error trapping around each call to the tesla API server or should I just do a test call at the top of my code and then retrieve a new token if the old one has expired?

Or should I just run a cron job every day to test the token and then update it if it has expired?

I cache the token in a json file and then feed it back. If the connection doesn't establish I re-try without the token.

I've actually open sourced the python code I did, see this GitHub repo:
GitHub - the-mace/evtools: A collection of python code for monitoring SolarCity and Tesla

This code has been running for 6+ months and has been super stable through many software updates etc.

 

[wayner]

Thanks - much of the code that I have found in the past was made obsolete by the auth changes that happened about a year ago but your stuff is very current it looks as you even include home link commands.

Does anyone know if there is a way to set the scheduled charge time via the API? It looked like this feature was coming a few months ago but I haven't heard if it is implemented yet.

 

[tliving]

Thanks - much of the code that I have found in the past was made obsolete by the auth changes that happened about a year ago but your stuff is very current it looks as you even include home link commands.

Does anyone know if there is a way to set the scheduled charge time via the API? It looked like this feature was coming a few months ago but I haven't heard if it is implemented yet.

The homelink stuff I havent tested as I don't have AP hardware and the homelink stuff only works if you have it (for some reason as I can use homelink otherwise).

For the scheduled charge time I don't see any way to do it via API but a simple cron job would solve that problem.

 

[wayner]

For the scheduled charge time I don't see any way to do it via API but a simple cron job would solve that problem.

That's what I do now. I have written some code to allow me to adjust my charge time so that my charging ends at 7 am so as to minimize regen limits. So I calculate what time the charging should start and kick off a cron job that starts the charging at that time.

 

[FlasherZ]

What's the best practice around managing your token when making API calls?

So far I have just been hardcoding the token into my Python files but this isn't the best way to do it. Should I store it in a text file and just read the text file whenever I need it?

And what is the best way to test to see if the token is still good? Should I put some error trapping around each call to the tesla API server or should I just do a test call at the top of my code and then retrieve a new token if the old one has expired?

Or should I just run a cron job every day to test the token and then update it if it has expired?

For a lot of my manual stuff, I use this crazy hack that runs on a cron job once a week:

curl --include --data "grant_type=password&client_id=${cid}&client_secret=${csec}&email=${email}&password=${password}" --request POST 'https://owner-api.teslamotors.com/oauth/token' >$HOME/tesla/.token.pre

grep "access_token" $HOME/tesla/.token.pre | sed 's/^.*token":"//' | sed 's/".*$//' > $HOME/tesla/.token || echo ERROR: check .token.pre

Then I simply read it in to my code.

I realize it's not good code, not protected against symlinks, yadda yadda... it's a hack. It runs with my own uid. It's on a private system. Don't use it if you don't understand the security implications.

Otherwise, TeslaMS does a good job of handling it.

 

[hans]

I never store the token. Just as easy to get a new one each time at process start time. Never had a problem getting blocked by Tesla for too many login requests (only too many REST API requests).

 

[ACDriveMotor]

Do we have documentation for any of the following REST calls?

upcoming_calendar_entries
notification_preferences
vehicle_subscriptions

 

[cryptyk]

Is there a way to close the chargeport? The apiary docs only show open, but curious if anyone ever found an API to close it now that the automatic ports have been around for a while.

 

[cryptyk]

Is there a way to close the chargeport? The apiary docs only show open, but curious if anyone ever found an API to close it now that the automatic ports have been around for a while.

Nevermind

I am still curious about summon and homelink, though. Does the car actually check to see if the bluetooth device is in range before executing these commands? If the FOB is in range, does it ignore the token param?

 

[ACDriveMotor]

Does nevermind mean you found the answer (please share) or that you no longer need to know the answer? I haven't tried it but believe I understand that the device sends a gps loc with the homelink command.

 

[brianman]

(1) I never store the token. Just as easy to get a new one each time at process start time. (2) Never had a problem getting blocked by Tesla for too many login requests (only too many REST API requests).

(1) I do, and (2) I had gotten blocked on more than one occasion prior to doing so.

 

[ACDriveMotor]

To me it seems better to keep the token as long as you plan to make repeated API calls rather than creating unnecessarily tps load processing login transactions.

But, that said I am concerned that we don't seem to have a documented way to invalidate the auth token. Does anyone know of a way to do so?

 

[cryptyk]

To me it seems better to keep the token as long as you plan to make repeated API calls rather than creating unnecessarily tps load processing login transactions.

But, that said I am concerned that we don't seem to have a documented way to invalidate the auth token. Does anyone know of a way to do so?

I keep tokens for users until they don't work anymore. Once they expire, I email the user and ask them to come back and re-enter their password. I don't think there's any other responsible way to handle it in a production application. Storing passwords is just bad news. I've been wanting to make a library that handles all of the above as a service and exposes Oauth2 for developers. It's in a long line of ideas that I don't have enough time to do