Add support for new Summon APIs

[timdorr]

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.

[btamburrino]

@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.

[timdorr]

@btamburrino Make sure you're issuing POST requests for the command endpoints. They are not GETs.

[btamburrino]

@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.

[dcdspace]

Did you figure out what the endpoints are for summon and homelink? I can't seem to find them anywhere on the web...

[timdorr]

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.

[timdorr]

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...)

[dcdspace]

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...

[timdorr]

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.

[mseminatore]

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.

[timdorr]

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.

[dcdspace]

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.

[mseminatore]

@dcdspace Do you have AP hardware?

[dcdspace]

Yes

[dcdspace]

Tesla must have updated their api because "trigger_homelink" no longer works, yet the native Tesla app can still do this. Any ideas?

[timdorr]

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.

[dcdspace]

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 notifications@github.com 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.

[dcdspace]

@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.

[timdorr]

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:

[timdorr]

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

[timdorr]

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

[timdorr]

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

[dcdspace]

@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.

[pdb0102]

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.

[jonasman]

I just went for a drive but no luck. There were no events from the stream. Did anyone get lucky using the stream?

[timdorr]

If this is about the streaming API, please open up a new issue. This is unrelated to Summon.

[frenchykiller]

Hey everyone! Great job on finding all this info!

Sorry to necro a relatively old issue, but I've hit a snag when trying to call the autopark commands from my custom app. The car will start up and shift into gear but then stop again without having moved.

I've got the heartbeat going on the requested frequency and sending pings every 5 seconds but I seem to be missing somethin along the way...

Here's a snippet of what I send the car and the answer I get:

Connected to server.
Server : {"autopark":{"autopark_pause_timeout":2000,"autopark_stop_timeout":10000,"heartbeat_frequency":500},"connection_timeout":20000,"msg_type":"control:hello"}
Server : {"autopark_style":"dead_man","msg_type":"autopark:style"}
Server : {"autopark_state":"ready","msg_type":"autopark:status"}
Server : {"homelink_nearby":false,"msg_type":"homelink:status"}
Client : {"longitude":CAR_LONG,"latitude":CAR_LAT,"msg_type":"autopark:cmd_reverse"}
Server : {"cmd_type":"autopark:cmd_reverse","msg_type":"autopark:cmd_result","reason":"","result":true}
Server : {"autopark_state":"preparing","msg_type":"autopark:status"}
Server : {"autopark_state":"active_reverse","msg_type":"autopark:status"}

The same thing happens for cmd_forward, the only time the car did anything more than start up and wait was when I accidently sent both commands almost simultaneously at which point the wheels turned left then right but it still didn't move...

Any insight into what I'm missing would be highly appreciated, I've looked through pretty much all the posts and proposed libs that I could find but can't seem to figure out where I went wrong...

[timdorr]

Obvious question: Are you able to AutoPark from that location with the app? It might be a physical problem, but just to rule that out.

We also might need to update things. I haven't kept this part of the code up to date (and haven't yet documented it), so the command structure and that state machine might have been updated. What car software version are you on? I'm still waiting on 2018.14 myself.

[frenchykiller]

Yup autopark from the app works like a charm, and from my code the car starts up and chimes but then refuses to budge and shuts down after a few seconds...

As for the car software I'm not sure as it's not my car, I'll try and get that info!

EDIT: Not sure if this has anything to do with the software version but the /data endpoint has the following field "car_version": "2018.10.4 8bbdc66"

EDIT 2: Forget I ever said anything, I should have included the heartbeats in my earlier snippet... Turns out I was sending the same timestamp with every heartbeat so the car didn't have time to start moving before it detected a problem and stopped...

[frenchykiller]

I think I remember getting the vehicle_data:location result by simply connecting to the web socket while the car was moving. Not sure if this was a coincidence as I was playing around with auto_park and didn't specifically attempt to get the vehicle location.

[davidhodge]

@frenchykiller thanks! yeah I just discovered that and deleted my comment before I saw yours. I've now moved on to my next problem?

Any ideas on how to get live power or speed data from the socket? The Official app appears to get the speed via the socket, but I can't tell exactly how.

[dabbler]

