Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[KC27]

Dogooder schreef op dinsdag 12 mei 2026 @ 21:51:
[...]

Om er zelf nog even in te duiken en ook om beter toe te lichten heb ik de rekentijden uit alle logs getrokken en in een grafiek geplot.

[Afbeelding] Voor 8 mei waren de rekentijden eigenlijk altijd onder de seconde. Je ziet mooi de rekentijd afnemen totdat de nieuwe prijzen zijn opgehaald. Maar sinds gisteren is zonder aanleiding het hek van de dam met rekentijden structureel meer dan 300 seconden.
Ik heb nu de max-gap naar 0.1 bijgesteld, en dat zal vast wat helpen. Maar misschien ook wel verhullen wat hier fout gaat. Restart van de docker mocht ook niet echt baten. Ik draai 2026.4.4 al sinds 2026-04-25.

Zou het iets in de prijsdata of solardata kunnen zijn geweest?

Ik weet ook niet wat er bij jou aan de hand is. Bij mij gebeurde dit een paar weken terug en nu komen de oude snelle rekentijden weer terug.
Ik hoorde het ook van @tonvanboven (maar dat was "oude" hardware), dus je bent niet de enige.
Ik heb ook nog een suggestie van @tonvanboven op mijn to-do lijstje staan, om alle resultaten van de laatste berekening voor de volgende periode op te slaan in een bestand en deze waarden/settings bij het begin van die volgende periode (als de berekening wordt gestart) als "eerste orde benadering" naar HA te communiceren. Als dan de berekening twee minuten duurt is HA alvast begonnen en kan dit eventueel worden aangepast met de laatste resultaten.
Deze kan ook interessant zijn als we gaan rekenen met een of meer dagen voorspellingen van de day-ahead-prijzen, want dan zullen de rekentijden sowieso flink oplopen.

[KC27]

atimmerman schreef op dinsdag 12 mei 2026 @ 22:54:
[...]

Report,balans,gisteren

code:

Uur Verbruik    Productie   Accu_uit    Accu in PV ac   Elec. vehicle   WP  Boiler  Machines    Baseload
kWh kWh kWh kWh kWh kWh kWh kWh kWh kWh
00:00   0.003   0.003   0.160   0.000   0.000   0.000   0.009   0.000   0.000   0.151
01:00   0.003   0.002   0.165   0.000   0.000   0.000   0.009   0.000   0.000   0.157
02:00   0.003   0.003   0.160   0.000   0.000   0.000   0.009   0.000   0.000   0.151
03:00   0.003   0.002   0.157   0.000   0.000   0.000   0.009   0.000   0.000   0.149
04:00   0.003   0.004   0.165   0.000   0.000   0.000   0.009   0.000   0.000   0.155
05:00   0.003   0.002   0.159   0.000   0.000   0.000   0.009   0.000   0.000   0.151
06:00   0.015   0.026   0.077   0.011   0.091   0.000   0.009   0.000   0.000   0.137
07:00   0.080   0.072   0.750   0.004   0.348   0.000   0.879   0.000   0.000   0.223
08:00   0.104   0.032   0.960   0.000   0.455   0.000   1.105   0.000   0.000   0.382
09:00   0.251   0.037   1.040   0.120   0.978   0.000   0.516   0.000   0.000   1.596
10:00   0.048   0.157   0.040   1.120   1.814   0.000   0.010   0.000   0.000   0.615
11:00   0.045   0.082   0.330   0.070   1.015   0.000   0.868   0.000   0.000   0.370
12:00   0.029   0.077   0.010   0.230   0.526   0.000   0.006   0.000   0.000   0.252
13:00   0.465   0.164   0.210   0.365   2.230   0.000   0.868   0.000   0.000   1.508
14:00   0.059   0.923   0.000   1.664   3.481   0.000   0.008   0.000   0.000   0.945
15:00   0.101   0.726   0.090   0.658   2.284   0.000   0.760   0.000   0.000   0.331
16:00   0.269   0.738   0.060   0.824   2.659   0.000   0.012   0.000   0.000   1.414
17:00   0.105   0.491   0.200   1.140   2.666   0.000   0.774   0.000   0.000   0.566
18:00   0.067   0.268   0.080   1.010   2.047   0.000   0.009   0.000   0.000   0.907
19:00   0.055   0.081   0.070   0.393   0.690   0.000   0.009   0.000   0.000   0.332
20:00   0.182   0.014   1.080   0.000   0.110   0.000   1.059   0.000   0.000   0.299
21:00   0.527   0.002   0.475   0.000   0.000   0.000   0.606   0.000   0.000   0.394
22:00   0.179   0.002   0.615   0.000   0.000   0.000   0.374   0.000   0.000   0.418
23:00   0.004   0.004   0.295   0.000   0.000   0.000   0.009   0.000   0.000   0.286
Totaal  2.603   3.912   7.348   7.609   21.394  0.000   7.934   0.000   0.000   11.890

