-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cope with tesla API errors #40
Comments
That must be another recent change, I've not seen these before. I'll try and reproduce soon, but if you could debug and get the |
I will add a resp.text() and log the output. I happens very rarely though. I hope I can catch it in the future. |
Tesla changed to v3 oauth api about last Friday so all their auth basically broke I have a work around in my python code 👍 |
Just found another Tesla Server oddity. I get an response with the correct header (and mimetype) but no body data at all. This causes a
The Tesla servers don't respond to this account/token with any valid response. No data or not even a authentication error. Maybe raising a 'No data' exception is ok for now and if it turns out to be a authentication problem changing it into a 'Authentication Error' exception. |
Thanks Tesla... :P |
OK, sounds like the latter issue may be a WAF? |
Hmmm, not sure if it is a WAF. WAFs typically block IP addresses and not single sessions. All other connections my servers hold (talking to the API-Servers) work without a problem. In theory it is possible to block a single session because it is identifiable via the auth-header but WAFs can't do that (at least none of the ones I know). I just retried the account in question with the same result, just no data from the Tesla API servers. This account had no requests for at least 4 hrs. Just to be clear: This is just a request to retrieve data from the API and not a request to authenticate via user/pass/MFA token. |
From time to time Tesla-API servers return text/html instead of application/json.
Which results in a rather nasty Exception (Some information is obfuscated):
Handling this is the app seems too complicated, as this error could occur at any point the app code (and api call) and just generate a lot of copy & paste code for exception handling. Or a 2nd api layer around the lib just to handle those rare hick-ups.
The lib could retry to send the command for a defined number of times or raise a CommunicationError Exception of some sort.
The text was updated successfully, but these errors were encountered: