Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Bravo]

Voor mij is het niet problematisch dat de kwartierprijzen niet exact om 12.55 beschikbaar zijn zodat de run van 13.00 daarmee kan werken. Een uurtje later rekenen voor de volgende dag heeft in mijn geval niet heel veel impact.
Wat wel lastig is dat DAO gelijk onderuit gaat als de prijzen niet beschikbaar zijn, dat was voor de 15 min interval nog niet het geval, toch?

Met betrekking tot de enorme rekentijden die mijn setup nodig heeft:
Ik ben aan het proberen welke variabelen een enorme impact hebben op de rekentijd en ik denk dat ik heb gevonden wat het is.
Achtergrondinformatie: Ik gebruik DAO om alvast inzicht te krijgen van het nut van een batterij voor de situatie als salderen niet meer mogelijk is, dus tax refund: "False".
Als ik tax refund op "True" zet zit ik weer in de <10 seconden range aan rekentijd (op een RPi5).

Wat zijn de ervaringen van anderen die ook een verschil tussen inkoop- en verkoopprijs hebben?

Config: Bravo in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

[simnet]

Tussen 13:00 en 15:00 kan de strategie zomaar ineens wijzigen als de informatie van morgen bekend is. Juist rond dat tijdstip is de kans groot dat de prijzen erg laag zijn. Dus een uur lang je batterij niet volle kracht laden tegen lage prijzen kan best wel impact hebben op de dag erna.
Als DAO namelijk deze fout heeft, blijft ie tussen 12:45 en 14:00 (of welke run er dan net na de scheduler staat) op de strategie van 12:45 staan.

[ Voor 6% gewijzigd door simnet op 02-10-2025 15:15 ]

[Mirabis]

2025.10.2.rc1 Werkt prima maar vandaag 15:30 toch ineens een foutmelding. Of njah, 15:29 ondanks dat ik 15:30 configureer.

code:

2025-10-02 15:30:30 info: Het programma heeft een optimale oplossing gevonden.
2025-10-02 15:30:31 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 532, in calc_optimum
    dacalc.calc_optimum()
  File "/root/dao/prog/day_ahead.py", line 2494, in calc_optimum
    ac_to_dc_eff = ac_to_dc_netto * 100.0 / dc_from_ac_netto
                   ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
ZeroDivisionError: float division by zero

https://pastebin.com/kPMCtKKc

[itavero]

simnet schreef op donderdag 2 oktober 2025 @ 15:13:
Tussen 13:00 en 15:00 kan de strategie zomaar ineens wijzigen als de informatie van morgen bekend is. Juist rond dat tijdstip is de kans groot dat de prijzen erg laag zijn. Dus een uur lang je batterij niet volle kracht laden tegen lage prijzen kan best wel impact hebben op de dag erna.
Als DAO namelijk deze fout heeft, blijft ie tussen 12:45 en 14:00 (of welke run er dan net na de scheduler staat) op de strategie van 12:45 staan.

Ik zag vandaag iets vergelijkbaars met mijn EV (die ik "gelukkig" nog door Frank Energie aan laat sturen).
Mijn EV stond in HA ingepland net als bij Frank Energie in de app: morgen om 7:30 klaar met laden tot 80% (hij was 16% of zo).
Heel de dag werd er niets mee gedaan, want vertrektijd ligt voorbij horizon.
Enigszins begrijpelijk, want de kristallenbol ontbreekt.
Helaas bleek ook dat de meteogegevens laat in de ochtend niet goed opgehaald waren, dus m'n planningshorizon stond net nog steeds op einde van vandaag totdat ik die handmatig even ophaalde (toen werd de EV wel ingepland gelukkig).
Toch maar eens de schedule van de meteogegevens wat finetunen.

Hoe dan ook, ik zat hierdoor wel te denken dat het maken voorspellen van tarieven voorbij de planningshorizon voor situaties als deze wel toegevoegde waarde kan hebben.
Dat heeft vast wel een bak data nodig, maar de voorspellingen op bijvoorbeeld https://energie.theoxygent.nl/ zijn niet heel slecht die keren dat ik er naar kijk.

PS: Ik ben nog niet over naar kwartierprijzen (want dat kan ik nog niet kiezen bij Frank en draai nog 2025.9.0).

[Ferrox1]

Ik wil de kwartierprijzen gebruiken voor de berekening, maar na 2 dagen op 15min te staan blijft hij zeggen bij de debug run dat deze ontbreken. Terwijl ik ze met nordpool wel binnen zie komen.

Mis ik dan nog ergens een instelling? Of moet ik nog iets anders doen?