Tesla fleet API error 429 Too Many Requests #14226
Comments
|
Gleiches Problem (bei mir Docker mit 0.126.6). Gefühlt wechselt sich dieser Fehler mit #14229 ab. |
|
Ist möglich, dass Tesla was an der API umgestellt hat. Evtl. limitieren sie jetzt die Commands pro Tag und Fahrzeug. |
|
Also wenn das stimmt, nur 50 Commands pro Tag und Fahrzeug, dann ist es vorbei mit dem PV-Überschussladen. |
|
Ja, sieht wohl leider so aus. Größere Pakete könnten natürlich helfen, aber die gibt es ja noch nichtmal. |
|
Oder einfach lokal wie vorgesehen über die Wallbox? 🤷🏻♂️ |
|
Gleiches Problem hier, ich hab auch die Meldung: 429 Too Many Requests |
Die gehen leider nur bis 6A runter. Meine PV hat aber nur 1,75kWp. Damit habe ich aber trotzdem im letzten Monat 90% nur durch PV geladen. |
|
@Raudi1 OT: wie machst du das? |
Bei gutem Wetter hauptsächlich das Fahrrad genommen und fast immer wenn Sonne war ab 1A 1-phasig über EVCC geladen. Waren im letzten Monat ca. 100kWh laut EVCC. Am elegantesten wäre es denke ich den Tesla BLE Support in ESPHome oder so zu integrieren und das dann über EVCC zu steuern. |
@Raudi1 nochmal OT: schon klar- aber wie? |
|
Bei evcc, insbesondere auch serverseitig bzgl. Tesla Service hat sich nichts geändert, es gab auch keinen Neustart. Im Logfile kann ich erkennen, dass es viele Fahrzeuge gibt wo das problemlos zu laufen scheint obwohl wir tw. mehrere Requests pro Sekunde (für unterschiedliche Fahrzeuge) in Richtung Tesla schicken. |
Genau. Kann auch gerne noch mehr Daten von EVCC und Teslamate teilen, falls Interesse besteht.
Ich habe heute Nacht bei meinem Tesla ein Update auf 2024.14.9 gemacht. Ggfs. hängt es damit zusammen. Oder es wird einfach nur sukzessiv umgestellt. |
|
Heute geht es wieder. Die Frage ist nur für wie lange bevor das Limit wieder erreicht wird. |
|
Same issue on my side, also since updating my Model Y to 2024.14.9. Yesterday evening, no way to control anything, 429 errors at any request. This morning it was working again. To mitigate the issue for the time being, I’ve increased the refresh interval in yaml config to 60 instead of 30. |
|
I think there is an issue with the Tesla API. Yesterday I got the 429 errors and nothing worked at all. Wallbox: Tesla Wallbox 3 with Tesla MY + M3 |
|
I observe something similar: I’m getting timeouts from EVCC proxy: "https://tesla.evcc.io/api/1/vehicles/XXXXXXX/command/set_charging_amps\": net/http: request canceled (Client.Timeout exceeded while awaiting headers). |
Having the exact same problem with our Model 3. |
|
@ALL could you please stop posting "me too"? |
|
Ich habe jetzt mal die Bluetooth Option getestet. Funktioniert super! Dann muss man einfach die Keycard auf die Konsole halten und bestätigen. Achtung: Es taucht vorher im Tesla keine Meldung auf! Jetzt wäre nur meine Frage, wie man das am besten in EVCC einbindet? MQTT, REST...? Am besten wäre es natürlich das ganze in den bestehenden Tesla Code einzubinden und redundant zu gestalten. Dann könnte man wenn vorhanden und erreichbar über BLE gehen, und sonst über die Cloud. |
|
Wie du willst, aber dafür bitte neue Diskussion. Template welcome. |
Wenn sich ein Entwickler dafür finden könnte, wäre das eine super Sache. Ich helfe auch so gut es geht, aber ich kann leider keinen sauberen Code schreiben. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
teslamate-org/teslamate#3928 (comment)
Man müsste das intervall also auf 300 Sekunden stellen. Wäre ja nicht so schlimm, wenn man unterschiedliche update intervalle konfigurieren könnte. |
This comment was marked as off-topic.
This comment was marked as off-topic.
https://docs.evcc.io/en/docs/reference/configuration/interval |
Hi @pssturges can you post any updates from that thread here? I cant find anything online about Tesla implementing OCPP, I though it would be bigger news than that |
|
No, unfortunately |
|
I am the developer of SolarDashboard (an iOS and macOS app), and I've been following this thread since Tesla introduced these strict rate limits. SolarDashboard directly integrates the fleet API to enable solar surplus charging, but as we all know, that is no longer usable for those use cases. I am currently experimenting with the BLE implementation of the Command SDK, but there is no way receiving any charge states via BLE, making it useless for our purposes. However, what about using the Fleet Telemetry (https://github.com/teslamotors/fleet-telemetry) to retrieve the states and utilizing BLE for the commands? Has anyone considered this approach? P.S. Would be surprised if you guys get an answer from the fleet api team (email). |
|
Not considered since we don't need it. We're getting the state via TWC, i.e. evcc requires a "charger". Btw: beautiful dashboard! |
|
thanks ;-) Right. Wallgen is also an option. understand you always get the charge state from the charger. makes sense |
|
With #14616 there's a working solution and unless Tesla changes something, EVCC works again for me. |
|
Excellent, thank you all for your patience! |
|
Hi, |
|
Yes, but Tesla doesn‘t answer at this time… |
|
Ich schlage vor Tesla mit der Anfrage zu überfluten das die APIs wieder freischalten. Das muss teurer und aufwendiger sein die Kunden Beschwerden zu bearbeiten als die Serverkosten oder warum es gedrosselt wurde. Am besten mit Papier Briefen damit kein bot es erledigen kann. |
|
Hi again, vehicles:
- name: modelX
type: custom
title: Hotblack Desiato
capacity: 100
icon: car
chargeenable: # start/stop charging
source: http
uri: "http://MY_HA_IP:8123/api/services/switch/{{if .chargeenable}}turn_on{{else}}turn_off{{end}}"
method: POST
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
body: '{"entity_id": "switch.MY_CAR_charger"}'
jq: .state
maxcurrent: # set charger max current (A)
source: http
uri: http://MY_HA_IP:8123/api/services/number/set_value
method: POST
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
body: '{"entity_id": "number.MY_CAR_charging_amps", "value": "{{.maxcurrent}}"}'
jq: .state | tonumber
wakeup: # vehicle wake up command
source: http
uri: http://MY_HA_IP:8123/api/services/button/press
method: POST
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
body: '{"entity_id": "button.MY_CAR_wake_up"}'
jq: .state
status: # get vehicle connection status
source: combined
plugged: # plugged in?
source: http
uri: http://MY_HA_IP:8123/api/states/binary_sensor.MY_CAR_charger
method: GET
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
jq: .state
charging: # charging?
source: http
uri: http://MY_HA_IP:8123/api/states/binary_sensor.MY_CAR_charging
method: GET
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
jq: .state
soc: # battery soc (%)
source: http
uri: http://MY_HA_IP:8123/api/states/sensor.MY_CAR_battery
method: GET
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
jq: .state | tonumber
range: # electric range (km)
source: http
uri: http://MY_HA_IP:8123/api/states/sensor.MY_CAR_range
method: GET
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
jq: .state | tonumber
limitsoc: # charge limit set by car (%)
source: http
uri: http://MY_HA_IP:8123/api/states/number.MY_CAR_charge_limit
method: GET
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
jq: .state | tonumber
odometer: # milage (km)
source: http
uri: http://MY_HA_IP:8123/api/states/sensor.MY_CAR_odometer
method: GET
headers:
- authorization: Bearer MY_HA_ACCESS_TOKEN
- content-type: application/json
jq: .state | tonumberThe important pice is that you use the custom integration whithout the fleet API. Maybe that helps someone out there. Cheers! |
That seems pretty impossible? |
Well, when you install the plug in in home assistant it shows you a checkmark box "use fleet API" that you can leave unchecked. If you do so you can enter a refresh token on the next page that you can generate as described in the installation instructions. With that it works for me. Frankly I'm not able to tell what really goes on in the background since I'm not that deep in the topic. |
|
@spubanz Did you try a longer charging session with that yet? Last time I tried without Fleet Api I also ran into the rate limit. |
|
@Maddimax, it ran yesterday the whole afternoon (approx. 5+ hours) and still works today - with the standard template it usually lasted for 30 minutes max. Never the less, I tried it with the Model 3 a bit ago and it seems that wrinting values does not work with that one. So it looks like I'll stick with the BLE solution for the M3 and with the custom vehicle implementation for the pre 2021 MX... |
|
Hi all, some more rublings on Facebook with regards to OCPP on the TWC3, anyone should be able to view (I dont have a FB account and can). Link to document: https://www.energymining.sa.gov.au/__data/assets/pdf_file/0005/1051358/27062024-EVSE-Registered-Equipment-Compliance-List.pdf I am also going to contact the SA government and ask how Tesla is on there when it doesn't currently support OCPP and see if I can get more info. |
|
Is there a solution coming soon for people without programming skills, or should one just buy a different wallbox? I have EVCC running in Home Assistant. I can still manage to forward a Bluetooth stick to HA. But I can't get the TeslaBle Proxy running as a container; I've been working on it for three days. Not to mention what needs to be configured afterward. That's why I'm asking if it will ever be officially integrated into EVCC or if there is another solution. I don't think I'm alone in not having any programming skills. And definitely not in combination with Tesla and TWC. |
|
You don't need programming skills to set up the proxy. I'd say anybody who can get EVCC running and configured should be able to get the proxy running on a dedicated raspberry pi with Bluetooth built in like the zero 2. Another potential future option would be ESP home. |
|
Well, it would be nice to have proper instructions on what needs to be done and how. There are different scenarios, raspberry, Nas etc. I don't know what works. Is my Raps sufficient for this, do I need a new one or a 2nd one? |
|
You need one near your car. If it's only running EVCC, it should be fine. With other stuff your mileage may vary. |
|
"I have a NUC, Proxmox, VM Home Assistant, and Docker. ESPHome is running in HA. If I understand correctly, it only works with ARM architecture." |
|
So what I would do, is get yourself a Raspberry Pi Zero 2 W (the W is important to have WiFi and Bluetooth onboard). Install an OS on it and than install the above mentioned BLE proxy by following the instruction on the GitHub repo. |
|
Hi, everyone! I paired both Teslas to the proxy and am happy to report that I can control them through the proxy with no problem at all! All I have to do is use this simple command: After starting evcc, the first car receiving the command is working great! However, the second car is raising the API error '429 Too Many Requests'. I tried several times and noticed that it really only depends on which one was controlled first. Is there someone else with this behavior? @andig should i create another issue for this? Thanks |
|
Needs trace log file for |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
OCPP apparently confirmed to be coming to TWC3 |
and others
Describe the bug
Plötzlich geht bei mir die Tesla Anbindung nicht mehr. Kommt immer
429 Too Many Requestsegal ob EVCC SOC abfragt, oder Ladegeschwindigkeit sendet. Hat bisher ohne jegliche Änderung meinerseits problemlos funktioniert. Über die Tesla APP und auch Home Assistant läuft alles ohne Probleme.Steps to reproduce
Tesla anstecken/als Fahrzeug auswählen
Configuration details
Log details
What type of operating system are you running?
HomeAssistant Add-on
Version
0.126.6
The text was updated successfully, but these errors were encountered: