Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Skevdude]

Goedenavond.

Zojuist update gedaan naar 2025.10. Na wat gerommel met de kwartierwaardes van de prognoses (entsoe werkte voor mij niet) heb ik de volgende bijzonderheid.

Bij de optimaliseringsberekening krijg ik een foutmelding op de boiler:

code:

Boiler wordt niet ingepland, omdat de verwachte eindtemperatuur 54.8000030517578 °C hoger is dan de opwarmgrens 65 °C.

Op dit moment is de actuele boiler temp 66.3 graden. De berekening crasht hier ook met de melding:
Geen oplossing voor minimize consumption. Bij minimize cost strategie dezelfde foutmelding.
Als ik dan de hysterese groter maak, krijg ik wel een berekening. Maar de uitkomst lijkt mij erg vreemd. De eind temperatuur is lager dan de actuele temperatuur. Zie:

code:

                 tijd  act_temp  heat  elec  interval  cost  end_temp  end_value  netto_cost
0   2025-09-29 19:15:00    66.300 0.531 0.631         3 0.358    58.800      0.514      -0.156
1   2025-09-29 19:30:00    66.200 0.546 0.646         3 0.338    58.900      0.519      -0.180
2   2025-09-29 19:45:00    66.100 0.560 0.660         3 0.286    59.000      0.523      -0.237
3   2025-09-29 20:00:00    66.000 0.574 0.674         3 0.234    59.100      0.527      -0.294
4   2025-09-29 20:15:00    65.900 0.589 0.689         3 0.239    59.200      0.532      -0.293
5   2025-09-29 20:30:00    65.800 0.603 0.703         3 0.232    59.300      0.536      -0.304
6   2025-09-29 20:45:00    65.700 0.618 0.718         3 0.222    59.400      0.540      -0.318
7   2025-09-29 21:00:00    65.600 0.632 0.732         3 0.212    59.500      0.545      -0.333
8   2025-09-29 21:15:00    65.500 0.646 0.746         3 0.216    59.600      0.549      -0.333
9   2025-09-29 21:30:00    65.400 0.661 0.761         4 0.216    59.800      0.558      -0.342
10  2025-09-29 21:45:00    65.300 0.675 0.775         4 0.216    59.900      0.562      -0.346
11  2025-09-29 22:00:00    65.200 0.689 0.789         4 0.216    60.000      0.567      -0.351
12  2025-09-29 22:15:00    65.100 0.704 0.804         4 0.219    60.100      0.571      -0.352
13  2025-09-29 22:30:00    65.000 0.718 0.818         4 0.219    60.200      0.575      -0.356
14  2025-09-29 22:45:00    64.900 0.732 0.832         4 0.220    60.300      0.580      -0.360
15  2025-09-29 23:00:00    64.800 0.747 0.847         4 0.220    60.400      0.584      -0.364

Hieronder nog mijn config voor de boiler:

code:

  "boiler": {
    "boiler present": "true",
    "entity actual temp.": "sensor.boiler_vat",
    "entity setpoint": "input_number.boiler_setpoint",
    "entity hysterese": "input_number.boiler_hysterese", 
    "entity boiler enabled": "input_boolean.boiler_opwarmen_meenemen_dao",
    "cop": 1,
    "cooling rate": 0.4,
    "volume": 100,
    "heating allowed below": 65,
    "boiler heated by heatpump": "false",
    "elec. power": 1000,
    "entity instant start": "input_boolean.boiler_geforceerd_opwarmen_dao",
    "activate service": "turn_on",
    "activate entity": "input_boolean.boiler_besturing_dao"
    }

edit 29-09 19:50:
Nu krijg ik altijd de error: Kan geen oplossing vinden voor minimize consumption. Minimize cost werkt wel met bovenstaande rariteiten.

[ Voor 4% gewijzigd door Skevdude op 29-09-2025 19:51 ]

[thewhi]

KC27 schreef op maandag 29 september 2025 @ 17:25:
[...]

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

hmmm ...

maar ook in de root hetzelfde issue (probleem had ik overigens ook zonder interval op te nemen in de config).

code:

....
  },
  "logging level" : "debug",
  "interval":"1hour",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload":
