Tesla fleet API error 429 Too Many Requests

[Raudi1]

Describe the bug

Plötzlich geht bei mir die Tesla Anbindung nicht mehr. Kommt immer 429 Too Many Requests egal 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

# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: warn
levels:
  wario: trace
  db: trace

# unique installation id
plant: xxx

interval: 15s # control cycle interval

# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: true

sponsortoken: xxx

meters:
  - type: template
    template: shelly-pro-3em
    usage: grid
    host: 192.168.1.131
    name: Strom

  - name: Balkonsolar
    type: template
    template: hoymiles-opendtu
    usage: pv
    host: 192.168.1.126

chargers:
  - type: template
    template: twc3
    host: 192.168.1.35
    name: twc

  - name: gemini
    type: template
    template: go-e-v3
    host: 192.168.1.149

  - name: handtuchwaermer
    type: template
    template: shelly
    host: 192.168.1.125
    standbypower: 15 # Leistung oberhalb des angegebenen Wertes wird als Ladeleistung gewertet (optional)
    integrateddevice: true
    icon: heater
    heating: true

vehicles:
  - name: wario
    type: template
    template: tesla
    title: Wario
    accessToken: xxx
    refreshToken: xxx
    vin: xxx
    capacity: 60
    mincurrent: 1
    maxcurrent: 16
    control: true

  - name: Teslamate
    type: template
    template: teslamate
    title: Wario-Teslamate
    id: 1
    capacity: 60

loadpoints:
  - title: TWC3
    charger: twc
    vehicle: wario
    mode: pv
    priority: 2

  - title: Go-e
    charger: gemini
    vehicle: wario
    mode: pv
    priority: 1

  - title: Handtuchwaermer
    charger: handtuchwaermer
    priority: 0
    guardduration: 1m

site:
  title: Heideweg 20
  meters:
    grid: Strom
    pv: Balkonsolar
tariffs:
  grid:
    type: tibber
    token: xxx
  co2:
    type: grünstromindex
    zip: xxx

mqtt:
  broker: localhost:1883
  topic: evcc # root topic for publishing, set empty to disable publishing
  user: MQTT
  password: xxx

Log details

[db    ] TRACE 2024/06/07 12:34:36 UPDATE `sessions` SET `created`="2024-06-07 12:09:20.11",`finished`="0000-00-00 00:00:00",`loadpoint`="TWC3",`identifier`="",`vehicle`="Wario",`odometer`=NULL,`meter_start_kwh`=NULL,`meter_end_kwh`=NULL,`charged_kwh`=0,`charge_duration`=NULL,`solar_percentage`=NULL,`price`=NULL,`price_per_kwh`=NULL,`co2_per_kwh`=NULL WHERE `id` = 412 1 <nil>
[lp-1  ] ERROR 2024/06/07 12:34:50 vehicle odometer: 429 Too Many Requests
[lp-1  ] ERROR 2024/06/07 12:34:50 vehicle soc: 429 Too Many Requests
[lp-1  ] ERROR 2024/06/07 12:34:50 charger get max current: 429 Too Many Requests
[lp-1  ] ERROR 2024/06/07 12:34:50 vehicle soc: 429 Too Many Requests
[lp-1  ] ERROR 2024/06/07 12:34:50 charger get max current: 429 Too Many Requests

What type of operating system are you running?

HomeAssistant Add-on

Version

0.126.6

[Dirk77777]

Gleiches Problem (bei mir Docker mit 0.126.6). Gefühlt wechselt sich dieser Fehler mit #14229 ab.

[Raudi1]

Ist möglich, dass Tesla was an der API umgestellt hat. Evtl. limitieren sie jetzt die Commands pro Tag und Fahrzeug.
https://developer.tesla.com/docs/tesla-fleet-api#membership-levels

[Dirk77777]

Also wenn das stimmt, nur 50 Commands pro Tag und Fahrzeug, dann ist es vorbei mit dem PV-Überschussladen.

[Raudi1]

Ja, sieht wohl leider so aus. Größere Pakete könnten natürlich helfen, aber die gibt es ja noch nichtmal.
Allerdings ginge es evtl. über BLE. https://github.com/teslamotors/vehicle-command
Wäre eh besser als über eine Cloud Lösung gehen zu müssen.

[premultiply]

Oder einfach lokal wie vorgesehen über die Wallbox? 🤷🏻‍♂️

[row2hot]

Gleiches Problem hier, ich hab auch die Meldung: 429 Too Many Requests

[Raudi1]

Oder einfach lokal wie vorgesehen über die Wallbox? 🤷🏻‍♂️

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.

[andig]

@Raudi1 OT: wie machst du das?

[Raudi1]

@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.
Es gibt auch schon Versuche in die Richtung: esphome/feature-requests#2630

[andig]

und fast immer wenn Sonne war ab 1A 1-phasig über EVCC geladen.

@Raudi1 nochmal OT: schon klar- aber wie? charger: twc3 mit minCurrent: 1?

[andig]

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.

See teslamotors/vehicle-command#255

[Raudi1]

und fast immer wenn Sonne war ab 1A 1-phasig über EVCC geladen.

@Raudi1 nochmal OT: schon klar- aber wie? charger: twc3 mit minCurrent: 1?

Genau. Kann auch gerne noch mehr Daten von EVCC und Teslamate teilen, falls Interesse besteht.

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.

See teslamotors/vehicle-command#255

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.
Jedenfalls reicht das aktuelle Limit des einzigen verfügbaren Membership Levels von Tesla nicht. Habe nachdem EVCC nicht mehr steuern konnte dann von Hand in Home Assistant gesteuert. Das ging nach einer Weile dann auch nicht mehr...
Ich denke mittelfristig wird es nur über BLE vernünftig gehen. Lokal ist mir eh lieber als Cloud. Diese Umstellung ist mal wieder ein gutes Beispiel warum.

[Raudi1]

Heute geht es wieder. Die Frage ist nur für wie lange bevor das Limit wieder erreicht wird.

[FraBoCH]

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.

[ugoetzen]

I think there is an issue with the Tesla API. Yesterday I got the 429 errors and nothing worked at all.
Today after evcc was working as aspected for a while, I now got these errors and the charging power cannot adjusted anymore. Reading the API seems to still working.
[lp-1 ] WARN 2024/06/08 13:37:09 charger logic error: current mismatch (got 6A, expected 16A)
[lp-1 ] DEBUG 2024/06/08 13:37:09 pv charge current: 0A = 6A + -8.79A (6065W @ 3p)
[lp-1 ] DEBUG 2024/06/08 13:37:09 projected site power 6065W >= 0W disable threshold
[lp-1 ] DEBUG 2024/06/08 13:37:09 pv disable timer start: 3m0s
[lp-1 ] DEBUG 2024/06/08 13:37:09 pv disable in 3m0s
[lp-1 ] ERROR 2024/06/08 13:37:19 max charge current 3A: Post "https://tesla.evcc.io/api/1/vehicles/XP7YGCEL7NB00XXXX/command/set_charging_amps": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Wallbox: Tesla Wallbox 3 with Tesla MY + M3

[FraBoCH]

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).
I have no issue changing the amp & starting/stopping charge from the Tesla mobile app.
I’m also on a tesla wallbox 3 with a Tesla Y.

[Shuflel]

I observe something similar: I’m getting timeouts from EVCC proxy: "[https://tesla.evcc.io/api/1/vehicles/XXXXXXX/command/set_charging_amps](https://tesla.evcc.io/api/1/vehicles/XXXXXXX/command/set_charging_amps%5C)": net/http: request canceled (Client.Timeout exceeded while awaiting headers). I have no issue changing the amp & starting/stopping charge from the Tesla mobile app. I’m also on a tesla wallbox 3 with a Tesla Y.

Having the exact same problem with our Model 3.

[andig]

@ALL could you please stop posting "me too"?

[Raudi1]