baseload_0:

JSON:

[
  0.151,
  0.157,
  0.151,
  0.149,
  0.155,
  0.151,
  39.098,
  140.083,
  215.167,
  762.834,
  1239.375,
  388.981,
  198.054,
  822.686,
  1124.82,
  635.695,
  707.707,
  414.152,
  223.684,
  106.226,
  26.273,
  0.394,
  0.418,
  0.286
]

Dank je wel.
Ik ga ernaar kijken.

Edit:
Ik heb ernaar gekeken en het blijkt dat de baseload berekening toch niet corrigeert voor Wh, MWh enz.
Ik dacht dat hij hetzelfde stuk code daarvoor gebruikte als voor de rapportage,
Ik ga het in de volgende versie aanpassen.
Dank voor het melden!

[ Voor 5% gewijzigd door KC27 op 12-05-2026 23:14 ]

[hemertje]

thomvh schreef op dinsdag 12 mei 2026 @ 22:58:
[...]

Laat je balance report van gister eens zien.

[thomvh]

hemertje schreef op dinsdag 12 mei 2026 @ 23:27:
[...]


[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Ik bedoel wat er onder reports. Bij balance staat. Hier zie je de baseload waardes.

[hemertje]

thomvh schreef op woensdag 13 mei 2026 @ 07:56:
[...]

Ik bedoel wat er onder reports. Bij balance staat. Hier zie je de baseload waardes.

ah zo...

[ Voor 37% gewijzigd door hemertje op 13-05-2026 08:16 ]

[thomvh]

hemertje schreef op woensdag 13 mei 2026 @ 08:14:
[...]


ah zo...

[Afbeelding]

[Afbeelding]

[Afbeelding]

Ja het gaat dus puur mis in de baseload berekening. Dit moet je zelf overwegen maar misschien kun je tijdelijk de baseload calculatie periode omlaag zetten? Waardoor deze verkeerde waardes wegvallen?

[Undertilted]

Hier gaat toch wel iets grondig mis...

[Undertilted]

2026-05-13 11:59:25 INFO: Configuration needs migration from unversioned to v0
2026-05-13 11:59:25 INFO: Saved backup configuration to ../data/options_unversioned.json
2026-05-13 11:59:25 INFO: Migrating unversioned configuration to v0
2026-05-13 11:59:25 INFO: Added config_version=0 to unversioned configuration
2026-05-13 11:59:25 INFO: Migrated scheduler: active=True, 14 schedule entries
2026-05-13 11:59:25 INFO: Coerced boiler.boiler present from 'False' to boolean
2026-05-13 11:59:25 INFO: Coerced heating.heater present from 'False' to boolean
2026-05-13 11:59:25 INFO: Configuration at version 0
2026-05-13 11:59:25 ERROR: Configuratie kon niet worden geladen: 1 validation error for ConfigurationV0
prices.vat consumption
Value error, VAT percentage must be between 0 and 100, got -6.0 for date 2022-04-01 [type=value_error, input_value={'2022-04-01': -6}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.13/v/value_error
Traceback (most recent call last):
File "/root/dao/webserver/../prog/day_ahead.py", line 4708, in <module>
main()
~~~~^^
File "/root/dao/webserver/../prog/day_ahead.py", line 4668, in main
da_calc = DaCalc("../data/options.json")
File "/root/dao/webserver/../prog/day_ahead.py", line 30, in __init__
if self.config is None:
^^^^^^^^^^^
AttributeError: 'DaCalc' object has no attribute 'config'. Did you mean: '_config'?

Ik heb dus de negatieve VAT nodig om de multiplier van belpex er in te krijgen.

[thomvh]

Undertilted schreef op woensdag 13 mei 2026 @ 12:02:
[...]


Ik heb dus de negatieve VAT nodig om de multiplier van belpex er in te krijgen.

Kun je die niet aan de supplier cost toevoegen? Die mag volgens mij wel negatief zijn.

[Undertilted]

Neen, dit moet een vermenigvuldiging zijn.

De multiplier is negatief bij terugleveren in België. De enige manier om dat in de formule te krijgen is met een negatieve btw.

Beste zou zijn om de prijzen uit te lezen via HA.

[ Voor 13% gewijzigd door Undertilted op 13-05-2026 12:12 ]

[thomvh]

Undertilted schreef op woensdag 13 mei 2026 @ 12:11:
Neen, dit moet een vermenigvuldiging zijn.

De multiplier is negatief bij terugleveren in België. De enige manier om dat in de formule te krijgen is met een negatieve btw.

Beste zou zijn om de prijzen uit te lezen via HA.

Ik gok dat je het beste een feature request op Github kunt indienen. Want ik snap de aanname dat BTW niet negatief mag zijn wel. Misschien is het uberhaupt beter om een mulitplier toe te voegen dan wordt die berekening vanzelf flexibeler.

[Beekforel]

Ik heb een tweede programma toegevoegd aan een "machine" maar nu wordt het niet meer ingepland.

Heb ik iets fout gedaan?

JSON:

  "machines": [
    {
      "name": "ariston_boost",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "boost-1",
          "power": [
            1300.0,
            1300.0,
            1300.0,
            1300.0
          ]
        },
        {
          "name": "boost-2",
          "power": [
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.dao_ariston_boost_start_window",
      "entity_end_window": "input_datetime.dao_ariston_boost_end_window",
      "entity_selected_program": "input_select.dao_ariston_boost_selected_program",
      "entity_calculated_start": "input_datetime.dao_ariston_boost_calculated_start",
      "entity_calculated_end": "input_datetime.dao_ariston_boost_calculated_end"
    }
  ],

Ik zie het iig niet. Alle drie de opties zijn beschikbaar op de input_select.

Oooo ik had het verkeerd begrepen. Ik dacht dat wanneer ik een tweede programma maak, DAO meer keuze had. Maar dat is niet zo, ik moet zelf kiezen welk programma hij gaat plannen. Moet ik dan een tweede machine entry maken om dit te realiseren?

Het is mijn boiler, mijn gedachte was: als er weinig stroom beschikbaar is dan een uurtje inplannen en als er genoeg is dan kan hij twee uren inplannen.

[ Voor 14% gewijzigd door Beekforel op 13-05-2026 12:57 ]

[KC27]

Beekforel schreef op woensdag 13 mei 2026 @ 12:50:
Ik heb een tweede programma toegevoegd aan een "machine" maar nu wordt het niet meer ingepland.

Heb ik iets fout gedaan?

JSON:

  "machines": [
    {
      "name": "ariston_boost",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "boost-1",
          "power": [
            1300.0,
            1300.0,
            1300.0,
            1300.0
          ]
        },
        {
          "name": "boost-2",
          "power": [
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0,
            1300.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.dao_ariston_boost_start_window",
      "entity_end_window": "input_datetime.dao_ariston_boost_end_window",
      "entity_selected_program": "input_select.dao_ariston_boost_selected_program",
      "entity_calculated_start": "input_datetime.dao_ariston_boost_calculated_start",
      "entity_calculated_end": "input_datetime.dao_ariston_boost_calculated_end"
    }
  ],

Ik zie het iig niet. Alle drie de opties zijn beschikbaar op de input_select.

Oooo ik had het verkeerd begrepen. Ik dacht dat wanneer ik een tweede programma maak, DAO meer keuze had. Maar dat is niet zo, ik moet zelf kiezen welk programma hij gaat plannen. Moet ik dan een tweede machine entry maken om dit te realiseren?

Het is mijn boiler, mijn gedachte was: als er weinig stroom beschikbaar is dan een uurtje inplannen en als er genoeg is dan kan hij twee uren inplannen.

Bij lage prijzen kun je in Home Assistant de waarde van de sensor die je bij "entity_setpoint" hebt opgegeven ophogen: dan gaat hij vanzelf langer stoken. Omgekeerd kun je bij hoge prijzen die waarde ook verlagen (zolang er maar geen ijspegels uit je douchekop komen )
Of als je dat toch met een machine wilt doen: dan laat je een automation in HA het programma selecteren op basis van de prijs.

[ Voor 3% gewijzigd door KC27 op 13-05-2026 13:23 ]

[Beekforel]

KC27 schreef op woensdag 13 mei 2026 @ 13:22:
[...]

Bij lage prijzen kun je in Home Assistant de waarde van de sensor die je bij "entity_setpoint" hebt opgegeven ophogen: dan gaat hij vanzelf langer stoken. Omgekeerd kun je bij hoge prijzen die waarde ook verlagen (zolang er maar geen ijspegels uit je douchekop komen )
Of als je dat toch met een machine wilt doen: dan laat je een automation in HA het programma selecteren op basis van de prijs.

Ok zoiets zat ik ook al te denken inderdaad.

Het stuurt de "boost" modus aan, de boiler zelf zorgt dat er altijd wel voldoende warm water is (dat laat zich minder goed sturen). Kan wel een automation maken die keuze maakt uit 1 van de drie waardes obv de voorspelling van die dag.

[DirkB19]

Goede middag KC27,

In December sprak u dat "In de pipeline zit een aanpassing zodat een gebruiker de formule en de componenten in die formule voor de tariefberekening helemaal zelf kan invullen."

Is hier al evolutie in?

Voor mijn situatie in Belgie moet ik voorlopig nog negatieve VAT kunnen invullen maar daar loopt hij nu op vast:

2026-05-11 12:16:33 ERROR: Configuratie kon niet worden geladen: Configuration validation failed:

• prices → vat_consumption: Value error, VAT percentage must be between 0 and 100, got -88.6792 for date 2026-05-11

• prices → vat_production: Value error, VAT percentage must be between 0 and 100, got -90.0 for date 2026-05-11

Alvast dank !

[Undertilted]

thomvh schreef op woensdag 13 mei 2026 @ 12:14:
[...]

Ik gok dat je het beste een feature request op Github kunt indienen. Want ik snap de aanname dat BTW niet negatief mag zijn wel. Misschien is het uberhaupt beter om een mulitplier toe te voegen dan wordt die berekening vanzelf flexibeler.

Heb ik gedaan ondertussen. En ook in de code in mijn docker de limiet op -100 ipv 0 gezet.

@DirkB19 ook voor jou interessant.

[hemertje]

thomvh schreef op woensdag 13 mei 2026 @ 09:10:
[...]

Ja het gaat dus puur mis in de baseload berekening. Dit moet je zelf overwegen maar misschien kun je tijdelijk de baseload calculatie periode omlaag zetten? Waardoor deze verkeerde waardes wegvallen?

heb je een tip voor me waar ik daarover meer informatie kan vinden hoe dit uit te voeren?

[Beekforel]

KC27 schreef op woensdag 13 mei 2026 @ 13:22:
[...]

Bij lage prijzen kun je in Home Assistant de waarde van de sensor die je bij "entity_setpoint" hebt opgegeven ophogen: dan gaat hij vanzelf langer stoken. Omgekeerd kun je bij hoge prijzen die waarde ook verlagen (zolang er maar geen ijspegels uit je douchekop komen )
Of als je dat toch met een machine wilt doen: dan laat je een automation in HA het programma selecteren op basis van de prijs.

Wat ik niet helemaal voorzien had: als hij een korter programma heeft, kan hij ook 2 keer worden ingepland blijkbaar.

[TheMystery]

KC27 schreef op dinsdag 12 mei 2026 @ 22:24:
[...]

Ga ik even over nadenken ... als ik nou niks te doen had
Je mag altijd een PR indienen in Github.

[...]

DAO neemt nu standaard de solar-data van de laatste drie jaar.
Dus als je twee jaar geleden je pv-installatie hebt uitgebreid nog een jaar.

Oké, ik heb een issue aangemaakt op GitHub. Voor nu is dan denk ik beste om ml_prediction op false te zetten dan pakt hij neem ik aan de waarde van dao die dichter bij de waarheid ligt?

[KC27]

Undertilted schreef op woensdag 13 mei 2026 @ 17:56:
[...]

Heb ik gedaan ondertussen. En ook in de code in mijn docker de limiet op -100 ipv 0 gezet.

@DirkB19 ook voor jou interessant.

@DirkB19 @Undertilted
Zijn jullie voorlopig geholpen als er een optionele multiplier komt (float die alle waarden mag hebben, default waarde=1), waarmee de day ahead prijs wordt vermenigvuldigd?
Zoja moet die in de tijd aanpasbaar zijn?

[diamanten]

Beste tweakers, sinds enkele weken heb ik de Smart-EVSE module in gebruik voor mijn laadpaal. Deze ondersteunt zowel 1F als 3F laden naast solar en smart modes. Zijn er andere tweakers die deze module ook gebruiken in combinatie met DAO en wat tips kunnen geven?

[ Voor 5% gewijzigd door diamanten op 14-05-2026 09:24 ]

[rescla]

diamanten schreef op donderdag 14 mei 2026 @ 09:18:
Beste tweakers, sinds enkele weken heb ik de Smart-EVSE module in gebruik voor mijn laadpaal. Deze ondersteunt zowel 1F als 3F laden naast solar en smart modes. Zijn er andere tweakers die deze module ook gebruiken in combinatie met DAO?

Zeker. Ik hebruik hem met deze firmware: https://github.com/SmartEVSE/SmartEVSE-3 en heb hem gekoppeld via MQTT en de HACS integratie https://github.com/dingo35/ha-SmartEVSEv3. MQTT is makkelijker, maar daar zijn niet alle opties beschikbaar. De integratie heeft wat meer opties.

[diamanten]

rescla schreef op donderdag 14 mei 2026 @ 09:27:
[...]

Zeker. Ik hebruik hem met deze firmware: https://github.com/SmartEVSE/SmartEVSE-3 en heb hem gekoppeld via MQTT en de HACS integratie https://github.com/dingo35/ha-SmartEVSEv3. MQTT is makkelijker, maar daar zijn niet alle opties beschikbaar. De integratie heeft wat meer opties.

Die heb ik inmiddels ook draaien. Hoe ziet jij DAO-config eruit voor wat betreft het EV-gedeelte? Ik ben met name benieuwd hoe je het omschakelen van 3F -> 1F en vice versa door DAO kan optimaliseren.