I don’t think that it’s useful in the widget. It’s more for dynamic adjustment of poll interval if you are hitting your personal daily average limit
I will keep an eye on the costs and if it’s getting higher that 0.33/day, Then I will check the next weeks, if it it balances out over a longer period.
I think after some weeks, you will find an average poll and all is ok 
Did you disconnect the cable? The meter_power capability is only updated in this case.
No… my car is always plugged in.
The car has no power meter. The app can only use the ‘added energy’ - and that can only be used if charging is stopped (means: disconnected)
Alright. I’ll see if it updates when I unplug my later for work.
Works fine now
Hi Ronny,
This morning I got an email from tesla with the topic Tesla Fleet API Limit Exceeded Alert.
The usage is mainly in requesting data, can I change some setting so the number of requests is Limited? I only want to use the app for reducing the load current while loading.
Thx Patrick
Hi,
set the interval in car device settings. You can also adjust it dynamically via flow.
And it seems, Tesla still allows free usage beyond he limit.
1 Like
Hi Ronny,
Which interval do I need to set? Online polling interval? Commands will always be send no matter what polling interval is set?
Yes, online interval should be set.
Offline interval should be set to the same interval. It’s still present since an old app version as Tesla used rate limits.
Commands are sent based on user interaction or flow actions. There is no polling.
Developer account created. Got both ‘key’ and ‘client id’. Able to login through Homey app (no new devices are found) but still all my flows fail du to ‘client id’ - but everything is correct.
Never get to the ‘add Homey as car key’ part in my setup? tried both the public and the ‘test version’.
Any ideas on how to resolve this issue?
The ‘add as car key’ appears at last step in pairing if a new car is added.
In repair mode, you have two buttons.One for re-auth and one for adding as car key.
And important: repair your existing device. start the add device view will add yoir client_id, but won’t re-auth your existing device.
1 Like
Hi @RonnyW, I notice that the “Start charging” command every time results in an API error. I suspect it is a timing problem.
I see the following:
- Start charging command is sent. The car is offline so I see that a “wake” command is sent. There is no immediate response that charging has started.
- There is a retry of the charging command (twice)
- There is still no response from the car.
- I get an API error; the API-status is “requested”. The flow is stopped.
- A few seconds after this, the car starts charging.
So the charging command is received in the end but then the “Start charging” card has already timed out.
Is there a setting that I am unaware of that I can set to lengthen the wait time of the “Start charging” command?
The “requested” response is new.
Perhaps the car has to check the the wallbox state first or it means it’s preheating the battery first.
A possible solution would be that I add a check for this result and consider it as “ok”. There are other result where I have to do this.
And I think about removing the retry option. In most cases it just results in 5 commands resulting in an error. For now you can deactivate the retry option in car settings.
Thanks! It could indeed be that the car is preheating the battery. That would explain why last week, when temperatures were below zero, I noticed it could take up to ten minutes until the car started charging after the charging command was given.
I monitor the API-status in the timeline and the API-status eventually changes into “charging”. This morning it took a minute or so but last week it took over 10 minutes to change from “requested” to “charging”.
I’ll switch off the retry for now.
Where did you see this state?
I use a flow that triggers when the API state changes and then shows the API state in the timeline.
Ok, so it was just the API error message but not an charging state. I’m curious if the API has also a new charging state that’s not defined in the app (could cause capability update error)
Yes, that is correct. But the API error message then is “Charging” although this is not really an error.
The ‘Start charging’ card times out and then the API error message is “requested”. And after a while it becomes “Charging”. Similar behaviour when charging is stopped or completed though.
Without sending commands? Or do you the send a command again and the car responds “charging”? The battery charging state has a state “Charging”, that’s why I wonder where the API error message comes from.
Too bad that Tesla does not provide these errors and states in the documentation…