Ich habe jetzt mal die Bluetooth Option getestet. Funktioniert super!
Installationsschritte:
Auf dem Raspberry PI Zero W raspberry OS lite installiert und SSH+WLAN konfiguriert.

sudo apt update && sudo apt install -y wget git build-essential
wget https://go.dev/dl/go1.20.14.linux-armv6l.tar.gz
tar -xvf go1.20.14.linux-armv6l.tar.gz
mkdir -p ~/.local/share && mv go ~/.local/share
echo 'export GOPATH=$HOME/.local/share/go' >> ~/.bashrc
echo 'export PATH=$HOME/.local/share/go/bin:$PATH' >> ~/.bashrc
git clone https://github.com/teslamotors/vehicle-command.git
cd vehicle-command
go get ./...
go build ./...
go install ./...
openssl ecparam -genkey -name prime256v1 -noout > private.pem
openssl ec -in private.pem -pubout > public.pem
sudo setcap 'cap_net_admin=eip' "$(which tesla-control)"
tesla-control -vin YOUR_VIN -ble add-key-request public.pem owner cloud_key

Dann muss man einfach die Keycard auf die Konsole halten und bestätigen. Achtung: Es taucht vorher im Tesla keine Meldung auf!
Im Anschluss kann man Kommandos wie über die cloud API schicken. Beispiel:
tesla-control -ble -vin YOUR_VIN -key-file private.pem charging-start

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.

[andig]

Wie du willst, aber dafür bitte neue Diskussion. Template welcome.

[Raudi1]

Wie du willst, aber dafür bitte neue Diskussion. Template welcome.

#14252

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.

[phoet]

teslamate-org/teslamate#3928 (comment)

The official API mentions a limit of 1 call every 5 minutes: that's actually 300 calls per day on vehicle_data then gets a 429 response with a retry-after header of 86400 seconds.

Man müsste das intervall also auf 300 Sekunden stellen. Wäre ja nicht so schlimm, wenn man unterschiedliche update intervalle konfigurieren könnte.

[infinus]

teslamate-org/teslamate#3928 (comment)

The official API mentions a limit of 1 call every 5 minutes: that's actually 300 calls per day on vehicle_data then gets a 429 response with a retry-after header of 86400 seconds.

Man müsste das intervall also auf 300 Sekunden stellen. Wäre ja nicht so schlimm, wenn man unterschiedliche update intervalle konfigurieren könnte.

https://docs.evcc.io/en/docs/reference/configuration/interval
So for now set interval: 300s to comply with current API limitations until fix is found.

[yipikaye]

Can confirm it does seem to be max requests in a 24hr period. After 24hrs it works for 30min or so then stops.

I'm thinking to get one of these and be done with it
TWC3 is no good

https://evse.com.au/product/ocular-iq-solar-7-kw-w-5m-cable/

[andig]

See #14252 for BLE

[phoet]

Vielleicht dieses Issue locken, bis es eine praktische Lösung gibt?

[wimaha]

If you are looking for a simple solution to use BLE instead of the Fleet API to bypass the rate limits, this is a functional solution that works with EVCC: https://github.com/wimaha/TeslaBleHttpProxy

[Maddimax]

So am I understanding it right, that the Tesla control just does not work at the moment the way its described in the documentation? Worth mentioning in the documentation maybe?

[Likemike24]

Wir hier eigentlich noch eine EVCC-eigene Lösung entwickelt, um das wieder hinzubekommen?
Tronity z.B. hat den Datenabruf zwischenzeitlich von 3 Minuten wieder auf 30 Sekunden umgestellt ("In Zusammenarbeit mit Tesla"). Man musste dafür aber einen neuen Zugriffschlüssel für das Fahrzeug erstellen.

[phoet]

Bekommen die das mit, wenn man die Org erwähnt @TRONITY_IO @tronity @sebastian-tronity ?

[Stacykid]

Bekommen die das mit, wenn man die Org erwähnt @TRONITY_IO @tronity @sebastian-tronity ?

