Model S REST API

[mmccord]

I see the issue, they tied it to Summon so people with non-AP hardware can't control homelink via the app even though everyone has homelink support in the car.

Yeah, it's kind of a dick move. It also prevents using homelink from the app when the car is plugged in.

 

[wayner]

I see the issue, they tied it to Summon so people with non-AP hardware can't control homelink via the app even though everyone has homelink support in the car.

Exactly so everyone outside of the US currently can't use it.

 

[green1]

But we don't know if that's just a stupid app design decision, or if it's tied to that deeper in the system.

If it's the former, then the API calls should be usable for our own purposes even if the official app doesn't allow it. If it's the latter, we may be out of luck.

 

[HankLloydRight]

Yeah, it's kind of a dick move. It also prevents using homelink from the app when the car is plugged in.

Once again: Hanlon's razor - Wikipedia, the free encyclopedia

"Never attribute to malice that which is adequately explained by stupidity"

 

[mmccord]

Once again: Hanlon's razor - Wikipedia, the free encyclopedia

"Never attribute to malice that which is adequately explained by stupidity"

I totally agree. I don't think it was done with intent. It's just not designed with my particular use in mind.

 

[wayner]

If it's the former, then the API calls should be usable for our own purposes even if the official app doesn't allow it. If it's the latter, we may be out of luck.

Has anyone managed to figure out the API call for this yet?

 

[timdorr]

Has anyone managed to figure out the API call for this yet?

There are a couple calls for the auto park (Summon) and homelink features. I'm working on them now. But here's the gist of it:

trigger_homelink: lat, lon, token
autopark_request: lat, lon, token, action (start_forward, start_reverse, abort)

It looks like token is just your bluetooth device name, so that's pretty easy to fill in. There are also some fun autopark states in there, such as "panic", and errors such as "keyfob_not_present", "12_volt_battery", and "public_road". Based on the keyfob one, it looks like you need to have your fob in the car for it to work. When I try it with neither my phone nor my keyfob nearby, I get back {"response"=>{"reason"=>"mobile_homelink_disabled", "result"=>false}}.

I'll do some more testing on it, but it looks like the car needs to see a fob to make it all work, so that might be a buzzkill for a lot of ideas.

 

[green1]

I'll do some more testing on it, but it looks like the car needs to see a fob to make it all work, so that might be a buzzkill for a lot of ideas.

I can't speak for anyone else, but for me, homelink would be useful as long as it can see the fob through a garage door, and will work with the car still plugged in. But I'll agree, it's a very frustrating implementation and really makes no sense. I can open and drive the car without the fob, (including using homelink on the screen) but I can't trigger homelink? Really?

 

[rsqunit]

The "Remote S" app supports triggering Homelink even if you are nowhere near the car.

This must mean it is possible to do with the API, right?

 

[AllenWong]

The "Remote S" app supports triggering Homelink even if you are nowhere near the car.

This must mean it is possible to do with the API, right?

Correct. HomeLink in the API doesn't require that your car is unplugged or keyfob is near the car. It's the Tesla official app that requires it. The API itself is not as strict, and Remote S takes advantage of this fact.

 

[rsqunit]

Has anyone documented the correct API call yet? I read a few pages back in the thread and did not see clear info on anyone that has made it work. The API docs on apiary don't have any details yet either.

Thanks!

 

[green1]

Correct. HomeLink in the API doesn't require that your car is unplugged or keyfob is near the car. It's the Tesla official app that requires it. The API itself is not as strict, and Remote S takes advantage of this fact.

Maybe I missed it, but what exactly IS the API for homelink? mind sharing?

 

[AllenWong]

Huh? You replied to timdorr's post which already said what the API call was. It's trigger_homelink.

 

[green1]

Huh? You replied to timdorr's post which already said what the API call was. It's trigger_homelink.

I was looking more for the rest of the format, according to his post it needs lat/long and token, but I don't know what those would be, the lat/long of the garage door? how would I know what Tesla used for that? does it have to be exact? or just close enough? what format? what precision? What's the token look like?

There are a couple calls for the auto park (Summon) and homelink features. I'm working on them now. But here's the gist of it:

trigger_homelink: lat, lon, token
autopark_request: lat, lon, token, action (start_forward, start_reverse, abort)

It looks like token is just your bluetooth device name, so that's pretty easy to fill in. There are also some fun autopark states in there, such as "panic", and errors such as "keyfob_not_present", "12_volt_battery", and "public_road". Based on the keyfob one, it looks like you need to have your fob in the car for it to work. When I try it with neither my phone nor my keyfob nearby, I get back {"response"=>{"reason"=>"mobile_homelink_disabled", "result"=>false}}.

I'll do some more testing on it, but it looks like the car needs to see a fob to make it all work, so that might be a buzzkill for a lot of ideas.

Being that someone seems to have actually implemented it in RemoteS, I was hoping someone could clarify what exactly is needed here to make it work.

 

[Jdeck]

Is anyone else noticing a lot HTTPError 408 - Request Timeouts lately? I've been noticing a ton of them over the last three days.

EDIT: Nevermind. For some reason the car is going to sleep a lot faster than usual. Sometimes within 3 minutes of requesting all data. It started since I had it in for service and got 2.11.54 installed. Maybe it's something new in the software? I had my script set to poll all data for 30 minutes then stop after inactivity to allow for sleep. Now it's sleeping even if I'm polling for data and giving me a timeout when it's sleeping and trying to poll for data, thus waking it back up.

EDIT again: I just woke the car up from sleep with the app and it went back to sleep in 4 minutes while requesting all data. I'm liking this. Pretty much stops the possibility of missing data being collected.

 

[rsqunit]

Huh? You replied to timdorr's post which already said what the API call was. It's trigger_homelink.

I was actually looking for the syntax and sample of the data to pass. From previous posts it looks like attempts to send the request are returning an error.

I guess I need to hack with it a bit more.

 

[TitanP90D]

Getting too_far_from_vehicle trying to do a summon request. Passing lat, long, action: 'start_reverse', homelink_nearby: true to autopark_request

 

[tliving]

Correct. HomeLink in the API doesn't require that your car is unplugged or keyfob is near the car. It's the Tesla official app that requires it. The API itself is not as strict, and Remote S takes advantage of this fact.

Note that the homelink doesn't work with non-AP cars. It probably shouldn't be on the app screen for cars without AP hardware

 

[wayner]

Presumably it also doesn't work for cars outside of the US for now since Summon doesn't work outside of the US.

 

[tliving]

2 new fields turned up today in vehicle_state after a software update:
spoiler_type
[FONT=helvetica Neue, helvetica]autopark_state_v2[/FONT]

[FONT=helvetica Neue, helvetica]Neither apply to my pre-AP car so values not valid.[/FONT]