I'm not sure how early it started, but with >= 2.4.251 the "data_request\vehicle_state" now includes:
Edit: I don't have my older logs handy at the moment, but 2.4.239 had this data as well.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
Edit: I don't have my older logs handy at the moment, but 2.4.239 had this data as well.
hans
P631
Yes. I had noticed this as well. This was one of my early API requests. No reason to invoke streaming just to get the ODO. Even with Maximum Plaid one would hope that miles aren't ticking by much faster then one every 20 - 30s or so!
I figure it might be useful to share with the class, in case others run into similar issues. Some of these are "non-changes" from my earlier implementation, but after a few refactorings I realized some things that changed for the worse and had to be fixed/restored.
1. Very early in your design, set up a method to save/load the login authorization token so that when debugging your app you don't make the server cranky. (Lots of requests seems fine. Lots of logins not so much.)
2. Streaming URL is the same as before the cookie -> OAuth changes.
3. Streaming URL "Authorization" header value must be "Basic" not "Bearer".
4. The new post-login OAuth URLs must have "Authorization" header value of "Bearer".
5. For #4, the Authorization must begin with title case ("Bearer") despite login returning the type in lowercase ("bearer").
6. Similar to #5, "Basic ####" not "basic ####".
7. For streaming URL, the authorization value part (#### in #6) needs to be encoded. I use:
Code:
Convert.ToBase64String(Encoding.Default.GetBytes("[I]loginname[/I]" + ":" + "[I]tokenvalue[/I]"))8. (Might be C# specific.) Only the wake_up URL is a POST that requires authorization, which makes it the only URL that finds the issue: when building your HttpWebRequest, make sure you populate the headers before the content. Otherwise the headers are lost and you get the Unauthorized issue noted above.
9. Wake_up POST request content should be "{}\n" (though "{}" might be ok). Empty string didn't seem to work.
10. With the cookie -> OAuth transition, some of the responses now say "response" rather than "result". (I think they all return "response" now.)
11. The "id" field in the response for "vehicles" method is now larger than 32-bit. Using 64-bit (even signed) seems large enough.
12. Observation: The wake_up POST request now seems to provide the tokens which allows for not having to repeat the "vehicles" method, presumably. (I haven't applied that optimization yet.)
13. Optimization: Cookies are no longer needed throughout the web requests (GETs and POSTs) at all. Allowed for a lot of code trimming for me.
I was just porting my library to the new authentication scheme and I noticed backseat_token and backseat_token_updated_at in the vehicle query result that I hadn't seen discussed before. Presumably those are for the back seat control app that was promised with the executive rear seats.
AllenWong
Member
You need the newest version of VisibleTesla. Can't speak for the other apps, but they probably need to be updated too. My Remote S app still works, so it's not an API issue.
gglockner
Member
FYI: I just released a teslajson class for Python. I did this because pytesla was no longer working for me. You can find it at https://github.com/gglockner/teslajson. Comments & feedback welcome.
AllenWong
Member
Anyone analyze the new Android app yet? I heard that they have a new command to turn on and off valet mode. I'd do it myself if I had the tools with me, but I'm stuck in recovery from surgery.
AllenWong
Member
That usually means that the content type or format is wrong. Make sure that you are sending it correctly.
hans
P631
hans
P631
looks like these are the new vehicle commands for valet mode
/vehicles/{id}/command/reset_valet_pin
/vehicles/{id}/command/set_valet_mode
{
"on": boolean
"password", string
}
I haven't tested them yet.
Also calls to /vehicles/{id}/data_request/vehicle_state now returns valet mode info:
{
...
valet_mode: boolean,
valet_pin_needed: boolean
...
}
Similar threads
