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).

[hemertje]

Uit: Storage magazine

Nieuw onderzoek: thuisbatterij rendabel bij
combinatie verdienmodellen
Huishoudens kunnen een thuisbatterij binnen 5 jaar terugverdienen als zij inkomsten uit
handel op de energiemarkten combineren met een hoger aandeel eigen verbruik van zon-
nestroom. Dat blijkt uit nieuw onderzoek. Ook bij ongunstige marktomstandigheden blijft
het terugverdienen van een batterij binnen 12 jaar mogelijk. Als de marktomstandigheden
gunstig zijn, blijft een terugverdientijd van 5 jaar zelfs na afschaffing van de salderingsrege-
ling mogelijk. Dat concludeert adviesbureau Berenschot in een nieuw onderzoek voor
Zonneplan. De zogenoemde cross-marketstrategie, waarbij een batterij op meerdere ener-
giemarkten tegelijk wordt ingezet, blijkt het meest toekomstbestendig.

Kan DAO ook deze cross-marketstrategie simuleren?

[Dapdodo]

@hemertje , je kunt er maar 2 zelf: Day ahead en eigen verbruik.
De rest ben je afhankelijk van je energieleverancier
De vraag is dus welke energiemarkten bedoelen ze.

[Bravo]

Dapdodo schreef op zaterdag 27 september 2025 @ 08:38:
@hemertje , je kunt er maar 2 zelf: Day ahead en eigen verbruik.
De rest ben je afhankelijk van je energieleverancier
De vraag is dus welke energiemarkten bedoelen ze.

De andere markten zullen waarschijnlijk de Intra Day markt zijn en de (passieve) onbalansmarkt. Op deze markten kun je alleen via je energieleverancier acteren, niet vanuit een eigen regeling.

[dennisdew16]

Is er iemand die ziet wat er hier fout gaat? Ik krijg een foutmelding "must be a mapping, not a list". Ik dacht dat ik het volgens de documentatie had gedaan maar blijkbaar zit er nog ergens een fout in...

code:

"machines" : [
      { "name": "wasmachine",
        "programs":[
          {"name": "uit",
           "power": []},
          {"name": "Kleur 40 graden",
           "power": [1100, 1600, 200, 150, 150, 150, 150, 150, 150, 250]
           },
          {"name": "Wit",
           "power": [2000, 250, 150, 150, 220]
           }
        ],
        "entity start window": "input_datetime.start_window_wasmachine",
        "entity end window": "input_datetime.end_window_wasmachine",
        "entity selected program": "input_select.wasmachine",
        "entity calculated start": "",
        "entity calculated end": ""
      }
  ],

Bovenstaande helpers heb ik ook allemaal aangemaakt.

[Bravo]

dennisdew16 schreef op zaterdag 27 september 2025 @ 15:05:
Is er iemand die ziet wat er hier fout gaat? Ik krijg een foutmelding "must be a mapping, not a list". Ik dacht dat ik het volgens de documentatie had gedaan maar blijkbaar zit er nog ergens een fout in...

code:

"machines" : [
      { "name": "wasmachine",
        "programs":[
          {"name": "uit",
           "power": []},
          {"name": "Kleur 40 graden",
           "power": [1100, 1600, 200, 150, 150, 150, 150, 150, 150, 250]
           },
          {"name": "Wit",
           "power": [2000, 250, 150, 150, 220]
           }
        ],
        "entity start window": "input_datetime.start_window_wasmachine",
        "entity end window": "input_datetime.end_window_wasmachine",
        "entity selected program": "input_select.wasmachine",
        "entity calculated start": "",
        "entity calculated end": ""
      }
  ],

Bovenstaande helpers heb ik ook allemaal aangemaakt.

code:

        "entity calculated start": "",
        "entity calculated end": ""

Volgens mij moet je een van deze twee ook invullen, of allebei.
Ondanks dat deze 'optioneel' worden genoemd bij de instellingen staat er ook:
Het is gewenst dat minimaal een van de twee "calculated" helpers wordt ingegeven, zodat het programma het resultaat kan communiceren naar HA

[ Voor 8% gewijzigd door Bravo op 27-09-2025 15:20 ]

[dennisdew16]

@Bravo In de documentatie staat dat het optioneel is, maar ik zou het natuurlijk even kunnen proberen.

Edit: Heb twee dummy helpers gemaakt en inderdaad nu werkt het wel. Misschien dan handig om de documentatie aan te passen dat het niet optioneel is

[ Voor 43% gewijzigd door dennisdew16 op 27-09-2025 15:28 ]

[Bravo]

dennisdew16 schreef op zaterdag 27 september 2025 @ 15:25:
@Bravo In de documentatie staat dat het optioneel is, maar ik zou het natuurlijk even kunnen proberen.

Edit: Heb twee dummy helpers gemaakt en inderdaad nu werkt het wel. Misschien dan handig om de documentatie aan te passen dat het niet optioneel is

Een van beide is optioneel, niet allebei. In de documentatie staat het een paar regels verder (onder het plaatje).
Zoek maar op de tekst die ik hierboven ook al heb gequote:
Het is gewenst dat minimaal een van de twee "calculated" helpers wordt ingegeven, zodat het programma het resultaat kan communiceren naar HA

[dennisdew16]

Bravo schreef op zaterdag 27 september 2025 @ 19:29:
[...]

Een van beide is optioneel, niet allebei. In de documentatie staat het een paar regels verder (onder het plaatje).
Zoek maar op de tekst die ik hierboven ook al heb gequote:
Het is gewenst dat minimaal een van de twee "calculated" helpers wordt ingegeven, zodat het programma het resultaat kan communiceren naar HA

Ik heb de tekst gevonden inderdaad. Maar om te testen heb ik een van de twee weg gehaald en dan krijg ik evengoed weer de foutmelding... Misschien ligt het aan mij maar als iemand het zou kunnen reproduceren weten we meer

[balk]

@KC27 ik heb een feature request het zou fijn zijn als we een aantal zaken in zouden kunnen stellen via de API of via een Home Assistant entity.

