If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Model S REST API

I'd like some help with this. If you'd like to sniff the traffic of the Model S app, you can use Fiddler and your phone on your local wifi network using these instructions: Fiddler Web Debugger - Configuring Google Nexus 7 running Android 4.1 That will work for any Android 4.1 or higher device, with the exception of some manufacturers that have customized the interface very heavily. It may still be possible to install the Fiddler CA cert, but you'll have to figure that out on your own. Same goes for older versions of Android.

I still need to list out the remaining API endpoints and document the return values. The syntax for Apiary is fairly simple, so if you can do Github Markdown, you can handle this system. Feel free to fork and submit pull requests and I'll merge in stuff whenever I can. The biggest thing missing is the authentication flow, which I don't know if that's OAuth or something else (it doesn't look OAuth, though).

My hope is that we can build some cool apps out of this for our smartphones and for the web. For example, we could build a Windows Phone app (which is being worked on) or an Android widget. Or you could build web service to turn on the climate control at set times or after certain triggers. There are tons of possibilities here and I'm really excited to see what people can think up. REST means the API is easy to use and friendly, so there should be lots of us able to produce something against the API.

Update 11/12/13:

Sorry for going silent for a while. I'm going to try and document any new and hidden endpoints that are found, but I'd appreciate some help if you see any missing. The best option is to submit a pull request on Github. You can also PM me here, though I may take a while to respond.

I'm also going to include a nice little HTTParty class for all you Rubyists out there that makes interacting with the API pretty simple. I'll throw that into the API repo on Github.

Tim, thanks for taking the initiative and setting this up. I'd be happy to contribute once the iOS app is available (of course, at the rate you are going you may be finished by then).

In addition to Fiddler, another commonly used SSL proxy with auto-cert generation is mitmproxy (mitmproxy - home). Their documentation provides info on how to configure for iOS devices as well as Android.

As far as authentication, was there an HTTP Authentication header sent with each request? Maybe they are just using cookies...

I am really hoping for OAuth, as they could eventually extend the "My Tesla" page to support 3rd party web/mobile apps, without requiring the vehicle owner to give out their username/password. Maybe Tesla hasn't thought that far ahead yet...

Thanks Tim. This is cool. Let me know by PM if you need some testers. I am letting some of my programming students have limited access to test Web apps so far and may let them go deeper if promising apps emerge.

The Auth is in form post format that sets cookies back on the client. I haven't monitored enough to know first login vs subsequent app launch is handled though -- what cookies their client is saving between sessions as its not resending user/pw each time.

Updated the docs with the authentication flow. Looks like it needs both a _s_portal_session and user_credentials cookie set. I haven't seen if the _s_portal_session is completely necessary, but I'm guessing it will be.

I also added some session logs to the github repo (hid my passwords, of course), if anyone wants to take a look. The root return is interesting because there's a telltale sign of a Rails app (the javascript is in an assets folder). I assume they're up to date on their Rails patches, but I'll make sure they're not susceptible to the YAML bug most recently. Definitely don't want people messing around with our cars or Tesla's systems!

I've been interested in the possible use of OVMS Apps to control multiple cars of different types - not necessarily just with OVMS modules. This allows us to extend the manufacturer's offering, and is real nice for those with more than one car in their garage. OVMS has received literally dozens of request for such support.

GM/OnStar now have a published API (although are not permitting this to be used against real cars until late 2013).

The Leaf carwings API has been reverse engineered.

Now, you guys are reverse engineering the Tesla Model S RESTfull API.

Perhaps the neatest way of doing this is by gatewaying at the server - no change to Apps necessary. But, I worry that the providers will rate limit requests from a single IP. Doing it at the server allows for all sorts of cool stuff (e.g.; timed pre-heat).

We could also do this in the Apps themselves.

But, my question is what is the legality of this? I suspect that it would be a contravention of the DMCA? I read that GM/OnStar stopped (or persuaded to stop) the VoltStats guy to stop - and he is now using a very restricted API just for him. What about Nissan? I guess the legalities of doing the reverse engineering vs using fruits of such work are different.

Looking at the Model S API, it would be about an evening's work to do a server gateway. Scarily simple. I don't have the car (yet), but if someone (presumably an OVMS roadster owner who also has a Model S) wants to work with me on a proof-of-concept for this, I'm more than willing to give it a go.

PLEASE NOTE:
These musings are the copyrighted intellectual property of the author, and are intended as part of a conversation among the Tesla Motors Clubs membership.
My words may not be quoted by any third party outside the Tesla Motors Clubs forums, without my express consent.

Cool. I now have a charge timer that I wrote in 5 minutes, using curl and cron.

Since charging starts when you plug it in, I imagine you'd have two parts --
When you want it off -- every 5 minutes (15, w/e, just so you aren't spamming the auth) you tell it to start charging.
When you want it on -- tell it to turn on and check once or twice later on the status.

You'll hafta remember to turn off the cron job when away from home, or you make the script location aware if that's available via the API (I think it is).