Skip to content

[BUG] Tibber prices sometimes not loaded #3703

Closed
Closed
[BUG] Tibber prices sometimes not loaded#3703
Labels
bugSomething isn't working

Description

@EckhardM
EckhardM
opened on Jul 23, 2026

Ich habe weiterhin gelegentlich Probleme beim Laden der Tibber-Preise für den folgenden Tag. Am Abend hat die openwb teilweise die Preise für den folgenden Tag noch nicht geladen. Die Folge sind falsche Planungen des Zielladens, die openwb rechnet dann nur mit den Preisen des aktuellen Tages. Damit wird häufig zu ungünstigeren Zeiten geladen (abends statt in den frühen Morgenstunden).

Ein Verbindungsproblem liegt nicht vor, denn durch den manuellen Aufruf von Einstellungen - Ladeeinstellungen - Übergreifendes - Speichern werden die Preisdaten zeitnah geladen.

openwb Version 2.2.1

Hier ist der Main-Log des ganzen Tages:

2026-07-23 03:25:34,369 - {root:242} - {WARNING:MainThread} - Display wird neu geladen.
2026-07-23 12:44:12,633 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -4.893000000000029W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 12:58:42,708 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -48.07100000000037W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:08:32,581 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -276.4100000000003W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:11:12,924 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -108.1579999999999W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:11:23,185 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 13:13:13,328 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -1.594000000000051W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:13:23,340 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 13:14:13,261 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -139.83799999999997W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:14:53,318 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -347.7020000000002W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:15:04,153 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 13:36:43,331 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -11.498999999999796W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 13:40:07,629 - {modules.utils:15} - {ERROR:MainThread} - Daten wurden noch nicht vollständig empfangen. Timeout abgelaufen, fortsetzen der Regelung.
2026-07-23 13:40:12,635 - {control.data:481} - {ERROR:MainThread} - Modul-Daten wurden noch nicht vollständig empfangen. Timeout abgelaufen, fortsetzen der Regelung.
2026-07-23 13:40:17,681 - {control.data:481} - {ERROR:MainThread} - Modul-Daten wurden noch nicht vollständig empfangen. Timeout abgelaufen, fortsetzen der Regelung.
2026-07-23 13:40:19,547 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 13:40:21,081 - {helpermodules.utils._thread_handler:50} - {ERROR:MainThread} - Thread smarthome ist bereits aktiv und wird nicht erneut gestartet.
2026-07-23 13:40:24,014 - {helpermodules.utils._thread_handler:50} - {ERROR:MainThread} - Thread smarthome ist bereits aktiv und wird nicht erneut gestartet.
2026-07-23 14:19:42,305 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -71.68200000000024W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 14:19:53,260 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 16:32:02,876 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -53.62900000000002W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 16:32:13,043 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 18:39:32,436 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -2642.167W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 20:01:22,461 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -3773.2279999999996W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 20:03:42,492 - {control.counter_all:107} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -2460.559W, Berücksichtigte Komponenten neben EVU [{'id': 2, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]
2026-07-23 21:15:02,598 - {helpermodules.setdata:344} - {ERROR:Setdata} - Unbekanntes set-Topic: openWB/set/optional/ep/prices, {'1784833200': 0.0004088, '1784834100': 0.00040760000000000004, '1784835000': 0.00040510000000000003, '1784835900': 0.00040029999999999997, '1784836800': 0.0004125, '1784837700': 0.0004042, '1784838600': 0.0003987, '1784839500': 0.00039, '1784840400': 0.0003956, '1784841300': 0.00038250000000000003, '1784842200': 0.000378, '1784843100': 0.0003726}
2026-07-23 21:15:48,168 - {modules.utils:15} - {ERROR:MainThread} - Daten wurden noch nicht vollständig empfangen. Timeout abgelaufen, fortsetzen der Regelung.
2026-07-23 21:15:53,172 - {control.data:481} - {ERROR:MainThread} - Modul-Daten wurden noch nicht vollständig empfangen. Timeout abgelaufen, fortsetzen der Regelung.
2026-07-23 21:15:53,413 - {modules.common.simcount._simcount:51} - {WARNING:MainThread} - Time difference between previous state and current state is too large. Set time difference to control interval.
2026-07-23 21:15:55,016 - {helpermodules.utils._thread_handler:50} - {ERROR:MainThread} - Thread smarthome ist bereits aktiv und wird nicht erneut gestartet.

Activity

  1. EckhardM
    added
    bugSomething isn't working
    on Jul 23, 2026

  2. seaspotter commented on Jul 24, 2026

    @seaspotter
    seaspotter
    on Jul 24, 2026
    Collaborator

    Der Log ist leider nicht auf Details und enthält damit leider nur einige wenige Fehler über den Tag aber keine Details auch zum Abruf der Tibber Daten. Ein Log auf Details hochgeladen auf http://paste.openwb.de wäre da notwendig (zum Zeitpunkt wenn das Problem auftaucht).

  3. EckhardM commented on Jul 24, 2026

    @EckhardM
    EckhardM
    on Jul 24, 2026
    Author

    Ich tu mich schwer, den Log Level auf Details zu stellen, da es Tage dauern kann, bis das Problem wieder auftritt. Ich schau trotzdem mal, ob es mir irgendwie gelingt, mehr Informationen bereitzustellen.

    Wie oft versucht die openwb derzeit, die Daten abzurufen? Das würde mir helfen, den Log beim Auftreten auf Details zu stellen.

  4. LKuemmel commented on Jul 28, 2026

    @LKuemmel
    LKuemmel
    on Jul 28, 2026
    Contributor

    weitere Meldung: #3446 (comment)

  5. LKuemmel commented on Jul 28, 2026

    @LKuemmel
    LKuemmel
    on Jul 28, 2026
    Contributor

    @tpd-opitz
    Konntest Du das bei dir auch beobachten? Kommen die Preise evtl nicht mehr pünktlich um 14.00 und es sollte um 18.00 nochmal probiert werden?

  6. EckhardM commented on Jul 28, 2026

    @EckhardM
    EckhardM
    on Jul 28, 2026
    Author

    Ich frage die Tibber-Preise für eine andere Anwendung (hat nichts mit openwb zu tun) einmal pro Stunde vom API ab (bei mir jeweils zur Minute 30). Meist stehen die Preise des Folgetags um 13:30 Uhr zur Verfügung, es gibt aber auch Tage, wo diese erst später abgefragt werden können. Daher checke ich immer, ob ich die Preise des Folgetages (und des aktuellen Tages) schon habe, falls nicht, versuche ich sie abzufragen. Das mache ich rund um die Uhr, den Zeitpunkt kann man ja per Zufall in der Stunde verteilen, damit nicht alle Boxen gleichzeitig das API belasten. @tpd-opitz

  7. LKuemmel commented on Aug 24, 2026

    @LKuemmel
    LKuemmel
    on Aug 24, 2026
    Contributor

    EckhardM
    commented
    2 weeks ago
    Wenn ich sie richtig verstehe, begeistert mich diese Lösung nicht. Wenn im Problemfall die Preise erst um 18 Uhr empfangen werden, wurde ggf. schon zu falschen Preisen geladen. Ich hänge mein Auto häufig schon am Nachmittag mit Zielladen an die Box. Wenn sie nur die Preise bis Mitternacht kennt, plant die Box das komplette Laden noch am gleichen Tag, obwohl es am nächsten Morgen meist günstigere Preise gibt. Außerdem warum macht ihr das für alle Boxen zur gleichen Zeit und baut nicht einen zufälligen Delay über die nächsten 60 Minuten ein? Außerdem gab es schon Tage, da hing das Tibber-API auch um 18 Uhr noch und die Preise standen erst später zur Verfügung. Daher schlage ich eine kontinuierliche Prüfung der Preise des aktuellen und des Folgetags vor.

    Mein Lösungsvorschlag:

    • Stündliche Prüfung, ob die Preise für den aktuellen Tag schon empfangen wurden, falls ja, do nothing
    • Ab 13 Uhr Prüfung, ob die Preise für den nächsten Tag schon empfangen wurden, falls ja, do nothing
    • Falls die Preise noch nicht empfangen wurden: Berechnung eines zufälligen Delays von 0 - 60 Minuten
    • Nach Ablauf des Delays Abfrage der Preise vom Tibber-API (genauso bei anderen Anbietern)

    Vorteil dieser Lösung:

    • Selbst bei großer Verzögerung werden die Preise sicher, aber frühestmöglich geladen
    • Lastverteilung und Vermeidung der API-Überlastung

    @tpd-opitz @LKuemmel

  8. LKuemmel commented on Aug 24, 2026

    @LKuemmel
    LKuemmel
    on Aug 24, 2026
    Contributor

    LKuemmel
    commented
    3 minutes ago
    Die Preise werde nicht von allen Boxen gleichzeitig abgefragt, sondern zu einer zufälligen Zeit, die jede openWB selbst generiert, innerhalb der nächsten halben Stunde, nachdem die Preise veröffentlicht werden.
    Der Vorschlag, die Preise solange abzufragen, bis die aktuellen Preise da sind, wird in 2.3.1 umgesetzt.

  9. EckhardM commented on Oct 11, 2026

    @EckhardM
    EckhardM
    on Oct 11, 2026
    Author

    Unter 2,2.3 funktioniert es so schlecht wie schon lange nicht: Ich hatte jetzt fast täglich um 20 Uhr keine Preise für den Folgetag, was dazu führt, dass das Fahrzeug fälschlicherweise am aktuellen Tag lädt:

    Image

    Und wieso steht da "Stromtarif: Kein Fehler", wenn offensichtlich die Preise nicht geladen werden konnten?

  10. tpd-opitz commented on Oct 11, 2026

    @tpd-opitz
    tpd-opitz
    on Oct 11, 2026
    Contributor

    10. Unter 2,2.3 funktioniert es so schlecht wie schon lange nicht: Ich hatte jetzt fast täglich um 20 Uhr keine Preise für den Folgetag, was dazu führt, dass das Fahrzeug fälschlicherweise am aktuellen Tag lädt:

    @EckhardM schaust Du bitte mal, was dann in openWB/set/optional/ep/flexible_tariff/get/next_query_time steht? (wenn möglich bitte in ein verständliches Datum übersetzten...)

         Und wieso steht da "Stromtarif: Kein Fehler", wenn offensichtlich die Preise nicht geladen werden konnten?

    Bisher sehen der copilot und ich noch nicht, wie das passieren kann... :o(

    [update]
    @LKuemmel
    Die Tarifdaten werden jetzt in jedem Regelzyklus abgefragt, das führt wahrscheinlich zu Problemen mit der concurrency.
    Ursprünglich erfolgte der Abruf nur alle 5 Minuten.

    ../main.log:2026-10-12 00:05:45,054 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexi>
../main.log:2026-10-12 00:05:45,059 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der grid_>
../main.log:2026-10-12 00:05:54,462 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexi>
../main.log:2026-10-12 00:05:54,466 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der grid_>
../main.log:2026-10-12 00:06:04,940 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexi>
../main.log:2026-10-12 00:06:04,945 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der grid_>

  11. EckhardM commented on Oct 12, 2026

    @EckhardM
    EckhardM
    on Oct 12, 2026
    Author

    @tpd-opitz Ich finde die next_query_time nur unter openWB/optional/ep/flexible_tariff/get/next_query_time, da steht jetzt (09:12 Uhr) der Wert 1791805500, was heute 13:45 ist - das passt erstmal.

  12. philipberghoff commented on Oct 12, 2026

    @philipberghoff
    philipberghoff
    on Oct 12, 2026

    Perfekt, wenn das Problem angegangen wird. Ich habe hier gerade angeregt, noch eine Möglichkeit zu schaffen, den API-Call manuell anzustoßen. Vielen Dank!

  13. tpd-opitz commented on Oct 12, 2026

    @tpd-opitz
    tpd-opitz
    on Oct 12, 2026
    Contributor

    Ich versuche gerade raus zu bekommen, warum das Update der Preise im normalen Regelzyklus aufgerufen wird. ich denke, es liegt daran, dass es beim Booten über handler.handler10Sec() aufgerufen wird:

    2026-10-12 20:05:32,284 - {modules.common.fault_state:47} - {ERROR:set values cp6} - Ladepunkt: FaultState FaultStateLevel.ERROR, FaultStr version, Traceback: 
NoneType: None

2026-10-12 20:05:32,639 - {modules.common.fault_state:47} - {ERROR:update values cp6} - Ladepunkt: FaultState FaultStateLevel.ERROR, FaultStr version, Traceback: 
NoneType: None

2026-10-12 20:05:32,955 - {modules.common.simcount._simcount:55} - {WARNING:component11} - Time difference between previous state and current state is too large.>
2026-10-12 20:05:33,200 - {control.optional:249} - {ERROR:MainThread} - Prüfe nächsten Preisabruf für flexible_tariff
Stack (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 373, in <module>
    handler.handler10Sec()
  File "/var/www/html/openWB/packages/main.py", line 170, in handler10Sec
    handler_with_control_interval()
  File "/var/www/html/openWB/packages/main.py", line 140, in handler_with_control_interval
    loadvars_.get_values()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 46, in get_values
    self.ep_get_prices()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 235, in ep_get_prices
    if data.data.optional_data.et_price_update_required():
  File "/var/www/html/openWB/packages/control/optional.py", line 265, in et_price_update_required
    self._is_et_price_update_required_for_module(self.data.electricity_pricing.flexible_tariff)) or
  File "/var/www/html/openWB/packages/control/optional.py", line 249, in _is_et_price_update_required_for_module
    log.error("Prüfe nächsten Preisabruf für %s", module.name, stack_info=True)
2026-10-12 20:05:38,443 - {modules.utils:15} - {ERROR:MainThread} - Daten wurden noch nicht vollständig empfangen. Timeout abgelaufen, fortsetzen der Regelung.

    zum 5 Minuten Intervall wird es dann zwei mal im selben Zyklus aufgerufen:

    2026-10-12 20:10:02,774 - {control.optional:249} - {ERROR:MainThread} - Prüfe nächsten Preisabruf für flexible_tariff
Stack (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 383, in <module>
    schedule.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 780, in run_pending
    default_scheduler.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 100, in run_pending
    self._run_job(job)
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 172, in _run_job
    ret = job.run()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 661, in run
    ret = self.job_func()
  File "/var/www/html/openWB/packages/main.py", line 90, in wrapper
    return func(self, *args, **kwargs)
  File "/var/www/html/openWB/packages/main.py", line 195, in handler5MinAlgorithm
    loadvars_.ep_get_prices()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 235, in ep_get_prices
    if data.data.optional_data.et_price_update_required():
  File "/var/www/html/openWB/packages/control/optional.py", line 265, in et_price_update_required
    self._is_et_price_update_required_for_module(self.data.electricity_pricing.flexible_tariff)) or
  File "/var/www/html/openWB/packages/control/optional.py", line 249, in _is_et_price_update_required_for_module
    log.error("Prüfe nächsten Preisabruf für %s", module.name, stack_info=True)
2026-10-12 20:10:02,812 - {control.optional:249} - {ERROR:MainThread} - Prüfe nächsten Preisabruf für grid_fee
Stack (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 383, in <module>
    schedule.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 780, in run_pending
    default_scheduler.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 100, in run_pending
    self._run_job(job)
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 172, in _run_job
    ret = job.run()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 661, in run
    ret = self.job_func()
  File "/var/www/html/openWB/packages/main.py", line 90, in wrapper
    return func(self, *args, **kwargs)
  File "/var/www/html/openWB/packages/main.py", line 195, in handler5MinAlgorithm
    loadvars_.ep_get_prices()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 235, in ep_get_prices
    if data.data.optional_data.et_price_update_required():
  File "/var/www/html/openWB/packages/control/optional.py", line 267, in et_price_update_required
    self._is_et_price_update_required_for_module(self.data.electricity_pricing.grid_fee)))
  File "/var/www/html/openWB/packages/control/optional.py", line 249, in _is_et_price_update_required_for_module
    log.error("Prüfe nächsten Preisabruf für %s", module.name, stack_info=True)
2026-10-12 20:10:05,096 - {modules.common.fault_state:47} - {ERROR:set values cp5} - Ladepunkt: FaultState FaultStateLevel.ERROR, FaultStr Erneutes Auslesen der EVSE, Traceback: 
NoneType: None

2026-10-12 20:10:05,591 - {modules.common.fault_state:47} - {ERROR:update values cp5} - Ladepunkt: FaultState FaultStateLevel.ERROR, FaultStr Erneutes Auslesen der EVSE, Traceback: 
NoneType: None

2026-10-12 20:10:06,121 - {control.optional:249} - {ERROR:MainThread} - Prüfe nächsten Preisabruf für flexible_tariff
Stack (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 383, in <module>
    schedule.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 780, in run_pending
    default_scheduler.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 100, in run_pending
    self._run_job(job)
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 172, in _run_job
    ret = job.run()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 661, in run
    ret = self.job_func()
  File "/var/www/html/openWB/packages/main.py", line 170, in handler10Sec
    handler_with_control_interval()
  File "/var/www/html/openWB/packages/main.py", line 140, in handler_with_control_interval
    loadvars_.get_values()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 46, in get_values
    self.ep_get_prices()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 235, in ep_get_prices
    if data.data.optional_data.et_price_update_required():
  File "/var/www/html/openWB/packages/control/optional.py", line 265, in et_price_update_required
    self._is_et_price_update_required_for_module(self.data.electricity_pricing.flexible_tariff)) or
  File "/var/www/html/openWB/packages/control/optional.py", line 249, in _is_et_price_update_required_for_module
    log.error("Prüfe nächsten Preisabruf für %s", module.name, stack_info=True)
2026-10-12 20:10:06,129 - {control.optional:249} - {ERROR:MainThread} - Prüfe nächsten Preisabruf für grid_fee
Stack (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 383, in <module>
    schedule.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 780, in run_pending
    default_scheduler.run_pending()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 100, in run_pending
    self._run_job(job)
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 172, in _run_job
    ret = job.run()
  File "/home/openwb/.local/lib/python3.9/site-packages/schedule/__init__.py", line 661, in run
    ret = self.job_func()
  File "/var/www/html/openWB/packages/main.py", line 170, in handler10Sec
    handler_with_control_interval()
  File "/var/www/html/openWB/packages/main.py", line 140, in handler_with_control_interval
    loadvars_.get_values()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 46, in get_values
    self.ep_get_prices()
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 235, in ep_get_prices
    if data.data.optional_data.et_price_update_required():
  File "/var/www/html/openWB/packages/control/optional.py", line 267, in et_price_update_required
    self._is_et_price_update_required_for_module(self.data.electricity_pricing.grid_fee)))
  File "/var/www/html/openWB/packages/control/optional.py", line 249, in _is_et_price_update_required_for_module
    log.error("Prüfe nächsten Preisabruf für %s", module.name, stack_info=True)

  14. seaspotter commented on Oct 12, 2026

    @seaspotter
    seaspotter
    on Oct 12, 2026
    Collaborator

    @tpd-opitz Glaube ich hab's – kein Concurrency-Problem, sondern ein Gating-Bug in configurable_tariff.py, der alle Tarif-Anbieter betrifft (nicht nur Tibber – awattar, octopusenergy, naturstrom etc. nutzen alle dieselbe ConfigurableFlexibleTariff/ConfigurableGridFee-Basis).

    In __call_component_updater() wird next_query_time nur neu gesetzt, wenn die Antwort tatsächlich neuere Preise liefert als schon bekannt:

    if last_known_timestamp < latest_price_timestamp:
    self._calculate_next_query_time(latest_price_timestamp)

    Hat der Anbieter beim ersten täglichen Versuch (13:25–13:55) die Preise für morgen noch nicht, bleibt next_query_time auf dem alten, bereits abgelaufenen Wert stehen. Im nächsten Regelzyklus (alle ~10s) greift die Abfragebedingung in update() dann sofort wieder – ohne Wartezeit. Das erklärt das "wird jetzt in jedem Regelzyklus abgefragt".

    Der Exception-Pfad hat dasselbe Problem: fault_state.warning("... retry in 5 minutes") ist nur Log-Text, next_query_time wird auch hier nie gesetzt. Führt das Dauerfeuer zu einem Rate-Limit beim Anbieter, bleibt es in der Schleife hängen – teils stundenlang.

    Erklärt auch das "Kein Fehler" trotz fehlender Preise: Auf dem "keine neuen Daten"-Pfad ruft __log_and_publish_progress() weiterhin no_error() auf, es gibt keinen Fehlerzustand für "immer noch keine Preise für morgen".

    Der doppelte Aufruf (handler10Sec + handler5MinAlgorithm) ist real, aber vermutlich nicht die Ursache – schedule.run_pending() läuft sequenziell, die sollten sich nicht überlappen.

    Vorschlag: next_query_time in beiden "kein Erfolg"-Fällen auf einen kurzen Backoff setzen (z.B. 15-30 min) statt gar nicht, plus eine echte Warnung ab einer gewissen Uhrzeit ohne Preise für morgen. Sag Bescheid, ob das passt – dann mach ich gerne einen PR oder du?

  15. EckhardM commented on Oct 12, 2026

    @EckhardM
    EckhardM
    on Oct 12, 2026
    Author

    Ich kann das morgen mal prüfen, falls ich um 14 Uhr wieder keine Preise habe, was dann bei mir in next_query_time steht. Nachdem ich die Einstellung "Ladeeinstellungen - Übergreifendes" heute aufgerufen und gespeichert habe, steht next_query_time richtigerweise erstmal wieder auf 1791892500 - also 13.10.2026 - 13:55:00.

    In einer völlig anderen Anwendung prüfe ich die Tibber-Preise in jeder Stunde zur Minute 31 und frage sie bei Tibber ab, falls ich sie noch nicht habe. Heute kamen die Preise erst um 14:31, das bedeutet, dass sie um 13:31 noch nicht verfügbar waren.

  16. 10 remaining items

  17. philipberghoff commented on Oct 14, 2026

    @philipberghoff
    philipberghoff
    on Oct 14, 2026

    27. Der PR ist jetzt im aktuellen Master, funkioniert es damit besser, schlechter, gar nicht mehr? :)

    Gute Frage - in der Tibber-App waren die Preise für morgen um 13:07 Uhr zumindest veröffentlicht. Die openWB kennt sie jetzt (13:24) noch nicht. Wie oft wird mit dem Fix abgefragt?

  18. seaspotter commented on Oct 14, 2026

    @seaspotter
    seaspotter
    on Oct 14, 2026
    Collaborator
     Gute Frage - in der Tibber-App waren die Preise für morgen um 13:07 Uhr zumindest veröffentlicht. Die openWB kennt sie jetzt (13:24) noch nicht. Wie oft wird mit dem Fix abgefragt?

    An der generellen Logik hat sich ja nichts geändert: openWB errechnet einen random Zeitraum zwischen 13:25 und 13:55 (für jede Installation was anderes) und versucht ab diesem Zeitpunkt die Daten zu holen. Der Zeitpunkt könnte bei dir also noch gar nicht erreicht sein.

    Was neu ist: Wenn dann keine Daten abgerufen werden können ab diesem Zeitpunkt, dann wird es alle 5min erneut versucht bis 16:00 Uhr und dann wird eine Warnung rausgegeben das keine Daten abgerufen werden können.

  19. philipberghoff commented on Oct 14, 2026

    @philipberghoff
    philipberghoff
    on Oct 14, 2026

    Jetzt sind die Preise da, @seaspotter. Sehr genial.

  20. EckhardM commented on Oct 14, 2026

    @EckhardM
    EckhardM
    on Oct 14, 2026
    Author

    Bei mir wurden heute bis jetzt (17:08) wieder keine Preise für morgen geladen (ich bin noch auf Version 2.2.3), was aber merkwürdig ist, openWB/optional/ep/flexible_tariff/get/next_query_time steht auf 1792014300 - das ist heute 23:45 - wie kommt er denn darauf?

  21. tpd-opitz commented on Oct 14, 2026

    @tpd-opitz
    tpd-opitz
    on Oct 14, 2026
    Contributor

    31. [...] was aber merkwürdig ist, openWB/optional/ep/flexible_tariff/get/next_query_time steht auf 1792014300 - das ist heute 23:45 - wie kommt er denn darauf?

    Dass ist der Fallback für Anbieter mit kürzeren Preisvorhersagen, wenn die Berechnung des nächsten update-timestamp einen Wert zu weit in der Zukunft ergab, dann wird der letzte Key der übermittelten Preise genommen. Die Frage ist, wieso er da hin kommt denn dieses if kann IMHO nicht true sein, wenn keine Taten von Tibber kamen:

            last_known_timestamp = datetime.fromtimestamp(max((int(ts) for ts in self.get.prices.keys()), default=0))
        tariff_state = self._component_updater()
        latest_price_timestamp = datetime.fromtimestamp(max((int(ts) for ts in tariff_state.prices.keys()), default=0))
        if last_known_timestamp < latest_price_timestamp: # < das war bei Eckhad 'true'
            self._calculate_next_query_time(latest_price_timestamp)

    Und damit sollte die "reguläre" Berechnung nicht aktiv sein, sondern seaspotters neue...

  22. seaspotter commented on Oct 14, 2026

    @seaspotter
    seaspotter
    on Oct 14, 2026
    Collaborator
     Und damit sollte die "reguläre" Berechnung nicht aktiv sein, sondern seaspotters neue...

    Aber er ist ja aufm 2.2.3 Release nicht aufm Master, da ist meine Berechnung nicht drin, nur im Master :)

  23. EckhardM commented on Oct 14, 2026

    @EckhardM
    EckhardM
    on Oct 14, 2026
    Author
     Aber er ist ja aufm 2.2.3 Release nicht aufm Master, da ist meine Berechnung nicht drin, nur im Master :)

    Ich habe mich bisher nicht getraut, auf den Master zu gehen, sondern war bisher immer auf dem Release. Repariert ihr Fehler immer zeitnah, falls doch mal was klemmt? Ich brauche die openWB wirklich täglich und muss mich drauf verlassen, dass das Auto am nächsten Morgen geladen ist.

  24. seaspotter commented on Oct 14, 2026

    @seaspotter
    seaspotter
    on Oct 14, 2026
    Collaborator
     Ich habe mich bisher nicht getraut, auf den Master zu gehen, sondern war bisher immer auf dem Release. Repariert ihr Fehler immer zeitnah, falls doch mal was klemmt? Ich brauche die openWB wirklich täglich und muss mich drauf verlassen, dass das Auto am nächsten Morgen geladen ist.

    Zumindest die Antworten kommen immer zeitnah :)
    Es kann im Master immer mal ein Bug sein der sich durch neue Änderungen einschleicht, das ist nie auszuschließen. Aber wenn man auch regelmäßig Backups macht plus vorm direkten Update, dann kannst du ja immer direkt wenn du merkst es funktioniert was nicht ein Backup einspielen. Aber man sollte sich dem eben bewusst sein, dass man da wirklich Alpha-Tester ist. Und ja auch Bugs werden ja meist zeitnah (sofern man es sofort findet und die Datenbasis gut ist) meist innerhalb ein paar Tage gefixt.

    Aber auch das nächste Release bzw. die Beta und dann das Release steht ja vor der Tür, dauert auch nicht mehr lange :)

  25. tpd-opitz commented on Oct 15, 2026

    @tpd-opitz
    tpd-opitz
    on Oct 15, 2026
    Contributor

    23. Der PR ist jetzt im aktuellen Master, funkioniert es damit besser, schlechter, gar nicht mehr? :)

    Mei mir gehts jetzt gar nicht mehr:

    • Stand: 2026-10-14 12:00:55 +0200 [c9606a1]

    • log:

        2026-10-15 14:18:15,565 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexible_tariff Strompreise 20261015-23:45:00.
  2026-10-15 14:18:15,569 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der grid_fee Strompreise 20261015-14:35:00.
    Image

    Ich habe also nach dem Fix das Verhalten, das Eckhard im release beobachtet

  26. seaspotter commented on Oct 15, 2026

    @seaspotter
    seaspotter
    on Oct 15, 2026
    Collaborator

    Ich habe also nach dem Fix das Verhalten, das Eckhard im release beobachtet

    Du hattest mit deinem Verdacht recht: der "kürzere-Preisvorhersage"-Fallback in _calculate_next_query_time() springt auf das Ende der heute schon bekannten Preise, sobald eine Anfrage "neuer als vorher" aussieht - auch wenn das nur bedeutet, dass die Antwort innerhalb des heutigen Tages weitergerollt ist, ohne je den Folgetag zu erreichen. Dadurch pausierte der Abruf bei dir bis 23:45, noch bevor die Warnschwelle (16:00) überhaupt erreicht war.

    Fix: der Sprung aufs Tagesende greift jetzt nur noch, wenn entweder schon Folgetagspreise da sind oder die Warnschwelle bereits erreicht ist - vorher bleibt's beim kurzen 5-Minuten-Backoff.
    #4122

  27. seaspotter commented on Oct 16, 2026

    @seaspotter
    seaspotter
    on Oct 16, 2026
    Collaborator

    Ist gemerged, geht's jetzt bei dir @tpd-opitz ?

  28. tpd-opitz commented on Oct 16, 2026

    @tpd-opitz
    tpd-opitz
    on Oct 16, 2026
    Contributor

    31. Ist gemerged, geht's jetzt bei dir @tpd-opitz ?

    sag ich Dir nach 14:00... ;o)

  29. tpd-opitz commented on Oct 16, 2026

    @tpd-opitz
    tpd-opitz
    on Oct 16, 2026
    Contributor

    30. Ist gemerged, geht's jetzt bei dir @tpd-opitz ?

    Hat geklappt:

    2026-10-16 14:45:03,855 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexible_tariff Strompreise 20261017-13:30:00.