• "reduced hours" is nu een statische lijst. Tijdens een vakantie zou ik deze waardes willen veranderen, want dan heeft niemand last van geluid. Nu moet ik dat handmatig doen.
• "optimal lower level" zou ik graag willen kunnen aanpassen. In de avond wil ik deze op 20 zetten om de nacht mee door te komen, en in de ochtend op 0 omdat er dan toch zon komt

er zijn vast nog wel andere settings, bijvoorbeeld bij boilers, vehicles, machines etc maar die gebruik ik niet. Zou je eens na willen denken over het in kunnen stellen van dit soor settings via een API of entity?

[KC27]

balk schreef op zondag 28 september 2025 @ 19:24:
@KC27 ik heb een feature request het zou fijn zijn als we een aantal zaken in zouden kunnen stellen via de API of via een Home Assistant entity.

• "reduced hours" is nu een statische lijst. Tijdens een vakantie zou ik deze waardes willen veranderen, want dan heeft niemand last van geluid. Nu moet ik dat handmatig doen.
• "optimal lower level" zou ik graag willen kunnen aanpassen. In de avond wil ik deze op 20 zetten om de nacht mee door te komen, en in de ochtend op 0 omdat er dan toch zon komt

er zijn vast nog wel andere settings, bijvoorbeeld bij boilers, vehicles, machines etc maar die gebruik ik niet. Zou je eens na willen denken over het in kunnen stellen van dit soor settings via een API of entity?

Die lijst met "reduced hours" kun je makkelijk opnemen in de settings.
Bijvoorbeeld: als je op vakantie gaat zet je (tijdelijk) een of twee slashjes voor reduced, dus zo:

code:

      "//reduced hours":
       { "23": 1200,
         "00": 1200
       },

En als je terugkomt van vakantie haal je ze weer weg

Dagelijks aanpassen van "optimal lower level" is moeilijker, dus die zet ik op mijn lijst.
Ik wil als de 15min-ellende voorbij is gaan kijken of ik alle "number-settings" optioneel kan "vervangen" door een entity.
Dus zoiets:

• staat er: "optimal lower level": 20.0: dan neemt ie 20
• maar staat er: "optimal lower level": "input_number_optimal_lower_level"; dan kijkt ie "automagisch" naar de ingevulde entity

En dat dan voor alle settings met een getal.
Even geduld svp.

[balk]

KC27 schreef op zondag 28 september 2025 @ 21:30:
[...]

Die lijst met "reduced hours" kun je makkelijk opnemen in de settings.
Bijvoorbeeld: als je op vakantie gaat zet je (tijdelijk) een of twee slashjes voor reduced, dus zo:

code:

      "//reduced hours":
       { "23": 1200,
         "00": 1200
       },

En als je terugkomt van vakantie haal je ze weer weg

Dagelijks aanpassen van "optimal lower level" is moeilijker, dus die zet ik op mijn lijst.
Ik wil als de 15min-ellende voorbij is gaan kijken of ik alle "number-settings" optioneel kan "vervangen" door een entity.
Dus zoiets:

• staat er: "optimal lower level": 20.0: dan neemt ie 20
• maar staat er: "optimal lower level": "input_number_optimal_lower_level"; dan kijkt ie "automagisch" naar de ingevulde entity

En dat dan voor alle settings met een getal.
Even geduld svp.

Uiteraard is dit geen prio, maar het leek me gewoon handig om deze zaken van een afstand te kunnen bedienen en dus niet handmatig de settings te hoeven veranderen. Maar misschien grijpt dit alles te diep in op hoe DAO momenteel is opgezet . Denk er eens rustig over na wat je er mee zou willen (of niet mee zou willen )

[Lasoul]

KC27 schreef op zondag 28 september 2025 @ 21:30:
[...]

Die lijst met "reduced hours" kun je makkelijk opnemen in de settings.
Bijvoorbeeld: als je op vakantie gaat zet je (tijdelijk) een of twee slashjes voor reduced, dus zo:

code:

      "//reduced hours":
       { "23": 1200,
         "00": 1200
       },

En als je terugkomt van vakantie haal je ze weer weg

Dagelijks aanpassen van "optimal lower level" is moeilijker, dus die zet ik op mijn lijst.
Ik wil als de 15min-ellende voorbij is gaan kijken of ik alle "number-settings" optioneel kan "vervangen" door een entity.
Dus zoiets:

• staat er: "optimal lower level": 20.0: dan neemt ie 20
• maar staat er: "optimal lower level": "input_number_optimal_lower_level"; dan kijkt ie "automagisch" naar de ingevulde entity

En dat dan voor alle settings met een getal.
Even geduld svp.

In het verlengde hiervan zou het handig zijn om via een API de mogelijkheid te hebben om settings via een API te wijzigen. Ik zit bijvoorbeeld te denken aan het dynamisch bepalen van de base_load op basis van de buitentemperatuur.

De use-case die ik heb zit op het vlak van de inzet van mijn warmtepomp. Ik heb gekeken naar de instellingen van de warmtepomp maar krijg het niet passend. Wellicht zie ik iets over het hoofd.
Ik wil mijn warmtepomp niet actief aansturen maar weet wel op basis van de gemiddelde buitentemperatuur wat het verwachte verbruik gaat worden voor de aankomende dag. Mijn idee is nu om op basis daarvan dynamisch de baseload voor die dag aan te passen.

[Bravo]

Lasoul schreef op maandag 29 september 2025 @ 08:43:
[...]


In het verlengde hiervan zou het handig zijn om via een API de mogelijkheid te hebben om settings via een API te wijzigen. Ik zit bijvoorbeeld te denken aan het dynamisch bepalen van de base_load op basis van de buitentemperatuur.

De use-case die ik heb zit op het vlak van de inzet van mijn warmtepomp. Ik heb gekeken naar de instellingen van de warmtepomp maar krijg het niet passend. Wellicht zie ik iets over het hoofd.
Ik wil mijn warmtepomp niet actief aansturen maar weet wel op basis van de gemiddelde buitentemperatuur wat het verwachte verbruik gaat worden voor de aankomende dag. Mijn idee is nu om op basis daarvan dynamisch de baseload voor die dag aan te passen.