I've reread this a bunch of times, but it's not clear to me. Does anyone have an API that has summon working? I just want to use any language to be able to run my own linux script to summon my car out of the garage. I used to have @timdorr's ruby working (and had it connected through Alexa). But I believe that no longer works, right? Or am I just using too old an API?

[frenchykiller]

@davidhodge
From the testing I've done, power and speed can be octained via the REST API with an HTTP GET to the /data_request/drive_state endpoint, not sure if you can get them from the web socket. Are you sure the official app doesn't just send a GET request periodically to update the info? (Though that would be pretty messy...)

@dabbler
Yup, I have a working auto_park (summon). Everything in this thread pertaining to the web socket is still up to date.

Basically:
-> connect to the websocket
-> send autopark_cmd:(forward|reverse|abort) to move or stop the car
-> send heartbeat_app at requested interval
-> disconnect from websocket

[davidhodge]

hey @frenchykiller yeah I've been using the /data_request/ endpoint for periodic requests. I'm trying to find a substitute for the seemingly deprecated old streaming API that would give power, position, speed, etc up to 4x a second while the car was in motion. I suppose I could poll drive_state super often, but that might seem a bit abusive.

[davidhodge]

@frenchykiller and no I'm not certain. The app could do a periodic get for the vehicle state and that could be the only means of update.

It does appear to be doing something else though.

[OneDroidyBoi]

Reading the socket is working for me still, so I've got no clue what's going on. Is it a recent update for some of you?

[dabbler]

I'm trying to get the @timdorr ruby code to summon. But I don't see any part of the API where I initiate a forward or reverse summon. Am I missing something?

[HudsonGraeme]

Anyone investigated smart summon connections?

[timdorr]

I haven't taken a crack at it yet, but my car just got it last night. I assume it's the same WebSocket-based connection.

[atx-barnes]

Is this thread still up to date about using a web socket for the summoning feature? The last comment about it working was made by @frenchykiller in 2018.

Yup, I have a working auto_park (summon). Everything in this thread pertaining to the web socket is still up to date.

Basically:
-> connect to the websocket
-> send autopark_cmd:(forward|reverse|abort) to move or stop the car
-> send heartbeat_app at requested interval
-> disconnect from websocket

[timdorr]

Yes, they only use WebSockets for anything that streams from the car (Summon, Smart Summon, streaming data).

[vekexasia]

Hello guys, so i'm trying to implement summon via API.
I'm connecting to wss://streaming.vn.teslamotors.com/streaming/

Once connected isend thendata:subscribe_oauth hence i receive the following:

{"msg_type":"control:hello","connection_timeout":0}
{"msg_type":"data:update","tag":"1876472448","value":"bla,bla,bla,bla,bla"}
{"msg_type":"data:error","tag":"1876472448","value":"disconnected","error_type":"vehicle_disconnected"}

In the meanwhile (before the disconnected error) i send {msg_type: 'autopark:cmd_reverse', latitude: a, longitude:b}

But i don't receive any message. As far as I understand i should be receiving autopark:status message. or autopark:cmd_result but i dont receive a damn thing.

Any hint?

[timdorr]

I haven't checked, but there may be changes to the protocol due to the new auth system.

[vekexasia]

@timdorr any hint on how to sniff traffic to get how the app behaves?

[pavanpkp33]

@timdorr @vekexasia How did you connect to WSS with auth? I see only commands going out. Any documentation that you can point me to? I'm able to use the REST endpoints with auth token.

[timdorr]

You have to send this message once you connect to the WebSocket. There is no auth for the WebSocket connection itself.

[akramaskar]

Hello guys, so i'm trying to implement summon via API.
I'm connecting to wss://streaming.vn.teslamotors.com/streaming/

Once connected isend thendata:subscribe_oauth hence i receive the following:

{"msg_type":"control:hello","connection_timeout":0}
{"msg_type":"data:update","tag":"1876472448","value":"bla,bla,bla,bla,bla"}
{"msg_type":"data:error","tag":"1876472448","value":"disconnected","error_type":"vehicle_disconnected"}

In the meanwhile (before the disconnected error) i send {msg_type: 'autopark:cmd_reverse', latitude: a, longitude:b}

But i don't receive any message. As far as I understand i should be receiving autopark:status message. or autopark:cmd_result but i dont receive a damn thing.

Any hint?

I'm experiencing the exact same error. Any solution on this?