Aktuell ruht der See, ich hoffe das EVCC auch an etwas bastelt, solange ist es nicht wirklich gut brauchbar.

[sebastian-tronity]

@phoet Hier am besten Tesla anschreiben.

[andig]

@Stacykid wir können nichts basteln da Tesla das Problem ist. Leider haben wir auf unsere Anfrage bisher keine Antwort erhalten. Wäre vielleicht eine gute Gelegenheit, Dich als Kunde von Tesla dafür einzusetzen, dass uns für unsere ClientID 08ff827fa31b-4ea6-bed1-817be0ab40c8 ein Angebot für einen hochvolumigeren Plan gemacht wird.

[D4rkH0ur]

@Stacykid wir können nichts basteln da Tesla das Problem ist. Leider haben wir auf unsere Anfrage bisher keine Antwort erhalten. Wäre vielleicht eine gute Gelegenheit, Dich als Kunde von Tesla dafür einzusetzen, dass uns für unsere ClientID 08ff827fa31b-4ea6-bed1-817be0ab40c8 ein Angebot für einen hochvolumigeren Plan gemacht wird.

Ich habe mal eine Email gesendet. Mal schauen ob es eine Antwort gibt 😅

[Stacykid]

Welche Mailadresse wäre das denn? Würde da auch hinschreiben.

[D4rkH0ur]

wäre

fleetapisupport@tesla.com

[Stacykid]

so, auch mal nett hingeschrieben.....

[pssturges]

Interesting development that has implications for this issue if there is any substance to it
https://www.facebook.com/groups/chargehqbeta/permalink/851971010123659/

[phoet]

@pssturges what exactly is to see under that private permalink?

[pssturges]

Ah sorry. Didn’t realise it’s a private group

[haroldboom]

I hope this is true because it would be the silver bullet for us

[Likemike24]

Neues von der Tronity Front:
`heute freuen wir uns, eine neue Art der Fahrzeugintegration vorstellen zu dürfen. Diese haben wir in Zusammenarbeit mit Tesla in Tronity implementiert und werden die betroffenen Nutzer schrittweise für das neue Vorgehen freischalten.

Was ist neu und warum ist dies auch für Nicht-Tesla-Fahrer spannend?

In der aktuellen Implementierung werden die Fahrzeugdaten jeweils von den Servern der Fahrzeughersteller abgerufen. Dabei sendet das Fahrzeug die Daten an den Fahrzeughersteller, und TRONITY kann im Namen der Nutzer die Daten entsprechend abrufen und verarbeiten.

Im Gegensatz dazu ist in der Zusammenarbeit mit Tesla nun eine Integration in TRONITY möglich, bei der das Fahrzeug die Daten direkt an TRONITY sendet! Dabei entscheidet das Fahrzeug, wann Daten gesendet werden, und es ist somit in der Regel ein Datenzugriff alle 30 Sekunden möglich 🤯 und nicht wie aktuell alle 3-5 Minuten.

Daneben gibt es viele weitere Vorteile. Zum Beispiel kann das Fahrzeug das eigene Energiemanagement berücksichtigen, wodurch kein unnötiger Batterieverlust in der Datenübertragung entsteht.
`

[andig]

Tronity war so nett uns auch direkt zu antworten wie sie das gemacht haben (dicker Dank an das @tronity Team).
In kurz: das hilf leider nichts weil darüber keine Kommandos an das Fahrzeug geschickt werden können- und genau das ist das Problem. Dabei hilft jetzt allerdings #14616.

[Likemike24]

OK, schade

[andig]

#14659 hat noch eine schöne Idee, wie sich das Rate Limit umgehen ließe wenn die Kontrolle über Bluetooth erfolgt. Muss zusammen mit #14616 und Lösungen wie https://github.com/wimaha/TeslaBleHttpProxy getestet werden (danke @FraBoCH für die Inspiration).

[haroldboom]

Ah sorry. Didn’t realise it’s a private group

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

[pssturges]

No, unfortunately