In plaats van een dynamische baseload kun je toch de warmtepomp mee laten rekenen? Dan heb je de warmtevraag en de load van de warmtepomp ook in DAO zitten. De aansturing van DAO naar de entiteiten in HA gebruik je dan verder niet en je laat de wp zijn eigen ding doen, maar je hebt wel een inschatting van WP gebruik voor de dag. En als je een entiteit wp consumption hebt gaat hij ook de opwek verrekenen.

Toch?

[Lasoul]

Bravo schreef op maandag 29 september 2025 @ 08:49:
[...]

In plaats van een dynamische baseload kun je toch de warmtepomp mee laten rekenen? Dan heb je de warmtevraag en de load van de warmtepomp ook in DAO zitten. De aansturing van DAO naar de entiteiten in HA gebruik je dan verder niet en je laat de wp zijn eigen ding doen, maar je hebt wel een inschatting van WP gebruik voor de dag. En als je een entiteit wp consumption hebt gaat hij ook de opwek verrekenen.

Toch?

Zoals ik het begrijp gaat DOA dan ook de wamtepomp op specifieke momenten inplannen en dat klopt dan niet aangezien dan op dat moment de warmtepomp niet wordt aangestuurd.

Wat bedoel je met:

code:

En als je een entiteit wp consumption hebt gaat hij ook de opwek verrekenen.

Ik heb inderdaad een HA entiteit die het verbruik van de warmtepomp bijhoudt. Welke opwek moet dan worden verrekend? Is dat de warmte die is opgewekt (COP)?

[Bravo]

Lasoul schreef op maandag 29 september 2025 @ 08:56:
[...]


Zoals ik het begrijp gaat DOA dan ook de wamtepomp op specifieke momenten inplannen en dat klopt dan niet aangezien dan op dat moment de warmtepomp niet wordt aangestuurd.

Wat bedoel je met:

code:

En als je een entiteit wp consumption hebt gaat hij ook de opwek verrekenen.

Ik heb inderdaad een HA entiteit die het verbruik van de warmtepomp bijhoudt. Welke opwek moet dan worden verrekend? Is dat de warmte die is opgewekt (COP)?

Ter test
Volgens mij heb ik nu de voorbeeld warmtepomp config aanstaan, er gaat alleen een aanpassing stooklijn naar HA. Maar ik heb geen wp.

code:

2025-09-29 09:00:00 info: Gewogen graaddagen: 2.6 K.day
2025-09-29 09:00:00 info: Degree days factor: 7.3 kWh/K.day
2025-09-29 09:00:00 info: Reeds geproduceerde warmte: 0.0 kWh
2025-09-29 09:00:00 info: Nog benodigde warmte: 18.7 kWh
2025-09-29 09:00:00 info: Actuele warmtevraag: Ja
2025-09-29 09:00:00 info: Warmtepomp met power-regeling wordt ingepland

Inzet warmtepomp
2025-09-29 09:00:11 info: u     tar     p0     p1     p2     p3     p4     p5     p6     p7   heat   cons
2025-09-29 09:00:11 info: 9 0.2942    150      0      0      0      0      0      0      0   1.06   0.15
2025-09-29 09:00:11 info: 10 0.2519      0      0      0    188      0      0      0      0   1.13   0.19
2025-09-29 09:00:11 info: 11 0.2431      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 12 0.2363      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 13 0.2333      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 14 0.2379      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 15 0.2435    225      0      0      0      0      0      0      0   1.60   0.22
2025-09-29 09:00:11 info: 16 0.2541    225      0      0      0      0      0      0      0   1.60   0.22
2025-09-29 09:00:11 info: 17 0.2989      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 18 0.4659      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 19 0.5756      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 20 0.3464      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 21 0.2900      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 22 0.2733    106      0      0      0      0      0      0      0   0.75   0.11
2025-09-29 09:00:11 info: 23 0.2599      0    300      0      0      0      0      0      0   2.10   0.30

Hoe de entiteit wp consumption wordt omgezet naar vermogen in heat [kWh(thermisch)] weet ik niet, mogelijk op basis van het uurverbruik en de cop uit de tabel?

Maar dan heb je al wel een inschatting van je verbruik op de dag. Op uur basis zal die vast iets anders zijn, maar daar compenseer je voor door de opwek mee te rekenen.

[Lasoul]

Bravo schreef op maandag 29 september 2025 @ 09:10:
[...]

Ter test
Volgens mij heb ik nu de voorbeeld warmtepomp config aanstaan, er gaat alleen een aanpassing stooklijn naar HA. Maar ik heb geen wp.

code:

2025-09-29 09:00:00 info: Gewogen graaddagen: 2.6 K.day
2025-09-29 09:00:00 info: Degree days factor: 7.3 kWh/K.day
2025-09-29 09:00:00 info: Reeds geproduceerde warmte: 0.0 kWh
2025-09-29 09:00:00 info: Nog benodigde warmte: 18.7 kWh
2025-09-29 09:00:00 info: Actuele warmtevraag: Ja
2025-09-29 09:00:00 info: Warmtepomp met power-regeling wordt ingepland

Inzet warmtepomp
2025-09-29 09:00:11 info: u     tar     p0     p1     p2     p3     p4     p5     p6     p7   heat   cons
2025-09-29 09:00:11 info: 9 0.2942    150      0      0      0      0      0      0      0   1.06   0.15
2025-09-29 09:00:11 info: 10 0.2519      0      0      0    188      0      0      0      0   1.13   0.19
2025-09-29 09:00:11 info: 11 0.2431      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 12 0.2363      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 13 0.2333      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 14 0.2379      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 15 0.2435    225      0      0      0      0      0      0      0   1.60   0.22
2025-09-29 09:00:11 info: 16 0.2541    225      0      0      0      0      0      0      0   1.60   0.22
2025-09-29 09:00:11 info: 17 0.2989      0    300      0      0      0      0      0      0   2.10   0.30
2025-09-29 09:00:11 info: 18 0.4659      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 19 0.5756      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 20 0.3464      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 21 0.2900      0      0      0      0      0      0      0      0   0.00  -0.00
2025-09-29 09:00:11 info: 22 0.2733    106      0      0      0      0      0      0      0   0.75   0.11
2025-09-29 09:00:11 info: 23 0.2599      0    300      0      0      0      0      0      0   2.10   0.30

Hoe de entiteit wp consumption wordt omgezet naar vermogen in heat [kWh(thermisch)] weet ik niet, mogelijk op basis van het uurverbruik en de cop uit de tabel?

Maar dan heb je al wel een inschatting van je verbruik op de dag. Op uur basis zal die vast iets anders zijn, maar daar compenseer je voor door de opwek mee te rekenen.

Ik ga het nog een poging geven

[hemertje]

Zijn er hier DAO gebruikers met een Panasonic warmtepomp en die ook @edterbak 's Node Red Dashboard for Heishamon gebruiken?

Zo je , wil jeje DAO instellingen en HA scripts hier delen zodat ik en anderen er dankbaar gebruik van kan maken?

[KC27]

Zojuist is versie 2025.10.0 gepubliceerd (in het testkanaal staat versie 2025.10.0.rc1, ze zijn identiek).
Deze versie implementeert het gebruik van het 15min interval voor de prijzen.
Dit staat in de changelog:

This version is similar with 2025.10.0.rc1 in the testing-channel

Fix error with storing forecast (there was no timezone-correction)
Maximised the calculationtime to 20 sec, the accuracy to 0.005 euro (whichever comes first)
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 calculation/presentation "time needed" charging an ev
Fixed error with postgresql da-database
Added logging of free/used memory in logging on level "debug"

Know issue:

The forecast-calculation in the reports is not good working

Interval
This release supports two intervals: 1hour and 15min You make your choice in the settings, put in your settings somewhere in the root the setting:
"interval": "1hour" or "interval": "15min", 1hour will be default when you make no intervalsetting

source prices
At the moment only Nordpool, Tibber and Entsoe (the last one could not be tested) supports 15min prices.
If you don't want trouble: make Nordpool your price-source.

boiler
The boiler part is completely redesigned and (in my opinion) become better. The (thermal and financial) value of the boiler at the beginning and the end of the calculationperiod is taken into account. For every interval the electricity consumption for reheating is calculated and the best fitting will be choosen in the algortime.

Nog enkele aanvullende opmerkingen voor de gebruikers hier:

• Ik had alles een week eerder en kant-en klaar willen publiceren, maar helaas door vakantie en griep was mijn tijd voor dit project te kort.
• Vanaf morgen 12:45 worden de eerste 15min-tarieven gepubliceerd (voor de volgende werkdag). Dus je kunt na installatie met deze versie morgen aan de slag.
• Zoals je in bovenstaande changelog kunt lezen werken de rapportages van de prognoses nog niet goed. Dat heeft komende week mijn prioriteit.
• Mochten jullie nog onvolkomenheden tegenkomen: laat het hier weten, dan kunnen die wellicht snel opgelost worden.

[Bravo]

KC27 schreef op maandag 29 september 2025 @ 13:32:
Zojuist is versie 2025.10.0 gepubliceerd (in het testkanaal staat versie 2025.10.0.rc1, ze zijn identiek).
Deze versie implementeert het gebruik van het 15min interval voor de prijzen.
Dit staat in de changelog:

[...]


Nog enkele aanvullende opmerkingen voor de gebruikers hier:

• Ik had alles een week eerder en kant-en klaar willen publiceren, maar helaas door vakantie en griep was mijn tijd voor dit project te kort.
• Vanaf morgen 12:45 worden de eerste 15min-tarieven gepubliceerd (voor de volgende werkdag). Dus je kunt na installatie met deze versie morgen aan de slag.
• Zoals je in bovenstaande changelog kunt lezen werken de rapportages van de prognoses nog niet goed. Dat heeft komende week mijn prioriteit.
• Mochten jullie nog onvolkomenheden tegenkomen: laat het hier weten, dan kunnen die wellicht snel opgelost worden.

Zijn er nog extra stappen die nodig zijn voor het omschakelen naar 15 minuten interval?

Als ik na de update op 15 min interval wil werken geeft hij aan

code:

2025-09-29 14:24:53 fout: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken

Als ik de Day Ahead prijzen opnieuw ophaal, geeft hij aan dat de prijzen al bekend zijn

code:

2025-09-29 14:26:40 info: Day ahead data already present

Het lijkt erop dat de prijzen niet opnieuw in 15 min format worden opgehaald omdat de 1h prijzen al zijn opgeslagen.
Moet ik tot morgen wachten en tussen 12.00 en 12.55 de instelling omzetten zodat hij de 15 minuten prijzen ophaalt?

[KC27]

Vul de datum van vandaag in in het veld achter het "ophalen van prijzen".
En dan "prijzen ophalen"

[ Voor 18% gewijzigd door KC27 op 29-09-2025 14:39 ]

[Bravo]

KC27 schreef op maandag 29 september 2025 @ 14:38:
Vul de datum van vandaag in in het veld achter het "ophalen van prijzen".
En dan "prijzen ophalen"

En dat moet je los voor vandaag en morgen doen. Beide in 1 keer werkt somehow niet.

Mooi werk weer!

[KC27]

Bravo schreef op maandag 29 september 2025 @ 14:46:
[...]

En dat moet je los voor vandaag en morgen doen. Beide in 1 keer werkt somehow niet.

Mooi werk weer!

Ja, sorry, ik had het in de changelog op moeten nemen, maar ik wou het publishen.
En een keer wordt niet ondersteund door Nordpool.

[ Voor 7% gewijzigd door KC27 op 29-09-2025 14:49 ]

[ErnstH]

Het lijkt hier ook goed te gaan. Ik houd het de komende dagen in de gaten!
Super hoor, @KC27 !

[Bravo]

Toch een tegenvallertje. Met de uursvariant kan ik een (toekomstige) WP, (toekomstige) batterij, EV, PV, baseload en 2 machines berekenen op mijn RPI5. Al wekenlang geen probleem.
Met 15min variant krijg ik regelmatig een time-out op de 20 seconden. Als ik de WP eruit haal (standaard config) dan lukt het wel weer...
Draait als Add on in HomeAssistant.

code:

Cbc0020I Exiting on maximum time
Cbc0005I Partial search - best objective 1e+50 (best possible -3.8718131), took 13468 iterations and 310 nodes (20.01 seconds)
Cbc0032I Strong branching done 3422 times (42707 iterations), fathomed 0 nodes and fixed 32 variables
Cbc0035I Maximum depth 60, 0 variables fixed on reduced cost
2025-09-29 15:35:58 waarschuwing: Geen oplossing  voor: minimize cost

