tesla-api
tesla-api copied to clipboard
timdorr
Add support for new Summon APIs
You can now "Summon" via the app and there is also some HomeLink capability. I have a 2012 Model S, so I'm unable to live test this stuff, but hopefully I can use the HomeLink APIs nonetheless.
@timdorr I was updating a PHP library with the new info from your code and I ran into a stumbling block. While data_requests were working, anything that was a command (or wake_up) was returning a 404 error. Is it because of the Client ID and Secret that I'm using, which I got from your page? I'm able to do the commands from the native apps.
It looks like folks on TMC found the endpoints for the 7.1 features, but since I can't even honk my horn right now I haven't bothered to try them.
@btamburrino Make sure you're issuing POST requests for the command endpoints. They are not GETs.
@timdorr I tried that, they still returned 404's.
One thing I can report is that get all vehicles now returns id_s which is a stringified version of id. This is good because the id is now a BIGINT and that messes with some JSON decoders (like PHP's.)
EDIT: Nevermind. You also have to send a null POSTFIELDS.
Did you figure out what the endpoints are for summon and homelink? I can't seem to find them anywhere on the web...
I mentioned them here: http://www.teslamotorsclub.com/showthread.php/13410-Model-S-REST-API/page49?p=1337610&viewfull=1#post1337610
They both require keyfob presence near the car, so it's hard to test. I haven't dragged my laptop out to the garage yet.
Just found out you can trick it by doing a keyless start and then using the associated APIs. I'll test this over the weekend. But I get the feeling Tesla is going to close up that hole pretty quickly (possibly even through the API itself...)
Thanks I'll have to test it out tomorrow. Also you said "It looks like token is just your bluetooth device name", so is this token for the https://owner-api.teslamotors.com/api/1/vehicles/vehicle_id/trigger_homelink different from the token we normally use that is returned from the oauth request?
Also I know that the phone has to be near the car so once you fake lat/long parameters to just be the car's current position, you're saying after doing a keyless start it will work? Pretty cool...
Yes, it's a separate token field. I traced the code back to the Bluetooth device name in the Android app.
And yeah, as long as the lat lon is within a certain distance (probably the magical 39 feet), it should work. It should be fine to simply duplicate the car's reported position.
I see my issue was closed dupe with this one. I am unable to get homelink to work. Have you made progress by chance? I have a 2013 and always get reason:"unavailable" when I try to invoke. I am sending the current vehicle lat/long and phone BT name. I've tried enabling remote start first.
I have a 2012, so I'm probably in the same boat. I'm pretty sure they group this off with Summon. I haven't made any attempts yet, though.
I don't pass the BT device name and it works well for both summon and homelink. I instead just pass the same token I've been using for everything else.
Tesla must have updated their api because "trigger_homelink" no longer works, yet the native Tesla app can still do this. Any ideas?
Are you attempting it with the fob within range? I think they make have closed the keyless driving loophole. As far as I know, the API itself hasn't changed.
Yes the fob is in the car, and when I press the home link button in the Tesla app it works but my own api request no longer works. If they didn't update their API then what changed?
Also I tried to analyze their app with a proxy tool like Charles but the connection fails when I try that, any advice?
Dylan Diamond
On Jun 20, 2016, at 9:32 AM, Tim Dorr [email protected] wrote:
Are you attempting it with the fob within range? I think they make have closed the keyless driving loophole. As far as I know, the API itself hasn't changed.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@timdorr here is the explanation: https://teslamotorsclub.com/tmc/threads/model-s-rest-api.13410/page-80
They switched to web sockets apparently so it will be a bit harder to call summon and homelink.
Looks like you open a standard Websocket connection to wss://streaming.vn.teslamotors.com/connect/{vehicle_id}.
From there, there is a JSON-based communication protocol with output commands and input results from the server: It has the rough format of
// Command from client
{"msg_type":"autopark:cmd_forward", "latitude":123.456, "longitude": 78.90}
// Response from server
{"msg_type":"autopark:cmd_result","cmd_type":"autopark:cmd_forward"","reason":"", "result":true}
So, it's pretty analogous to other parts of the standard HTTP API. I'm looking through all the commands right now and there are a bunch. Comments below have the details:
Commands that can be received (msg_type -> arg1, arg2, ...) :
control:hello -> connection_timeout, autopark: {autopark_pause_timeout, autopark_stop_timeout, heartbeat_frequency}
control:goodbye -> reason
control:pong -> timestamp
autopark:status -> autopark_state
autopark:cmd_result -> cmd_type, reason, result
autopark:heartbeat_car -> timestamp
autopark:error -> error_type
homelink:status -> homelink_nearby (bool)
homelink:cmd_result -> command_type, failure_reason, result
vehicle_data:location -> latitude, longitude
Commands that can be sent (msg_type -> arg1, arg2, ...):
control:ping -> timestamp
autopark:heartbeat_app -> timestamp
autopark:cmd_abort ->
autopark:cmd_forward -> latitude, longitude
autopark:cmd_reverse -> latitude, longitude
homelink:cmd_trigger -> latitude, longitude
For those really interested, here's the entire state machine they use for autopark related stuff (it's pretty complex): https://gist.github.com/timdorr/61834c6ada93d961e4646ea5fff6d7f7
@timdorr Thanks so much! I just tested this and it works. A few questions I'm hoping you'll have the answers to:
I noticed that the headers that are sent with the initial websocket have a different Authorization value than normally. It is not Bearer: {token} but Basic with something else, so I'm wondering how to get that other value.
Do we need to include the Sec-WebSocket-Key value? If so where do we retrieve it?
Here is a screenshot of the headers with private info redacted. Thanks.
Sec-WebSocket-Key is a mechanism to prevent proxies from caching any WebSocket stream being passed through them, by altering the data every time. It should be automatically handled by any WebSocket framework used to communicate. (In short, it's a SHA1 hash that is generated by taking the previous value, hashing it with a particular guid, and then Base64 encoding that)
The Authorization: Basic is the standard HTTP auth mechanism, a base64 encoding of username, followed by a colon (:) and then the password. The username is your Tesla account email address, the password being sent is the text/hex representation of 8 bytes , but I haven't been able to determine how that's generated yet. It is not a partial md5/sha1/sha256 hash of the tesla password or bearer token, nor a part of the bearer token itself. I'm assuming they're transforming the bearer token by some means to derive the password, but nothing obvious jumped out at me.
Correct. The header is in the format Authorization: Basic %{base64(token)}. The token comes from the vehicles endpoint in the tokens field. Same as the streaming data API.
Duh, yeah. Forgot about the streaming tokens. But wouldn't the format be Authorization: Basic %{base64(email_addr ':' token)} ?
@dcdspace The Tesla implementation seems to send a ping every 5 seconds. The server will respond with a pong having the same time stamp as the ping you sent.
@pdb0102 Ok awesome. And when doing the autopark, should I send a heartbeat every 0.5 seconds? I have it going on a timer so that the user doesn't have to hold down a button so I'm hoping the car will stop on its own after a certain amount of time...?