.....
 [

[Mirabis]

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.

Vanmiddag van 2025.9.1.rc7 naar 2025.10.0 overgestapt, maar kort daarna ondervond ik al wat probleempjes. Gezien de hoge tarieven tussen 18:00 en 19:59 heb ik maar 9.1.rc7 teruggezet.

Om 18:45 en 19:00 kreeg ik namelijk "waarschuwing: Geen oplossing voor: minimize costs" .

18:45 https://pastebin.com/YUYmsgN9
19:00 https://pastebin.com/FR3u4Y8g
19:01 (handmatig): https://pastebin.com/rpTEb76h
19:15 (weer terug op 2025.9.1.rc7: https://pastebin.com/

De EV was ook aan het laden met Grid Rewards wat de planning misschien ietwat in de war schopte.

[KC27]

Mirabis schreef op maandag 29 september 2025 @ 20:27:
[...]

Vanmiddag van 2025.9.1.rc7 naar 2025.10.0 overgestapt, maar kort daarna ondervond ik al wat probleempjes. Gezien de hoge tarieven tussen 18:00 en 19:59 heb ik maar 9.1.rc7 teruggezet.

Om 18:45 en 19:00 kreeg ik namelijk "waarschuwing: Geen oplossing voor: minimize costs" .

18:45 https://pastebin.com/YUYmsgN9
19:00 https://pastebin.com/FR3u4Y8g
19:01 (handmatig): https://pastebin.com/rpTEb76h
19:15 (weer terug op 2025.9.1.rc7: https://pastebin.com/

De EV was ook aan het laden met Grid Rewards wat de planning misschien ietwat in de war schopte.

Het lijkt er toch op dat in sommige ingewikkelde situaties die 20 sec grens te laag is. Ik zal morgen een nieuwe versie maken waar die grens uit is.

[KC27]

Skevdude schreef op maandag 29 september 2025 @ 19:29:
Goedenavond.

Zojuist update gedaan naar 2025.10. Na wat gerommel met de kwartierwaardes van de prognoses (entsoe werkte voor mij niet) heb ik de volgende bijzonderheid.

Bij de optimaliseringsberekening krijg ik een foutmelding op de boiler:

code:

Boiler wordt niet ingepland, omdat de verwachte eindtemperatuur 54.8000030517578 °C hoger is dan de opwarmgrens 65 °C.

Op dit moment is de actuele boiler temp 66.3 graden. De berekening crasht hier ook met de melding:
Geen oplossing voor minimize consumption. Bij minimize cost strategie dezelfde foutmelding.
Als ik dan de hysterese groter maak, krijg ik wel een berekening. Maar de uitkomst lijkt mij erg vreemd. De eind temperatuur is lager dan de actuele temperatuur. Zie:

code:

                 tijd  act_temp  heat  elec  interval  cost  end_temp  end_value  netto_cost
0   2025-09-29 19:15:00    66.300 0.531 0.631         3 0.358    58.800      0.514      -0.156
1   2025-09-29 19:30:00    66.200 0.546 0.646         3 0.338    58.900      0.519      -0.180
2   2025-09-29 19:45:00    66.100 0.560 0.660         3 0.286    59.000      0.523      -0.237
3   2025-09-29 20:00:00    66.000 0.574 0.674         3 0.234    59.100      0.527      -0.294
4   2025-09-29 20:15:00    65.900 0.589 0.689         3 0.239    59.200      0.532      -0.293
5   2025-09-29 20:30:00    65.800 0.603 0.703         3 0.232    59.300      0.536      -0.304
6   2025-09-29 20:45:00    65.700 0.618 0.718         3 0.222    59.400      0.540      -0.318
7   2025-09-29 21:00:00    65.600 0.632 0.732         3 0.212    59.500      0.545      -0.333
8   2025-09-29 21:15:00    65.500 0.646 0.746         3 0.216    59.600      0.549      -0.333
9   2025-09-29 21:30:00    65.400 0.661 0.761         4 0.216    59.800      0.558      -0.342
10  2025-09-29 21:45:00    65.300 0.675 0.775         4 0.216    59.900      0.562      -0.346
11  2025-09-29 22:00:00    65.200 0.689 0.789         4 0.216    60.000      0.567      -0.351
12  2025-09-29 22:15:00    65.100 0.704 0.804         4 0.219    60.100      0.571      -0.352
13  2025-09-29 22:30:00    65.000 0.718 0.818         4 0.219    60.200      0.575      -0.356
14  2025-09-29 22:45:00    64.900 0.732 0.832         4 0.220    60.300      0.580      -0.360
15  2025-09-29 23:00:00    64.800 0.747 0.847         4 0.220    60.400      0.584      -0.364

Hieronder nog mijn config voor de boiler:

code:

  "boiler": {
    "boiler present": "true",
    "entity actual temp.": "sensor.boiler_vat",
    "entity setpoint": "input_number.boiler_setpoint",
    "entity hysterese": "input_number.boiler_hysterese", 
    "entity boiler enabled": "input_boolean.boiler_opwarmen_meenemen_dao",
    "cop": 1,
    "cooling rate": 0.4,
    "volume": 100,
    "heating allowed below": 65,
    "boiler heated by heatpump": "false",
    "elec. power": 1000,
    "entity instant start": "input_boolean.boiler_geforceerd_opwarmen_dao",
    "activate service": "turn_on",
    "activate entity": "input_boolean.boiler_besturing_dao"
    }

edit 29-09 19:50:
Nu krijg ik altijd de error: Kan geen oplossing vinden voor minimize consumption. Minimize cost werkt wel met bovenstaande rariteiten.

Wat zijn de overige waarden van je boiler in HA als er geen oplossing wordt gevonden:
"input_number.boiler_setpoint"?
"input_number.boiler_hysteres"?
"sensor.boiler_vat" heb je gezegd: 66,3 °C
As je hier de eerste twee deelt kan ik het narekenen.

[Mirabis]

KC27 schreef op maandag 29 september 2025 @ 21:20:
[...]

Het lijkt er toch op dat in sommige ingewikkelde situaties die 20 sec grens te laag is. Ik zal morgen een nieuwe versie maken waar die grens uit is.

Om jezelf wat werk te besparen: misschien handig daar een setting voor te maken (met een fallback/default)? Mensen hebben toch verschillende setups qua compute power. Het gebruikt bij mij niet alle beschikbare rekenkracht dus er zal elders wel een limitatie zijn (1 thread/core/anders).

[KC27]

Mirabis schreef op maandag 29 september 2025 @ 21:39:
[...]


Om jezelf wat werk te besparen: misschien handig daar een setting voor te maken (met een fallback/default)? Mensen hebben toch verschillende setups qua compute power. Het gebruikt bij mij niet alle beschikbare rekenkracht dus er zal elders wel een limitatie zijn (1 thread/core/anders).

Voorlopig haal ik hem eruit. Dan kan ik later daar een instelling van maken.
Die andere limiet (nauwkeurigheid) staat nu op 0,001 euro. Die kan ik voor nu ophogen naar 0,005 euro (=halve cent) en later instelbaar maken. Scheelt ook weer rekentijd.

Een medegebruiker (@simnet ) is bezig om de mogelijkheid te scheppen voor de "heavy" users dat ze zelf een binary kunnen compileren die parallelle verwerking (meer cores) ondersteunt. Maar dat kan nog wel even duren.

[Skevdude]

KC27 schreef op maandag 29 september 2025 @ 21:33:
[...]

Wat zijn de overige waarden van je boiler in HA als er geen oplossing wordt gevonden:
"input_number.boiler_setpoint"?
"input_number.boiler_hysteres"?
"sensor.boiler_vat" heb je gezegd: 66,3 °C
As je hier de eerste twee deelt kan ik het narekenen.

Boiler setpoint staat vast op 70
hysterese op 3

[KC27]

thewhi schreef op maandag 29 september 2025 @ 19:44:
[...]

hmmm ...

maar ook in de root hetzelfde issue (probleem had ik overigens ook zonder interval op te nemen in de config).

code:

....
  },
  "logging level" : "debug",
  "interval":"1hour",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload":
.....
 [

Ik ben nog even voor je in de code gedoken.
DAO stuurt de landcode mee naar nordpool om de goede prijzen op te halen.
Die haalt DAO uit HA.
Wat staat er bij jou bij land: als je via Instellingen\Systeem\Algemeen kijkt bij "Land"?

[thewhi]

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

Ik ben nog even voor je in de code gedoken.
DAO stuurt de landcode mee naar nordpool om de goede prijzen op te halen.
Die haalt DAO uit HA.
Wat staat er bij jou bij land: als je via Instellingen\Systeem\Algemeen kijkt bij "Land"?

Fantastisch! Dat was de truc! Ik had daar (nog) niets ingevuld.
Dit is nu blijkbaar een voorwaarde vanaf de nieuwe release? Voorheen had ik geen last van deze omissie.

Thanks in ieder geval!!

[balk]

Nou, hier lijkt het goed te lopen! Ik heb een relatief simpele setup, panelen en een accu. Dankjewel voor al jouw harde werk @KC27 !

[KC27]

Skevdude schreef op maandag 29 september 2025 @ 21:58:
[...]


Boiler setpoint staat vast op 70
hysterese op 3

Dus als ik het goed begrijp "pingelt" (vergeef me het woord) de boiler tussen 67 en 70.
Maar de instelling "heating allowed below": 65, klopt dan niet, die moet dan ergens tussen die 67 en de 70 zitten. Het beste kan deze op ongeveer 1/2 - 1/3 zitten van het totale hysterese traject. Dus in jouw geval ergens tussen 68.0 of 68.5.
Zoals je het nu gedefinieerd hebt gaat het dus niet werken.

[Skevdude]

KC27 schreef op maandag 29 september 2025 @ 22:19:
[...]

Dus als ik het goed begrijp "pingelt" (vergeef me het woord) de boiler tussen 67 en 70.
Maar de instelling "heating allowed below": 65, klopt dan niet, die moet dan ergens tussen die 67 en de 70 zitten. Het beste kan deze op ongeveer 1/2 - 1/3 zitten van het totale hysterese traject. Dus in jouw geval ergens tussen 68.0 of 68.5.
Zoals je het nu gedefinieerd hebt gaat het dus niet werken.

Ok duidelijk, maar de vreemde getallen in de run blijven wel, kun je uitleggen waar die vandaan komen?
Ik zet de hysterese nu op 10 graden.
En minimize consumption met interval 15 minuten werkt helemaal niet. No solution melding ongeacht wat ik probeer. Of komt dat door de maximum tijd van 20 seconden?

Daarnaast nog een algemene vraag: Waarom is het niet mogelijk om de boiler entiteit als boolean te laten schakelen? Nu is het een button press of een turn on. Ik vind toggle gevaarlijk omdat het dan uit sync kan gaan bij een reboot of iets dergelijks. Ik hoop dat het duidelijk is wat ik bedoel. Zeg maar zoals balanceren true of false is zou de boiler ook aan of uit door kunnen geven. i.p.v. alleen aan commando.

[KC27]

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


Fantastisch! Dat was de truc! Ik had daar (nog) niets ingevuld.
Dit is nu blijkbaar een voorwaarde vanaf de nieuwe release? Voorheen had ik geen last van deze omissie.

Thanks in ieder geval!!

Ja ik heb met dit deel voorgesorteerd op een ontwikkeling om DAO ook bruikbaar te maken voor andere landen m.n. België.
Wil het verder goed werken dan moet je in HA ook je tijdzone goed invullen

[KC27]

Skevdude schreef op maandag 29 september 2025 @ 22:27:
[...]


Ok duidelijk, maar de vreemde getallen in de run blijven wel, kun je uitleggen waar die vandaan komen?
Ik zet de hysterese nu op 10 graden.
En minimize consumption met interval 15 minuten werkt helemaal niet. No solution melding ongeacht wat ik probeer. Of komt dat door de maximum tijd van 20 seconden?

Daarnaast nog een algemene vraag: Waarom is het niet mogelijk om de boiler entiteit als boolean te laten schakelen? Nu is het een button press of een turn on. Ik vind toggle gevaarlijk omdat het dan uit sync kan gaan bij een reboot of iets dergelijks. Ik hoop dat het duidelijk is wat ik bedoel. Zeg maar zoals balanceren true of false is zou de boiler ook aan of uit door kunnen geven. i.p.v. alleen aan commando.

Ik ken de rest van je setup niet maar ik denk dat "minimize consumption" met alleen een boiler niet gaat werken met DAO: het ding moet toch opgewarmd worden.
Met een accu en of pv zou het wel moeten kunnen werken.
Hoe lang rekent ie voordat je de warning krijgt (zie logging)?

Ik vind jouw suggestie voor het aansturen van de boiler wel zinvol.
Ik ga het t.z.t. als alternatief beschikbaar maken.

[Skevdude]

KC27 schreef op maandag 29 september 2025 @ 22:35:
[...]

Ik ken de rest van je setup niet maar ik denk dat "minimize consumption" met alleen een boiler niet gaat werken met DAO: het ding moet toch opgewarmd worden.
Met een accu en of pv zou het wel moeten kunnen werken.
Hoe lang rekent ie voordat je de warning krijgt (zie logging)?

Ik vind jouw suggestie voor het aansturen van de boiler wel zinvol.
Ik ga het t.z.t. als alternatief beschikbaar maken.

Fijn dat zou voor mij super zijn. En ik denk voor meerdere mensen.

Sorry hieronder mijn volledige config. Ik heb zon, accu, boiler en warmtepomp (maar staat nog uit in config).
In 2025.9 werkt het wel allemaal goed, ik heb voor nu weer even gedowngrade. (vandaar dat 15min/1hour mist in config file)

Ik kan dus nu niet terugkijken hoelang hij rekent omdat door het terugzetten de logs verloren zijn gegaan. Maar in versie 2025.9 duurt het meestal al 20 seconden voordat die met een eerste berekening komt in de log. Zie:

code:

2025-09-29 20:15:00 info: Day Ahead Optimalisering versie: 2025.9.0
2025-09-29 20:15:00 info: Day Ahead Optimalisering gestart op: 29-09-2025 20:15:00
2025-09-29 20:15:00 info: Day Ahead Optimalisatie gestart: 29-09-2025 20:15:00 taak: calc_optimum
...
2025-09-29 20:15:20 info: Eerste berekening
2025-09-29 20:15:20 info: Kosten (euro): 2.22  
2025-09-29 20:15:20 info: Levering (kWh): 0.19  
2025-09-29 20:15:50 info: Herberekening
2025-09-29 20:15:50 info: Kosten (euro): -7.31 
2025-09-29 20:15:50 info: Levering (kWh): 0.19  
2025-09-29 20:15:50 info: Strategie: minimale levering
2025-09-29 20:15:50 info: Het programma heeft een optimale oplossing gevonden.
2025-09-29 20:15:50 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -5.74 
2025-09-29 20:15:50 info: Geoptimaliseerd, kosten met day ahead tarieven: -7.31

Ik draai als HA addon up een Dell NUC met een 9e generatie i5 proc.


Config:

code:

{
  "homeassistant": { },
  "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": "tibber",
    "entsoe-api-key": "!secret entsoe-api-key",
    "energy taxes consumption": {
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2025-01-01": 0.020496
    },
    "cost supplier production": {
      "2025-01-01": 0.020496
    },
    "vat consumption": {
      "2025-01-01": 21
    },
    "vat production": {
      "2025-01-01": 21
    },
   "tax refund": "True",
   "last invoice": "2025-09-15"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.60,    0.70,    0.60,    0.72,    0.45,    0.52,    0.51,    0.68,    0.85,    0.96,    0.71,    0.82,
    0.81,    0.83,    0.86,    0.91,    0.81,    0.84,    0.86,    0.92,    0.92,    0.69,    0.68,    0.70
  ],
  "graphical backend": "",
  "graphics": {
    "style": "dark_background",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "False",
    "average consumption": "True"
  },
  "strategy": "minimize consumption",
  "notifications": {
     "notification entity": "input_text.notificaties_dao",
     "opstarten": "True",
     "berekening": "True"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.boiler_vat",
    "entity setpoint": "input_number.boiler_setpoint",
    "entity hysterese": "input_number.boiler_hysterese", 
    "entity boiler enabled": "input_boolean.boiler_opwarmen_meenemen_dao",
    "cop": 1,
    "cooling rate": 0.4,
    "volume": 100,
    "heating allowed below": 65,
    "boiler heated by heatpump": "false",
    "elec. power": 1000,
    "entity instant start": "input_boolean.boiler_geforceerd_opwarmen_dao",
    "activate service": "turn_on",
    "activate entity": "input_boolean.boiler_besturing_dao"

  },
  "heating": {
    "heater present": "false",
    "degree days factor": 3.6,
    "entity hp enabled": "input_boolean.warmtepomp_opwarmen_meenemen_dao",
    "adjustment": "heating curve",
    "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.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_dao",
    "adjustment factor": 0.04
  },

  "battery": [
   {
      "name": "Marstek L1",
      "entity actual level": "sensor.lilygors485_marstek_l1_marstek_battery_state_of_charge",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 25,
      "charge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100.0, "efficiency": 0.6364 },
        { "power": 200.0, "efficiency": 0.8221 },
        { "power": 400.0, "efficiency": 0.8673 },
        { "power": 500.0, "efficiency": 0.91   },
        { "power": 600.0, "efficiency": 0.8861 },
        { "power": 800.0, "efficiency": 0.8933 },
        { "power": 1000.0, "efficiency": 0.8975 },
        { "power": 1500.0, "efficiency": 0.9015 },
        { "power": 2000.0, "efficiency": 0.9010 },
        { "power": 2500.0, "efficiency": 0.9017 }
      ],
      "discharge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100.0, "efficiency": 0.7907 },
        { "power": 200.0, "efficiency": 0.8957 },
        { "power": 400.0, "efficiency": 0.9581 },
        { "power": 500.0, "efficiency": 0.9587 },
        { "power": 600.0, "efficiency": 0.9767 },
        { "power": 800.0, "efficiency": 0.9812 },
        { "power": 1000.0, "efficiency": 0.9890 },
        { "power": 1500.0, "efficiency": 0.9907 },
        { "power": 2000.0, "efficiency": 0.9841 },
        { "power": 2500.0, "efficiency": 0.9927 }
      ],
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "cycle cost": 0.005,
      "minimum power": 200,
      "entity set power feedin": "input_number.batterij_l1_feedin_vermogen_dao",
      "entity balance switch": "input_boolean.batterij_l1_op_nom_modus_dao",

      "entity set operating mode": "input_select.batterij_l1_operating_mode_dao",
      "entity stop inverter": "input_datetime.stop_batterij_l1_datum_tijd_dao",
      "entity from battery": "input_number.batterij_l1_vermogen_van_batterij_dao",
      "entity from ac": "input_number.batterij_l1_vermogen_van_net_dao",
      "entity calculated soc": "input_number.batterij_l1_berekende_soc_einde_uur_dao",
      "solar": []
   },
   {
      "name": "Marstek L2",
      "entity actual level": "sensor.lilygors485_marstek_l2_marstek_battery_state_of_charge",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 25,
      "charge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100.0, "efficiency": 0.6364 },
        { "power": 200.0, "efficiency": 0.8221 },
        { "power": 400.0, "efficiency": 0.8673 },
        { "power": 500.0, "efficiency": 0.91   },
        { "power": 600.0, "efficiency": 0.8861 },
        { "power": 800.0, "efficiency": 0.8933 },
        { "power": 1000.0, "efficiency": 0.8975 },
        { "power": 1500.0, "efficiency": 0.9015 },
        { "power": 2000.0, "efficiency": 0.9010 },
        { "power": 2500.0, "efficiency": 0.9017 }
      ],
      "discharge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100.0, "efficiency": 0.7907 },
        { "power": 200.0, "efficiency": 0.8957 },
        { "power": 400.0, "efficiency": 0.9581 },
        { "power": 500.0, "efficiency": 0.9587 },
        { "power": 600.0, "efficiency": 0.9767 },
        { "power": 800.0, "efficiency": 0.9812 },
        { "power": 1000.0, "efficiency": 0.9890 },
        { "power": 1500.0, "efficiency": 0.9907 },
        { "power": 2000.0, "efficiency": 0.9841 },
        { "power": 2500.0, "efficiency": 0.9927 }
      ],
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "cycle cost": 0.005,
      "minimum power": 200,
      "entity set power feedin": "input_number.batterij_l2_feedin_vermogen_dao",
      "entity balance switch": "input_boolean.batterij_l2_op_nom_modus_dao",
      "solar": []
   },
   {
      "name": "Marstek L3",
      "entity actual level": "sensor.lilygors485_marstek_l3_marstek_battery_state_of_charge",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 25,
      "charge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100.0, "efficiency": 0.6364 },
        { "power": 200.0, "efficiency": 0.8221 },
        { "power": 400.0, "efficiency": 0.8673 },
        { "power": 500.0, "efficiency": 0.91   },
        { "power": 600.0, "efficiency": 0.8861 },
        { "power": 800.0, "efficiency": 0.8933 },
        { "power": 1000.0, "efficiency": 0.8975 },
        { "power": 1500.0, "efficiency": 0.9015 },
        { "power": 2000.0, "efficiency": 0.9010 },
        { "power": 2500.0, "efficiency": 0.9017 }
      ],
      "discharge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100.0, "efficiency": 0.7907 },
        { "power": 200.0, "efficiency": 0.8957 },
        { "power": 400.0, "efficiency": 0.9581 },
        { "power": 500.0, "efficiency": 0.9587 },
        { "power": 600.0, "efficiency": 0.9767 },
        { "power": 800.0, "efficiency": 0.9812 },
        { "power": 1000.0, "efficiency": 0.9890 },
        { "power": 1500.0, "efficiency": 0.9907 },
        { "power": 2000.0, "efficiency": 0.9841 },
        { "power": 2500.0, "efficiency": 0.9927 }
      ],
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "cycle cost": 0.005,
      "minimum power": 200,
      "entity set power feedin": "input_number.batterij_l3_feedin_vermogen_dao",
      "entity balance switch": "input_boolean.batterij_l3_op_nom_modus_dao",
      "solar": []
   }
  ],


  "solar": [
    { "name" : "Dak loods",
    "max power": 9.0,
    "strings": [
      {"tilt": 10, "orientation": -104, "capacity": 4.96, "yield": 0.01116875},
      {"tilt": 10, "orientation": 76, "capacity": 4.96, "yield": 0.01116875}
    ],
    "entity pv switch": "input_boolean.zonnepanelen_loods_sturing_dao"
  },
    { "name" : "Dak woning",
    "tilt": 25,
    "max power": 3.3,
    "orientation": 2,
    "capacity": 3.5,
    "yield": 0.0084925,
    "entity pv switch": "input_boolean.zonnepanelen_woning_sturing_dao"
  },
    { "name" : "Dak garage",
    "tilt": 4,
    "max power": 2,
    "orientation": 3,
    "capacity": 2.5,
    "yield": 0.052875,
    "entity pv switch": "input_boolean.zonnepanelen_garage_sturing_dao"
  }
  ],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.dsmr_energy_delivered_tariff1",
      "sensor.dsmr_energy_delivered_tariff2"
    ],
    "entities grid production": [
      "sensor.dsmr_energy_returned_tariff1",
      "sensor.dsmr_energy_returned_tariff2"
    ],
    "entities solar production ac": [
      "sensor.totaal_opwek",
      "sensor.energy_generated_garage",
      "sensor.loods_total_lifetime_energy_output"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : ["sensor.remeha_elga_ace_energy_total"],
    "entities boiler consumption": ["sensor.boiler_woning_energy_total"],
    "entities battery consumption": ["sensor.lilygors485_marstek_l1_marstek_total_charging_energy","sensor.lilygors485_marstek_l2_marstek_total_charging_energy","sensor.lilygors485_marstek_l3_marstek_total_charging_energy"],
    "entities battery production": ["sensor.lilygors485_marstek_l1_marstek_total_discharging_energy","sensor.lilygors485_marstek_l2_marstek_total_discharging_energy", "sensor.lilygors485_marstek_l3_marstek_total_discharging_energy"],
    "entity co2-intensity": ["sensor.co2_signal_co2_intensity"]
  },
  "scheduler": {
    "active": "True",
    "0455": "get_meteo_data",
    "0920": "calc_baseloads",
    "1040": "get_meteo_data",
    "0952": "get_tibber_data",
    "1052": "get_tibber_data",
    "1152": "get_tibber_data",
    "1245": "get_meteo_data",
    "1252": "get_tibber_data",
    "1258": "get_day_ahead_prices",
    "1313": "get_day_ahead_prices",
    "1328": "get_day_ahead_prices",
    "1350": "get_tibber_data",
    "1358": "get_day_ahead_prices",
    "1452": "get_tibber_data",
    "1458": "get_day_ahead_prices",
    "1450": "get_meteo_data",
    "1558": "get_day_ahead_prices",
    "2235": "calc_baseloads",
    "2245": "get_meteo_data",
    "2355": "clean_data",
    "xx00": "calc_optimum",
    "xx15": "calc_optimum",
    "xx30": "calc_optimum",
    "xx45": "calc_optimum"
  }
}

[ Voor 100% gewijzigd door Skevdude op 29-09-2025 23:02 ]

[tonvanboven]

Nog een kleine aanvulling op de inrichting van de scheduler; zorg er voor dat er op een kwartier geen andere taak loopt. In de configuratie van @Skevdude zie je bijvoorbeeld staan dat op 2245 de meteo data opgehaald moet worden. Verander die tijd dus naar iets anders.

[Skevdude]

Goede tip, meteen aangepast!

[KC27]

Skevdude schreef op maandag 29 september 2025 @ 22:47:
[...]


Fijn dat zou voor mij super zijn. En ik denk voor meerdere mensen.

Sorry hieronder mijn volledige config. Ik heb zon, accu, boiler en warmtepomp (maar staat nog uit in config).
In 2025.9 werkt het wel allemaal goed, ik heb voor nu weer even gedowngrade. (vandaar dat 15min/1hour mist in config file)

Ik kan dus nu niet terugkijken hoelang hij rekent omdat door het terugzetten de logs verloren zijn gegaan. Maar in versie 2025.9 duurt het meestal al 20 seconden voordat die met een eerste berekening komt in de log. Zie:

code:

2025-09-29 20:15:00 info: Day Ahead Optimalisering versie: 2025.9.0
2025-09-29 20:15:00 info: Day Ahead Optimalisering gestart op: 29-09-2025 20:15:00
2025-09-29 20:15:00 info: Day Ahead Optimalisatie gestart: 29-09-2025 20:15:00 taak: calc_optimum
...
2025-09-29 20:15:20 info: Eerste berekening
2025-09-29 20:15:20 info: Kosten (euro): 2.22  
2025-09-29 20:15:20 info: Levering (kWh): 0.19  
2025-09-29 20:15:50 info: Herberekening
2025-09-29 20:15:50 info: Kosten (euro): -7.31 
2025-09-29 20:15:50 info: Levering (kWh): 0.19  
2025-09-29 20:15:50 info: Strategie: minimale levering
2025-09-29 20:15:50 info: Het programma heeft een optimale oplossing gevonden.
2025-09-29 20:15:50 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -5.74 
2025-09-29 20:15:50 info: Geoptimaliseerd, kosten met day ahead tarieven: -7.31

Ik draai als HA addon up een Dell NUC met een 9e generatie i5 proc.


Config:

[...]

Met deze config maak je het DAO wel onnodig lastig.
Je hebt drie identieke batterijen. Voor de snelheid kun je deze beter vervangen door een (gesommeerde) virtuele batterij.En de berekende charge/discharge verdeel je dan over de batterijen. Je kunt dan zelfs bij een lage charge/discharge dit door een van de accu's laten verzorgen wat dan met een beter rendement plaatsvindt.
Hiervoor in dit topic zijn ook gebruikers met meer dan een Sessy die hetzelfde doen: zoek en je zult vinden.

[balk]

Idee voor de complexe systemen of Raspberry Pi's met beperkte rekenkracht: introduceer een optie om per half uur te rekenen ipv kwartier. Dan rekenen met het gemiddelde van twee kwartier, en dan kunnen schakelen per half uur. Iets om over na te denken?

[diamanten]

Geupgrade naar 2025.10, mijn config niet aangepast, sindsdien deze fout:

code:

Logging van bewerking "Optimaliseringsberekening zonder debug":
2025-09-30 08:42:53 info: Day Ahead Optimalisering versie: 2025.10.0
2025-09-30 08:42:53 info: Day Ahead Optimalisering gestart op: 30-09-2025 08:42:53
2025-09-30 08:42:53 info: Day Ahead Optimalisatie gestart: 30-09-2025 08:42:53 taak: calc_optimum
2025-09-30 08:42:53 info: Debug = False
2025-09-30 08:42:54 info: Baseload uit instellingen
2025-09-30 08:42:54 info: Start waarden: 
      uur                tijd   p_l   p_t  base  pv_ac  pv_dc
0   08:00 2025-09-30 08:00:00 0.381 0.258 0.230  0.132      0
1   09:00 2025-09-30 09:00:00 0.312 0.189 0.260  2.769      0
2   10:00 2025-09-30 10:00:00 0.278 0.155 0.310  1.765      0
3   11:00 2025-09-30 11:00:00 0.254 0.131 0.320  0.349      0
4   12:00 2025-09-30 12:00:00 0.244 0.121 0.310  1.064      0
5   13:00 2025-09-30 13:00:00 0.241 0.118 0.230  3.422      0
6   14:00 2025-09-30 14:00:00 0.240 0.117 0.260  2.826      0
7   15:00 2025-09-30 15:00:00 0.252 0.129 0.210  1.973      0
8   16:00 2025-09-30 16:00:00 0.259 0.137 0.210  1.420      0
9   17:00 2025-09-30 17:00:00 0.298 0.175 0.540  0.996      0
10  18:00 2025-09-30 18:00:00 0.456 0.333 0.260  0.423      0
11  19:00 2025-09-30 19:00:00 0.525 0.402 0.260  0.000      0
12  20:00 2025-09-30 20:00:00 0.317 0.194 0.220  0.000      0
13  21:00 2025-09-30 21:00:00 0.281 0.158 0.190  0.000      0
14  22:00 2025-09-30 22:00:00 0.266 0.143 0.180  0.000      0
15  23:00 2025-09-30 23:00:00 0.257 0.134 0.160  0.000      0
2025-09-30 08:42:55 info: No reduced hours applied for EvaPower
2025-09-30 08:42:55 info: Startwaarde SoC EvaPower: 0.0%

2025-09-30 08:42:55 info: No reduced hours applied for Delta2Max
2025-09-30 08:42:55 info: Startwaarde SoC Delta2Max: 16.0%

2025-09-30 08:42:55 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-09-30 08:42:55 info: Instellingen voor laden van EV: Kia Niro EV
2025-09-30 08:42:55 info: Direct laden is uit
2025-09-30 08:42:55 info:  Ampere  Effic. Grid kW Accu kW
2025-09-30 08:42:55 info:    0.00    1.00    0.00    0.00
2025-09-30 08:42:55 info:    6.00    0.95    4.14    3.93
2025-09-30 08:42:55 info:    7.00    0.95    4.83    4.59
2025-09-30 08:42:55 info:    8.00    0.95    5.52    5.24
2025-09-30 08:42:55 info:    9.00    0.95    6.21    5.90
2025-09-30 08:42:55 info:   10.00    0.95    6.90    6.55
2025-09-30 08:42:55 info:   11.00    0.95    7.59    7.21
2025-09-30 08:42:55 info:   12.00    0.95    8.28    7.87
2025-09-30 08:42:55 info:   13.00    0.95    8.97    8.52
2025-09-30 08:42:55 info:   14.00    0.95    9.66    9.18
2025-09-30 08:42:55 info:   15.00    0.95   10.35    9.83
2025-09-30 08:42:55 info:   16.00    0.95   11.04   10.49
2025-09-30 08:42:55 info: Capaciteit accu: 55 kWh
2025-09-30 08:42:55 info: Maximaal laadvermogen: 11.04 kW
2025-09-30 08:42:55 info: Klaar met laden op: 05-09-2025 06:00:00
2025-09-30 08:42:55 info: Huidig laadniveau: 34.0 %
2025-09-30 08:42:55 info: Gewenst laadniveau:90.0 %
2025-09-30 08:42:55 info: Marge voor het laden: 2 %
2025-09-30 08:42:55 info: Locatie: home
2025-09-30 08:42:55 info: Ingeplugged:False
2025-09-30 08:42:55 info: Benodigde energie: 0.000 kWh
2025-09-30 08:42:55 info: Tijd nodig om te laden: 0:0 uur
2025-09-30 08:42:55 info: Afgerond naar hele intervallen: 0 uur
2025-09-30 08:42:55 info: Stand laden schakelaar: off
2025-09-30 08:42:55 info: Stand aantal ampere laden: 0.0 A
2025-09-30 08:42:55 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd, opgegeven tijdstip (2025-09-05 06:00:00) is verouderd.
2025-09-30 08:42:55 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-09-30 08:42:55 info: Apparaat Airco direct starten staat uit
2025-09-30 08:42:55 info: Machine Airco wordt niet ingepland, want er is gekozen voor Uit
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
2025-09-30 08:43:07 info: Strategie: minimale kosten
2025-09-30 08:43:07 info: Het programma heeft een optimale oplossing gevonden.
2025-09-30 08:43:07 info: In- en uitgaande energie per uur batterij EvaPower
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 08:00   0.00     --   0.00   0.00   0.00     --   0.00     --  -0.00
 09:00   0.35  90.56   0.32   0.00   0.32  95.00   0.30  86.03  10.00
 10:00   0.00     --   0.00   0.00  -0.00  95.00  -0.00  -0.00  10.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 12:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 13:00   0.50  91.53   0.46   0.00   0.46  95.00   0.43  86.95  24.44
 14:00   1.29  92.84   1.20   0.00   1.20  95.00   1.14  88.20  62.44
 15:00   0.00     --   0.00   0.00  -0.00  95.00  -0.00  -0.00  62.44
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     --  62.44
 17:00   0.00     --   0.00   0.00   0.00 105.26   0.00     --  62.44
 18:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  41.39
 19:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  20.34
 20:00  -0.22  94.00  -0.23   0.00  -0.23  95.00  -0.25  89.30  12.12
 21:00   0.00     --   0.00   0.00   0.00 105.26   0.00     --  12.12
 22:00  -0.06  92.00  -0.06   0.00  -0.06  95.00  -0.06  87.40  10.00
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal   0.76     --   0.48   0.00   0.48     --   0.30     --       
2025-09-30 08:43:07 info: In- en uitgaande energie per uur batterij Delta2Max
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 08:00  -0.10  92.00  -0.11   0.00  -0.11  95.00  -0.12  87.40  10.00
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 12:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 13:00   1.30  92.56   1.20   0.00   1.20  95.00   1.14  87.93  67.00
 14:00   0.76  91.71   0.69   0.00   0.69  95.00   0.66  87.12 100.00
 15:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  68.42
 19:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  36.84
 20:00   0.00     --   0.00   0.00   0.00     --   0.00     --  36.84
 21:00  -0.19  93.00  -0.20   0.00  -0.20  95.00  -0.22  88.35  26.09
 22:00  -0.12  93.00  -0.13   0.00  -0.13  95.00  -0.14  88.35  19.05
 23:00  -0.16  93.00  -0.17   0.00  -0.17  95.00  -0.18  88.35  10.00
Totaal   0.37     --   0.07   0.00   0.07     --  -0.12     --       
2025-09-30 08:43:08 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 08:00    0.00     0.10   0.00   0.17   0.23   0.00   0.00   0.00   0.13   0.00   -0.04  20.00   0.00
 09:00    0.35     0.00   0.00   2.16   0.26   0.00   0.00   0.00   2.77   0.00   -0.41  20.00   0.00
 10:00    0.00     0.00   0.00   1.46   0.31   0.00   0.00   0.00   1.77   0.00   -0.23  20.00   0.00
 11:00    0.00     0.00   0.00   0.03   0.32   0.00   0.00   0.00   0.35   0.00   -0.00  20.00   0.00
 12:00    0.00     0.00   0.00   0.75   0.31   0.00   0.00   0.00   1.06   0.00   -0.09  20.00   0.00
 13:00    1.79     0.00   0.00   1.40   0.23   0.00   0.00   0.00   3.42   0.00   -0.17  20.00   0.00
 14:00    2.05     0.00   0.00   0.52   0.26   0.00   0.00   0.00   2.83   0.00   -0.06  20.00   0.00
 15:00    0.00     0.00   0.00   1.76   0.21   0.00   0.00   0.00   1.97   0.00   -0.23  20.00   0.00
 16:00    0.00     0.00   0.00   1.21   0.21   0.00   0.00   0.00   1.42   0.00   -0.17  20.00   0.00
 17:00    0.00     0.00   0.00   0.46   0.54   0.00   0.00   0.00   1.00   0.00   -0.08  20.00   0.00
 18:00    0.00     1.10   0.00   1.27   0.26   0.00   0.00   0.00   0.42   0.00   -0.42  20.00   0.00
 19:00    0.00     1.10   0.00   0.84   0.26   0.00   0.00   0.00   0.00   0.00   -0.34  20.00   0.00
 20:00    0.00     0.22   0.00   0.00   0.22   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:00    0.00     0.19   0.00   0.00   0.19   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:00    0.00     0.18   0.00   0.00   0.18   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:00    0.00     0.16   0.00   0.00   0.16   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
Totaal    4.19     3.06   0.00  12.02   4.15   0.00   0.00   0.00  17.14   0.00   -2.23          0.00

2025-09-30 08:43:08 info: Consumption               0.00 (kWh)
2025-09-30 08:43:08 info: Cost consumption          0.00 (€)
2025-09-30 08:43:08 info: Tariff consumption          nan (€/kWh)
2025-09-30 08:43:08 info: Production               12.02 (kWh)
2025-09-30 08:43:08 info: Profit production        -2.23 (€)
2025-09-30 08:43:08 info: Tariff production        -0.186 (€/kWh)

2025-09-30 08:43:08 info: /nCalculation profit after optimize in €
Cost before optimize              -1.61
Cost consumption      0.00
Profit production    -2.23
Cycle cost            0.22
Battery storage      -0.03
Boiler storage        0.00
Total                -2.05
Cost after optimize              -2.00
Profit:                           0.38
2025-09-30 08:43:08 info: Doorzetten van alle settings naar HA
2025-09-30 08:43:08 info: Berekeningsuitkomst voor opladen van Kia Niro EV:
2025-09-30 08:43:08 info: - aantal ampere 0A (was 0.0A)
2025-09-30 08:43:08 info: - stand schakelaar 'off' (was 'off')
2025-09-30 08:43:08 info: - positie: home
2025-09-30 08:43:08 info: - ingeplugd: False
2025-09-30 08:43:08 info: Kia Niro EV is niet thuis of niet ingeplugd
2025-09-30 08:43:08 info: Evaluatie status laden Kia Niro EV op 2025-09-30 08:43
2025-09-30 08:43:08 info: - schakelaar laden: off
2025-09-30 08:43:08 info: - aantal ampere: 0.0
2025-09-30 08:43:08 info: Grid set point: -599.0 W
2025-09-30 08:43:08 info: Cycle cost EvaPower: 0.10 euro
2025-09-30 08:43:08 info: Netto vermogen naar(+)/uit(-) omvormer EvaPower: 0 W
2025-09-30 08:43:08 info: Balanceren: False
2025-09-30 08:43:08 info: Vermogen uit batterij: 0W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van pv: 0W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van ac: 0W
2025-09-30 08:43:08 info: Waarde SoC na eerste uur: -0.0%
2025-09-30 08:43:08 info: Grid set point: -599.0 W
2025-09-30 08:43:08 info: Cycle cost Delta2Max: 0.11 euro
2025-09-30 08:43:08 info: Netto vermogen naar(+)/uit(-) omvormer Delta2Max: -367 W
2025-09-30 08:43:08 info: Balanceren: False
2025-09-30 08:43:08 info: Vermogen uit batterij: 399W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van pv: 0W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van ac: -399W
2025-09-30 08:43:08 info: Waarde SoC na eerste uur: 10.0%
2025-09-30 08:43:08 info: Apparaat: Airco
2025-09-30 08:43:08 info: Programma: Uit
/root/dao/webserver/../prog/day_ahead.py:2682: RuntimeWarning: invalid value encountered in scalar divide
  tariff_consumption = cost_consumption / delivery.x

Moet ik nog wat aanpassen: consumption = 0?
Edit: tijdelijk opgelost door dit in te vullen:

code:

Day ahead prijzen ophalen prijzen_start jjjj-mm-dd prijzen_tot  jjjj-mm-dd

maar moet ik dit elke keer invullen? Als ik dat niet nameljk nie doe, dan krijg ik nog steeds bovenstaande meldingen.

[KC27]

diamanten schreef op dinsdag 30 september 2025 @ 08:46:
Geupgrade naar 2025.10, mijn config niet aangepast, sindsdien deze fout:

code:

Logging van bewerking "Optimaliseringsberekening zonder debug":
2025-09-30 08:42:53 info: Day Ahead Optimalisering versie: 2025.10.0
2025-09-30 08:42:53 info: Day Ahead Optimalisering gestart op: 30-09-2025 08:42:53
2025-09-30 08:42:53 info: Day Ahead Optimalisatie gestart: 30-09-2025 08:42:53 taak: calc_optimum
2025-09-30 08:42:53 info: Debug = False
2025-09-30 08:42:54 info: Baseload uit instellingen
2025-09-30 08:42:54 info: Start waarden: 
      uur                tijd   p_l   p_t  base  pv_ac  pv_dc