[KC27]

Bravo schreef op maandag 29 september 2025 @ 15:40:
Toch een tegenvallertje. Met de uursvariant kan ik een (toekomstige) WP, (toekomstige) batterij, EV, PV, baseload en 2 machines berekenen op mijn RPI5. Al wekenlang geen probleem.
Met 15min variant krijg ik regelmatig een time-out op de 20 seconden. Als ik de WP eruit haal (standaard config) dan lukt het wel weer...
Draait als Add on in HomeAssistant.

code:

Cbc0020I Exiting on maximum time
Cbc0005I Partial search - best objective 1e+50 (best possible -3.8718131), took 13468 iterations and 310 nodes (20.01 seconds)
Cbc0032I Strong branching done 3422 times (42707 iterations), fathomed 0 nodes and fixed 32 variables
Cbc0035I Maximum depth 60, 0 variables fixed on reduced cost
2025-09-29 15:35:58 waarschuwing: Geen oplossing  voor: minimize cost

Kun jij je settings hier delen (als quote 😉)?

[thewhi]

Helaas krijg ik deze fout:

code:

2025-09-29 15:47:31 info: Day Ahead Optimalisatie gestart: 29-09-2025 15:47:31 taak: get_day_ahead_prices
2025-09-29 15:47:31 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 590 in /root/dao/prog/da_base.py
2025-09-29 15:47:31 fout: sequence item 0: expected str instance, NoneType found
Traceback (most recent call last):
  File "/root/dao/prog/da_prices.py", line 150, in get_prices
    act_spot_prices = prices_spot.fetch(
                      ^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 242, in fetch
    return self._fetch_json(data_type, end_date, areas, resolution)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 201, in _fetch_json
    api_url, params, areas = self._get_url_params_areas(
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 187, in _get_url_params_areas
    params["indexNames"] = ",".join(
                           ^^^^^^^^^
TypeError: sequence item 0: expected str instance, NoneType found
2025-09-29 15:47:31 fout: Geen data van Nordpool: tussen 2025-09-29 00:00:00 en 2025-09-29 00:00:00

[KC27]

thewhi schreef op maandag 29 september 2025 @ 15:49:
Helaas krijg ik deze fout:

code:

2025-09-29 15:47:31 info: Day Ahead Optimalisatie gestart: 29-09-2025 15:47:31 taak: get_day_ahead_prices
2025-09-29 15:47:31 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 590 in /root/dao/prog/da_base.py
2025-09-29 15:47:31 fout: sequence item 0: expected str instance, NoneType found
Traceback (most recent call last):
  File "/root/dao/prog/da_prices.py", line 150, in get_prices
    act_spot_prices = prices_spot.fetch(
                      ^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 242, in fetch
    return self._fetch_json(data_type, end_date, areas, resolution)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 201, in _fetch_json
    api_url, params, areas = self._get_url_params_areas(
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 187, in _get_url_params_areas
    params["indexNames"] = ",".join(
                           ^^^^^^^^^
TypeError: sequence item 0: expected str instance, NoneType found[message=83550198]Bravo in "Day Ahead Optimizer: ervaringen met Home..."[/message]

2025-09-29 15:47:31 fout: Geen data van Nordpool: tussen 2025-09-29 00:00:00 en 2025-09-29 00:00:00

Zie Bravo in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Had je alleen maar het vanaf veld ingevuld?

[Bravo]

KC27 schreef op maandag 29 september 2025 @ 15:48:
[...]

Kun jij je settings hier delen (als quote 😉)?

Maar natuurlijk

code:

{
  "homeassistant": {
    "protocol api": "http",
    "host": "192.168.1.202",
    "ip port": 8123,
    "token": "!secret ha_api_token"
 },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "meteoserver-model": "harmonie",
  "meteoserver-attempts": 2,
  "interval": "15min",
  "prices": {
    "source day ahead": "nordpool",
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.0916
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2025-02-01": 0.10154,
      "2026-01-01": 0.0916,
      "2027-01-01": 0.0000
    },
    "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,
      "2027-01-01": 0
    },
    "last invoice": "2025-01-14",
    "tax refund": "False"
  },
  "logging level" : "Info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.10,
    0.11,
    0.11,
    0.12,
    0.11,
    0.1,
    0.11,
    0.35,
    0.13,
    0.2,
    0.14,
    0.17,
    0.27,
    0.22,
    0.29,
    0.34,
    0.23,
    0.2,
    0.27,
    0.2,
    0.23,
    0.11,
    0.11,
    0.11
  ],
  "graphical backend": "",
  "graphics": {
    "style": "bmh",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "True",
    "average consumption": "True",
    "prices spot": "True",
    "battery balance": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 6
  },
  "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": 7.3,
    "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": [
          {
      "name": "Victron 16kWh",
      "entity actual level": "sensor.soc_16kwh_dao",
      "capacity": 16,
      "upper limit": 98,
      "lower limit": 5,
      "optimal lower level": 11,
      "entity min soc end opt": "input_number.min_soc_einde_opt",
      "entity max soc end opt": "input_number.max_soc_einde_opt",

      "charge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 500,
          "efficiency": 0.785
        },
        {
          "power": 1000,
          "efficiency": 0.872
        },
        {
          "power": 1500,
          "efficiency": 0.897
        },
        {
          "power": 2000,
          "efficiency": 0.899
        },
        {
          "power": 2500,
          "efficiency": 0.898
        },
        {
          "power": 3000,
          "efficiency": 0.892
        },
        {
          "power": 3500,
          "efficiency": 0.882
        },
        {
          "power": 4000,
          "efficiency": 0.865
        }
      ],
      "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 200,
          "efficiency": 0.891
        },
        {
          "power": 500,
          "efficiency": 0.935
        },
        {
          "power": 1000,
          "efficiency": 0.952
        },
        {
          "power": 1250,
          "efficiency": 0.962
        },
        {
          "power": 1500,
          "efficiency": 0.952
        },
        {
          "power": 2000,
          "efficiency": 0.950
        },
        {
          "power": 2500,
          "efficiency": 0.934
        },
        {
          "power": 3000,
          "efficiency": 0.925
        },
        {
          "power": 3755,
          "efficiency": 0.908
        },
        {
          "power": 4126,
          "efficiency": 0.896
        },
        {
          "power": 4750,
          "efficiency": 0.886
        },
        {
          "power": 5120,
          "efficiency": 0.863
        }
      ],
      "reduced hours":
       {  },
      "minimum power": 50,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4800.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 4800.0,

      "cycle cost": 0.01,
      "entity set power feedin": "input_number.feedin_grid_dao",
      "entity stop inverter": "input_datetime.inverter_stop",
      "entity balance switch": "input_boolean.balanceer_grid_2",
      "solar": [ ]
    }
    ],
  "solar": [
        { 
      "name" : "SE2200",
      "tilt": 40,
      "orientation": 62,
      "capacity": 2.7,
      "max power": 2.3,
      "yield": 0.00714
    },
    {
      "name": "HM1500",
      "tilt": 5,
      "orientation": 62,
      "capacity": 1.7,
      "max power": 1.5,
      "yield": 0.00271
    }

],
  "electric vehicle": [
    {
      "name": "Ioniq 6",
      "capacity": 74,
      "entity position": "device_tracker.ioniq6_location",
      "entity max amperage": "number.evcc_lp_1_max_current",
      "charge three phase": "False",
      "charge stages" : [
        {"ampere":  0, "efficiency" : 0.1},
        {"ampere":  6, "efficiency" : 0.91},
        {"ampere": 10, "efficiency" : 0.92},
        {"ampere": 12, "efficiency" : 0.79}
      ],
      "entity actual level": "sensor.ioniq6_ev_battery_level",
      "entity plugged in": "binary_sensor.ioniq6_ev_battery_plug",
      "charge scheduler": {
        "entity set level": "input_number.target_soc_ioniq6",
        "level margin": 1,
        "entity ready datetime": "input_datetime.ev_charging_finish_time"
      },
      "charge switch": "input_boolean.ev_charging",
      "entity set charging ampere" : "input_number.set_car_charging_ampere",
      "entity stop charging": "input_datetime.ev_charging_stop"
    }
  ],
  "machines" : [
      { "name": "vaatwasser",
      "programs": [
        {"name": "off",
         "power": []},
        {"name": "auto2",
         "power": [1300, 220, 45, 200, 2460, 0, 0, 0, 0]
         },
        {"name": "quick 65",
         "power": [560, 1000, 1200, 1520, 0]
         }
       ],
        "entity start window": "input_datetime.start_window_vaatwasser",
        "entity end window": "input_datetime.end_window_vaatwasser",
        "entity selected program": "input_select.program_vaatwasser",
        "entity calculated start": "input_datetime.calculated_start_vaatwasser",
        "entity calculated end": "input_datetime.calculated_stop_vaatwasser"
     },
   { "name": "washing_machine",
      "programs": [
        {"name": "off",
         "power": []},
        {"name": "40 graden",
         "power": [867, 2000, 120, 100, 100, 100, 110, 130, 120]
         },
        {"name": "2x 40 graden",
         "power": [867, 2000, 120, 100, 100, 100, 110, 130, 120, 0, 867, 2000, 120, 100, 100, 100, 110, 130, 120]
         },
        {"name": "90 graden",
         "power": [1000, 2000, 38, 36, 40, 77, 80, 156, 100]
         }
       ],
        "entity start window": "input_datetime.start_window_washing_machine",
        "entity end window": "input_datetime.end_window_washing_machine",
        "entity selected program": "input_select.program_washing_machine",
        "entity calculated start": "input_datetime.calculated_start_washing_machine",
        "entity calculated end": "input_datetime.calculated_stop_washing_machine"
     }   
 ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.battery_sim_zp_20kwh_10_10_1_1_simulated_sensor_p1_meter_total_energy_import"
    ],
    "entities grid production": [
      "sensor.battery_sim_zp_20kwh_10_10_1_1_simulated_sensor_p1_meter_total_energy_export"
    ],
    "entities solar production dc": [],
    "entities solar production ac":  [
      "sensor.schuur_yieldtotal",
      "sensor.solaredge2200_ac_energy_kwh"
    ],
    "entities ev consumption" : ["sensor.energysocket_energy_import"],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.battery_sim_zp_20kwh_10_10_1_1_battery_energy_in"],
    "entities battery production": ["sensor.battery_sim_zp_20kwh_10_10_1_1_battery_energy_out"],
    "entity co2-intensity": ["sensor.electricity_maps_co2_intensity"]
  },
  "scheduler": {
    "active": "True",
    "0554": "get_meteo_data",
    "1154": "get_meteo_data",
    "1229": "get_meteo_data",
    "1754": "get_meteo_data",
    "2354": "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"
  }
}

