Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Torch1969]

KC27 schreef op woensdag 17 september 2025 @ 13:55:
Misschien is er iets fout gegaan bij installatie van rc4. Was het ook met rc3?
Is er nog andere hardware waar je het als Docker container op kunt zetten?

Ik heb rc4 ook maar eens op de testomgeving gezet. De eerste optimalisatie berekening geeft deze fout

code:

2025-09-17 19:22:55 debug: Reduced hours for Sessy_dllu
hour max-power(kW)
2025-09-17 19:22:55 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 585, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 515, in calc_optimum_met_debug
    dacalc.calc_optimum()
  File "/root/dao/prog/day_ahead.py", line 400, in calc_optimum
    print(f"{uur[u]:2.0f} {red_power[u]:6.3f}")
            ^^^^^^^^^^^^^
ValueError: Unknown format code 'f' for object of type 'str'

Lijkt op een foutje in de code? De print functie lijkt niet goed (zou dit 'printf(' moeten zijn?)

[dennisdew16]

Ik heb inmiddels de installatie voor elkaar gekregen in home assistant. Nu loop ik echter tegen wat configuratie problemen aan met betrekking tot de DAO database. Ik gebruik een externe mariadb database waar ik een nieuwe user en database heb aangemaakt. Deze ingesteld en een test run gedaan. Geeft dan echter aan dat de tabel "values" ontbreekt. En dit klopt ook want het is een nieuwe/lege database. Moet ik zelf nog een aantal dingen configureren? Had het idee dat dit ingesteld zou worden als ik de DAO zou runnen maar mogelijk begrijp ik het verkeerd, ik hoor het graag!

[KC27]

Torch1969 schreef op woensdag 17 september 2025 @ 19:29:
[...]

Ik heb rc4 ook maar eens op de testomgeving gezet. De eerste optimalisatie berekening geeft deze fout


[...]

Lijkt op een foutje in de code? De print functie lijkt niet goed (zou dit 'printf(' moeten zijn?)

Die fout treedt op als je log-level op debug hebt staan.
Draait je met log-level=info dan blijft ie achterwege,
In de volgende rc is deze error gefixed.

[KC27]

dennisdew16 schreef op woensdag 17 september 2025 @ 20:34:
Ik heb inmiddels de installatie voor elkaar gekregen in home assistant. Nu loop ik echter tegen wat configuratie problemen aan met betrekking tot de DAO database. Ik gebruik een externe mariadb database waar ik een nieuwe user en database heb aangemaakt. Deze ingesteld en een test run gedaan. Geeft dan echter aan dat de tabel "values" ontbreekt. En dit klopt ook want het is een nieuwe/lege database. Moet ik zelf nog een aantal dingen configureren? Had het idee dat dit ingesteld zou worden als ik de DAO zou runnen maar mogelijk begrijp ik het verkeerd, ik hoor het graag!

Deze database en de tabellen worden aangemaakt bij een (re)build van de addon.

[KC27]

@Mirabis goed nieuws: ik heb zeer waarschijnlijk de fout gevonden die de oorzaak is van jouw scheve grafiek.
Ik verwacht uiterlijk morgen een nieuwe rc, waarin dit is opgelost!

[tonvanboven]

KC27 schreef op dinsdag 16 september 2025 @ 09:27:
[...]

Ik twijfel of bij jouw de installatie van de update van rc4 wel goed is gegaan.
Naast de berekening heb ik ook de formattering aangepast en die zie ik bij jou niet terug:

[...]

Wat staat er boven in de log. Daar zou zoiets moeten staan (met rc4):

[...]

Dat lijkt wel goed gegaan te zijn, behalve dat er een spatie vooraan staat:

code:

 2025-09-17 23:00:00 info: Day Ahead Optimalisering versie: 2025.9.1.rc4

Als rc5 uit is gekomen gaan we er weer naar kijken.

[KC27]

Ik heb weer een nieuwe test-versie gepubliceerd: 2025.9.1.rc5
Dit staat in de changelog:

• Fixed format-error when loglevel=debug
• Set max of y-as for soc to 102%: when soc=100% the line is visible
• Extra information in the logging (level info) for control of the calculation of the profit
• Fixed error with wrong calculation of the consumption after optimization (reported by @Mirabis )

In de echte changelog staat ook nog:

Maximised the calculationtime to 20 sec, the accuracy to 0.005 euro (whichever comes first)

Maar deze aanpassing is nog niet meegekomen, maar die komt in rc6.

Door de correctie van de fout gevonden door @Mirabis komen de winst-berekeningen met interval=15min en interval=1hour nagenoeg overeen.

Er staat een m.i. verhelderend overzicht in de logging van de winstberekening, zodat iedereen deze berekening kan controleren:

code:

2025-09-17 23:01:32 info: Calculation profit optimize
2025-09-17 23:01:32 info: Cost before optimize:                  1.83 (€)
2025-09-17 23:01:32 info: Cost consumption:      7.85 (€)
2025-09-17 23:01:32 info: Profit production:    -8.68 (€)
2025-09-17 23:01:32 info: Cycle cost:            0.72 (€)
2025-09-17 23:01:32 info: Battery storage:       0.10 (€)
2025-09-17 23:01:32 info: Boiler storage:        0.03 (€)
2025-09-17 23:01:32 info: Total:                 0.01 (€)
2025-09-17 23:01:32 info: Cost after optimize:                   0.01 (€)
2025-09-17 23:01:32 info: Profit:                                1.82 (€)

[Mirabis]

Zojuist geupdatet naar 2025.9.1.rc5. De (visuele) afwijking is hier nu opgelost .

Logging: https://pastebin.com/6shsUeqq
Visueel: https://shottr.cc/s/1B5F/SCR-20250917-xxa

[Mirabis]

Hmm @KC27 Wanneer het "2025-09-18 13:14:01 waarschuwing: Geen oplossing voor: minimize cost" rapporteert door het ontbreken van day ahead data voor morgen lijkt het ook te stoppen met het doorgeven van waarden naar de batterij. Zo zou het om 13:00 moeten beginnen met opladen maar stuurt het de batterij niet aan door de foutmelding.

Logs: https://pastebin.com/24rCJ0gN
Visueel: https://shottr.cc/s/1iFJ/SCR-20250918-jfa.png

PS: Kan ik dit soort dingen beter melden op GitHub (per issue) of gewoon via Tweakers blijven doen?

[ Voor 10% gewijzigd door Mirabis op 18-09-2025 13:35 ]

[KC27]

Mirabis schreef op donderdag 18 september 2025 @ 13:16:
Hmm @KC27 Wanneer het "2025-09-18 13:14:01 waarschuwing: Geen oplossing voor: minimize cost" rapporteert door het ontbreken van day ahead data voor morgen lijkt het ook te stoppen met het doorgeven van waarden naar de batterij. Zo zou het om 13:00 moeten beginnen met opladen maar stuurt het de batterij niet aan door de foutmelding.

Logs: https://pastebin.com/24rCJ0gN
Visueel: https://shottr.cc/s/1iFJ/SCR-20250918-jfa.png

PS: Kan ik dit soort dingen beter melden op GitHub (per issue) of gewoon via Tweakers blijven doen?

Kan hier ook prima.
Ik had het zelf ook.
Dat moet ik nog oplossen in de software.
Workaround: handmatig de prijzen alsnog ophalen en dan doet ie het weer.

[f.welvering]

Ik heb sinds een aantal dagen dat het berekenen van de baseloads een timeout geeft.
Ik heb voor de test de laatste rc gedownload (werk op docker) maar krijg hier nog steeds de timeout.