0   08:00 2025-09-30 08:00:00 0.381 0.258 0.230  0.132      0
1   09:00 2025-09-30 09:00:00 0.312 0.189 0.260  2.769      0
2   10:00 2025-09-30 10:00:00 0.278 0.155 0.310  1.765      0
3   11:00 2025-09-30 11:00:00 0.254 0.131 0.320  0.349      0
4   12:00 2025-09-30 12:00:00 0.244 0.121 0.310  1.064      0
5   13:00 2025-09-30 13:00:00 0.241 0.118 0.230  3.422      0
6   14:00 2025-09-30 14:00:00 0.240 0.117 0.260  2.826      0
7   15:00 2025-09-30 15:00:00 0.252 0.129 0.210  1.973      0
8   16:00 2025-09-30 16:00:00 0.259 0.137 0.210  1.420      0
9   17:00 2025-09-30 17:00:00 0.298 0.175 0.540  0.996      0
10  18:00 2025-09-30 18:00:00 0.456 0.333 0.260  0.423      0
11  19:00 2025-09-30 19:00:00 0.525 0.402 0.260  0.000      0
12  20:00 2025-09-30 20:00:00 0.317 0.194 0.220  0.000      0
13  21:00 2025-09-30 21:00:00 0.281 0.158 0.190  0.000      0
14  22:00 2025-09-30 22:00:00 0.266 0.143 0.180  0.000      0
15  23:00 2025-09-30 23:00:00 0.257 0.134 0.160  0.000      0
2025-09-30 08:42:55 info: No reduced hours applied for EvaPower
2025-09-30 08:42:55 info: Startwaarde SoC EvaPower: 0.0%

2025-09-30 08:42:55 info: No reduced hours applied for Delta2Max
2025-09-30 08:42:55 info: Startwaarde SoC Delta2Max: 16.0%

2025-09-30 08:42:55 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-09-30 08:42:55 info: Instellingen voor laden van EV: Kia Niro EV
2025-09-30 08:42:55 info: Direct laden is uit
2025-09-30 08:42:55 info:  Ampere  Effic. Grid kW Accu kW
2025-09-30 08:42:55 info:    0.00    1.00    0.00    0.00
2025-09-30 08:42:55 info:    6.00    0.95    4.14    3.93
2025-09-30 08:42:55 info:    7.00    0.95    4.83    4.59
2025-09-30 08:42:55 info:    8.00    0.95    5.52    5.24
2025-09-30 08:42:55 info:    9.00    0.95    6.21    5.90
2025-09-30 08:42:55 info:   10.00    0.95    6.90    6.55
2025-09-30 08:42:55 info:   11.00    0.95    7.59    7.21
2025-09-30 08:42:55 info:   12.00    0.95    8.28    7.87
2025-09-30 08:42:55 info:   13.00    0.95    8.97    8.52
2025-09-30 08:42:55 info:   14.00    0.95    9.66    9.18
2025-09-30 08:42:55 info:   15.00    0.95   10.35    9.83
2025-09-30 08:42:55 info:   16.00    0.95   11.04   10.49
2025-09-30 08:42:55 info: Capaciteit accu: 55 kWh
2025-09-30 08:42:55 info: Maximaal laadvermogen: 11.04 kW
2025-09-30 08:42:55 info: Klaar met laden op: 05-09-2025 06:00:00
2025-09-30 08:42:55 info: Huidig laadniveau: 34.0 %
2025-09-30 08:42:55 info: Gewenst laadniveau:90.0 %
2025-09-30 08:42:55 info: Marge voor het laden: 2 %
2025-09-30 08:42:55 info: Locatie: home
2025-09-30 08:42:55 info: Ingeplugged:False
2025-09-30 08:42:55 info: Benodigde energie: 0.000 kWh
2025-09-30 08:42:55 info: Tijd nodig om te laden: 0:0 uur
2025-09-30 08:42:55 info: Afgerond naar hele intervallen: 0 uur
2025-09-30 08:42:55 info: Stand laden schakelaar: off
2025-09-30 08:42:55 info: Stand aantal ampere laden: 0.0 A
2025-09-30 08:42:55 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd, opgegeven tijdstip (2025-09-05 06:00:00) is verouderd.
2025-09-30 08:42:55 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-09-30 08:42:55 info: Apparaat Airco direct starten staat uit
2025-09-30 08:42:55 info: Machine Airco wordt niet ingepland, want er is gekozen voor Uit
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
2025-09-30 08:43:07 info: Strategie: minimale kosten
2025-09-30 08:43:07 info: Het programma heeft een optimale oplossing gevonden.
2025-09-30 08:43:07 info: In- en uitgaande energie per uur batterij EvaPower
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 08:00   0.00     --   0.00   0.00   0.00     --   0.00     --  -0.00
 09:00   0.35  90.56   0.32   0.00   0.32  95.00   0.30  86.03  10.00
 10:00   0.00     --   0.00   0.00  -0.00  95.00  -0.00  -0.00  10.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 12:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 13:00   0.50  91.53   0.46   0.00   0.46  95.00   0.43  86.95  24.44
 14:00   1.29  92.84   1.20   0.00   1.20  95.00   1.14  88.20  62.44
 15:00   0.00     --   0.00   0.00  -0.00  95.00  -0.00  -0.00  62.44
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     --  62.44
 17:00   0.00     --   0.00   0.00   0.00 105.26   0.00     --  62.44
 18:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  41.39
 19:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  20.34
 20:00  -0.22  94.00  -0.23   0.00  -0.23  95.00  -0.25  89.30  12.12
 21:00   0.00     --   0.00   0.00   0.00 105.26   0.00     --  12.12
 22:00  -0.06  92.00  -0.06   0.00  -0.06  95.00  -0.06  87.40  10.00
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal   0.76     --   0.48   0.00   0.48     --   0.30     --       
2025-09-30 08:43:07 info: In- en uitgaande energie per uur batterij Delta2Max
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 08:00  -0.10  92.00  -0.11   0.00  -0.11  95.00  -0.12  87.40  10.00
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 12:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 13:00   1.30  92.56   1.20   0.00   1.20  95.00   1.14  87.93  67.00
 14:00   0.76  91.71   0.69   0.00   0.69  95.00   0.66  87.12 100.00
 15:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  68.42
 19:00  -0.55  92.00  -0.60   0.00  -0.60  95.00  -0.63  87.40  36.84
 20:00   0.00     --   0.00   0.00   0.00     --   0.00     --  36.84
 21:00  -0.19  93.00  -0.20   0.00  -0.20  95.00  -0.22  88.35  26.09
 22:00  -0.12  93.00  -0.13   0.00  -0.13  95.00  -0.14  88.35  19.05
 23:00  -0.16  93.00  -0.17   0.00  -0.17  95.00  -0.18  88.35  10.00
Totaal   0.37     --   0.07   0.00   0.07     --  -0.12     --       
2025-09-30 08:43:08 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 08:00    0.00     0.10   0.00   0.17   0.23   0.00   0.00   0.00   0.13   0.00   -0.04  20.00   0.00
 09:00    0.35     0.00   0.00   2.16   0.26   0.00   0.00   0.00   2.77   0.00   -0.41  20.00   0.00
 10:00    0.00     0.00   0.00   1.46   0.31   0.00   0.00   0.00   1.77   0.00   -0.23  20.00   0.00
 11:00    0.00     0.00   0.00   0.03   0.32   0.00   0.00   0.00   0.35   0.00   -0.00  20.00   0.00
 12:00    0.00     0.00   0.00   0.75   0.31   0.00   0.00   0.00   1.06   0.00   -0.09  20.00   0.00
 13:00    1.79     0.00   0.00   1.40   0.23   0.00   0.00   0.00   3.42   0.00   -0.17  20.00   0.00
 14:00    2.05     0.00   0.00   0.52   0.26   0.00   0.00   0.00   2.83   0.00   -0.06  20.00   0.00
 15:00    0.00     0.00   0.00   1.76   0.21   0.00   0.00   0.00   1.97   0.00   -0.23  20.00   0.00
 16:00    0.00     0.00   0.00   1.21   0.21   0.00   0.00   0.00   1.42   0.00   -0.17  20.00   0.00
 17:00    0.00     0.00   0.00   0.46   0.54   0.00   0.00   0.00   1.00   0.00   -0.08  20.00   0.00
 18:00    0.00     1.10   0.00   1.27   0.26   0.00   0.00   0.00   0.42   0.00   -0.42  20.00   0.00
 19:00    0.00     1.10   0.00   0.84   0.26   0.00   0.00   0.00   0.00   0.00   -0.34  20.00   0.00
 20:00    0.00     0.22   0.00   0.00   0.22   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:00    0.00     0.19   0.00   0.00   0.19   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:00    0.00     0.18   0.00   0.00   0.18   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:00    0.00     0.16   0.00   0.00   0.16   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
Totaal    4.19     3.06   0.00  12.02   4.15   0.00   0.00   0.00  17.14   0.00   -2.23          0.00

2025-09-30 08:43:08 info: Consumption               0.00 (kWh)
2025-09-30 08:43:08 info: Cost consumption          0.00 (€)
2025-09-30 08:43:08 info: Tariff consumption          nan (€/kWh)
2025-09-30 08:43:08 info: Production               12.02 (kWh)
2025-09-30 08:43:08 info: Profit production        -2.23 (€)
2025-09-30 08:43:08 info: Tariff production        -0.186 (€/kWh)

2025-09-30 08:43:08 info: /nCalculation profit after optimize in €
Cost before optimize              -1.61
Cost consumption      0.00
Profit production    -2.23
Cycle cost            0.22
Battery storage      -0.03
Boiler storage        0.00
Total                -2.05
Cost after optimize              -2.00
Profit:                           0.38
2025-09-30 08:43:08 info: Doorzetten van alle settings naar HA
2025-09-30 08:43:08 info: Berekeningsuitkomst voor opladen van Kia Niro EV:
2025-09-30 08:43:08 info: - aantal ampere 0A (was 0.0A)
2025-09-30 08:43:08 info: - stand schakelaar 'off' (was 'off')
2025-09-30 08:43:08 info: - positie: home
2025-09-30 08:43:08 info: - ingeplugd: False
2025-09-30 08:43:08 info: Kia Niro EV is niet thuis of niet ingeplugd
2025-09-30 08:43:08 info: Evaluatie status laden Kia Niro EV op 2025-09-30 08:43
2025-09-30 08:43:08 info: - schakelaar laden: off
2025-09-30 08:43:08 info: - aantal ampere: 0.0
2025-09-30 08:43:08 info: Grid set point: -599.0 W
2025-09-30 08:43:08 info: Cycle cost EvaPower: 0.10 euro
2025-09-30 08:43:08 info: Netto vermogen naar(+)/uit(-) omvormer EvaPower: 0 W
2025-09-30 08:43:08 info: Balanceren: False
2025-09-30 08:43:08 info: Vermogen uit batterij: 0W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van pv: 0W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van ac: 0W
2025-09-30 08:43:08 info: Waarde SoC na eerste uur: -0.0%
2025-09-30 08:43:08 info: Grid set point: -599.0 W
2025-09-30 08:43:08 info: Cycle cost Delta2Max: 0.11 euro
2025-09-30 08:43:08 info: Netto vermogen naar(+)/uit(-) omvormer Delta2Max: -367 W
2025-09-30 08:43:08 info: Balanceren: False
2025-09-30 08:43:08 info: Vermogen uit batterij: 399W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van pv: 0W
2025-09-30 08:43:08 info: Vermogen dat binnenkomt van ac: -399W
2025-09-30 08:43:08 info: Waarde SoC na eerste uur: 10.0%
2025-09-30 08:43:08 info: Apparaat: Airco
2025-09-30 08:43:08 info: Programma: Uit
/root/dao/webserver/../prog/day_ahead.py:2682: RuntimeWarning: invalid value encountered in scalar divide
  tariff_consumption = cost_consumption / delivery.x

Moet ik nog wat aanpassen: consumption = 0?
Edit: tijdelijk opgelost door dit in te vullen:

code:

Day ahead prijzen ophalen prijzen_start jjjj-mm-dd prijzen_tot  jjjj-mm-dd

maar moet ik dit elke keer invullen? Als ik dat niet nameljk nie doe, dan krijg ik nog steeds bovenstaande meldingen.

Dit is een foutje in de code.
Is opgelost in de volgende versie.
Ik wacht nog even de ervaringen vanmiddag met de nieuwe prijzen af en dan komt die nieuwe versie.

[simnet]

@KC27 Ik weet dat de rapporten nog wat liefde nodig hebben, maar wilde deze nog even noemen; mocht die je ontgaan zijn (als je hem al wist, negeer dit bericht ):

De '/api/report/da/vandaag_en_morgen' API antwoord nog met prijzen per uur, ondanks dat 15min prijzen beschikbaar zijn.

[KC27]

simnet schreef op dinsdag 30 september 2025 @ 10:31:
@KC27 Ik weet dat de rapporten nog wat liefde nodig hebben, maar wilde deze nog even noemen; mocht die je ontgaan zijn (als je hem al wist, negeer dit bericht ):

De '/api/report/da/vandaag_en_morgen' API antwoord nog met prijzen per uur, ondanks dat 15min prijzen beschikbaar zijn.

Dank voor de tip, kleine aanpassing.
Zit als fix in de komende release (ergens vanmiddag, wacht even af hoe het om 13:00 uur gaat)
Maar op dat vlak moet nog veel gebeuren.
Eerst maar eens goed laten rekenen.

[ErnstH]

Moest inderdaad wel handmatig de prijzen ophalen, maar tot dusver gaat het goed!

[KC27]

Ik had het ook.
Ik denk dat nordpool opstart/conversie problemen had.

[Bravo]

KC27 schreef op dinsdag 30 september 2025 @ 13:08:
Ik had het ook.
Ik denk dat nordpool opstart/conversie problemen had.

Epex:

Maar ondertussen inderdaad de status gepubliceerd

[KC27]

Nu is er wel een verschil in winst bij 1hour-interval en 15min-interval:
15min winst 3.70:

code:

Calculation profit after optimize in €
Cost before optimize              -5.37
Cost consumption      4.71
Profit production   -14.54
Cycle cost            0.60
Battery storage       0.17
Boiler storage       -0.01
Total                -9.07
Cost after optimize              -9.06
Profit:                           3.70

1hour winst 3.43:

code:

Calculation profit after optimize in €
Cost before optimize              -5.00
Cost consumption      4.03
Profit production   -13.84
Cycle cost            0.55
Battery storage       0.83
Boiler storage       -0.00
Total                -8.43
Cost after optimize              -8.43
Profit:                           3.43

Dus voorlopig alle reden om over te stappen op kwartier-prijzen.

[KC27]

Bravo schreef op dinsdag 30 september 2025 @ 13:13:
[...]

Epex:
[Afbeelding]
Maar ondertussen inderdaad de status gepubliceerd

Thanks!
Dus de transitieproblemen zaten bij Epex en niet bij Nordpool.

[Voogel]

code:

2025-09-30 13:10:20 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 413, in get_loc
    return self._range.index(new_key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 12 is not in range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 591, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 2601, in calc_optimum
    self.save_df(tablename="prognoses", tijd=tijd_soc, df=df_soc)
  File "/root/dao/prog/da_base.py", line 353, in save_df
    db_row = [str(utc), c, float(df.loc[index, c])]
                                 ~~~~~~^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexing.py", line 1183, in __getitem__
    return self.obj._get_value(*key, takeable=self._takeable)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4226, in _get_value
    row = self.index.get_loc(index)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 415, in get_loc
    raise KeyError(key) from err
KeyError: 12
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 413, in get_loc
    return self._range.index(new_key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 12 is not in range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3869, in main
    da_calc.run_task_function("calc_optimum")
  File "/root/dao/prog/da_base.py", line 591, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 2601, in calc_optimum
    self.save_df(tablename="prognoses", tijd=tijd_soc, df=df_soc)
  File "/root/dao/prog/da_base.py", line 353, in save_df
    db_row = [str(utc), c, float(df.loc[index, c])]
                                 ~~~~~~^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexing.py", line 1183, in __getitem__
    return self.obj._get_value(*key, takeable=self._takeable)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4226, in _get_value
    row = self.index.get_loc(index)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 415, in get_loc
    raise KeyError(key) from err
KeyError: 12

Ik kreeg net nog even deze error toen ik probeerde handmatig een optimaliseringsberekening zonder debug te starten, een paar minuten later werkte alles wel gewoon foutloos.

[KC27]

Voogel schreef op dinsdag 30 september 2025 @ 13:28:

code:

2025-09-30 13:10:20 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 413, in get_loc
    return self._range.index(new_key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 12 is not in range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 591, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 2601, in calc_optimum
    self.save_df(tablename="prognoses", tijd=tijd_soc, df=df_soc)
  File "/root/dao/prog/da_base.py", line 353, in save_df
    db_row = [str(utc), c, float(df.loc[index, c])]
                                 ~~~~~~^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexing.py", line 1183, in __getitem__
    return self.obj._get_value(*key, takeable=self._takeable)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4226, in _get_value
    row = self.index.get_loc(index)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 415, in get_loc
    raise KeyError(key) from err
KeyError: 12
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 413, in get_loc
    return self._range.index(new_key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 12 is not in range

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3869, in main
    da_calc.run_task_function("calc_optimum")
  File "/root/dao/prog/da_base.py", line 591, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 2601, in calc_optimum
    self.save_df(tablename="prognoses", tijd=tijd_soc, df=df_soc)
  File "/root/dao/prog/da_base.py", line 353, in save_df
    db_row = [str(utc), c, float(df.loc[index, c])]
                                 ~~~~~~^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexing.py", line 1183, in __getitem__
    return self.obj._get_value(*key, takeable=self._takeable)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4226, in _get_value
    row = self.index.get_loc(index)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 415, in get_loc
    raise KeyError(key) from err
KeyError: 12

Ik kreeg net nog even deze error toen ik probeerde handmatig een optimaliseringsberekening zonder debug te starten, een paar minuten later werkte alles wel gewoon foutloos.

Ik kan deze helaas niet meer fixen bij de eerstvolgende release, die is al onderweg!

[KC27]

Zojuist versie 2025.10.1 (stable) /2025.10.1.rc1 (testing) gepubliceerd.
Deze versie is tot stand gekomen dankzij jullie testen en commentaren, daarvoor dank!
Dit staat er in de changelog:

code:

Fixes:
- deleted max_seconds limit
- max_mip_gap set to 0.005 (was 0.001)
- added logging.debug of hass/api/config
- fixed divide-zero error when production or consumption are 0.0
- when no country is configured in HA, "NL" is assumed
- "api/report/da/vandaag" and "api/report/da/vandaag en morgen" present data with the configured interval
- added documentation about the interval-setting to DOCS.md

Know issue:
- The forecast in the reports still nog good working

Dit staat er in DOCS.md m.b.t. het interval:

interval
Standaard rekent het programma met een 1 uur interval (default settings = "1hour") Als jouw energieleverancier rekent met kwartierprijzen dan kun je het interval op "15min" zetten. Let daarbij op de volgende aandachtspunten:

1. Pas de scheduler aan zodat het programma ook ieder kwartier rekent. Zet de volgende extra regels in de scheduler:
"xx15": "calc_optimum",
"xx30": "calc_optimum",
"xx45": "calc_optimum",
Let daarbij op dat deze "kwartieren" niet overeenkomen met een andere actie (bijv. meteo ophalen). Het programma kan vooralsnog per minuut maar 1 taak uitvoeren. Pas in dat geval de planning van deze taak aan.

2. Vul bij price-source een provider in die het leveren van kwartierprijzen ondersteunt. Vooralsnog zijn dat nordpool, tibber (beide getest) en entsoe (niet getest)
3. Haal ("met de hand" via het run menu) de prijzen voor vandaag en na 13:00 voor morgen opnieuw op. Vul de datum van vandaag (en morgen) in bij het "vanaf"-veld.

[Bravo]

Dank voor de update!
Nu weer gedraaid met EV en WP erbij, komt er een rekentijd van 1:25 uit op de RPi5. Oef, die kwartieren hakken er wel in qua rekentijd.

[KC27]

Bravo schreef op dinsdag 30 september 2025 @ 14:20:
Dank voor de update!
Nu weer gedraaid met EV en WP erbij, komt er een rekentijd van 1:25 uit op de RPi5. Oef, die kwartieren hakken er wel in qua rekentijd.

Ik heb ook een RPi5 en een batterij, mijn ev staat vol stil, wel een wp en hij rekent 6 seconden.
Ik ben toch wel benieuwd naar jouw options.json (of heb je die al eens gedeeld, dan graag een link)?

[Bravo]

KC27 schreef op dinsdag 30 september 2025 @ 14:25:
[...]

Ik heb ook een RPi5 en een batterij, mijn ev staat vol stil, wel een wp en hij rekent 6 seconden.
Ik ben toch wel benieuwd naar jouw options.json (of heb je die al eens gedeeld, dan graag een link)?

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

[simnet]

@Bravo Als je het leuk vind, zou je dan dit compile script willen proberen in je container (docker exec -it <name> bash)? Kan wel lang duren voordat hij klaar is met compilen, op mijn celeron n4500 duurt het ongeveer 15 minuten.

Je zou de /root/dao/prog/miplib folder even opzij kunnen zetten als backup, maar de container deleten en opnieuw starten is voldoende. (deze changes zijn niet permanent).

Ben wel benieuwd of het je enige winst oplevert. Bij mij maar een beetje, maar dat komt omdat mijn cpu veel extensies niet heeft die CBC snel maken (zoals avx). De meeste modernere cpu's hebben die wel.

code:

mkdir -p ~/build
cd ~/build
apt-get install -y gcc g++ gfortran libgfortran-9-dev liblapack-dev libmetis-dev libsuitesparse-dev git

wget -nH https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod +x coinbrew

./coinbrew build Cbc@master ADD_CXXFLAGS="-march=native -O3" --no-prompt --prefix=prog/ --tests=none --enable-cbc-parallel --enable-relocatable --no-third-party --with-gcc-arch=native
if [ -d "/root/dao/prog/miplib/lib" ]; then rm -rf /root/dao/prog/miplib/lib; fi
mkdir -p /root/dao/prog/miplib
cp -a ~/build/prog/lib/ /root/dao/prog/miplib

Met logging op debug zie je dan de versie van CBC... die moet dan iets bevatten in de trend van:

Welcome to the CBC MILP Solver
Version: devel
Build Date: Sep 30 2025
Starting solution of the Linear programming relaxation problem using Dual Simplex

[KC27]

simnet schreef op dinsdag 30 september 2025 @ 14:37:
@Bravo Als je het leuk vind, zou je dan dit compile script willen proberen in je container (docker exec -it <name> bash)? Kan wel lang duren voordat hij klaar is met compilen, op mijn celeron n4500 duurt het ongeveer 15 minuten.

Je zou de /root/dao/prog/miplib folder even opzij kunnen zetten als backup, maar de container deleten en opnieuw starten is voldoende. (deze changes zijn niet permanent).

Ben wel benieuwd of het je enige winst oplevert. Bij mij maar een beetje, maar dat komt omdat mijn cpu veel extensies niet heeft die CBC snel maken (zoals avx). De meeste modernere cpu's hebben die wel.

code:

mkdir -p ~/build
cd ~/build
apt-get install -y gcc g++ gfortran libgfortran-9-dev liblapack-dev libmetis-dev libsuitesparse-dev git

wget -nH https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod +x coinbrew

./coinbrew build Cbc@master ADD_CXXFLAGS="-march=native -O3" --no-prompt --prefix=prog/ --tests=none --enable-cbc-parallel --enable-relocatable --no-third-party --with-gcc-arch=native
if [ -d "/root/dao/prog/miplib/lib" ]; then rm -rf /root/dao/prog/miplib/lib; fi
mkdir -p /root/dao/prog/miplib
cp -a ~/build/prog/lib/ /root/dao/prog/miplib

Met logging op debug zie je dan de versie van CBC... die moet dan iets bevatten in de trend van:

[...]

@balk heeft een RPi5 ben heel benieuwd of het daar uberhaupt op compileert

[KC27]

@Bravo Als je toch een keer draait met logging op "debug", ik ben benieuwd naar je resources, die worden gelogd met debug:

code:

2025-09-30 15:18:24 debug: Memory used/free:
MemTotal:       16385384 kB
MemFree:          774832 kB
MemAvailable:   14027084 kB

[sailor_dg]

bedankt voor je harde werk - lijkt hier allemaal soepel te draaien!

[KC27]

@Bravo
Ik heb in HA grafiekjes gemaakt van de processor-belasting en het geheugengebruik tijdens een berekening (gaat via Instellingen\Systeem\Hardware):

Ik ben benieuwd hoe die van jou eruit ziet.

[balk]

KC27 schreef op dinsdag 30 september 2025 @ 15:11:
[...]

@balk heeft een RPi5 ben heel benieuwd of het daar uberhaupt op compileert

Nope, geen RPi hier, althans niet voor DAO. Ik heb een NAB9 veel te zware overkill maar ik wil wel even testen

[Mirabis]

simnet schreef op dinsdag 30 september 2025 @ 14:37:
@Bravo Als je het leuk vind, zou je dan dit compile script willen proberen in je container (docker exec -it <name> bash)? Kan wel lang duren voordat hij klaar is met compilen, op mijn celeron n4500 duurt het ongeveer 15 minuten.

Je zou de /root/dao/prog/miplib folder even opzij kunnen zetten als backup, maar de container deleten en opnieuw starten is voldoende. (deze changes zijn niet permanent).

Ben wel benieuwd of het je enige winst oplevert. Bij mij maar een beetje, maar dat komt omdat mijn cpu veel extensies niet heeft die CBC snel maken (zoals avx). De meeste modernere cpu's hebben die wel.

code:

mkdir -p ~/build
cd ~/build
apt-get install -y gcc g++ gfortran libgfortran-9-dev liblapack-dev libmetis-dev libsuitesparse-dev git

wget -nH https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod +x coinbrew

./coinbrew build Cbc@master ADD_CXXFLAGS="-march=native -O3" --no-prompt --prefix=prog/ --tests=none --enable-cbc-parallel --enable-relocatable --no-third-party --with-gcc-arch=native
if [ -d "/root/dao/prog/miplib/lib" ]; then rm -rf /root/dao/prog/miplib/lib; fi
mkdir -p /root/dao/prog/miplib
cp -a ~/build/prog/lib/ /root/dao/prog/miplib

Met logging op debug zie je dan de versie van CBC... die moet dan iets bevatten in de trend van:

[...]

Thanks, ik ga dat eens proberen

EDIT: @simnet script draaide wel maar het resultaat blijft: Welcome to the CBC MILP Solver
Version: Trunk
Build Date: Oct 24 2021

https://pastebin.com/UBQn6Q25

[ Voor 5% gewijzigd door Mirabis op 30-09-2025 16:24 ]

[simnet]

balk schreef op dinsdag 30 september 2025 @ 15:33:
[...]

Nope, geen RPi hier, althans niet voor DAO. Ik heb een NAB9 veel te zware overkill maar ik wil wel even testen

Kan zijn dat je op x86_64 archs nog de oude versie houdt. De container heeft nog geen support voor eigen binaries op die arch.

[simnet]

Mirabis schreef op dinsdag 30 september 2025 @ 15:52:
[...]

Thanks, ik ga dat eens proberen

EDIT: @simnet script draaide wel maar het resultaat blijft: Welcome to the CBC MILP Solver
Version: Trunk
Build Date: Oct 24 2021

https://pastebin.com/UBQn6Q25

Draai je op x86_64 architectuur? Want die container is nog niet helemaal gereed daarvoor. Je kunt het forceren door de juiste environment variabelen te zetten:

code:

cd ~/dao/webserver
export PMIP_CBC_LIBRARY="/root/dao/prog/miplib/lib/libCbc.so"
pkill -f /root/dao/venv/day_ahead/bin/python3
/root/dao/venv/day_ahead/bin/python3 /root/dao/venv/day_ahead/bin/gunicorn --config gunicorn_config.py app:app &>/dev/null &

[ Voor 3% gewijzigd door simnet op 30-09-2025 16:46 ]

[BBuilds]

Net even de update naar v2025.10.1 gedaan en krijg de volgende error bij het ophalen van de Day Ahead prijzen:

code:

2025-09-30 16:39:50 info: Day Ahead Optimalisering versie: 2025.10.1
2025-09-30 16:39:50 info: Day Ahead Optimalisering gestart op: 30-09-2025 16:39:50
2025-09-30 16:39:50 info: Day Ahead Optimalisatie gestart: 30-09-2025 16:39:50 taak: get_day_ahead_prices
2025-09-30 16:39:50 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 335, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 164, in get_prices
    act_values = act_spot_prices["areas"]["NL"]["values"]
                 ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'NL'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3875, in main
    da_calc.run_task_function("prices")
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 335, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 164, in get_prices
    act_values = act_spot_prices["areas"]["NL"]["values"]
                 ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'NL'

Als ik de landcode in HA op Netherlands zet, dan werkt het ophalen van de prijzen wel. Als ik het terug op België zet, dan krijg ik terug bovenstaande fout.
In v2025.09.xx werkte België wel goed

[Mirabis]

simnet schreef op dinsdag 30 september 2025 @ 16:38:
[...]


Draai je op x86_64 architectuur? Want die container is nog niet helemaal gereed daarvoor. Je kunt het forceren door de juiste environment variabelen te zetten:

code:

cd ~/dao/webserver
export PMIP_CBC_LIBRARY="/root/dao/prog/miplib/lib/libCbc.so"
pkill -f /root/dao/venv/day_ahead/bin/python3
/root/dao/venv/day_ahead/bin/python3 /root/dao/venv/day_ahead/bin/gunicorn --config gunicorn_config.py app:app &>/dev/null &

Yep, LXC op een ProxMox host met 13th Gen Intel(R) Core(TM) i5-13500. Tijdje geleden al mijn Pi's geconsolideerd naar een low-power server die alles (en meer dan) wat de Pi's deden kan. cat /proc/cpuinfo = https://pastebin.com/Hqtj6ueb

Bovenstaande stukje code werkt en ik krijg nu:

code:

Welcome to the CBC MILP Solver 
Version: devel 
Build Date: Sep 30 2025
...

Voor de wijziging:
Search completed - best objective -3.037565665452877, took 5436 iterations and 503 nodes (14.84 seconds)

Na de wijziging:

code:

Search completed - best objective -2.870543565840125, took 2010 iterations and 120 nodes (4.62 seconds)
...
Result - Optimal solution found (within gap tolerance)
Objective value:                -2.87054356584
Lower bound:                    -2.87512
Gap:                            0.00159101
Enumerated nodes:               120
Total iterations:               2010
Time (CPU seconds):             4.74664
Time (Wallclock seconds):       4.80894
Total time (CPU seconds):       4.74685   (Wallclock seconds):       4.80916

Bijna een factor 3 sneller. Vind het prima zo... kan ik de fijnmazige charge stages laten staan.

[ Voor 4% gewijzigd door Mirabis op 30-09-2025 16:57 ]

[simnet]

Mirabis schreef op dinsdag 30 september 2025 @ 16:56:
[...]

Bijna een factor 3 sneller. Vind het prima zo... kan ik de fijnmazige charge stages laten staan.

Dat is een flinke speedup! Ik ga kijken of ik dit wat meer permanent kan maken voor iedereen. Ziet er vooralsnog naar uit dat het niet heel lastig hoeft te zijn.

[storeman]

Ik heb zojuist de update gedaan naar 10.1 en de interval op 15min gezet.

Mijn boiler wordt niet ingepland (duur en nog binnen de hysterese), dus dat lijkt me logisch, echter krijg in in debug nu deze fout. Ik denk dat er geen tijd wordt bepaald en hierdoor een exceptie optreed?

[code]
122 2025-10-01 23:45:00 37.175 0.000 0.000 0 0.000 0.000 0.000 0.000

2025-09-30 17:21:03 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
File "/root/dao/prog/da_base.py", line 594, in run_task_function
getattr(self, run_task["function"])()
File "/root/dao/prog/da_base.py", line 524, in calc_optimum_met_debug
dacalc.calc_optimum()
File "/root/dao/prog/day_ahead.py", line 1091, in calc_optimum
logging.info(f"Boiler start wordt ingezet op {tijd[boiler_start]} met "
~~~~^^^^^^^^^^^^^^
TypeError: list indices must be integers or slices, not NoneType
Traceback (most recent call last):
File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
main()
File "/root/dao/webserver/../prog/day_ahead.py", line 3867, in main
da_calc.run_task_function("calc_optimum_met_debug")
File "/root/dao/prog/da_base.py", line 594, in run_task_function
getattr(self, run_task["function"])()
File "/root/dao/prog/da_base.py", line 524, in calc_optimum_met_debug
dacalc.calc_optimum()
File "/root/dao/prog/day_ahead.py", line 1091, in calc_optimum
logging.info(f"Boiler start wordt ingezet op {tijd[boiler_start]} met "
~~~~^^^^^^^^^^^^^^
TypeError: list indices must be integers or slices, not NoneType
[/code]

- Fout treedt op in debug, maar ook in normale modus
- Het uitzetten van de boiler zorgt voor een succesvolle run

Dit is inmiddels opgelost. Ik had het vermogen op 3.5 (kW) ipv 3500, hierdoor ging DAO stuk.

[ Voor 5% gewijzigd door storeman op 30-09-2025 21:06 ]

[KC27]

BBuilds schreef op dinsdag 30 september 2025 @ 16:44:
Net even de update naar v2025.10.1 gedaan en krijg de volgende error bij het ophalen van de Day Ahead prijzen:

code:

2025-09-30 16:39:50 info: Day Ahead Optimalisering versie: 2025.10.1
2025-09-30 16:39:50 info: Day Ahead Optimalisering gestart op: 30-09-2025 16:39:50
2025-09-30 16:39:50 info: Day Ahead Optimalisatie gestart: 30-09-2025 16:39:50 taak: get_day_ahead_prices
2025-09-30 16:39:50 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 335, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 164, in get_prices
    act_values = act_spot_prices["areas"]["NL"]["values"]
                 ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'NL'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3875, in main
    da_calc.run_task_function("prices")
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 335, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 164, in get_prices
    act_values = act_spot_prices["areas"]["NL"]["values"]
                 ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'NL'

Als ik de landcode in HA op Netherlands zet, dan werkt het ophalen van de prijzen wel. Als ik het terug op België zet, dan krijg ik terug bovenstaande fout.
In v2025.09.xx werkte België wel goed

Wil je de berekening met logging level "debug" draaien, dan zie je wel landcode er in HA staat.
Ik hoor het graag.

[georgeboot]

Ik haal prijzen op bij Tibber en heb nieuwe versie icm 15m instelling, maar dan krijg ik deze foutmelding:

2025-09-30 17:54:15 info: Day Ahead Optimalisering versie: 2025.10.1
2025-09-30 17:54:15 info: Day Ahead Optimalisering gestart op: 30-09-2025 17:54:15
2025-09-30 17:54:15 info: Day Ahead Optimalisatie gestart: 30-09-2025 17:54:15 taak: calc_optimum
2025-09-30 17:54:15 info: Debug = False
2025-09-30 17:54:15 fout: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken

Heb opnieuw prijzen opgehaald maar dat maakt niets uit. Ondersteunt de Tibber api nog geen kwartierprijzen?

[KC27]

georgeboot schreef op dinsdag 30 september 2025 @ 17:55:
Ik haal prijzen op bij Tibber en heb nieuwe versie icm 15m instelling, maar dan krijg ik deze foutmelding:

2025-09-30 17:54:15 info: Day Ahead Optimalisering versie: 2025.10.1
2025-09-30 17:54:15 info: Day Ahead Optimalisering gestart op: 30-09-2025 17:54:15
2025-09-30 17:54:15 info: Day Ahead Optimalisatie gestart: 30-09-2025 17:54:15 taak: calc_optimum
2025-09-30 17:54:15 info: Debug = False
2025-09-30 17:54:15 fout: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken

Heb opnieuw prijzen opgehaald maar dat maakt niets uit. Ondersteunt de Tibber api nog geen kwartierprijzen?

Het zou wel moeten (hebben ze beloofd).
Ik zal het nog een keer testen, nu met echte data.
Je kunt altijd nog (tijdelijk) switchen naar nordpool.

[ Voor 3% gewijzigd door KC27 op 30-09-2025 18:13 ]

[Skevdude]

KC27 schreef op maandag 29 september 2025 @ 23:40:
[...]

Met deze config maak je het DAO wel onnodig lastig.
Je hebt drie identieke batterijen. Voor de snelheid kun je deze beter vervangen door een (gesommeerde) virtuele batterij.En de berekende charge/discharge verdeel je dan over de batterijen. Je kunt dan zelfs bij een lage charge/discharge dit door een van de accu's laten verzorgen wat dan met een beter rendement plaatsvindt.
Hiervoor in dit topic zijn ook gebruikers met meer dan een Sessy die hetzelfde doen: zoek en je zult vinden.

Bedankt voor de tip, hier ga ik mee aan de slag.
Als test heb ik even 2 batterijen weggehaald uit de config. Strategie minimize consumption.
Ik heb na het installeren van 2025.10.1 gekeken hoe lang het duurt: 1 minuut 20 seconden voordat er een solution is. Dus duurt alsnog lang. Zou er nog een andere reden zijn waarom het zolang duurt?

[simnet]

simnet schreef op dinsdag 30 september 2025 @ 17:01:
[...]


Dat is een flinke speedup! Ik ga kijken of ik dit wat meer permanent kan maken voor iedereen. Ziet er vooralsnog naar uit dat het niet heel lastig hoeft te zijn.

Als je dit permanent wilt maken voer dan het volgende uit (zorg dat je vers begint en niet de commando's uit mijn vorige post gebruikt). Ik weet eerlijk niet hoe dit moet met een hass addon.

1. voeg een docker volume toe op de locatie /root/dao/customcbc
hier wordt straks de eigen gecompilede versie in opgeslagen
2. compileer de custom cbc library met dit script:

code:

if [ ! -d "/root/dao/customcbc" ]; then
  echo No Custom CBC directory found at /root/dao/customcbc... exitting
  exit 0
fi

mkdir -p ~/build
cd ~/build
apt-get install -y gcc g++ git

wget -nH https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod +x coinbrew

./coinbrew build Cbc@master ADD_CXXFLAGS="-march=native -O3" --no-prompt --prefix=prog/ --tests=none --enable-cbc-parallel --enable-relocatable --no-third-party --with-gcc-arch=native

if [ -d "/root/dao/customcbc/lib" ]; then rm -rf /root/dao/customcbc/lib; fi
mkdir -p /root/dao/customcbc/lib
cp -a ~/build/prog/lib/*.so* /root/dao/customcbc/lib

3. als dit correct is uitgevoerd, voeg dan de volgende twee environment variabelen toe aan de docker commandline:
- PMIP_CBC_LIBRARY = "/root/dao/customcbc/lib/libCbc.so"
- LD_LIBRARY_PATH = "/root/dao/customcbc/lib"

Zolang de container start met bovenstaande environment variabelen zal hij je eigen gecompileerde versie van cbc gebruiken.

[georgeboot]

KC27 schreef op dinsdag 30 september 2025 @ 18:12:
[...]

Het zou wel moeten (hebben ze beloofd).
Ik zal het nog een keer testen, nu met echte data.
Je kunt altijd nog (tijdelijk) switchen naar nordpool.

Hmm als ik naar noordpool ga en prijzen ophaal, krijg ik inderdaad prijzen per kwartier terug in de debug log.

Maar doe ik daarna een berekening, dan krijg ik alsnog zelfde melding.

Update vandaag eind van de middag pas gedaan, dus wellicht had ie al uurprijzen bij Tibber opgehaald en overschrijft hij ze niet? Als ik hem weer op uur zet en berekening maak, dan geeft de prijsgrafiek ook nog steeds data per uur aan.

[diamanten]

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

Dit is een foutje in de code.
Is opgelost in de volgende versie.
Ik wacht nog even de ervaringen vanmiddag met de nieuwe prijzen af en dan komt die nieuwe versie.

Dank voor de update! Het werkt nu idd.
Een detail: volgens mij zou de linkerschaal van de accugrafieken wat aangepast kunnen worden. Nu zijn de staafdiagrammen amper leesbaar.

[balk]

simnet schreef op dinsdag 30 september 2025 @ 15:52:
[...]

Kan zijn dat je op x86_64 archs nog de oude versie houdt. De container heeft nog geen support voor eigen binaries op die arch.

Ik heb inderdaad geen directory /root/dao/prog/miplib
Is er een andere manier om het te testen?

Ik kan wel proberen met een losse dokker image.

[ Voor 6% gewijzigd door balk op 30-09-2025 19:04 ]

[simnet]

@balk zou je deze instructies kunnen proberen? Die werken voor mijzelf op x86_64:
simnet in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

[KC27]

[quote]BBuilds schreef op dinsdag 30 september 2025 @ 16:44:
Net even de update naar v2025.10.1 gedaan en krijg de volgende error bij het ophalen van de Day Ahead prijzen:

code:

2025-09-30 16:39:50 info: Day Ahead Optimalisering versie: 2025.10.1
2025-09-30 16:39:50 info: Day Ahead Optimalisering gestart op: 30-09-2025 16:39:50
2025-09-30 16:39:50 info: Day Ahead Optimalisatie gestart: 30-09-2025 16:39:50 taak: get_day_ahead_prices
2025-09-30 16:39:50 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 335, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 164, in get_prices
    act_values = act_spot_prices["areas"]["NL"]["values"]
                 ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'NL'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3875, in main
    da_calc.run_task_function("prices")
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 335, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 164, in get_prices
    act_values = act_spot_prices["areas"]["NL"]["values"]
                 ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: 'NL'

Dank voor het melden!
Ik heb de fout gevonden, wordt in de volgende versie (waarschijnlijk morgen) hersteld.

[Bravo]

simnet schreef op dinsdag 30 september 2025 @ 14:37:
@Bravo Als je het leuk vind, zou je dan dit compile script willen proberen in je container (docker exec -it <name> bash)? Kan wel lang duren voordat hij klaar is met compilen, op mijn celeron n4500 duurt het ongeveer 15 minuten.

Je zou de /root/dao/prog/miplib folder even opzij kunnen zetten als backup, maar de container deleten en opnieuw starten is voldoende. (deze changes zijn niet permanent).

Ben wel benieuwd of het je enige winst oplevert. Bij mij maar een beetje, maar dat komt omdat mijn cpu veel extensies niet heeft die CBC snel maken (zoals avx). De meeste modernere cpu's hebben die wel.

code:

mkdir -p ~/build
cd ~/build
apt-get install -y gcc g++ gfortran libgfortran-9-dev liblapack-dev libmetis-dev libsuitesparse-dev git

wget -nH https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod +x coinbrew

./coinbrew build Cbc@master ADD_CXXFLAGS="-march=native -O3" --no-prompt --prefix=prog/ --tests=none --enable-cbc-parallel --enable-relocatable --no-third-party --with-gcc-arch=native
if [ -d "/root/dao/prog/miplib/lib" ]; then rm -rf /root/dao/prog/miplib/lib; fi
mkdir -p /root/dao/prog/miplib
cp -a ~/build/prog/lib/ /root/dao/prog/miplib

Met logging op debug zie je dan de versie van CBC... die moet dan iets bevatten in de trend van:

[...]

Ik draai het als Addon in HA, niet in een losse docker omgeving. Even zelf compilen is lang geleden voor mij

KC27 schreef op dinsdag 30 september 2025 @ 15:27:
@Bravo
Ik heb in HA grafiekjes gemaakt van de processor-belasting en het geheugengebruik tijdens een berekening (gaat via Instellingen\Systeem\Hardware):
[Afbeelding]
Ik ben benieuwd hoe die van jou eruit ziet.

Dat ziet er bij mij zo uit:

KC27 schreef op dinsdag 30 september 2025 @ 15:19:
@Bravo Als je toch een keer draait met logging op "debug", ik ben benieuwd naar je resources, die worden gelogd met debug:

code:

2025-09-30 15:18:24 debug: Memory used/free:
MemTotal:       16385384 kB
MemFree:          774832 kB
MemAvailable:   14027084 kB

Bijbehorende debug:
https://pastebin.com/aUveWmwP

code:

025-09-30 19:31:35 debug: Memory used/free:
MemTotal:        4083948 kB
MemFree:           31320 kB
MemAvailable:    1693540 kB

[ Voor 8% gewijzigd door Bravo op 30-09-2025 19:56 ]

[KC27]

diamanten schreef op dinsdag 30 september 2025 @ 18:44:
[...]

Dank voor de update! Het werkt nu idd.
Een detail: volgens mij zou de linkerschaal van de accugrafieken wat aangepast kunnen worden. Nu zijn de staafdiagrammen amper leesbaar.
[Afbeelding]

Ik heb ervoor gekozen om die drie bovenstaande grafieken dezelfde y-as te geven zodat je die aacu-waarden terugvindt in de de tweede grafiek.
Als meer mensen hier last van hebben kan ik het aanpassen

[Impossibl3]

Ik heb mijn boiler al een tijdje als dummy draaien voordat ik die door DAO laat aansturen (nu nog op een gewoon klok programma). Maar ik snap iets niet.

Bij DAO heb ik de volgende parameters opgegeven:

code:

   },
  "boiler": {
    "boiler present": "True",
    "boiler heated by heatpump": "True"
    "entity boiler enabled": "input_boolean.boiler_enabled"
    "entity instant start": "input_boolean.dhw_start_run_now"
    "entity actual temp.": "sensor.ithodaalderop_amber_domestic_hot_water_temperature",
    "entity setpoint": "number.ithodaalderop_amber_domestic_hot_water_setpoint",
    "entity hysterese": "number.ithodaalderop_amber_domestic_hot_water_reheating_point",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 270,
    "heating allowed below": 43,
    "elec. power": 2200,
    "activate service": "press",
    "activate entity": "input_button.dhw_activate_run"
  },

Waarbij:
* "entity actual temp.": de actuele temperatuur in het vat is (logisch)
* "entity setpoint": de doel temperatuur van het vat is (in mijn geval 55 graden)
* "entity hysterese": de ruimte waar die niets moet doen (in mijn geval 5 graden). Als mijn tapwatervat onder deze waarde komt (binnen het klokprogramma) dan start het verwarmen van het water automatisch. Ik verwacht dat dit is < 50 graden (55 - 5)
* "heating allowed below": staat op 43.

Als ik in de docs kijkt zie ik niet hoe "entity hysterese" en "heating allowed below" samenwerken/elkaar versterken. Ik verwacht altijd verwarmen als de "entity actual temp." < "heating allowed below" dat er verwarmt moet gaan worden maar dat het ook het geval is bij "entity actual temp." < "entity setpoint" - "entity hysterese".

Als ik namelijk bij mijn tabel kijk zie ik het volgende:

2025-09-30 20:00:00 info: Boiler direct opwarmen staat uit
2025-09-30 20:00:00 info: Boiler wordt niet ingepland, omdat de verwachte eindtemperatuur 40.5000007629395 °C hoger is dan de opwarmgrens 43 °C.
2025-09-30 20:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-09-30 20:00:00 info: Strategie: minimale kosten
2025-09-30 20:00:00 info: Het programma heeft een optimale oplossing gevonden.
2025-09-30 20:00:00 info: Waarde boiler om 23 uur: -1.06 kWh
2025-09-30 20:00:01 info: Berekende prognoses:

DAO verwacht dus dat mijn vat vandaag onder de 43 graden komt maar toch gaat DAO niet het verwarmen inplannen. Maar een paar regels later geeft die aan "Waarde boiler om 23:00 -1.06 kWh". Dus blijkbaar plant die wel wat in maar op basis van welke logica (behalve de prijs). Mijn vat staat overigens nu op 51.8 graden en zou met de afkoeling van 0.4 K/uur pas over 4.5 (rond 00:30 uur) onder de waarde komen entity actual temp." < "entity setpoint" - "entity hysterese" maar nog ruim boven de 43 graden als ondergrens zitten en toch wordt om 23:00 uur 1.06 kWh ingepland volgens de tabel.

Ik snap dus niet hoe DAO omgaat met de boiler. Kan iemand mij dit uitleggen?

Daarnaast. Als ik kijk naar de input_button.dhw_activate_run dan staat die nog op 2025-09-30T10:00:00.882520+00:00 met als attribuut status True. Hieruit maak ik op dat ik na behalen doeltemperatuur mijn input_button.dhw_activate_run via een automatisering terug naar "False" moet zetten. Klopt dit?

Nu ik toch bezig ben met de boiler. Nog een verzoek. Kan er voor de boiler tzt een tijdsvenster ingebouwd worden wanneer die actief mag zijn. Ik wil hem graag overdag laten draaien (ook als het financieel ongunstig is) omdat de WP die mijn vat verwarmt naast een van de slaapkamers staat.

[storeman]

@Impossibl3
Hier heb ik ook mee zitten stoeien, je hebt de twee waardes omgedraaid.

Heating allowed below
Dit is de waarde waaronder je op een OPTIMAAL moment wil gaan verwarmen. DAO berekent de (verwachte) afkoeling en schat de temperatuur dan in, en kan dan een moment inplannen.

Hysterese
Dit is het verschil wat het maximaal mag zijn onder de MAX temperatuur. Als je hieronder komt, zal DAO altijd per direct de opwarming inplannen zonder optimalisatie.

Dus de ingeplande opwarming zal ergens liggen tussen 'heating allowed below' en (MAX - hysterese). Onder de laatste start opwarming direct.

[Impossibl3]

storeman schreef op dinsdag 30 september 2025 @ 20:32:
@Impossibl3
Hier heb ik ook mee zitten stoeien, je hebt de twee waardes omgedraaid.

Heating allowed below
Dit is de waarde waaronder je op een OPTIMAAL moment wil gaan verwarmen. DAO berekent de (verwachte) afkoeling en schat de temperatuur dan in, en kan dan een moment inplannen.

Hysterese
Dit is het verschil wat het maximaal mag zijn onder de MAX temperatuur. Als je hieronder komt, zal DAO altijd per direct de opwarming inplannen zonder optimalisatie.

Dus de ingeplande opwarming zal ergens liggen tussen 'heating allowed below' en (MAX - hysterese). Onder de laatste start opwarming direct.

Oke dus:
* Hysterese zet ik op 12 zodat er altijd opgewarmd wordt bij 43 graden (55-12) en
*Heating allowed below zet ik op "number.ithodaalderop_amber_domestic_hot_water_setpoint" - "number.ithodaalderop_amber_domestic_hot_water_reheating_point".

Op deze manier hou ik mijn Heating allowed below flexibel.

Hoe zou je vervolgens door DAO een legionella run inplannen. Mijn idee is Hysterese variabel (ik weet dat er gewerkt wordt aan alle vast waardes om te zetten naar helpers) en de setpoint verhogen naar 63 met een reheating_point van 0. Op deze manier bijft de ondergrens 43 (ik verhoog dan de hysterese) en wordt wel ergens op de dag de legeonella run gedaan.

[storeman]

@Impossibl3 Legionellarun kan niet zomaar, maar je zou kunnen overwegen dit als een "machine" erin te zetten, die kun je dan wel flexibel aansturen.

[storeman]

@KC27 Mijn eerdere report over een error bleek te komen doordat ik slechts 3.5 (kw) had ingevuld bij boiler "elec. power", in plaats van 3500 (W). Nadat ik dat heb bijgewerkt ging het allemaal prima. Ik heb mijn eerdere berichtje even doorgehaald en een opmerking bijgezet.

[Faceless]

Bedankt voor het aanpassen zodat DAO werkt met kwartierprijzen. Wat is het toch een indrukwekkend stukje software. Veel dank!

(Ik zou willen dat er een donatie-knop/patreon/buy-me-a-coffee link ergens was).

[Impossibl3]

storeman schreef op dinsdag 30 september 2025 @ 21:02:
@Impossibl3 Legionellarun kan niet zomaar, maar je zou kunnen overwegen dit als een "machine" erin te zetten, die kun je dan wel flexibel aansturen.

Hmm dat wordt dan nog een lastige. In de zomer heb ik er namelijk last van dat de doeltemperatuur hoger is dan dat de compressor kan halen (ja ik kan 63 graden op mijn compressor halen met een cop van 3). Ik zoek daarom een optimum tussen elektrische kWh en €'s. Door mijn COP van 3 kan een duurder uur zomaar goedkoper zijn dan een goedkoop uur maar dan op het backup element wat de WP zelf inschakelt. In die periode kan ik ook niet verwarmen (of koelen).

[storeman]

@Impossibl3 Kun je dat nog eens herfomuleren wat je precies wil doen? Ik kan niet exact duiden wat de bedoeling is, maar een afweging maken tussen elektrisch of met WP de run doen lijkt me bijna niet te bepalen. Immers zal het met een COP van 3 altijd goedkoper zijn op eenzelfde moment als met een COP van 1.

Op het goedkoopste moment wil je dus zoveel mogelijk noodzakelijke kWh gebruiken. Dus een legionellarun is altijd interessant op het goedkoopste moment. Of dit nu met WP of elektrisch element moet.

Als je een machine aanmaakt, kun je die inplannen en de run afhandelen zoals je wil. Dus bijvoorbeeld afhankelijk van de buitentemperatuur dit elektrisch of met de WP doen.

Koelen/verwarmen kun je altijd wel even verschuiven, aangezien je COP hier altijd hoger zal liggen dan bij een legionellarun.

[Impossibl3]

@storeman mijn compressor bereik is afhankelijk van de buitentemperatuur ter plaatsen van de warmtepomp tussen de -10 en +20 red ik het op de compressor (zie onderstaan figuur). Daar buiten (vooral in de zomer) zal het elektrische element bij springen. Als ik in de zomer een legionellarun midden op de dag doe wanneer de kWh prijs laag is (veel PV) maar de temperatuur hoog is heb ik vaak dat ik volledig op het elektrische element mijn vat op warm ipv op de compressor. In de ochtend of avond kan dan goedkoper zijn ondanks dat de kWh prijs dan hoger is. Juist vanwege die COP.

Hopelijk maakt dit mijn dilemma wat duidelijker.

[storeman]

@tonvanboven Ah, zo. Dat was niet iets wat ik verwachtte in eerste instantie, maar met uitleg snap ik hem en is het mij duidelijk. Ik denk even hardop, ik zie hem nog niet helemaal, maar wellicht komen we er samen.

Bij een negatieve stroomprijs => altijd elektrisch

Bij stroomprijs < 10ct en buitentemp tussen -10 en 20 => WP op goedkoopste moment

Laagste stroomprijs valt meestal behoorlijk samen met een warm moment op de dag, indien verwachte temp tussen -10 en 20, dan op goedkoopste moment

Anders: 's nachts om 3 uur?

DAO heeft momenteel volgens mij geen ondersteuning om rekening te houden met de COP en/of buitentemperatuur. Je zal het dus moeten aanvliegen op een creatievere manier. Je kunt ook denken aan een machine die zichzelf opnieuw in blijft plannen indien het moment niet geschikt is.

Al schrijvende, ik zie hem nog niet...

[Impossibl3]

@storeman wat ik nu doe is op het goedkoopste moment tussen 9:00 en 18:00 een legionellarun inplannen op zaterdag mits de compressor het trekt met een buffer tenzij de totale prijs lager is dan €0,00. Mocht de compressor het niet redden dan kijk ik om 20:00 uur nog eens of het kan (zondag ochtend wordt er gesport door mijn vrouw en staat de douche dus lang aan). Mocht het op zaterdag nog niet lukken wordt er op zondag sowieso om 8:30 een run ingepland ondanks de kosten.

De ervaring leert dat dit in 90% van de gevallen goed werkt. Ik moet dan de legionellarun alleen als machine in DAO opnemen waarbij DAO alleen op zaterdag in plant maar ook rekening kan houden met de situatie dat die nu aan gaat (net zoals ik doe met de wasmachine, droger en vaatwasser). Via een rest commando zou ik dan een berekening opnieuw moeten laten starten denk ik.

[KC27]

georgeboot schreef op dinsdag 30 september 2025 @ 18:36:
[...]

Hmm als ik naar noordpool ga en prijzen ophaal, krijg ik inderdaad prijzen per kwartier terug in de debug log.

Maar doe ik daarna een berekening, dan krijg ik alsnog zelfde melding.

Update vandaag eind van de middag pas gedaan, dus wellicht had ie al uurprijzen bij Tibber opgehaald en overschrijft hij ze niet? Als ik hem weer op uur zet en berekening maak, dan geeft de prijsgrafiek ook nog steeds data per uur aan.

Ik heb een fout bij het ophalen bij Tibber gevonden en gefixed.
Die fix komt in de volgende versie.

[KC27]

Ondanks de grote steun voor ons feature request (https://github.com/orgs/home-assistant/discussions/836 met 43 votes) heeft de HA directie er nog niet op gereageerd.
Dus ik denk dat we zelf wat moeten verzinnen willen we de historie van de kosten ontwikkeling in onze rapportages krijgen.
Er zijn drie opties:

1. We doen de rapportages en de kostenberekeningen in HA en ik sloop dat uit DAO
2. Gebruikers die klant zijn bij Tibber kunnen hun gebruiks- en kosten-info ophalen bij Tibber (vendor lockin)
3. Ik (of iemand met python-ervaring) ga iets bouwen in DAO waarmee de kwartierverbruiken en -productie worden opgehaald uit de short-term tabel van HA (die blijven daar maximaal 10 dagen) en sla de kwartierwaarden op in de DAO database.

Wat heeft jullie voorkeur?
Ik ben een discussie met een poll gestart op github:
https://github.com/corneel27/day-ahead/discussions/393
Breng jullie stem uit uiterlijk donderdag a.s., want als we zelf iets gaan maken moet het over uiterlijk 10 dagen (liefst iets eerder) klaar zijn.

[jbvo]

KC27 schreef op dinsdag 30 september 2025 @ 22:58:
[...]

Ik heb een fout bij het ophalen bij Tibber gevonden en gefixed.
Die fix komt in de volgende versie.

Als ik het goed zie is de wijziging voor kwartier prijzen pas in HA 2025.10 geïntegreerd?

https://github.com/home-a...805cc502540fcf89f72df50a2

[Mirabis]

@KC27 Als je "electric vehicle": [], instelt telt DAO dan nog wel "entities ev consumption" mee?

Ik regel het laden van mijn EV via een andere tool maar wil wel dat het de EV exclude voor baseload. Ik had eerder al een dummy entity gemaakt die altijd 'away' aangeeft maar af en toe probeert het de schakelaars ook an te passen. Ik wil juist de EV niet aansturen maar wel de consumption daarvan excluden.

[KC27]

Mirabis schreef op woensdag 1 oktober 2025 @ 00:11:
@KC27 Als je "electric vehicle": [], instelt telt DAO dan nog wel "entities ev consumption" mee?

Ik regel het laden van mijn EV via een andere tool maar wil wel dat het de EV exclude voor baseload. Ik had eerder al een dummy entity gemaakt die altijd 'away' aangeeft maar af en toe probeert het de schakelaars ook an te passen. Ik wil juist de EV niet aansturen maar wel de consumption daarvan excluden.

Als je de sensor die het verbruik van je laadpaal meet opneemt bij \report\entities ev consumption dan wordt het verbruik van die laadpaal niet meegenomen als baseload.

[Los Tigros]

Klopt het dat de Entsoe provider nog geen kwartier prijzen heeft? Het lukt mij alleen het binnen te halen via Nordpool...Overigens is Zonneplan nog niet over op kwartier prijzen. Benieuwd hoe lang ze het gaan uitstellen.

[ Voor 29% gewijzigd door Los Tigros op 01-10-2025 11:29 . Reden: Aanvulling ]

[KC27]

Los Tigros schreef op woensdag 1 oktober 2025 @ 11:24:
Klopt het dat de Entsoe provider nog geen kwartier prijzen heeft? Het lukt mij alleen het binnen te halen via Nordpool...Overigens is Zonneplan nog niet over op kwartier prijzen. Benieuwd hoe lang ze het gaan uitstellen.

Nee zou moeten werken (ik heb het gisteren nog getest).
Misschien moet je de datum invullen in het vanaf-veld?

[Martijn18]

Allereerst: wat een uitgebreide add-on!

Sinds kort heb ik twee Marstek-batterijen en ik probeer uit te vinden welke aansturing het beste werkt. Het AI-model van Marstek lijkt vooral te sturen op “0 op de meter”. De batterij wordt volgeladen bij overtollige stroom, maar er is geen gedrag waarbij de batterij in de ochtend of avond bij hoge prijzen volledig wordt ontladen.

Met DAO lijkt het allemaal wat statischer. Het charge/discharge-vermogen wijzigt niet erg frequent. Hierdoor wordt soms overtollige zonne-energie teruggeleverd terwijl de batterij nog niet vol is, of wordt er juist ’s nachts bijgeladen. Hierbij geldt dan ook dat er landurig wordt geladen met het "minmale" vermogen, ipv met de maximale 2500w.

Op dit moment voelt het Marstek-AI model prettiger dan DAO, maar wellicht kan ik dit ook berijken met DAO

Wat ik concreet zou willen bereiken:
1. Batterij laadt zoveel mogelijk met zonne-energie
2. Batterij verkoopt overtollige energie bij hoge prijzen (winst maximaliseren)
3. Batterij houdt voldoende energie over om de nacht (zonloze uren) door te komen

Addionele vragen:
1. Wat is de aanbevolen instelling bij gebruik van twee identieke batterijen? Twee losse batterijen in DAO, of zien als één totaalpakket en de berekende vermogens via HA verdelen over beide batterijen?
2. Zou het zinvol kunnen zijn om in DAO de “verkoopmomenten” te laten berekenen en de rest van de dag over te schakelen op het Marstek-AI model?

[KC27]

Zonet de laatste versie gepubliceerd versie 2025.10.2 (stabiel),2025.10.2.rc1 (testing).
Dit is waarschijnlijk de laatste keer dat ze tegelijk worden gepubliceerd. Vanaf nu ga ik eerst weer nieuwe aanpassingen laten testen in het testing-channel.
Dit staat er in de changelog:

Fixes:
- Fixed index-error when saving soc-forecast
- Fixed error using other landcode
- Fix error getting 15-min prices from Tibber

Know issue:
- The forecast in the reports still nog good working

[itavero]

Martijn18 schreef op woensdag 1 oktober 2025 @ 11:47:
Met DAO lijkt het allemaal wat statischer. Het charge/discharge-vermogen wijzigt niet erg frequent. Hierdoor wordt soms overtollige zonne-energie teruggeleverd terwijl de batterij nog niet vol is, of wordt er juist ’s nachts bijgeladen. Hierbij geldt dan ook dat er landurig wordt geladen met het "minmale" vermogen, ipv met de maximale 2500w.

Op dit moment voelt het Marstek-AI model prettiger dan DAO, maar wellicht kan ik dit ook berijken met DAO

Wat ik concreet zou willen bereiken:
1. Batterij laadt zoveel mogelijk met zonne-energie
2. Batterij verkoopt overtollige energie bij hoge prijzen (winst maximaliseren)
3. Batterij houdt voldoende energie over om de nacht (zonloze uren) door te komen

Ik pas in mijn Home Assistant automation dynamisch het (ont)laadvermogen aan op basis van het huisverbruik (of productie).
Dat wil zeggen, als hij moet laden en er wordt nog meer terug geleverd, dan verhoog ik tijdelijk het laadvermogen. Als hij moet ontladen en het huis verbruikt meer, dan verhoog ik tijdelijk het ontlaadvermogen.

Mijn automatisering en relevante entiteiten zien er zo uit:

Automatisering:

YAML:

alias: Sessy DF4K – DAO Aansturing
triggers:
  - trigger: state
    id: cfg_change
    entity_id:
      - input_select.dao_sessy_df4k_operating_mode
      - input_boolean.dao_balance_grid_sessy_df4k
  - trigger: state
    id: desired_change
    entity_id: sensor.battery_power_setpoint_calculated
  - trigger: time
    id: stop_time
    at: input_datetime.dao_stop_sessy_df4k
conditions: []
actions:
  - choose:
      - conditions:
          - condition: or
            conditions:
              - condition: template
                value_template: "{{ trig == 'stop_time' }}"
              - condition: template
                value_template: "{{ opmode != 'Aan' }}"
        sequence:
          - if:
              - condition: template
                value_template: "{{ current_strategy != 'idle' }}"
            then:
              - action: select.select_option
                target:
                  entity_id: select.sessy_df4k_power_strategy
                data:
                  option: idle
      - conditions:
          - condition: template
            value_template: "{{ opmode == 'Aan' and balance }}"
        sequence:
          - if:
              - condition: template
                value_template: "{{ current_strategy != 'nom' }}"
            then:
              - action: select.select_option
                target:
                  entity_id: select.sessy_df4k_power_strategy
                data:
                  option: nom
    default:
      - if:
          - condition: template
            value_template: "{{ opmode == 'Aan' and not balance }}"
        then:
          - if:
              - condition: template
                value_template: "{{ current_strategy != 'api' }}"
            then:
              - action: select.select_option
                target:
                  entity_id: select.sessy_df4k_power_strategy
                data:
                  option: api
          - if:
              - condition: template
                value_template: "{{ (desired - current_sp) | abs > 0 }}"
            then:
              - action: number.set_value
                target:
                  entity_id: number.sessy_df4k_power_setpoint
                data:
                  value: "{{ desired | int }}"
mode: queued
variables:
  opmode: "{{ states('input_select.dao_sessy_df4k_operating_mode') }}"
  balance: "{{ is_state('input_boolean.dao_balance_grid_sessy_df4k','on') }}"
  desired: "{{ states('sensor.battery_power_setpoint_calculated')|float(0) }}"
  current_sp: "{{ states('number.sessy_df4k_power_setpoint')|float(0) }}"
  current_strategy: "{{ states('select.sessy_df4k_power_strategy') }}"
  trig: "{{ trigger.id if trigger is defined else 'unknown' }}"
max: 2

Templated sensor om gewenste setpoint te berekenen:
De *_recent_max en *_recent_min zijn statistieken helper entiteiten die het maximum/minimum van de laatste 15 seconden bevatten van de helper entiteit die het vermogen van de woning (zonder de batterij) bevat (zie hieronder)

code:

{% set dao = states('input_number.dao_sessy_df4k_from_battery')|float(0) %}
{% if dao == 0 %}
0
{% else %}
  {% set round_factor = 50 %}
  {# Helpers over de recente historie: max = import (>0), min = export (<0) #}
  {% set imp_peak = states('sensor.grid_power_excl_battery_recent_max')|float(-1.0) %}
  {% set exp_peak = states('sensor.grid_power_excl_battery_recent_min')|float(1.0) %}
  
  {# Veiligstellen van tekenconventie #}
  {% if imp_peak < 0 %}{% set imp_peak = 0 %}{%else%}{% set imp_peak = ((imp_peak/round_factor)|round(0, 'ceil') * round_factor) %}{% endif %}
  {% if exp_peak > 0 %}{% set exp_peak = 0 %}{%else%}{% set exp_peak = ((exp_peak/round_factor)|round(0, 'floor') * round_factor) %}{% endif %}
  
  {% set cap_pos = 1800 %}
  {% set cap_neg = -2200 %}
  
  {% if dao > 0 %}
    {# ONTLADEN: neem max(DAO, import-piek). Rond OMHOOG naar veelvoud van 50 W. #}
    {% set result = [dao, imp_peak]|max %}
  {% else %}
    {# LADEN: neem min(DAO, export-piek) (beiden negatief). Rond OMLAAG naar veelvoud van 50 W. #}
    {% set result = [dao, exp_peak]|min %}
  {% endif %}
  {{ [[result, cap_pos]|min, cap_neg]|max | int }}
{% endif %}

Vermogen huisaansluiting zonder batterij
Erg simpele templated sensor, maar handig in de berekeningen..

code:

{{ (states('sensor.sessy_df4k_power')|float(0) + states('sensor.sessy_pfuv_p1_power')|float(0)) }}

Wat betreft je andere vraag..

Martijn18 schreef op woensdag 1 oktober 2025 @ 11:47:
1. Wat is de aanbevolen instelling bij gebruik van twee identieke batterijen? Twee losse batterijen in DAO, of zien als één totaalpakket en de berekende vermogens via HA verdelen over beide batterijen?

De batterijen samenvoegen tot 1 is wel de meest efficiënte manier om de berekeningen te doen begrijp ik uit eerdere posts in dit topic.

[ Voor 16% gewijzigd door itavero op 01-10-2025 12:46 . Reden: Helper entiteiten in HA ook toegevoegd ]

[Mirabis]

KC27 schreef op woensdag 1 oktober 2025 @ 09:06:
[...]

Als je de sensor die het verbruik van je laadpaal meet opneemt bij \report\entities ev consumption dan wordt het verbruik van die laadpaal niet meegenomen als baseload.

Dubbel check: OOK als je geen electric vehicle gedefinieerd hebt (dus : [ ])?

[Skevdude]

KC27 schreef op woensdag 1 oktober 2025 @ 11:52:
Zonet de laatste versie gepubliceerd versie 2025.10.2 (stabiel),2025.10.2.rc1 (testing).
Dit is waarschijnlijk de laatste keer dat ze tegelijk worden gepubliceerd. Vanaf nu ga ik eerst weer nieuwe aanpassingen laten testen in het testing-channel.
Dit staat er in de changelog:

[...]

Ik krijg met 2025.10.2 weer een nieuw soort error:

code:

2025-10-01 13:06:22 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 1068, in calc_optimum
    df_boiler = pd.DataFrame(
                ^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/frame.py", line 782, in __init__
    mgr = dict_to_mgr(data, index, columns, dtype=dtype, copy=copy, typ=manager)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 503, in dict_to_mgr
    return arrays_to_mgr(arrays, columns, index, dtype=dtype, typ=typ, consolidate=copy)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 114, in arrays_to_mgr
    index = _extract_index(arrays)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 677, in _extract_index
    raise ValueError("All arrays must be of the same length")
ValueError: All arrays must be of the same length
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3869, in main
    da_calc.run_task_function("calc_optimum")
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 1068, in calc_optimum
    df_boiler = pd.DataFrame(
                ^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/frame.py", line 782, in __init__
    mgr = dict_to_mgr(data, index, columns, dtype=dtype, copy=copy, typ=manager)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 503, in dict_to_mgr
    return arrays_to_mgr(arrays, columns, index, dtype=dtype, typ=typ, consolidate=copy)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 114, in arrays_to_mgr
    index = _extract_index(arrays)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 677, in _extract_index
    raise ValueError("All arrays must be of the same length")
ValueError: All arrays must be of the same length

Enig idee? Of een bugje? 10.1 werkte prima.

[KC27]

Skevdude schreef op woensdag 1 oktober 2025 @ 13:11:
[...]


Ik krijg met 2025.10.2 weer een nieuw soort error:

code:

2025-10-01 13:06:22 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 1068, in calc_optimum
    df_boiler = pd.DataFrame(
                ^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/frame.py", line 782, in __init__
    mgr = dict_to_mgr(data, index, columns, dtype=dtype, copy=copy, typ=manager)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 503, in dict_to_mgr
    return arrays_to_mgr(arrays, columns, index, dtype=dtype, typ=typ, consolidate=copy)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 114, in arrays_to_mgr
    index = _extract_index(arrays)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 677, in _extract_index
    raise ValueError("All arrays must be of the same length")
ValueError: All arrays must be of the same length
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3893, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3869, in main
    da_calc.run_task_function("calc_optimum")
  File "/root/dao/prog/da_base.py", line 594, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/webserver/../prog/day_ahead.py", line 1068, in calc_optimum
    df_boiler = pd.DataFrame(
                ^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/frame.py", line 782, in __init__
    mgr = dict_to_mgr(data, index, columns, dtype=dtype, copy=copy, typ=manager)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 503, in dict_to_mgr
    return arrays_to_mgr(arrays, columns, index, dtype=dtype, typ=typ, consolidate=copy)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 114, in arrays_to_mgr
    index = _extract_index(arrays)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.12/site-packages/pandas/core/internals/construction.py", line 677, in _extract_index
    raise ValueError("All arrays must be of the same length")
ValueError: All arrays must be of the same length

Enig idee? Of een bugje? 10.1 werkte prima.

Dank voor de melding!
De prijzen waren vandaag weer te laat.
Dan gaat het fout bij de berekening.
Haal ze nog eens handmatig op dan zal ie wel goed rekenen.

[KC27]

Mirabis schreef op woensdag 1 oktober 2025 @ 13:03:
[...]


Dubbel check: OOK als je geen electric vehicle gedefinieerd hebt (dus : [ ])?

Ik heb het voor jouw nog even opgezocht in de code: zeker weten bij de berekening van de baseload kijkt DAO naar de sensors die jij opgeeft op bij \report\entities ev consumption

[balk]

Martijn18 schreef op woensdag 1 oktober 2025 @ 11:47:
Allereerst: wat een uitgebreide add-on!

Sinds kort heb ik twee Marstek-batterijen en ik probeer uit te vinden welke aansturing het beste werkt. Het AI-model van Marstek lijkt vooral te sturen op “0 op de meter”. De batterij wordt volgeladen bij overtollige stroom, maar er is geen gedrag waarbij de batterij in de ochtend of avond bij hoge prijzen volledig wordt ontladen.

Met DAO lijkt het allemaal wat statischer. Het charge/discharge-vermogen wijzigt niet erg frequent. Hierdoor wordt soms overtollige zonne-energie teruggeleverd terwijl de batterij nog niet vol is, of wordt er juist ’s nachts bijgeladen. Hierbij geldt dan ook dat er landurig wordt geladen met het "minmale" vermogen, ipv met de maximale 2500w.

Op dit moment voelt het Marstek-AI model prettiger dan DAO, maar wellicht kan ik dit ook berijken met DAO

Wat ik concreet zou willen bereiken:
1. Batterij laadt zoveel mogelijk met zonne-energie
2. Batterij verkoopt overtollige energie bij hoge prijzen (winst maximaliseren)
3. Batterij houdt voldoende energie over om de nacht (zonloze uren) door te komen

Addionele vragen:
1. Wat is de aanbevolen instelling bij gebruik van twee identieke batterijen? Twee losse batterijen in DAO, of zien als één totaalpakket en de berekende vermogens via HA verdelen over beide batterijen?
2. Zou het zinvol kunnen zijn om in DAO de “verkoopmomenten” te laten berekenen en de rest van de dag over te schakelen op het Marstek-AI model?

Naast wat Itavero al aanstipte: DAO geeft slechts een 'getal'. Wat je er mee doet is aan jou. Als je 'laden met 2000W' krijgt kun je dat ook op je meter toepassen. Jouw batterij zal dan 2000+zon proberen bij te houden. Vermits je de aansturing op orde hebt.

Ik laad de accu met het getal dat van dao komt maar bij 0 ga ik op NoM stand. Beetje hybride dus. In de avond na de piek ga ik niet lager dan 20%, doorgaans genoeg om de nacht door te komen.

[Martijn18]

Dank voor jullie tips. Inmiddels terug naar 1 batterij in de configuratie.
Nog 1 vraag nav het onderstaande:

code:

2025-10-01 19:10:27 info: Doorzetten van alle settings naar HA
2025-10-01 19:10:27 info: Grid set point: -4560.0 W
2025-10-01 19:10:27 info: Cycle cost Marstek Venus: 0.64 euro
2025-10-01 19:10:27 info: Netto vermogen naar(+)/uit(-) omvormer Marstek Venus: -4880 W
2025-10-01 19:10:27 info: Balanceren: False
2025-10-01 19:10:27 info: Vermogen uit batterij: 5000W
2025-10-01 19:10:27 info: Vermogen dat binnenkomt van pv: 0W
2025-10-01 19:10:27 info: Vermogen dat binnenkomt van ac: -5000W
2025-10-01 19:10:27 info: Waarde SoC na eerste uur: 68.2%

In de batterij config wordt een maximale charge/discharge stage gevraagd.
Aangezien mijn batterijen max 2500 kunnen chargen/dischargen, heb ik hier 5000 ingevuld. Dit komt overeen met "vermogen uit batterij".

Echter stuurt DAO -4880 door naar HA. Het lijkt veroorzaakt te worden doordat er nog een klein beetje zonne energie wordt opgewekt die wordt afgetrokken(?) van die 5000.

M.a.w. hoe zorg ik er voor dat er op dit tijdstip "maximaal" wordt ontladen?

[KC27]

Heb je het vermogen vanaf dc_to_bat niet begrensd op 5000W.
Die zou ik dan iets hoger zetten (rekening houdend met het conversie-verlies van je omvormer)

[Martijn18]

Update - komt uit deze setting

code:

 { "power": 5000, "efficiency": 0.976 }

Komt door deze setting: dit is precies 4880

[ Voor 81% gewijzigd door Martijn18 op 01-10-2025 20:04 ]