aanvulling: EV is gevuld, dus die wordt ook buiten beschouwing gelaten.

[KC27]

Bravo schreef op maandag 29 september 2025 @ 15:56:
[...]

Maar natuurlijk

[...]

Dank je.
Zo op het eerste gezicht zie ik er niks geks aan.
Ik zal er binnenkort een proef mee draaien.

[KC27]

Nog een belangrijke aanwijzing om die 15min versie goed te laten draaien:
Zet deze extra regels in de scheduler:

code:

    "xx15": "calc_optimum",
    "xx30": "calc_optimum",
    "xx45": "calc_optimum",

[thewhi]

KC27 schreef op maandag 29 september 2025 @ 15:51:
[...]

Zie Bravo in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Had je alleen maar het vanaf veld ingevuld?

Jazeker, juist daarmee blijft DAO die melding geven. Als ik geen tijdsbeperking opgeef dan meldt ie netjes dat ik al data heb opgehaald (vermoedelijk nog gevuld met de vorige release om 13:00).

[KC27]

thewhi schreef op maandag 29 september 2025 @ 16:31:
[...]


Jazeker, juist daarmee blijft DAO die melding geven. Als ik geen tijdsbeperking opgeef dan meldt ie netjes dat ik al data heb opgehaald (vermoedelijk nog gevuld met de vorige release om 13:00).