dao | [2025-09-18 13:58:41 +0200] [16] [CRITICAL] WORKER TIMEOUT (pid:1557)
dao | [2025-09-18 13:58:41 +0200] [1557] [ERROR] Error handling request /
dao | Traceback (most recent call last):
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/gunicorn/workers/sync.py", line 134, in handle
dao | self.handle_request(listener, req, client, addr)
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/gunicorn/workers/sync.py", line 177, in handle_request
dao | respiter = self.wsgi(environ, resp.start_response)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 1536, in __call__
dao | return self.wsgi_app(environ, start_response)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 1511, in wsgi_app
dao | response = self.full_dispatch_request()
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request
dao | rv = self.dispatch_request()
dao | ^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request
dao | return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/webserver/app/routes.py", line 213, in menu
dao | return run_process()
dao | ^^^^^^^^^^^^^
dao | File "/root/dao/webserver/app/routes.py", line 342, in run_process
dao | proc = run(cmd, stdout=PIPE, stderr=PIPE)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/subprocess.py", line 550, in run
dao | stdout, stderr = process.communicate(input, timeout=timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/subprocess.py", line 1209, in communicate
dao | stdout, stderr = self._communicate(input, endtime, timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/subprocess.py", line 2115, in _communicate
dao | ready = selector.select(timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/selectors.py", line 415, in select
dao | fd_event_list = self._selector.poll(timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/gunicorn/workers/base.py", line 204, in handle_abort
dao | sys.exit(1)
dao | SystemExit: 1
dao | [2025-09-18 13:58:41 +0200] [1557] [INFO] Worker exiting (pid: 1557)
dao | sys:1: ResourceWarning: unclosed <socket.socket fd=5, family=2, type=1, proto=0, laddr=('0.0.0.0', 5000)>
dao | [2025-09-18 13:58:41 +0200] [1566] [INFO] Booting worker with pid: 1566

Mijn systeem draait op een supermicro server met meer dan ruim voldoende aan resources.

Config:

{
"homeassistant": {
"host": "192.168.60.3",
"ip port": 8123,
"token": "!secret ha_api_token"
},
"database ha": {
"engine": "mysql",
"server": "192.168.60.3",
"port": 3306,
"database": "homeassistant",
"username": "dao",
"password": "!secret db_da_password"
},
"database da": {
"engine": "mysql",
"server": "192.168.60.3",
"port": 3306,
"database": "dao",
"username": "dao",
"password": "!secret db_da_password"
},
"meteoserver-key": "!secret meteoserver-key",
"prices": {
"source day ahead": "nordpool",
"regular high": 0.50,
"regular low": 0.40,
"switch to low": 23,
"energy taxes consumption": {
"2022-01-01": 0.06729,
"2023-01-01": 0.12599,
"2024-01-01": 0.10880,
"2025-01-01": 0.10154
},
"energy taxes production": {
"2022-01-01": 0.06729,
"2023-01-01": 0.12599,
"2024-01-01": 0.10880,
"2025-01-01": 0.10154
},
"cost supplier consumption": {
"2022-01-01": 0.002,
"2023-03-01": 0.018,
"2024-04-01": 0.0175,
"2024-08-01": 0.020496
},
"cost supplier production": {
"2022-01-01": 0.002,
"2023-03-01": 0.018,
"2024-04-01": 0.0175,
"2024-08-01": 0.020496
},
"vat consumption": {
"2022-01-01": 21,
"2022-07-01": 9,
"2023-01-01": 21
},
"vat production": {
"2022-01-01": 21,
"2022-07-01": 9,
"2023-01-01": 21
},
"last invoice": "2025-09-01",
"tax refund": "False"
},
"logging level" : "info",
"use_calc_baseload": "True",
"baseload calc periode": 56,
"baseload": [
0.14,
0.38,
0.26,
0.42,
0.15,
0.12,
0.13,
0.15,
0.23,
0.26,
0.31,
0.32,
0.31,
0.23,
0.26,
0.21,
0.21,
0.54,
0.26,
0.26,
0.22,
0.19,
0.18,
0.16
],
"graphical backend": "",
"graphics": {
"style": "Solarize_Light2",
"show" : "true",
"battery balance": "True",
"prices consumption": "True",
"prices production": "True",
"prices spot": "True",
"average consumption": "True"
},
"strategy": "minimize cost",
"notifications": {
},
"grid": {
"max_power": 17
},
"history": {
"save days": 7
},
"dashboard": {
"port": 5000
},
"boiler": {
"boiler present": "False",
"entity actual temp.": "sensor.boiler_gemeten",
"entity setpoint": "sensor.boiler_ingesteld",
"entity hysterese": "sensor.hysterese_hot_water",
"cop": 2.9,
"cooling rate": 0.4,
"volume": 180,
"heating allowed below": 44,
"elec. power": 1500,
"activate service": "press",
"activate entity": "input_button.hw_trigger"
},
"heating": {
"heater present": "False",
"degree days factor": 3.6,
"stages": [
{
"max_power": 225,
"cop": 7.1
},
{
"max_power": 300,
"cop": 7.0
},
{
"max_power": 400,
"cop": 6.5
},
{
"max_power": 500,
"cop": 6.0
},
{
"max_power": 600,
"cop": 5.5
},
{
"max_power": 750,
"cop": 5.0
},
{
"max_power": 1000,
"cop": 4.5
},
{
"max_power": 1250,
"cop": 4.0
}
],
"entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
"adjustment factor": 0.04
},
"battery": [ ],
"solar": [ ],
"electric vehicle": [ ],
"machines" : [ ],
"tibber": {
"api_token": "!secret tibber_api_token"
},
"report": {
"entities grid consumption": [
"sensor.p1_meter_energie_import_tarief_1",
"sensor.p1_meter_energie_import_tarief_2"
],
"entities grid production": [
"sensor.p1_meter_energie_export_tarief_1",
"sensor.p1_meter_energie_export_tarief_2"
],
"entities solar production ac": [
"sensor.solaredge_panel_production_daily"
],
"entities solar production dc": [],
"entities ev consumption" : [],
"entities wp consumption" : [],
"entities boiler consumption": [],
"entities battery consumption": [],
"entities battery production": []
},
"scheduler": {
"active": "true",
"0430": "get_meteo_data",
"1030": "get_meteo_data",
"1630": "get_meteo_data",
"2230": "get_meteo_data",
"1255": "get_day_ahead_prices",
"1355": "get_day_ahead_prices",
"1455": "get_day_ahead_prices",
"1554": "get_day_ahead_prices",
"1655": "get_day_ahead_prices",
"xx00": "calc_optimum",
"2359": "clean_data"
}
}

[tonvanboven]

rc5 geïnstalleerd. De berekende tijd om de EV te laden wordt nu correct weergegeven in de log. Dank @KC27 voor de aanpassing hiervan.
Het overschakelen naar kwartierprijzen heeft als gevolg dat de berekeningen ook vier keer per uur worden gedaan. Tijdens het opladen van de auto gaat het op het einde van de oplaadsessie voor mij mis:

code:

2025-09-18 13:42:56 info: Instellingen voor laden van EV: Tesla
2025-09-18 13:42:56 info: Direct laden is uit
2025-09-18 13:42:56 info:  Ampere  Effic. Grid kW Accu kW
2025-09-18 13:42:56 info:    0.00    0.00    0.00    0.00
2025-09-18 13:42:56 info:   16.00    0.90   11.04    9.94
2025-09-18 13:42:56 info: Capaciteit accu: 70 kWh
2025-09-18 13:42:56 info: Maximaal laadvermogen: 11.04 kW
2025-09-18 13:42:56 info: Klaar met laden op: 19-09-2025 07:59:59
2025-09-18 13:42:56 info: Huidig laadniveau: 86.0 %
2025-09-18 13:42:56 info: Gewenst laadniveau:90.0 %
2025-09-18 13:42:56 info: Marge voor het laden: 4 %
2025-09-18 13:42:56 info: Locatie: home
2025-09-18 13:42:56 info: Ingeplugged:True
2025-09-18 13:42:56 info: Benodigde energie: 2.800 kWh
2025-09-18 13:42:56 info: Tijd nodig om te laden: 0:17 uur
2025-09-18 13:42:56 info: Afgerond naar hele intervallen: 2 kwartier
2025-09-18 13:42:56 info: Stand laden schakelaar: off
2025-09-18 13:42:56 info: Stand aantal ampere laden: 0.0 A
2025-09-18 13:42:56 info: Opladen wordt niet ingepland, omdat werkelijk niveau (86.0%) hoger is of gelijk aan gewenst niveau (90.0% minus de marge 4%).

Die 4% had ik ingesteld om niet elke keer voor een paar procent te gaan laden. Maar ja, nu zit DOA er meer bovenop en daarmee wordt het laden bij 86% gestopt. Ik heb de marge maar naar 1% gezet.

[Mirabis]

KC27 schreef op donderdag 18 september 2025 @ 13:56:
[...]

Kan hier ook prima.
Ik had het zelf ook.
Dat moet ik nog oplossen in de software.
Workaround: handmatig de prijzen alsnog ophalen en dan doet ie het weer.

Ok prima. Vanochtend merkte ik ook dat het op een duur moment (tussen 08:00 en 09:00) koos om op te laden. Om 07:45 stond dit niet in de planning, om 08:00-08:15 wel en dan 08:30 en later dan weer niet.

08:00 https://pastebin.com/qWhvaTnC
08:15 https://pastebin.com/AsvAAG7g
08:30 https://pastebin.com/PLRvt0VP
08:45 https://pastebin.com/v99dGqK3

[Hedzie]

Lasoul schreef op vrijdag 12 september 2025 @ 10:41:
[...]


Interessant, je hebt toevallig een link naar de Github pagina?

Het mooiste zou zijn dat ik niet hoef in te grijpen op wat de warmtepomp precies wanneer doet (aan/uit, vermogen). Eigenlijk lijkt het mij handig om de warmtepomp gewoon zijn ding te laten doen. Ik wil er wel voor zorgen dat de stroom die de warmtepomp gedurende de dag gaat gebruiken zo goedkoop mogelijk is zodat wanneer stroom duur is de warmtepomp de stroom uit de accu kan halen en dat daar dan genoeg in zit.

Ik ben hier ook naar op zoek.

Zou je de warmtepomp niet kunnen definiëren als “machine” ?
Weet niet hoe DAO reageert als je 96 kwartieren invult.

[Lasoul]

Hedzie schreef op donderdag 18 september 2025 @ 21:35:
[...]


Ik ben hier ook naar op zoek.

Zou je de warmtepomp niet kunnen definiëren als “machine” ?
Weet niet hoe DAO reageert als je 96 kwartieren invult.

Dat zou inderdaad een idee kunnen zijn, de vraag is alleen dan hoe je het verbruik dan dynamisch gaat invullen. Je wil namelijk op basis van de verwachte buitentemperatuur een verbruik voor de aankomende dag gaan doorgeven. Ik weet op basis van mijn stooklijn ongeveer mijn verbruik per dag in relatie tot de gemiddelde buitentemperatuur.

[KC27]

@Lasoul @Hedzie
Hebben jullie het hoofdstuk over heating in DOCs.md gelezen?
Je kunt momenteel je warmtepomp op drie manieren door DAO aansturen, m.n. afhankelijk van welke beïnvloedingsmogelijkheden er zijn:

• verschuiving stooklijn
• aan/uit schakelaar warmtepomp
• het elektrisch vermogen dat de wp mag verbruiken.

Deze keuze maak je met de instelling "adjustment".
Daarnaast "exporteert" het programma de gemiddelde buitentemperatuur voor de huidige optimaliseringsperiode (komt te staan in de entity avg outside temp ).
Hiermee kun je in HA het aantal graaddagen berekenen.
Als jullie nog meer nodig hebben wil ik daar best naar kijken, maar pas na 1 oktober.
Ik ben nu druk met alles op de rit te krijgen voor het 15min-interval.

[dennisdew16]

Ik heb inmiddels een basis configuratie gemaakt met PV en batterij, maar krijg nog steeds geen oplossing voor minimize cost. Denk dat het komt door ontbrekende data, zie hieronder. Delen door NaN zal wel het probleem zijn maar geen idee hoe ik dit oplos. Iemand suggesties? Heb debug logging al aan staan maar wordt er niet wijzer uit

code:

2025-09-19 09:31:04 debug: Prognose data:
          time                tijd  temp  glob_rad     pv_rad  da_price   da_cons   da_prod
0   1758265200 2025-09-19 07:00:00  17.0      88.0  109.47000   0.10696  0.163418  0.163418
1   1758268800 2025-09-19 08:00:00  18.0     114.0  159.80200   0.05161  0.148861  0.148861
2   1758272400 2025-09-19 09:00:00  19.0     161.0  231.91000   0.01302  0.147664  0.147664
3   1758276000 2025-09-19 10:00:00  20.0     204.0  300.88200   0.00099  0.147664  0.147664
4   1758279600 2025-09-19 11:00:00  21.0     198.0  277.84000   0.00000  0.162147  0.162147
5   1758283200 2025-09-19 12:00:00  22.0     191.0  261.37800   0.00000  0.230984  0.230984
6   1758286800 2025-09-19 13:00:00  23.0     178.0  240.13200   0.01197  0.284841  0.284841
7   1758290400 2025-09-19 14:00:00  23.0     137.0  175.10800   0.06886  0.426327  0.426327
8   1758294000 2025-09-19 15:00:00  23.0      98.0  119.65800   0.11337  0.599853  0.599853
9   1758297600 2025-09-19 16:00:00  23.0      48.0   53.08160   0.23030  0.345329  0.345329
10  1758301200 2025-09-19 17:00:00  21.0       7.0    7.19589   0.37371  0.280824  0.280824
11  1758304800 2025-09-19 18:00:00  20.0       0.0    0.00000   0.16336  0.251240  0.251240
12  1758308400 2025-09-19 19:00:00  19.0       0.0    0.00000   0.11005  0.243278  0.243278
13  1758312000 2025-09-19 20:00:00  18.0       0.0    0.00000   0.08560       NaN       NaN
14  1758315600 2025-09-19 21:00:00  18.0       0.0    0.00000   0.07902       NaN       NaN
2025-09-19 09:31:04 info: Baseload uit instellingen
2025-09-19 09:31:05 info: No reduced hours applied for Thuisbatterij

[KC27]

dennisdew16 schreef op vrijdag 19 september 2025 @ 09:34:
Ik heb inmiddels een basis configuratie gemaakt met PV en batterij, maar krijg nog steeds geen oplossing voor minimize cost. Denk dat het komt door ontbrekende data, zie hieronder. Delen door NaN zal wel het probleem zijn maar geen idee hoe ik dit oplos. Iemand suggesties? Heb debug logging al aan staan maar wordt er niet wijzer uit

code:

2025-09-19 09:31:04 debug: Prognose data:
          time                tijd  temp  glob_rad     pv_rad  da_price   da_cons   da_prod
0   1758265200 2025-09-19 07:00:00  17.0      88.0  109.47000   0.10696  0.163418  0.163418
1   1758268800 2025-09-19 08:00:00  18.0     114.0  159.80200   0.05161  0.148861  0.148861
2   1758272400 2025-09-19 09:00:00  19.0     161.0  231.91000   0.01302  0.147664  0.147664
3   1758276000 2025-09-19 10:00:00  20.0     204.0  300.88200   0.00099  0.147664  0.147664
4   1758279600 2025-09-19 11:00:00  21.0     198.0  277.84000   0.00000  0.162147  0.162147
5   1758283200 2025-09-19 12:00:00  22.0     191.0  261.37800   0.00000  0.230984  0.230984
6   1758286800 2025-09-19 13:00:00  23.0     178.0  240.13200   0.01197  0.284841  0.284841
7   1758290400 2025-09-19 14:00:00  23.0     137.0  175.10800   0.06886  0.426327  0.426327
8   1758294000 2025-09-19 15:00:00  23.0      98.0  119.65800   0.11337  0.599853  0.599853
9   1758297600 2025-09-19 16:00:00  23.0      48.0   53.08160   0.23030  0.345329  0.345329
10  1758301200 2025-09-19 17:00:00  21.0       7.0    7.19589   0.37371  0.280824  0.280824
11  1758304800 2025-09-19 18:00:00  20.0       0.0    0.00000   0.16336  0.251240  0.251240
12  1758308400 2025-09-19 19:00:00  19.0       0.0    0.00000   0.11005  0.243278  0.243278
13  1758312000 2025-09-19 20:00:00  18.0       0.0    0.00000   0.08560       NaN       NaN
14  1758315600 2025-09-19 21:00:00  18.0       0.0    0.00000   0.07902       NaN       NaN
2025-09-19 09:31:04 info: Baseload uit instellingen
2025-09-19 09:31:05 info: No reduced hours applied for Thuisbatterij

Er gaan dingen niet goed met de berekening van je inkoop- (da_cons) en terugleveringtarief (da_prod).
Wat heb je ingesteld bij prices?

[dennisdew16]

@KC27 Ik heb het inmiddels met wat geluk gevonden via de github issues. Het ging om de laatste twee waarde en laat er nu net twee uur verschil zitten tussen UTC en CEST... Dus ik heb in mijn externe mariaDB de tijdzone aangepast en nu werkt het wel!
Een van de nadelen als je alles zelf host dat dit soort dingen niet automatisch aangepast wordt

[balk]

dennisdew16 schreef op vrijdag 19 september 2025 @ 10:28:
@KC27 Ik heb het inmiddels met wat geluk gevonden via de github issues. Het ging om de laatste twee waarde en laat er nu net twee uur verschil zitten tussen UTC en CEST... Dus ik heb in mijn externe mariaDB de tijdzone aangepast en nu werkt het wel!
Een van de nadelen als je alles zelf host dat dit soort dingen niet automatisch aangepast wordt

@KC27 is dit vergelijkbaar het het timezone issue dat we een tijdje geleden hadden gevonden icm PostgreSQL?

[dennisdew16]

balk schreef op vrijdag 19 september 2025 @ 13:20:
[...]

@KC27 is dit vergelijkbaar het het timezone issue dat we een tijdje geleden hadden gevonden icm PostgreSQL?

Ik heb exact dit issue gebruikt om het op te lossen. Kan ook aan mijn container configuratie liggen hoor dat ie standaard op UTC staat waardoor het niet werkte. Maar het was dus inderdaad een vergelijkbaar probleem.

[KC27]

@balk Werkt bij jouw rc5 inmiddels wel "goed" op jouw postgresql-systeem.
Goed wil nu zeggen: hij kan nu rekenen maar de reportagesmoet ik nog onder handen nemen.

[balk]

KC27 schreef op vrijdag 19 september 2025 @ 16:14:
@balk Werkt bij jouw rc5 inmiddels wel "goed" op jouw postgresql-systeem.
Goed wil nu zeggen: hij kan nu rekenen maar de reportagesmoet ik nog onder handen nemen.

Ik ben nog niet thuis geweest. Hopelijk lukt het dit weekend om te testen (bijna thuis nu).

[balk]

KC27 schreef op vrijdag 19 september 2025 @ 16:14:
@balk Werkt bij jouw rc5 inmiddels wel "goed" op jouw postgresql-systeem.
Goed wil nu zeggen: hij kan nu rekenen maar de reportagesmoet ik nog onder handen nemen.

Het lijkt het zelfde te doen als de stable versie. Wel moest ik expliciet de data opgeven bij ophalen van de tarieven. Maar dat kan ook komen door dat het niet het normale tijdstip is. Wel maak ik 8 cent minder winst
Het valt me ook op dat de tijdsassen niet gelijk lopen.

[Torch1969]

balk schreef op vrijdag 19 september 2025 @ 20:35:
[...]

Het lijkt het zelfde te doen als de stable versie. Wel moest ik expliciet de data opgeven bij ophalen van de tarieven. Maar dat kan ook komen door dat het niet het normale tijdstip is. Wel maak ik 8 cent minder winst
Het valt me ook op dat de tijdsassen niet gelijk lopen.
[Afbeelding]

[Afbeelding]

Een opvallend verschil in de periode 6 tot 8 uur. Bij kwartierprijs is er meer lever vermogen in het eerste uur, bij uurprijzen net andersom….

[Batavia]

Ik heb een nieuwe eigenaardigheid. Om 5 uur besluit dao om de auto nog een keer op te laden. In de grafiek is niks te zien en de entity die vertrek tijdstip weer geeft staat op zondag middag

[Torch1969]

Batavia schreef op zaterdag 20 september 2025 @ 18:12:
[Afbeelding]

Ik heb een nieuwe eigenaardigheid. Om 5 uur besluit dao om de auto nog een keer op te laden. In de grafiek is niks te zien en de entity die vertrek tijdstip weer geeft staat op zondag middag

Volgens mij heb je een verkeerde (oude) screenshot geplaatst. Deze komt me nog bekend voor (verkeerde yield voor je zonnepanelen )

[f.welvering]

f.welvering schreef op donderdag 18 september 2025 @ 14:01:
Ik heb sinds een aantal dagen dat het berekenen van de baseloads een timeout geeft.
Ik heb voor de test de laatste rc gedownload (werk op docker) maar krijg hier nog steeds de timeout.

[...]


Mijn systeem draait op een supermicro server met meer dan ruim voldoende aan resources.

Config:

[...]

Niemand een idee?

Ik zal ook al een tijdje te stoeien met het feit dat ik nooit een oplossing had voor optimalisatie.
Ik zag nu een aantal posts voorbij komen met de tijdzone verschillen, en dit bleek bij mij ook het geval.
Mijn systeem draait eigenlijk overal in CEST, maar de MariaDB container gaf UTC. Dit nu aangepast en ineens werkt het wel en zie ik geen NAN mee voorbij komen.

Baseload issue is hiermee helaas niet opgelost, die blijft een timeout geven.

[DaBit]

Als ik Run -> bereken de baseloads doe krijg ik na een hele tijd 'Bewerking "Bereken de baseloads" wordt uitgevoerd' een zwart scherm te zien. Maar vervolgens kan ik wel bij Home->Tabel (naast grafiek) de resultaten van de baseload berekening zien.

Lijkt inderdaad dat die berekening net wat langer duurt dan een timeout.

[f.welvering]

DaBit schreef op zondag 21 september 2025 @ 09:52:
Als ik Run -> bereken de baseloads doe krijg ik na een hele tijd 'Bewerking "Bereken de baseloads" wordt uitgevoerd' een zwart scherm te zien. Maar vervolgens kan ik wel bij Home->Tabel (naast grafiek) de resultaten van de baseload berekening zien.

Lijkt inderdaad dat die berekening net wat langer duurt dan een timeout.

Dat zwarte scherm is inderdaad de time-out.
Als ik het aantal dagen halveer gaat het wel goed

[DaBit]

Dat is ook half zoveel werk voor de databases.

Tsja. KC27 kan aan die timeout gaan morrelen, maar wanneer is het goed genoeg...
Persoonlijk vind ik een keer refreshen of Home->Tabel en een paar keer pijltje terug klikken tot ik de log van de baseloadberekening te pakken heb best acceptabel.

[f.welvering]

DaBit schreef op zondag 21 september 2025 @ 10:27:
Dat is ook half zoveel werk voor de databases.

Tsja. KC27 kan aan die timeout gaan morrelen, maar wanneer is het goed genoeg...
Persoonlijk vind ik een keer refreshen of Home->Tabel en een paar keer pijltje terug klikken tot ik de log van de baseloadberekening te pakken heb best acceptabel.

Deels klopt dat natuurlijk, maar hij maakt de berekening niet af.
Draait bij mij op een xeon processor met 8 beschikbare cores en 64GB geheugen. Dacht dat dit wel voldoende moest zijn

[KC27]

f.welvering schreef op zondag 21 september 2025 @ 12:23:
[...]


Deels klopt dat natuurlijk, maar hij maakt de berekening niet af.
Draait bij mij op een xeon processor met 8 beschikbare cores en 64GB geheugen. Dacht dat dit wel voldoende moest zijn

Als hij via de scheduler wordt afgetrapt, maakt hij dan ook niet de berekening af?
Wat staat er dan in de logging?

[jvanderkroon]

https://github.com/cornee.../main/dao/DOCS.md#heating

Ik wil de degree days factor gaan berekenen alleen vraag ik mij af hoe anderen dit doen?
Als ik bij mindergas.nl kijk heb ik een gemiddelde van 0,46 kWh/graaddag.
Vul ik dan bij de degree days factor 0,46 in?

Zijn er mensen die het dynamisch voor de dag zelf berekenen en hoe doe je dit dan? In de docs lees ik dan je wind- en/of zonprognoses mee zou kunnen nemen daarin.

[f.welvering]

KC27 schreef op zondag 21 september 2025 @ 15:26:
[...]

Als hij via de scheduler wordt afgetrapt, maakt hij dan ook niet de berekening af?
Wat staat er dan in de logging?

Dan wordt hij ook afgekapt, nu ook met 28 dagen.
Volgende error zie ik dan:

[2025-09-21 09:23:00 +0200] [15] [CRITICAL] WORKER TIMEOUT (pid:916)
dao | [2025-09-21 09:23:00 +0200] [916] [fout] Error handling request /
dao | Traceback (most recent call last):
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/gunicorn/workers/sync.py", line 134, in handle
dao | self.handle_request(listener, req, client, addr)
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/gunicorn/workers/sync.py", line 177, in handle_request
dao | respiter = self.wsgi(environ, resp.start_response)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 1536, in __call__
dao | return self.wsgi_app(environ, start_response)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 1511, in wsgi_app
dao | response = self.full_dispatch_request()
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request
dao | rv = self.dispatch_request()
dao | ^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request
dao | return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/root/dao/webserver/app/routes.py", line 213, in menu
dao | return run_process()
dao | ^^^^^^^^^^^^^
dao | File "/root/dao/webserver/app/routes.py", line 342, in run_process
dao | proc = run(cmd, stdout=PIPE, stderr=PIPE)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/subprocess.py", line 550, in run
dao | stdout, stderr = process.communicate(input, timeout=timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/subprocess.py", line 1209, in communicate
dao | stdout, stderr = self._communicate(input, endtime, timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/subprocess.py", line 2115, in _communicate
dao | ready = selector.select(timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^
dao | File "/usr/lib/python3.12/selectors.py", line 415, in select
dao | fd_event_list = self._selector.poll(timeout)
dao | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^Cdao | File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/gunicorn/workers/base.py", line 204, in handle_abort
dao | sys.exit(1)
dao | SystemExit: 1
dao | [2025-09-21 09:23:00 +0200] [916] [info] Worker exiting (pid: 916)
dao | sys:1: ResourceWarning: unclosed <socket.socket fd=5, family=2, type=1, proto=0, laddr=('0.0.0.0', 5000)>
dao | [2025-09-21 09:23:00 +0200] [3282] [INFO] Booting worker with pid: 3282
dao | ../data/options.json MODIFY
dao | Setting up watches.
dao | Watches established.

[KC27]

f.welvering schreef op maandag 22 september 2025 @ 11:14:
[...]


Dan wordt hij ook afgekapt, nu ook met 28 dagen.
Volgende error zie ik dan:

[...]

De foutmelding die je laat zien is de foutmelding die je krijgt als je via het run-menu de baseload berekent.
Maar hoe ziet de logging eruit als je hem via de scheduler inplant en laat uitvoeren?

[KC27]

jvanderkroon schreef op maandag 22 september 2025 @ 10:58:
https://github.com/cornee.../main/dao/DOCS.md#heating

Ik wil de degree days factor gaan berekenen alleen vraag ik mij af hoe anderen dit doen?
Als ik bij mindergas.nl kijk heb ik een gemiddelde van 0,46 kWh/graaddag.
Vul ik dan bij de degree days factor 0,46 in?

Zijn er mensen die het dynamisch voor de dag zelf berekenen en hoe doe je dit dan? In de docs lees ik dan je wind- en/of zonprognoses mee zou kunnen nemen daarin.

De door DAO berekende graaddagen staan in de berekeningslogging van DAO:

code:

2025-09-22 12:00:00 info: Gewogen graaddagen: 4.7 K.day
2025-09-22 12:00:00 info: Degree days factor: 4.0 kWh/K.day
2025-09-22 12:00:00 info: Reeds geproduceerde warmte: 13.5 kWh
2025-09-22 12:00:00 info: Nog benodigde warmte: 5.3 kWh
2025-09-22 12:00:00 info: Actuele warmtevraag: Ja
2025-09-22 12:00:00 info: Warmtepomp met power-regeling wordt ingepland

De gewogen graaddagen zijn de graaddagen van vandaag.
Dus in totaal heeft de woning nodig: 4.0 x 4,7 = 18,7 kWh (thermisch!)
De wp heeft al 13,5 kWh geproduceerd, dus nog te gaan 18,7-13,5 = 5,2 kWh(het verschil met 5,3 zal wel in de afronding zitten).
Zal ik de berekende graaddagen ook beschikbaar stellen via een entity?

[f.welvering]

KC27 schreef op maandag 22 september 2025 @ 12:04:
[...]

De foutmelding die je laat zien is de foutmelding die je krijgt als je via het run-menu de baseload berekent.
Maar hoe ziet de logging eruit als je hem via de scheduler inplant en laat uitvoeren?

Ik heb hem via de scheduler laten lopen.
Initieel zonder debug, en zag regeltjes voorbij komen tot aan weekdag 6.
Met debug aan zie ik waarden terug komen van 30-7 t/m 21-9 dus dat lijkt wel goed te gaan.
Dus via het run-menu gaat het niet goed lijkt het.

Ik draai overigens de recentste rc5.
CPU load tijdens de actie komt niet boven de 10% uit, en dit is inclusief de CPU hongerige Frigate NVR

[KC27]

f.welvering schreef op maandag 22 september 2025 @ 13:38:
[...]


Ik heb hem via de scheduler laten lopen.
Initieel zonder debug, en zag regeltjes voorbij komen tot aan weekdag 6.
Met debug aan zie ik waarden terug komen van 30-7 t/m 21-9 dus dat lijkt wel goed te gaan.
Dus via het run-menu gaat het niet goed lijkt het.

Ik draai overigens de recentste rc5.
CPU load tijdens de actie komt niet boven de 10% uit, en dit is inclusief de CPU hongerige Frigate NVR

Dat bevestigt mijn opinie dat het komt door een time-out-error op de webpagina waarmee de berekening wordt gestart.
Ik twijfel nog of ik die time-out-instelling wil verhogen....

[jvanderkroon]

KC27 schreef op maandag 22 september 2025 @ 12:10:
[...]
Zal ik de berekende graaddagen ook beschikbaar stellen via een entity?

Ik ben meer op zoek hoe ik zou kunnen berekenen wat de `degree days factor` voor die dag is. Zal hem voor nu wel even op de 0,46 instellen en kijken hoe dat bevalt.

[KC27]

Heb je een warmteverlies berekening van je huis?
Daar staat in hoeveel thermisch vermogen je minimaal nodig hebt om je huis bij -10 °C te verwarmen.
Vaak wordt daar nog een risico-opslag overeen gezet (kan de installateur lekker verdienen).
Neem als voorbeeld de waarde 6000W (6kW) (goed geïsoleerd vrijstaand huis)
Als je die waarde weet zonder opslag dan kun je die om te beginnen delen door 26 (16 - -10).
Die 16°C is een grenswaarde van de buitentemperatuur waarboven je meestal niet hoeft te verwarmen.
Dan heb je het thermisch vermogen om bij 1 K verschil tussen binnen en buiten om je huis te verwarmen.
Dus 6000/26 = 230 W
Over een hele dag gemiddeld heb je dan nodig 230 x 24 = 5520 Wh = 5,5 kWh (24 uur per dag).
Dus je gevoeligheid is : 5,5 kWh/graaddag.

Je kunt ook achteraf deze factor uitrekenen:
Als je op je wp kunt aflezen hoeveel warmte hij gisteren heeft geleverd en je neemt de graaddagen die DAO gisteren heeft berekend (zie logging). Dan kun je die twee op elkaar delen.

[KC27]

Ik heb vanavond 2025.9.1.rc6 in het test-kanaal gepubliceerd.
Dit staat in de changelog:

2025.9.1.rc6

• Maximised the calculationtime to 20 sec, the accuracy to 0.005 euro (whichever comes first)
• Fixed issues with boiler with 15min-interval

Known issue:

• The prognoses in the reports and the savings are incorrect

Mochten jullie nog wat vinden: laat het me hier of op Github weten.
Ik zal er deze week niks meer mee doen: ik ben er namelijk even tussenuit.
Dit is waarschijnlijk de laatste "release candidate".
Ik zal waarschijnlijk maandag 29 a.s. de productieversie publiceren, waarin ik zal proberen jullie laatste bevindingen (alleen als het error-fixes betreft, niet "nice to have") mee te nemen. Als het grote aanpassingen zijn die getest moeten worden komt er nog een rc7, maar die stel ik liever uit tot na 1oktober.

Dinsdag 30 september a.s. om 12:45 worden de eerste 15min tarieven gepubliceerd. Daar kunnen we dan mee gaan rekenen!

[simnet]

Ik krijg met de laatste versie (rc6) een segmentation fault.
Dit is bij ongewijzigde config, 1e keer draaien.

code:

 Logging van bewerking "Optimaliseringsberekening met debug":

2025-09-22 20:02:15 info: Day Ahead Optimalisering versie: 2025.9.1.rc6
2025-09-22 20:02:15 info: Day Ahead Optimalisering gestart op: 22-09-2025 20:02:15
2025-09-22 20:02:15 info: Day Ahead Optimalisatie gestart: 22-09-2025 20:02:15 taak: calc_optimum_met_debug
2025-09-22 20:02:15 info: Debug = True
2025-09-22 20:02:15 info: Zelf berekende baseload
2025-09-22 20:02:15 info: Start waarden: 
      uur                tijd   p_l   p_t  base  pv_ac  pv_dc
0   20:00 2025-09-22 20:00:00 0.310 0.187 0.310  0.000      0
1   21:00 2025-09-22 21:00:00 0.283 0.160 0.354  0.000      0
2   22:00 2025-09-22 22:00:00 0.274 0.151 0.328  0.000      0
3   23:00 2025-09-22 23:00:00 0.261 0.138 0.270  0.000      0
4   00:00 2025-09-23 00:00:00 0.257 0.134 0.202  0.000      0
5   01:00 2025-09-23 01:00:00 0.257 0.134 0.337  0.000      0
6   02:00 2025-09-23 02:00:00 0.258 0.135 0.393  0.000      0
7   03:00 2025-09-23 03:00:00 0.258 0.135 0.250  0.000      0
8   04:00 2025-09-23 04:00:00 0.258 0.136 0.176  0.000      0
9   05:00 2025-09-23 05:00:00 0.262 0.139 0.188  0.000      0
10  06:00 2025-09-23 06:00:00 0.302 0.179 0.219  0.000      0
11  07:00 2025-09-23 07:00:00 0.356 0.233 0.253  0.013      0
12  08:00 2025-09-23 08:00:00 0.354 0.231 0.302  0.125      0
13  09:00 2025-09-23 09:00:00 0.306 0.183 0.302  0.068      0
14  10:00 2025-09-23 10:00:00 0.272 0.149 0.384  1.323      0
15  11:00 2025-09-23 11:00:00 0.241 0.118 0.365  2.211      0
16  12:00 2025-09-23 12:00:00 0.231 0.109 0.559  1.700      0
17  13:00 2025-09-23 13:00:00 0.226 0.103 0.450  2.307      0
18  14:00 2025-09-23 14:00:00 0.226 0.103 0.445  2.732      0
19  15:00 2025-09-23 15:00:00 0.238 0.115 0.278  2.649      0
20  16:00 2025-09-23 16:00:00 0.251 0.129 0.371  1.485      0
21  17:00 2025-09-23 17:00:00 0.272 0.149 0.369  1.256      0
22  18:00 2025-09-23 18:00:00 0.313 0.190 0.489  0.587      0
23  19:00 2025-09-23 19:00:00 0.337 0.214 0.326  0.040      0
24  20:00 2025-09-23 20:00:00 0.290 0.167 0.227  0.000      0
25  21:00 2025-09-23 21:00:00 0.265 0.142 0.353  0.000      0
26  22:00 2025-09-23 22:00:00 0.249 0.126 0.285  0.000      0
27  23:00 2025-09-23 23:00:00 0.248 0.125 0.244  0.000      0
2025-09-22 20:02:16 info: No reduced hours applied for Marstek P3
2025-09-22 20:02:16 info: Startwaarde SoC Marstek P3: 99.0%

2025-09-22 20:02:16 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-09-22 20:02:16 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-09-22 20:02:16 info: Apparaat wasmachine direct starten staat uit
2025-09-22 20:02:16 info: Machine wasmachine wordt niet ingepland, want er is gekozen voor uit
2025-09-22 20:02:16 info: Apparaat droger direct starten staat uit
2025-09-22 20:02:16 info: Machine droger wordt niet ingepland, want er is gekozen voor uit
2025-09-22 20:02:16 info: Apparaat vaatwasser direct starten staat uit
2025-09-22 20:02:16 info: Machine vaatwasser wordt niet ingepland, want er is gekozen voor uit
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/entities.py:755: SyntaxWarning: invalid escape sequence '\l'
  """A conflict graph stores conflicts between incompatible assignments in


ERROR while running Cbc. Signal SIGSEGV caught. Getting stack trace.
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/libraries/cbc-c-linux-x86-64.so(_Z15CbcCrashHandleri+0x119) [0x7f49941c3459]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7f49a3783330]
python3(_PyObject_MakeTpCall+0x79) [0x5492f9]
python3(_PyEval_EvalFrameDefault+0xadf) [0x5d68bf]
python3(PyEval_EvalCode+0x15b) [0x5d4dab]
python3() [0x607fc2]
python3() [0x6b4393]
python3(_PyRun_SimpleFileObject+0x1aa) [0x6b40fa]
python3(_PyRun_AnyFileObject+0x4f) [0x6b3f2f]
python3(Py_RunMain+0x3b5) [0x6bbf45]
python3(Py_BytesMain+0x2d) [0x6bba2d]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7f49a37681ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7f49a376828b]
python3(_start+0x25) [0x656a35]




ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace.
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/libraries/cbc-c-linux-x86-64.so(_Z15CbcCrashHandleri+0x119) [0x7f49941c3459]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7f49a3783330]
/lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x11c) [0x7f49a37dcb2c]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x1e) [0x7f49a378327e]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xdf) [0x7f49a37668ff]
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/libraries/cbc-c-linux-x86-64.so(+0x1772d2) [0x7f49941772d2]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7f49a3783330]
python3(_PyObject_MakeTpCall+0x79) [0x5492f9]
python3(_PyEval_EvalFrameDefault+0xadf) [0x5d68bf]
python3(PyEval_EvalCode+0x15b) [0x5d4dab]
python3() [0x607fc2]
python3() [0x6b4393]
python3(_PyRun_SimpleFileObject+0x1aa) [0x6b40fa]
python3(_PyRun_AnyFileObject+0x4f) [0x6b3f2f]
python3(Py_RunMain+0x3b5) [0x6bbf45]
python3(Py_BytesMain+0x2d) [0x6bba2d]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7f49a37681ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7f49a376828b]
python3(_start+0x25) [0x656a35]

[KC27]

simnet schreef op maandag 22 september 2025 @ 20:05:
Ik krijg met de laatste versie (rc6) een segmentation fault.
Dit is bij ongewijzigde config, 1e keer draaien.


[...]

Dank voor het testen!
Ojee, die had ik er met rc5 eruit weten te krijgen.
Met veel moeite.
Ik hoop dat me dat vanavond nog lukt ....

[ Voor 3% gewijzigd door KC27 op 22-09-2025 21:40 ]

[balk]

rc6, prijzen ophalen:

code:

2025-09-22 21:53:55 debug: Save record: 2025-09-23 23:15 da 1758662100 0.08274
2025-09-22 21:53:55 debug: Save record: 2025-09-23 23:30 da 1758663000 0.08274
2025-09-22 21:53:55 debug: Save record: 2025-09-23 23:45 da 1758663900 0.08274
2025-09-22 21:53:55 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -4 Current Checked out connections: 1 at line 318 in /root/dao/prog/db_manager.py
2025-09-22 21:53:55 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 320 in /root/dao/prog/db_manager.py
2025-09-22 21:53:55 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2025-09-22 21:53:55 debug: http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 10
2025-09-22 21:53:55 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 587 in /root/dao/prog/da_base.py
2025-09-22 21:53:55 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 3897 in /root/dao/webserver/../prog/day_ahead.py
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/entities.py:755: SyntaxWarning: invalid escape sequence '\l'
  """A conflict graph stores conflicts between incompatible assignments in
debug:root:Dialect: postgresql, database: day_ahead_test, server: 192.168.1.111
debug:root:db_url: postgresql+psycopg2://day_ahead:<knip>@192.168.1.111:5432/day_ahead_test
debug:root:Dialect: postgresql, database: homeassistant3, server: 192.168.1.111
debug:root:db_url: postgresql+psycopg2://postgres:<knip>@192.168.1.111:5432/homeassistant3
debug:urllib3.connectionpool:Starting new HTTP connection (1): 192.168.1.7:8123
debug:urllib3.connectionpool:http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 323
debug:root:Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 203 in /root/dao/prog/da_base.py

Optimalisatieberekening met debug:

code:

Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
44 bounds tightened after postprocessing

Total time (CPU seconds):       0.02   (Wallclock seconds):       0.03

/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/entities.py:755: SyntaxWarning: invalid escape sequence '\l'
  """A conflict graph stores conflicts between incompatible assignments in
debug:root:Dialect: postgresql, database: day_ahead_test, server: 192.168.1.111
debug:root:db_url: postgresql+psycopg2://day_ahead:<knip>@192.168.1.111:5432/day_ahead_test
debug:root:Dialect: postgresql, database: homeassistant3, server: 192.168.1.111
debug:root:db_url: postgresql+psycopg2://postgres:<knip>@192.168.1.111:5432/homeassistant3
debug:urllib3.connectionpool:Starting new HTTP connection (1): 192.168.1.7:8123
debug:urllib3.connectionpool:http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 323
debug:root:Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 203 in /root/dao/prog/da_base.py


ERROR while running Cbc. Signal SIGSEGV caught. Getting stack trace.
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/libraries/cbc-c-linux-x86-64.so(_Z15CbcCrashHandleri+0x119) [0x7fa9d71c3459]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7fa9eb5f7330]
python3(_PyObject_MakeTpCall+0x79) [0x5492f9]
python3(_PyEval_EvalFrameDefault+0xadf) [0x5d68bf]
python3(PyEval_EvalCode+0x15b) [0x5d4dab]
python3() [0x607fc2]
python3() [0x6b4393]
python3(_PyRun_SimpleFileObject+0x1aa) [0x6b40fa]
python3(_PyRun_AnyFileObject+0x4f) [0x6b3f2f]
python3(Py_RunMain+0x3b5) [0x6bbf45]
python3(Py_BytesMain+0x2d) [0x6bba2d]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7fa9eb5dc1ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7fa9eb5dc28b]
python3(_start+0x25) [0x656a35]




ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace.
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/libraries/cbc-c-linux-x86-64.so(_Z15CbcCrashHandleri+0x119) [0x7fa9d71c3459]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7fa9eb5f7330]
/lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x11c) [0x7fa9eb650b2c]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x1e) [0x7fa9eb5f727e]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xdf) [0x7fa9eb5da8ff]
/root/dao/venv/day_ahead/lib/python3.12/site-packages/mip/libraries/cbc-c-linux-x86-64.so(+0x1772d2) [0x7fa9d71772d2]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7fa9eb5f7330]
python3(_PyObject_MakeTpCall+0x79) [0x5492f9]
python3(_PyEval_EvalFrameDefault+0xadf) [0x5d68bf]
python3(PyEval_EvalCode+0x15b) [0x5d4dab]
python3() [0x607fc2]
python3() [0x6b4393]
python3(_PyRun_SimpleFileObject+0x1aa) [0x6b40fa]
python3(_PyRun_AnyFileObject+0x4f) [0x6b3f2f]
python3(Py_RunMain+0x3b5) [0x6bbf45]
python3(Py_BytesMain+0x2d) [0x6bba2d]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7fa9eb5dc1ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7fa9eb5dc28b]
python3(_start+0x25) [0x656a35]

[KC27]

@simnet @balk
Fout gevonden (de update van een andere library gooide de mip-library in de fout).
Ik heb de andere library gedowngrade (zoals ie was in rc5) en nu werkt het ook weer op x86/amd64 machines.
Je moet daarvoor wel versie 2025.9.1.rc7 installeren.

[simnet]

Top, werkt weer!

[balk]

hier ook! Bedankt

[simnet]

Even algemeen vraagje:
Ik merk dat met de kwartier prijzen de tijd van een berekening (logisch) weer is opgelopen. Nu vroeg ik me af of het haalbaar (en wenselijk) is om de CBC libraries te compileren met CPU optimalisaties.
Als dit een mogelijke versnelling weer oplevert ,dan kan ik hier wel wat tijd in steken om dit voor iedereen op een ondersteunde manier mogelijk te maken (zodat iedereen voor zijn eigen cpu kan compilen).
Ik hoor het graag. Met name de reactie van @KC27, aangezien hij dit al eens voor arm heeft gedaan. Als het niet veel nut gaat hebben dan stop ik er ook geen tijd in... 😁

[balk]

simnet schreef op dinsdag 23 september 2025 @ 15:27:
Even algemeen vraagje:
Ik merk dat met de kwartier prijzen de tijd van een berekening (logisch) weer is opgelopen. Nu vroeg ik me af of het haalbaar (en wenselijk) is om de CBC libraries te compileren met CPU optimalisaties.
Als dit een mogelijke versnelling weer oplevert ,dan kan ik hier wel wat tijd in steken om dit voor iedereen op een ondersteunde manier mogelijk te maken (zodat iedereen voor zijn eigen cpu kan compilen).
Ik hoor het graag. Met name de reactie van @KC27, aangezien hij dit al eens voor arm heeft gedaan. Als het niet veel nut gaat hebben dan stop ik er ook geen tijd in... 😁

hier duurt een berekening ongeveer 6 seconden. Dat is 2 seconden langzamer dan de 1 uurs berekening maar nog altijd allezins snel. Wat mij betreft geen noodzaak om hier iets aan te verbeteren...

[itavero]

Momenteel ook bezig met het inregelen van DAO voor mijn setup.
Ik heb nog wel een vraag over de cost supplier production.
Bij mijn Frank Energie contract betaal ik per teruggeleverde kWh een bedrag van 0.01271 euro.

Ik heb nu dat als positieve waarde ingevuld in mijn config, maar dan komt het tarief voor productie hoger uit dan voor verbruik. Uit de documentatie werd het mij niet helemaal duidelijk, maar ik neem dus aan dat in dit geval de waarde bij cost supplier production negatief ingevuld dient te worden?

(Sorry als dit een dubbele vraag is. Heb verschillende zoektermen geprobeerd in dit topic, maar helaas geen antwoord kunnen vinden.)

[Mirabis]

@itavero Er is zowel "cost supplier production" en "cost supplier consumption". Je kunt dus verschillende waardes invullen
* cost supplier consumption: kosten leverancier voor levering (euro/kWh, ex BTW)
* cost supplier production; teruggave leverancier bij teruglevering (euro/kWh, ex BTW)

In jouw geval zou je bij production dus een negatief getal invullen voor Frank.

[ Voor 11% gewijzigd door Mirabis op 24-09-2025 09:08 . Reden: formatting ]

[DaBit]

Bij mij (NextEnergy, rekent ook een vergoeding voor terugleveren):

code:

    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0181
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": -0.0181
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2025-02-27",
    "tax refund": "True"

[itavero]

Bedankt. Dan had ik het toch goed begrepen.

Ik dacht na het posten nog wel dat, nu we nog kunnen salderen (en ik nog steeds meer verbruik dan dat ik produceer) ik de bedragen misschien beter gelijk kan houden.
Houden jullie daar rekening mee in jullie configuratie?

[Mirabis]

Lijkt me in jouw situatie niet handig. Want ondanks dat je kan salderen is je opwek minder waard dan je verbruik door de verschillende opslagkosten? Als je de daadwerkelijke getallen invult zal DAO zelf berekenen wat handig is voor dat uur/kwartier.

[DaBit]

Ik ben het met Mirabis eens: geef DAO de beste representatie van de werkelijkheid die je kunt geven. Kwa kosten, maar ook kwa voorspelling van opwek en dergelijke. Pas dan werkt het optimalisatie-algorithme optimaal.

Jouw situatie waarin je meer verbruikt dan opwekt is een relatief makkelijke voor DAO; van elke kWh is de belasting te salderen bij teruglevering. Als je meer opwekt dan verbruikt is het lastiger want dan kun je van een deel de belasting niet meer salderen, alleen weet DAO niet precies welk deel.

[dennisdew16]

Heb DAO nu een aantal dagen draaien en ben er aardig tevreden mee al is het nog maar een basis configuratie. Nu zit ik echter met de vraag of je het prijsniveau vanaf wanneer DAO extra terug gaat leveren met een thuisasccu in kan stellen of zit dit helemaal in het programma gebakken als je minimize cost als optie hebt? Of dat je een minimale spread mee kan geven tussen laagste en hoogste prijs? Mogelijk gaat dat het doel van deze addon wel voorbij, laat het dan ook gerust weten

[Bravo]

dennisdew16 schreef op donderdag 25 september 2025 @ 12:03:
Heb DAO nu een aantal dagen draaien en ben er aardig tevreden mee al is het nog maar een basis configuratie. Nu zit ik echter met de vraag of je het prijsniveau vanaf wanneer DAO extra terug gaat leveren met een thuisasccu in kan stellen of zit dit helemaal in het programma gebakken als je minimize cost als optie hebt? Of dat je een minimale spread mee kan geven tussen laagste en hoogste prijs? Mogelijk gaat dat het doel van deze addon wel voorbij, laat het dan ook gerust weten

Deze addon kun je gebruiken voor minimale kosten (= maximale opbrengst) of minimale afname van het net, dus het doel is legitiem.

Je kunt het prijsniveau voor de spread beinvloeden door de parameter "cycle cost". Deze wordt zowel meegerekend bij het laden als ontladen, dus om op een cycle cost van 8 ct/kWh uit te komen zul je hier 0.04 moeten invullen.
De rest van de verliezen (kosten) volgen uit je configuratie.

Er zijn twee kampen, het ene kamp vindt dat je deze kosten niet meer moet rekenen als je een batterij hebt staan en je er maximaal gebruik van moet maken. Het andere kamp vindt dat je hier reele kosten moet rekenen.

[Dogooder]

Ik heb volgens mij een bug gevonden in de hier veel gedeelde apex chart code. Dit komt naar boven op het moment dat je meerdere keren per uur DAO aftrapt.
Bij de DAO run rond het hele uur wordt de state van de zon voorspelling aangepast naar de verwachte opbrengst van het hele uur. Als DAO vervolgens op het halve uur nog eens draait dan is de zon voorspelling aangepast naar wat nog te verwachten voor het komende half uur. voorbeeld:
1300 uur waarde 2 kwh
1330 uur waarde 1 kwh
Als je vervolgens in apex, of grafana ergens een grafiek maakt met group by 1 uur dan telt alleen de eerste waarde. Het is niet de waardes samen, of het gemiddelde.
Nu staat er bij de veel gedeelde apex chart code

code:

group_by:
      func: last
      duration: 1h

Apex pakt dan de laatste waarde in dat uur, maar volgens mij moet dat de eerste waarde zijn. Dus

code:

group_by:
      func: first
      duration: 1h

Zien meer mensen dit? Ik draai nog wel de oude DAO dus nog niet de kwartier versie.

[Bravo]

Dogooder schreef op donderdag 25 september 2025 @ 14:54:
Ik heb volgens mij een bug gevonden in de hier veel gedeelde apex chart code. Dit komt naar boven op het moment dat je meerdere keren per uur DAO aftrapt.
Bij de DAO run rond het hele uur wordt de state van de zon voorspelling aangepast naar de verwachte opbrengst van het hele uur. Als DAO vervolgens op het halve uur nog eens draait dan is de zon voorspelling aangepast naar wat nog te verwachten voor het komende half uur. voorbeeld:
1300 uur waarde 2 kwh
1330 uur waarde 1 kwh
Als je vervolgens in apex, of grafana ergens een grafiek maakt met group by 1 uur dan telt alleen de eerste waarde. Het is niet de waardes samen, of het gemiddelde.
Nu staat er bij de veel gedeelde apex chart code

code:

group_by:
      func: last
      duration: 1h

Apex pakt dan de laatste waarde in dat uur, maar volgens mij moet dat de eerste waarde zijn. Dus

code:

group_by:
      func: first
      duration: 1h

Zien meer mensen dit? Ik draai nog wel de oude DAO dus nog niet de kwartier versie.

Dit hangt af van de manier waarop je de informatie naar HA haalt. Bij mij is het een waarde die iedere 3600 sec (ieder uur) wordt opgehaald via de REST api. Toevalligerwijs is dit 3 minuten na het hele uur, dus pakt hij bij mij de waarde bij de berekening van het hele uur, waardoor het niet uitmaakt wat de uitkomsten van de andere berekeningen dat uur zijn.
Vervolgens wordt het via Apex Charts gevisualiseerd, maar die ziet dus alleen de uur data.

[Dogooder]

that makes sense Ik heb de scan_interval nog op 600 staan, zoals uit het voorbeeld in de docs. Ik ga dat even aanpassen naar 3600.

[Torch1969]

Dogooder schreef op donderdag 25 september 2025 @ 17:12:
that makes sense Ik heb de scan_interval nog op 600 staan, zoals uit het voorbeeld in de docs. Ik ga dat even aanpassen naar 3600.

Als je toch vaker of tussendoor handmatig een update doet (ik heb een knop op m’n dashboard voor ad-hoc report api aanroep), dan kun je ook ‘func: max’ proberen, die pakt dan de hoogste waarde van dat uur.
Ik ben nog niet met de kwartier prijzen en meerdere berekeningen per uur aan het uitproberen (zit bij zonneplan en die blijft eerst bij uurprijzen). Kan dus zijn dat die apexcharts-code daar nog niet lekker op aansluit. Daar komen we gezamenlijk vast wel uit

[thewhi]

Bravo schreef op donderdag 25 september 2025 @ 13:19:
[...]
Er zijn twee kampen, het ene kamp vindt dat je deze kosten niet meer moet rekenen als je een batterij hebt staan en je er maximaal gebruik van moet maken. Het andere kamp vindt dat je hier reele kosten moet rekenen.

En er is een derde kamp en die vindt dat je ergens in het midden moet gaan zitten met de kosten om de batterij niet onnodig te belasten (oftewel als de "winst" minimaal is en je de cycle wilt bewaren voor gunstigere momenten).