As many would be aware, Tesla has introduced a public API and support for 3rd party apps, rather than having to use the previous reverse engineered APIs.
At some point it is likely Tesla will charge for use of the API - how open source projects will be considered is TBD.
I’ve started playing around with use of the Fleet API - and don’t think it would be too difficult to adapt the current [tesla] binding, as well as my [teslapowerwallcloud] binding which uses the energy api’s to manage Powerwalls.
The key issue is that the vehicle command SDK uses Go not the Rest API - but does include a proxy server which translates the Rest API into the new proto commands that are requried.
I’ve hacked enough of powerwallcloud to have some ideas on paths forward.
My current proposal is:
Add Advanced ‘Things’ for the following items:
Configurable App ‘client-id’ - which would default to my registered client-id
Configurable Tesla Server (Tesla runs NA, EU and CN servers depending on vehicle location)
Configurable Proxy Hostname - which would default to a proxy that I would run
Configurable Proxy port - which would default to a proxy that I would run
This would allow those users who want to register their own account with Tesla to run their own proxy and client-id for privacy reasons. Also, if Tesla introduce API limits, the client-id can be changed without the binding having to be recompiled.
Note: All of this is based on my exploration of what’s required to update [teslapowerwallcloud] - I haven’t looked closely at [tesla] yet but I expect a similar approach would work.
Thoughts appreciated - and no timeline for me to look at this yet - firstly - I want to finalise/test the changes to [teslapowerwallcloud] as that is my most pressing need for my own HA.
OK - 1st problem - the tesla-http-proxy is designed to run only on localhost - and installs a self-signed certificate - which will cause problems…
Edit: I wonder if I can run nginx or something public facing - with a lets encrypt key - and forward incoming requests to the proxy running on localhost?
Edit2: looks like this might work - need to do some more testing
I have a WIP version of the [tesla] binding using the Fleet API. Querying data seems to work OK. Trying to send a command yields a 404 I need to work out how to display the URL it’s trying to load - trying to use getUri() is giving an error
I think I found the problem - I had a brainwave and checked the nginx logs I’m using to forward cmds to the tesla-http-proxy. The binding is using /api/1/vehicles/3744xxxxxxxxxxxx/command/charge_port_door_open - when with the fleet API, you need to use the vehicle VIN. Off to find the offending code…
OK - sending commands works now. I need to add the ability to:
Change the Client ID
Change the URL for the server running tesla-http-proxy
Change the port number for the server running tesla-http-proxy
So that people can either register using my client-id - or if they choose, register their own account and run their own proxy.
If someone wants to test either the [tesla] or [teslapowerwallcloud] binding using the fleet API - please PM me and I’ll send you a link to register your tesla account with my client_id, and send you a link to a JAR to test.
Once you use a refresh_token to generate a bearer_token, it expires the previous refresh_token and returns an updated refresh_token. So I need to work out how to override the configured refresh_token and update it in the binding code - hopefully there is a way to do this.
I’ll update this post once I figure it out.
Edit: I think I need to use editConfiguration & updateConfiguration but on compiling, I’m getting:
[ERROR] /home/psmedley/openhab-addons/bundles/org.openhab.binding.tesla/src/main/java/org/openhab/binding/tesla/internal/handler/TeslaSSOHandler.java:[80,47] The method editConfiguration() is undefined for the type org.openhab.binding.tesla.internal.handler.TeslaSSOHandler
[ERROR] /home/psmedley/openhab-addons/bundles/org.openhab.binding.tesla/src/main/java/org/openhab/binding/tesla/internal/handler/TeslaSSOHandler.java:[82,17] The method updateConfiguration(org.openhab.core.config.core.Configuration) is undefined for the type org.openhab.binding.tesla.internal.handler.TeslaSSOHandler
I think there’s a missing ‘import’ statement, I just need to find the right one. More after work tonight
I’ve had a couple of DM’s from people interested in testing, and until now, no replies here - so based on apparent interest levels, I stopped updating here.
Current status is:
Tesla vehicle - working for me and a couple of other testers
Tesla powerwall - needs some redesign to more easily handle the latest Tesla API changes.
I’m hoping to switch over to your branch; I’m assuming that the latest code is on github.
I was hoping to register my own OAuth client with Tesla, however I haven’t yet been able to do so. Did you use https://smedley.id.au for you OAuth origin and redirect URLs? I have been trying to do something similar however it’s always rejected with “domain must be registered with a certificate authority”. I’m using LetsEncrypt and have the same root cert as you do on your domain.
I’ll have a go using your client id whilst I’m trying to figure it out.
Is there a difference with the OAuth tokens when switching APIs? I don’t seem to be able to use an existing refresh token, not sure if that is expected or not. I don’t believe that I can generate an OAuth token myself as I would need your client secret. I’m also not clear on whether the OAuth token is tied to the same public key and hence proxy server. Lots of questions, sorry!
The refresh tokens are tied to the Tesla developer account in use. You need to register/link your Tesla Account to my App - or get your own local setup working and update the client-id/proxy in the binding’s advanced settings.
Yes, all code is in the github branch I posted in post 2 of this thread.
I’ll DM you the details to use my setup - I’m reluctant to post it publically as Tesla could start charging for the use of the API tomorrow which would result in me running the proxy for my uses only (with a fresh developer account).
Yeah I guessed that the tokens are tied to the account like typical OAuth, I just wasn’t sure if Tesla also tied the token to the PKI stuff that they have added on top (which the proxy server implements). I am assuming that it is though, which means that I’ll have to use your proxy too.
Completely understand regarding not posting publicly - it’s also not a great situation for people using your proxy either as there is nothing preventing you using their OAuth tokens.
I’ll get things running via your proxy then continue trying to get my own set up (just fighting with acme cert renewals at the moment). Thanks!
Whilst I guess that in theory I could be trying to capture peoples details - I’m not - but I get the concern. At some point I’ll try write up what I did to register a developer account and setup the proxy - I deliberately added the fields to the binding to allow anyone to use their own proxy and client id.
So using your proxy I have got to the point where the outgoing requests seem to be failing:
An exception occurred while invoking a HTTP request: 'org.eclipse.jetty.client.HttpResponseException : HTTP protocol violation: Authentication challenge without WWW-Authenticate header'
In tandem I have been working on getting my own account & proxy set up, and now have it working, although I am getting exactly the same error with my own proxy
Presumably this is only when sending a command? Have you registered a virtual key for your car? ie the step of going to https://tesla.com/_ak/smedley.id.au ?
I’ve registered everything, however it appears that it’s failing to exchange the refresh token for an access token. I’ll look into it a little more but I suspect I must have messed up my refresh token somehow.
NB: the refresh token works exactly once. The latest code updates the refresh token in the config after it has been used. You need to use a gui config not a text based config, otherwise the binding can’t update the refresh token.
Thanks - I did manage to figure that out, after also realising that there were 3 tokens returned from the call to fetch a refresh token (access/refresh/id) and I was using the wrong one. All working with my own proxy & account now. Thanks very much for the help and work, good that there are now at least two of us running this that can keep it updated. Not sure how we can make it workable into a solution for all (non-dev) users though; I guess we’ll have to wait for Tesla to see what they do with the API plans.
It’s a patched proxy that avoids using the fleet api; instead using whatever APIs the Tesla app is using (which obviously doesn’t require the owner to sign up the fleet API).
I need to work out how to display the URL it’s trying to load - trying to use getUri() is giving an error