Tibber 429 too many requests Schleife

[Andi1887]

Describe the bug

Die Tibber-API, welche auch von evcc genutzt wird, hat ein Rate-Limit von 100 Abfragen pro 5 Minuten (https://developer.tibber.com/docs/overview). Wenn dieses Limit erreicht wurde, egal ob durch evcc oder einen anderen Dienst, kommt es zu folgendem Verhalten:

Nach einem 429 Status Code wird jeweils eine Sekunde später ein erneuter Versuch gestartet. Das führt dazu, dass die Sperre aufrecht erhalten bleibt, bis man evcc für einige Minuten ausschaltet.

Steps to reproduce

1. evcc mit Tibber-Anbindung nutzen
2. Das API-Limit von Tibber überschreiten

Configuration details

meters:
  - name: mygridmeter
    type: template
    template: tibber-pulse
    usage: grid
    token: xxxxxxxxxxxxxxxxx 
    timeout: 1m

Log details

[pulse ] TRACE 2025/02/01 06:44:16 failed to WebSocket dial: expected handshake response status code 101 but got 429. retry in 1 second... client
[pulse ] TRACE 2025/02/01 06:44:17 failed to WebSocket dial: expected handshake response status code 101 but got 429. retry in 1 second... client
[pulse ] TRACE 2025/02/01 06:44:18 failed to WebSocket dial: expected handshake response status code 101 but got 429. retry in 1 second... client
[pulse ] TRACE 2025/02/01 06:44:19 failed to WebSocket dial: expected handshake response status code 101 but got 429. retry in 1 second... client
[pulse ] TRACE 2025/02/01 06:44:20 failed to WebSocket dial: expected handshake response status code 101 but got 429. retry in 1 second... client

What type of operating system or environment does evcc run on?

Docker container

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

evcc version 0.133.0 (b7a9abb)

[phrozen77]

Siehe auch #17706 - "einfach" exponential backoff implementieren bei allem anderen als 200 - schon wärs gut?

[Andi1887]

Ja, das sollte das Problem lösen. Theoretisch könnte man aber auch mit fixen 30 Sekunden Wartezeit arbeiten, zumindest für diesen konkreten Fall.

[andig]

Der Logschnipsel ist leider nichtssagend. Mal wieder ist unklar wie es dazu kommt. These: das passiert nur im Fehlerfall.
Dann ist Tibber ja schon sehr lustig. Erst droppen sie die subscription fehlerhafterweise und dann beschweren sie sich wenn man die wieder haben will. Aber ja...

/cc @GrimmiMeloni

[GrimmiMeloni]

Ein exponentielles Backoff einzubauen ist leider so ohne weiteres nicht möglich, das gibt die Client Library nicht her.
Wir können aber sehr einfach das Default Retry Delay von 1s überschreiben.
Ich habe mal 5s angesetzt, damit bleiben wir auf jeden Fall unter den 100 Req / 300s