En als je 2025-09-29 invult in het eerste (vanaf) veld en 2025-09-30 in het tweede (tot) veld?

[Bravo]

KC27 schreef op maandag 29 september 2025 @ 16:36:
[...]

En als je 2025-09-29 invult in het eerste (vanaf) veld en 2025-09-30 in het tweede (tot) veld?

Dat werkte bij mij dus niet.
Ik heb voor zowel voor 28, 29 als 30 september de data los opgehaald door deze data als prijzen_start mee te geven. Prijzen_tot was leeg.

[thewhi]

KC27 schreef op maandag 29 september 2025 @ 16:36:
[...]

En als je 2025-09-29 invult in het eerste (vanaf) veld en 2025-09-30 in het tweede (tot) veld?

Bij geen tijdsbeperking:

code:

 Logging van bewerking "Day ahead prijzen ophalen":

2025-09-29 16:58:07 debug: python pad:['/root/dao/prog', '/root', '/root/dao', '/root/dao/prog', '/usr/lib/python312.zip', '/usr/lib/python3.12', '/usr/lib/python3.12/lib-dynload', '/root/dao/venv/day_ahead/lib/python3.12/site-packages']
2025-09-29 16:58:07 info: Day Ahead Optimalisering versie: 2025.10.0
2025-09-29 16:58:07 info: Day Ahead Optimalisering gestart op: 29-09-2025 16:58:07
2025-09-29 16:58:07 debug: Locatie: latitude 52.4986101395639 longitude: 6.102287024259568
2025-09-29 16:58:07 info: Day Ahead Optimalisatie gestart: 29-09-2025 16:58:07 taak: get_day_ahead_prices
2025-09-29 16:58:07 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 590 in /root/dao/prog/da_base.py
2025-09-29 16:58:07 info: Day ahead data already present
2025-09-29 16:58:07 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 593 in /root/dao/prog/da_base.py
2025-09-29 16:58:07 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 3889 in /root/dao/webserver/../prog/day_ahead.py
debug:root:Dialect: sqlite, database: day_ahead.db, db_path: ../data
debug:root:db_url: sqlite://///root/dao/data/day_ahead.db
debug:root:Dialect: sqlite, database: home-assistant_v2.db, db_path: /homeassistant
debug:root:db_url: sqlite://///homeassistant/home-assistant_v2.db
debug:root:Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 206 in /root/dao/prog/da_base.py

Bij invullen van 2025-09-29 en 2025-09-30 gaat het dus niet goed...

code:

2025-09-29 17:00:56 debug: python pad:['/root/dao/prog', '/root', '/root/dao', '/root/dao/prog', '/usr/lib/python312.zip', '/usr/lib/python3.12', '/usr/lib/python3.12/lib-dynload', '/root/dao/venv/day_ahead/lib/python3.12/site-packages']
2025-09-29 17:00:56 info: Day Ahead Optimalisering versie: 2025.10.0
2025-09-29 17:00:56 info: Day Ahead Optimalisering gestart op: 29-09-2025 17:00:56
2025-09-29 17:00:56 debug: Locatie: latitude 52.4986101395639 longitude: 6.102287024259568
2025-09-29 17:00:56 info: Day Ahead Optimalisatie gestart: 29-09-2025 17:00:56 taak: get_day_ahead_prices
2025-09-29 17:00:56 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 590 in /root/dao/prog/da_base.py
2025-09-29 17:00:56 fout: sequence item 0: expected str instance, NoneType found
Traceback (most recent call last):
  File "/root/dao/prog/da_prices.py", line 150, in get_prices
    act_spot_prices = prices_spot.fetch(
                      ^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 242, in fetch
    return self._fetch_json(data_type, end_date, areas, resolution)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 201, in _fetch_json
    api_url, params, areas = self._get_url_params_areas(
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/nordpool/elspot.py", line 187, in _get_url_params_areas
    params["indexNames"] = ",".join(
                           ^^^^^^^^^
TypeError: sequence item 0: expected str instance, NoneType found
2025-09-29 17:00:56 fout: Geen data van Nordpool: tussen 2025-09-29 00:00:00 en 2025-09-30 00:00:00
2025-09-29 17:00:56 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 593 in /root/dao/prog/da_base.py
2025-09-29 17:00:56 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 3889 in /root/dao/webserver/../prog/day_ahead.py
debug:root:Dialect: sqlite, database: day_ahead.db, db_path: ../data
debug:root:db_url: sqlite://///root/dao/data/day_ahead.db
debug:root:Dialect: sqlite, database: home-assistant_v2.db, db_path: /homeassistant
debug:root:db_url: sqlite://///homeassistant/home-assistant_v2.db
debug:root:Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 206 in /root/dao/prog/da_base.py

[KC27]

Misschien heel flauw: wat heb jij bij "interval": ingevuld?
En als je interval weglaat, haalt ie dan uurprijzen op door alleen het vanaf-veld in te vullen?

[thewhi]

KC27 schreef op maandag 29 september 2025 @ 17:06:
Misschien heel flauw: wat heb jij bij "interval": ingevuld?
En als je interval weglaat, haalt ie dan uurprijzen op door alleen het vanaf-veld in te vullen?

ik had nog geen interval ingevuld, maar met interval idem...

code:

{
  "homeassistant": {
    "protocol api": "http",
    "host": "192.168.1.101",
    "ip port": "8123",
    "token": "!secret ha_api_token"
  },

  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "interval": "1hour",
    "entsoe-api-key": "!secret entsoe-api-key",
    "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,
      "2025-01-01": 0.01653
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2025-01-01": 0.03306
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2024-09-01",
    "tax refund": "True"
  },
  "logging level" : "debug",
  "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",
    "prices consumption": "True",
    "prices production": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
     "opstarten": "True",
     "berekening": "True"
  },
  "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": [
    {
      "name": "batterij",
      "entity actual level": "sensor.instantaneous_battery_soc",
      "capacity": 6,
      "upper limit": 100,
      "lower limit": 9,
      "optimal lower level": 10,
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.75},
        {"power": 110.0,
         "efficiency": 0.780},
        {"power": 220.0,
         "efficiency": 0.800},
        {"power": 330.0,
         "efficiency": 0.820},
        {"power": 440.0,
         "efficiency": 0.850},
        {"power": 660.0,
         "efficiency": 0.880},
        {"power": 880.0,
         "efficiency": 0.89},
        {"power": 1100.0,
         "efficiency": 0.890},
        {"power": 1320.0,
         "efficiency": 0.900},
        {"power": 1540.0,
         "efficiency": 0.91},
        {"power": 1760.0,
         "efficiency": 0.92},
        {"power": 1980.0,
         "efficiency": 0.92},
        {"power": 2000.0,
         "efficiency": 0.92}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.750},
        {"power": 220.0,
         "efficiency": 0.760},
        {"power": 330.0,
         "efficiency": 0.780},
        {"power": 440.0,
         "efficiency": 0.790},
        {"power": 660.0,
         "efficiency": 0.800},
        {"power": 880.0,
         "efficiency": 0.820},
        {"power": 1100.0,
         "efficiency": 0.850},
        {"power": 1320.0,
         "efficiency": 0.90},
        {"power": 1540.0,
         "efficiency": 0.90},
        {"power": 1760.0,
         "efficiency": 0.90},
        {"power": 1980.0,
         "efficiency": 0.90},
        {"power": 2000.0,
         "efficiency": 0.90}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 200,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 2000.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 2000.0,
      "cycle cost": 0.02,
      "entity set power feedin": "input_number.dao_feedin_grid",
      "entity from ac": "input_number.dao_ac",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "entity balance switch": "input_boolean.balanceer_gridUITGESCHAKELD",
      "solar": []
    }
 ],
  "solar": [
   {
      "name": "pv woning Oost",
      "tilt": 60,
      "orientation": -90,
      "capacity": 3.24,
      "yield": 0.007,
      "entity pv switch": ""
    },
    {
      "name": "pv woning2 West",
      "tilt": 60,
      "orientation": 90,
      "capacity": 2.430,
      "yield": 0.007,
      "entity pv switch": ""
    }
],

  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.smartmeter_energieverbruik_laag_tarief",
      "sensor.smartmeter_energieverbruik_hoog_tarief"
    ],
    "entities grid production": [
      "sensor.smartmeter_energieproductie_laag_tarief",
      "sensor.smartmeter_energieproductie_hoog_tarief"
    ],
    "entities solar production ac": [
      "sensor.zonneplan_one_refurbished_yield_total"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.charge"],
    "entities battery production": ["sensor.discharge"]
  },
  "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",
    "1551": "get_day_ahead_prices",
    "2255": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