2026-10-16 14:45:03,878 - {modules.common.configurable_tariff:60} - {DEBUG:update values flexible_tariff_module} - Tarifaktualisierung für flexible_tariff
2026-10-16 14:45:03,888 - {modules.common.component_context:29} - {DEBUG:update values flexible_tariff_module} - Update Komponente ['Tibber']
2026-10-16 14:45:03,946 - {urllib3.connectionpool:990} - {DEBUG:update values flexible_tariff_module} - Starting new HTTPS connection (1): api.tibber.com:443
2026-10-16 14:45:04,242 - {urllib3.connectionpool:453} - {DEBUG:update values flexible_tariff_module} - https://api.tibber.com:443 "POST /v1-beta/gql HTTP/1.1" 200 None
2026-10-16 14:45:04,270 - {modules.common.req:53} - {DEBUG:update values flexible_tariff_module} - Get-Response: {"data":{"viewer":{"home":{"currentSubscription":{"priceInfo":{"today":[{"total":0.3942,"startsAt":"2026-10-16T00:00:00.000+02:00"},>
2026-10-16 14:45:04,386 - {modules.common.configurable_tariff:83} - {DEBUG:update values flexible_tariff_module} - Aktuelle Tarif Update Stunde: 15 Uhr. Berechne nächsten Abruf der flexible_tariff Strompreise.
2026-10-16 14:45:04,392 - {modules.common.configurable_tariff:85} - {DEBUG:update values flexible_tariff_module} - Konfigurierte Tarifaktualisierungsstunden für flexible_tariff : [14]
2026-10-16 14:45:04,395 - {modules.common.configurable_tariff:88} - {DEBUG:update values flexible_tariff_module} - Nächste Tarifaktualisierungsstunde: 14 Uhr.
2026-10-16 14:45:04,399 - {modules.common.configurable_tariff:90} - {DEBUG:update values flexible_tariff_module} - Berechneter Tagsoffset für nächsten Abruf: 1 Tage.
2026-10-16 14:45:04,402 - {modules.common.configurable_tariff:118} - {DEBUG:update values flexible_tariff_module} - Nächster Abruf der flexible_tariff Strompreise geplant für: 2026-10-17 13:50:00 (Unix Timestamp: 1792237800)
2026-10-16 14:45:04,408 - {modules.common.store._api:26} - {DEBUG:update values flexible_tariff_module} - Raw data TariffState(prices={'1792154700': 0.0003312, '1792155600': 0.0003314, '1792156500': 0.00033939999999999996, '1792157400': 0.000341>
2026-10-16 14:45:04,446 - {modules.common.store._api:31} - {INFO:update values flexible_tariff_module} - Saving TariffState(prices={'1792154700': 0.0003312, '1792155600': 0.0003314, '1792156500': 0.00033939999999999996, '1792157400': 0.000341899>
2026-10-16 14:45:04,482 - {modules.common.store._tariff:24} - {DEBUG:update values flexible_tariff_module} - published prices list to MQTT having 133 entries
2026-10-16 14:45:24,363 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexible_tariff Strompreise 20261017-13:50:00.
OptionalData(electricity_pricing=ElectricityPricing(configured=True, flexible_tariff=FlexibleTariff(get=PricingGet(fault_state=0, next_query_time=1792237800, fault_str='Die flexible_tariff Preisliste hat 133 Einträge. ', prices={'1792154700': 0.>
2026-10-16 14:45:32,112 - {control.optional:253} - {DEBUG:MainThread} - Nächster Abruf der flexible_tariff Strompreise 20261017-13:50:00.

  30. seaspotter commented on Oct 16, 2026

    @seaspotter
    seaspotter
    on Oct 16, 2026
    Collaborator

    Yeah :) Dann mach ich das Issue hier mal zu weil Erledigt? Und du machst das dann nochmal "hübsch und schön" in Richtig @tpd-opitz mit nem eigenen PR ausserhalb des Bugfixes?

  31. seaspotter
    closed this as completedon Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions