Hello @RonnyW ,
I got the message again, here it is.
Trying to go through “set current charge” card but 500 internal error.
No API rate limit reach (I am at 5%).
Reading cards before have been success.
Any idea ?
Thank you
Pierre
This can happen if the car does not react or if the parameter is not valid. Can you write a timeline message if this card throws an error including the apps value?
But it’s hard to find a reason if Tesla API only returns a general 500 error.
Excuse me, I don’t understand what write a time line message means ? Do you have any process detailed / forum which explain ?
Also for information, if manually I try to start charging within battery device directly, I have “network request failed”. Doesn’t work.
I’ve just change to API Rest and if I do the same, it works…
In your flow, add card: Then… > Timeline (left, in system group) > Add timeline (don’t have my version in english, translation may not be correct)
1 Like
Version 1.7.1 is now live
The car data is requested only if the Tespa API reports the car as online.
That saves a lot of request during offline/asleep time.
The state request seems not to count up the rate limit counter. So you also use shorter offline interval like 5min.
An onlin einterval of 5min will keep you below the rate limit. Use this if your car is online the whole day (sentry mode).
If your only use the car for some hours and rest of the day it’s asleep, you can use a 1min online interval. Try what’s the best for you.
You can use the new flow trigger to react on API counter. You can remind yourself if the counter raises over 200.
1 Like
Hi Ronny!
Encountered some problems, API requests over limit all the time…
42329db1-a883-4000-a445-89b9b90717fe
In the app:
API state: ok
Requests made : 72/300
/Johan
@RonnyW I’ve got the same issue as Pierre_Balbinot…
See my setting below:
I’ve updated to V1.7.1 but still getting the same error.
This used to be working perfect as I’m using the app to adjust the Amperage depending on the solar panel production to limit the bandwith on the grid.
I’m getting a error every minute on my timeline.
Any solution to the “500 internal server error” yet?
Thanks!
The app internal counter doesn’t know Teslas counter. It counts since app update. If rate limit was already active for you, you have to wait until 0:00 UTC.
Is data reading working?
Do you get only rate limit error for commands via RestAPI?
Edit: The app currently counts API requests only for readings.
Perhaps commands via REST are also counted by Tesla. But I have no information about
…but nevertheless you should not send commands in such short intervals.
@RonnyW Would it be possible to automate the polling interval?
For example, UTC 00:00 the interval is set to 1 minute. If you get above the average, the interval is increased by one minute. And if you get below the average, the interval is reduced.
1 Like
That’s a rate limit for commands.
Based on my tests, the current rate limit is between 30 and 50 commands a day.
I’ll update the proxy and import all changes from the Tesla Repo. Then I can update the app to check for http-429 error (rate limit).
Edit:
From (older) Tesla documantation:
- 50 commands
- 5 charging commands
- 15 wake up requests
Don’t know if it’s still valid, because currently the request limit is 300 instead of 200 as listes in Tesla docs.
Perhaps I can add flow actions to adjust the interval. I will check this later…
1 Like
The proxy is updated now. Flow actions are throwing a rate limit error now instead of http-500.
But the “retry in 0 minutes” is not correct. It seems the API does not provide the correct time. But it will also be at 0:00 UTC.
I updated the proxy server which is converting the app command request as encrypted messages to the Tesla API/car.
As result, the app now gets the correct rate limit error (http-429).
I will check later if/how I can handle this error in the app - perhaps writing additional data to device settings page.
Edit: I can’t provide further details in device settings. The API/proxy does not pass the limit data inside the http error response. So the flow card error and the API state in device settings is all I can do.
You can use the API error flow trigger to get informed if such an error happens.
New test version 1.7.2:
- Added counter for API commands
- Added rate limit information for commands to car device settings
This is onyl for information. This won’t change the rate limit.
Tesla has now independent rate limits for car data request and commands.
- data request: 300 requests/day
- commands: ~50 commands/day
Limit reset is at 0:00 UTC. The time is shown in car device settings.
Using these limits, it will be impossible to control charging for PV surplus charging in a good way.
Commands will only be useful for car dependent controls like climate preconditioning or sentry control.
If you really want to use PV charging control, you will need a smart wallbox and control charging (start/stop, ampere) directly from the wallbox.
You can use the “API count changed” or “API count getting higher than” trigger to control your API usage. In addition you can use the “API error” trigger to send you a push message if an error occours.
1 Like
RonnyW, Thanks for your investigative work.
Do I interpret your recommendations here, with the current knowledge of commands/day limits, that setting amperage or stopping/starting charging got a limit of around 50 per day?
I am currently setting amperage directly in a local API to my ChargeAmps Halo wallbox, but stopping/starting the charging with your App’s Then-cards. Perhaps I should reconsider, and test setting amperage to below 5A, so that charging essentially stops during my 1-hour charging breaks (to keep the kwh/h numbers down a bit, due to new regulations coming…)
Hi,
this are the limits documented by Tesla.
https://developer.tesla.com/docs/fleet-api?javascript#membership-levels
The first is 300/day now.
The command limit is ~50 (my experience)
I have not checked if wake up or charging commands are limited, too.
But if charging commands are limited to 5/day it would be better for you to lower the ampere to stop charging instead. But that’s currently all trial&error.
Hi Ronny!
I’ve solved the problem.
In my flows I had quite a few checks to see if my car was at home or not. (‘Is at location Home with a tolerance of 30 m’)
I replaced all of them with a logic check of a local variable (Is tesla home)
And I use the ‘Location Home has been reached/left with a tolerance of 30 m’ cards, to update my variable.
Btw, earlier when I got the errors, it was over an period > 48 hours.
Bug: when my car is charging, charge phases is always 0, even though I’m charging using my Tesla wall charger, 3-phase.
Anyway, my logic to control my charging from my solar/batteries is working again! 
Thanks for your hard work! 
The condition cards are using the last known coordinates in car location device. This won’t call the API. You can still use the “is at location” condition.