[KC27]

thewhi schreef op maandag 29 september 2025 @ 17:11:
[...]


ik had nog geen interval ingevuld, maar met interval idem...

code:

{
  "homeassistant": {
    "protocol api": "http",
    "host": "192.168.1.101",
    "ip port": "8123",
    "token": "!secret ha_api_token"
  },

  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "interval": "1hour",
    "entsoe-api-key": "!secret entsoe-api-key",
    "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,
      "2025-01-01": 0.01653
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2025-01-01": 0.03306
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2024-09-01",
    "tax refund": "True"
  },
  "logging level" : "debug",
  "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",
    "prices consumption": "True",
    "prices production": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
     "opstarten": "True",
     "berekening": "True"
  },
  "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": [
    {
      "name": "batterij",
      "entity actual level": "sensor.instantaneous_battery_soc",
      "capacity": 6,
      "upper limit": 100,
      "lower limit": 9,
      "optimal lower level": 10,
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.75},
        {"power": 110.0,
         "efficiency": 0.780},
        {"power": 220.0,
         "efficiency": 0.800},
        {"power": 330.0,
         "efficiency": 0.820},
        {"power": 440.0,
         "efficiency": 0.850},
        {"power": 660.0,
         "efficiency": 0.880},
        {"power": 880.0,
         "efficiency": 0.89},
        {"power": 1100.0,
         "efficiency": 0.890},
        {"power": 1320.0,
         "efficiency": 0.900},
        {"power": 1540.0,
         "efficiency": 0.91},
        {"power": 1760.0,
         "efficiency": 0.92},
        {"power": 1980.0,
         "efficiency": 0.92},
        {"power": 2000.0,
         "efficiency": 0.92}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.750},
        {"power": 220.0,
         "efficiency": 0.760},
        {"power": 330.0,
         "efficiency": 0.780},
        {"power": 440.0,
         "efficiency": 0.790},
        {"power": 660.0,
         "efficiency": 0.800},
        {"power": 880.0,
         "efficiency": 0.820},
        {"power": 1100.0,
         "efficiency": 0.850},
        {"power": 1320.0,
         "efficiency": 0.90},
        {"power": 1540.0,
         "efficiency": 0.90},
        {"power": 1760.0,
         "efficiency": 0.90},
        {"power": 1980.0,
         "efficiency": 0.90},
        {"power": 2000.0,
         "efficiency": 0.90}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 200,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 2000.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 2000.0,
      "cycle cost": 0.02,
      "entity set power feedin": "input_number.dao_feedin_grid",
      "entity from ac": "input_number.dao_ac",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "entity balance switch": "input_boolean.balanceer_gridUITGESCHAKELD",
      "solar": []
    }
 ],
  "solar": [
   {
      "name": "pv woning Oost",
      "tilt": 60,
      "orientation": -90,
      "capacity": 3.24,
      "yield": 0.007,
      "entity pv switch": ""
    },
    {
      "name": "pv woning2 West",
      "tilt": 60,
      "orientation": 90,
      "capacity": 2.430,
      "yield": 0.007,
      "entity pv switch": ""
    }
],

  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.smartmeter_energieverbruik_laag_tarief",
      "sensor.smartmeter_energieverbruik_hoog_tarief"
    ],
    "entities grid production": [
      "sensor.smartmeter_energieproductie_laag_tarief",
      "sensor.smartmeter_energieproductie_hoog_tarief"
    ],
    "entities solar production ac": [
      "sensor.zonneplan_one_refurbished_yield_total"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.charge"],
    "entities battery production": ["sensor.discharge"]
  },
  "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",
    "1551": "get_day_ahead_prices",
    "2255": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

"interval" moet in de root staan, dus op hetzelfde niveau als "battery".