• simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
Karpertje schreef op dinsdag 24 maart 2026 @ 12:59:
[...]


Dat zou top zijn als windsnelheid alsnog toegevoegd wordt. Ik zit alleen wel met het punt dat het model anders misschien ook windenergie gaat berekenen op momenten dat het gewoon windstil is en alleen de zon schijnt. Daarom zou het mooi zijn als je in het ML-model ook alleen wind apart kunt selecteren.
Dat zou niet mogen. In jouw geval heeft zonlicht geen invloed op de windopwek. Dus zou die als feature insignificant worden (nets als dat windsnelheid insignificant is voor PV).
Het enige wat ik vooraf niet kan beoordelen is of het model rekening houdt met een minimale windsnelheid. Ik vermoed van wel, xgboost is slim genoeg.

  • BBuilds
  • Registratie: November 2013
  • Laatst online: 23:32
Sinds de prijzen van vanmiddag gepubliceerd zijn kan DAO geen oplossing vinden.
Geeft het na 0.01 sec rekentijd ook op met rekenen.

Heb een update gedaan van 2026.02.02 naar 2026.03.02 maar dit geeft hetzelfde resultaat.
Verrassend want heb al maanden niks aan de config veranderd of toegevoegd, en al maanden ook geen problemen gehad met het berekenen van een oplossing.

Config
Log berekening met debug

Iemand die hier nog tegenaan loopt?

[ Voor 6% gewijzigd door BBuilds op 24-03-2026 13:43 ]


  • Karpertje
  • Registratie: Januari 2013
  • Laatst online: 06-05 14:37
simnet schreef op dinsdag 24 maart 2026 @ 13:33:
[...]

Dat zou niet mogen. In jouw geval heeft zonlicht geen invloed op de windopwek. Dus zou die als feature insignificant worden (nets als dat windsnelheid insignificant is voor PV).
Het enige wat ik vooraf niet kan beoordelen is of het model rekening houdt met een minimale windsnelheid. Ik vermoed van wel, xgboost is slim genoeg.
Helder. Dan ben ik wel benieuwd hoe dat in het model precies berekend wordt. Vooral of het model echt leert dat bij lage of vrijwel nul windsnelheid de windopwek ook naar nul gaat, en niet via historische samenhang met zonnige dagen toch nog iets blijft voorspellen.

  • itavero
  • Registratie: Oktober 2004
  • Laatst online: 05-05 21:51
simnet schreef op dinsdag 24 maart 2026 @ 00:03:
[...]

Je hebt hiervoor meetspoelen nodig bij de hoofdaansluiting. Vervolgens kun je het configureren in enlighten manager. Zeker niet het makkelijkste klusje. Als je het wilt automatiseren heb je een relais nodig om direct op de envoy aan te sluiten op de binaire ingangen.
Ik heb zelf die spoelen (nog) niet, dus ik kan ze alleen aan/uit zetten. Dat doenik ook met een relais op een binair contact van de envoy. Zodat ik niet afhankelijk ben van hun waardeloze cloud omgeving.
Die spoelen heb ik en heb ook al een relais om ze helemaal uit te zetten (via de DRM0 interface).
Binnenkort eens in duiken hoe ik dat verder kan inregelen.

  • itavero
  • Registratie: Oktober 2004
  • Laatst online: 05-05 21:51
Torch1969 schreef op maandag 23 maart 2026 @ 21:47:
[...]

Kijk of er (grote) verbruikers (of leveranciers) van energie zijn die niet niet heel periodiek rapporteren en dan net ná het uur rapporteren. Bijvoorbeeld een laadpaal die eens per 15 minuten rapporteert (en dat waarschijnlijk net steeds een paar seconden na dat kwartier doet). De p1 meter ziet het verbruik “meteen”, maar de bijbehorende verbruiker komt dan in het volgende uur. Dit levert een verbruik op dat out of sync is qua uur.
Als ik vanuit het energiedashboard in HA kijk, en doorklik naar de individuele sensoren, zie ik voor elke sensor gewoon "fijnmazig" (in die pop-up is het dan per 5 minuten) nieuwe data.
KC27 schreef op maandag 23 maart 2026 @ 23:27:
[...]

Aangezien de negatieve getallen overdag plaatsvinden zou ik het probleem toch zoeken in de pv productie.
Als je nu kijkt met reports/balans naar de opwekking van gisteren. In hoeverre klopt die met de opwekking zoals gerapporteerd in het energie-dashboard van HA?
Ik zie zelfs dat als je sommeert per dag dat je nog negatief uitkomt.
In welke eenheden rapporteert "sensor.envoy_122251081559_lifetime_energy_production"?
Die rapporteert in MWh.
Als ik naar gisteren kijk zie ik geen negatieve getallen onder verbruik in de report van DAO, maar ik zie wel een viertal uren waar het verbruik nihil is.
Dit is onmogelijk aangezien mijn standby verbruik al rond de 300 a 400W zit.

In het dashboard van HA zie ik dit niet terug.
Enige wat mij aan die uren zo direct opvalt is dat er eigenlijk geen afname van het net is.
Alle stroom komt uit de accu of zonnepanelen (op 1 uur na, waar er slechts 0.003 kWh uit het net komt).

Ik zal binnenkort eens kjiken of ik de data die DAO gebruikt kan exporteren en zelf de analyse lokaal kan draaien.

  • Noshi
  • Registratie: Januari 2007
  • Laatst online: 06:42
BBuilds schreef op dinsdag 24 maart 2026 @ 13:42:
Sinds de prijzen van vanmiddag gepubliceerd zijn kan DAO geen oplossing vinden.
Geeft het na 0.01 sec rekentijd ook op met rekenen.

Heb een update gedaan van 2026.02.02 naar 2026.03.02 maar dit geeft hetzelfde resultaat.
Verrassend want heb al maanden niks aan de config veranderd of toegevoegd, en al maanden ook geen problemen gehad met het berekenen van een oplossing.

Config
Log berekening met debug

Iemand die hier nog tegenaan loopt?
Niet perse nu, maar ook ik heb soms dat DAO een uurtje geen oplossing kan vinden. Soms heeft DAO ook moeite met een oplossing halverwege het uur, e.g. als ik wat aan het debuggen ben.

[ Voor 5% gewijzigd door Noshi op 24-03-2026 14:56 ]

Karpertje schreef op dinsdag 24 maart 2026 @ 12:59:
[...]


Dat zou top zijn als windsnelheid alsnog toegevoegd wordt. Ik zit alleen wel met het punt dat het model anders misschien ook windenergie gaat berekenen op momenten dat het gewoon windstil is en alleen de zon schijnt. Daarom zou het mooi zijn als je in het ML-model ook alleen wind apart kunt selecteren.
Daar hoef je niet bang voor te zijn. Tijdens de training van het model worden de variabelen die geen invloed hebben op de uitkomst vanzelf uitgerangeerd. Dat is juist het mooie van dit soort ml-technieken.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • BBuilds
  • Registratie: November 2013
  • Laatst online: 23:32
Noshi schreef op dinsdag 24 maart 2026 @ 14:55:
[...]

Niet perse nu, maar ook ik heb soms dat DAO een uurtje geen oplossing kan vinden. Soms heeft DAO ook moeite met een oplossing halverwege het uur, e.g. als ik wat aan het debuggen ben.
Bedankt voor je reactie. Nu toch al reeds 3 uur aan eens stuk dat DAO geen oplossing kan vinden.
Heb gezien dat de prijzen voor vannacht en morgen overdag vrij laag zijn. Kan het daar wat mee te maken hebben?

Hoe kan ik dat debuggen? Heb de config in maanden niet aangeraakt en geen probleem gehad, en sinds de nieuwe prijzen van vanmiddag kan hij geen oplossing meer berekenen.
Laatste berekening die werkte was om 12h45

  • rescla
  • Registratie: November 2012
  • Laatst online: 06:52
BBuilds schreef op dinsdag 24 maart 2026 @ 16:06:
[...]


Bedankt voor je reactie. Nu toch al reeds 3 uur aan eens stuk dat DAO geen oplossing kan vinden.
Heb gezien dat de prijzen voor vannacht en morgen overdag vrij laag zijn. Kan het daar wat mee te maken hebben?

Hoe kan ik dat debuggen? Heb de config in maanden niet aangeraakt en geen probleem gehad, en sinds de nieuwe prijzen van vanmiddag kan hij geen oplossing meer berekenen.
Laatste berekening die werkte was om 12h45
Je zou kunnen proberen om je DC solar er even uit te halen? En anders de EVs tijdelijk even verwijderen, kijken of hij dan een oplossing kan maken. Dat geeft misschien wat inzicht.

  • Voogel
  • Registratie: April 2016
  • Laatst online: 04-05 19:44
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2026-03-24 16:00:07 fout: Fout bij schrijven naar input_number.alg001124080565_instantaneous_battery_soc, waarde 100.0
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 64, in <module>
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 60, in main
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 48, in scheduler
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 739, in run_task_function
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 583, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/day_ahead.py, line 4170, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 485, in set_entity_value
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 235, in set_value
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/states.py, line 15, in get_state
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 54, in _get
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 90, in _process_response
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 95, in _raise_error
2026-03-24 16:00:07 fout: Onverwachte fout: 404 status code returned from http://supervisor/core/api/states/input_number.alg001124080565_instantaneous_battery_soc
DAO wil graag data scrijven naar het SOC percentage, maar die data komt van mn batterij integratie... alles werkt verder overigens prima.

7 zonnepanelen, 4kWh thuis accu en binnenkort een Flint op een huisje uit 1896


  • Torch1969
  • Registratie: Juni 2013
  • Laatst online: 06-05 21:08
itavero schreef op dinsdag 24 maart 2026 @ 14:23:
[...]


Als ik vanuit het energiedashboard in HA kijk, en doorklik naar de individuele sensoren, zie ik voor elke sensor gewoon "fijnmazig" (in die pop-up is het dan per 5 minuten) nieuwe data.


[...]


Die rapporteert in MWh.
Als ik naar gisteren kijk zie ik geen negatieve getallen onder verbruik in de report van DAO, maar ik zie wel een viertal uren waar het verbruik nihil is.
Dit is onmogelijk aangezien mijn standby verbruik al rond de 300 a 400W zit.

In het dashboard van HA zie ik dit niet terug.
Enige wat mij aan die uren zo direct opvalt is dat er eigenlijk geen afname van het net is.
Alle stroom komt uit de accu of zonnepanelen (op 1 uur na, waar er slechts 0.003 kWh uit het net komt).

Ik zal binnenkort eens kjiken of ik de data die DAO gebruikt kan exporteren en zelf de analyse lokaal kan draaien.
Met fijnmazig bedoel ik een p1 meter die per 5 of 10 seconden rapporteert, of ct-klemmen per seconde. 5 minuten levert geen grote afwijkingen, maar het verbruik van minuut 55 tot 00 komt binnen op of na 00 en dus in het volgende uur.
BBuilds schreef op dinsdag 24 maart 2026 @ 13:42:
Sinds de prijzen van vanmiddag gepubliceerd zijn kan DAO geen oplossing vinden.
Geeft het na 0.01 sec rekentijd ook op met rekenen.

Heb een update gedaan van 2026.02.02 naar 2026.03.02 maar dit geeft hetzelfde resultaat.
Verrassend want heb al maanden niks aan de config veranderd of toegevoegd, en al maanden ook geen problemen gehad met het berekenen van een oplossing.

Config
Log berekening met debug

Iemand die hier nog tegenaan loopt?
Ik denk het probleem gevonden te hebben (maar ik weet het niet zeker):
  • Je hebt je PV DC-gekoppeld aan je batterij dus alle opwekking gaat naar de DC-bar
  • Je hebt geen schakelaar/regelaar in de MPPT-regelaar (of niet ingevuld) die de PV productie op de DC-bar beperkt
  • Je kunt niet meer salderen (althans salderen staat uit)
  • Er zijn vanmiddag, vannachr en morgen veel uren met lage negatieve tarieven (buiten de piek-uren) en in die uren gaat terugleveren geld kosten
Mogelijke consequentie: het systeem krijgt teveel energie binnen en kan het niet kwijt op het grid.
Ik weet het niet zeker maar je zou het kunnen oplossen door (voor de test) die "entity pv switch": wel in te vullen met een input_boolean en dan kijken of er wel een oplossing uit rolt.
Ik ben benieuwd.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Voogel schreef op dinsdag 24 maart 2026 @ 16:37:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2026-03-24 16:00:07 fout: Fout bij schrijven naar input_number.alg001124080565_instantaneous_battery_soc, waarde 100.0
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 64, in <module>
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 60, in main
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 48, in scheduler
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 739, in run_task_function
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 583, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/day_ahead.py, line 4170, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 485, in set_entity_value
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 235, in set_value
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/states.py, line 15, in get_state
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 54, in _get
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 90, in _process_response
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 95, in _raise_error
2026-03-24 16:00:07 fout: Onverwachte fout: 404 status code returned from http://supervisor/core/api/states/input_number.alg001124080565_instantaneous_battery_soc
DAO wil graag data scrijven naar het SOC percentage, maar die data komt van mn batterij integratie... alles werkt verder overigens prima.
Dan moet je de regel met "entity calculated soc" uit je configuratie verwijderen of daar een input_number in zetten die nergens anders voor wordt gebruikt. Dit is de berekende SoC aan het einde van het interval.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Er was een nieuwe testversie gepubliceerd: 2026.03.3.rc4.
Helaas zat er nog een storende fout in bij de battery-settings.
Sorry voor het ongemak.
Deze versie is nu teruggetrokken.
Er komt zeer binnenkort een werkende versie!

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Karpertje
  • Registratie: Januari 2013
  • Laatst online: 06-05 14:37
KC27 schreef op dinsdag 24 maart 2026 @ 15:01:
[...]

Daar hoef je niet bang voor te zijn. Tijdens de training van het model worden de variabelen die geen invloed hebben op de uitkomst vanzelf uitgerangeerd. Dat is juist het mooie van dit soort ml-technieken.
Ah dat is mooi dat dit blijkbaar zo goed ingeregeld kan worden. Dan ben ik zeker benieuwd naar de uitkomst.

  • itavero
  • Registratie: Oktober 2004
  • Laatst online: 05-05 21:51
Torch1969 schreef op dinsdag 24 maart 2026 @ 21:43:
[...]

Met fijnmazig bedoel ik een p1 meter die per 5 of 10 seconden rapporteert, of ct-klemmen per seconde. 5 minuten levert geen grote afwijkingen, maar het verbruik van minuut 55 tot 00 komt binnen op of na 00 en dus in het volgende uur.
Als ik bij geschiedenis kijk zie ik bij de Sessy apparaten (batterij + P1 meter) dat deze elke 5 seconden uitgelezen worden.
De Peblar laadpaal elke 10 seconden.
De Enphase Envoy sensor update elke minuut.
Dat lijkt mij allemaal redelijk dicht bij elkaar en op de 15 minuten niet zo'n grote verschillen op te leveren.

Helaas nog geen tijd gehad om alle rauwe data eens te analyseren. Daar kom ik nog op terug.
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.
Breaking change
The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:
  • Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
  • Then install the new release (or when you allready have installed restart the addon/app)
  • Look in the logging off the app/addon if you see errors during the conversion.
Most important changes in the config/options.json:<br>
  • all booleans are now noted as true or false: no "True" or "False" anymore.
  • changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
  • removed "show_graph" from settings
  • implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
  • (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"
These errors are fixed:
  • defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
  • default for ev "entity stop charging" (none)
  • boiler activate service must have a value if boiler activate entity is set
  • removed the requirement off stages from heating when adjustement is on/off
  • when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
  • if scheduler active = true is not present it will be set to true

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • balk
  • Registratie: Januari 2000
  • Laatst online: 08:03
KC27 schreef op woensdag 25 maart 2026 @ 19:06:
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.
Breaking change
The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:
  • Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
  • Then install the new release (or when you allready have installed restart the addon/app)
  • Look in the logging off the app/addon if you see errors during the conversion.
Most important changes in the config/options.json:<br>
  • all booleans are now noted as true or false: no "True" or "False" anymore.
  • changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
  • removed "show_graph" from settings
  • implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
  • (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"
These errors are fixed:
  • defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
  • default for ev "entity stop charging" (none)
  • boiler activate service must have a value if boiler activate entity is set
  • removed the requirement off stages from heating when adjustement is on/off
  • when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
  • if scheduler active = true is not present it will be set to true
Ik krijg deze fout:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
2026-03-25 19:49:52 debug: query get column data da:
 SELECT strftime(?, datetime(prognoses.time, ?, ?)) AS uur, prognoses.time AS time, prognoses.time AS utc, prognoses.value AS value 
FROM prognoses, variabel 
WHERE variabel.code = ? AND prognoses.variabel = variabel.id AND prognoses.time >= strftime(?, ?, ?) AND prognoses.time < strftime(?, ?, ?) ORDER BY time
2026-03-25 19:49:52 debug: query get column data da:
 SELECT strftime(?, datetime(prognoses.time, ?, ?)) AS uur, prognoses.time AS time, prognoses.time AS utc, prognoses.value AS value 
FROM prognoses, variabel 
WHERE variabel.code = ? AND prognoses.variabel = variabel.id AND prognoses.time >= strftime(?, ?, ?) AND prognoses.time < strftime(?, ?, ?) ORDER BY time
2026-03-25 19:49:52 debug: query get column data da:
 SELECT strftime(?, datetime(prognoses.time, ?, ?)) AS uur, prognoses.time AS time, prognoses.time AS utc, prognoses.value AS value 
FROM prognoses, variabel 
WHERE variabel.code = ? AND prognoses.variabel = variabel.id AND prognoses.time >= strftime(?, ?, ?) AND prognoses.time < strftime(?, ?, ?) ORDER BY time
2026-03-25 19:49:52 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 694, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 538, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 288, in calc_optimum
    solar_prog = self.calc_solar_predictions(
        self.solar[s], start_interval_dt, end, self.interval
    )
  File "/root/dao/prog/da_base.py", line 587, in calc_solar_predictions
    solar_prog = solar_predictor.predict_solar_device(
        solar_option, vanaf, tot
    )
  File "/root/dao/prog/solar_predictor.py", line 1024, in predict_solar_device
    prediction = self.predict(weather_data)
  File "/root/dao/prog/solar_predictor.py", line 702, in predict
    prediction = self.model.predict(featured_df)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/sklearn.py", line 1446, in predict
    predts = self.get_booster().inplace_predict(
        data=X,
    ...<4 lines>...
        validate_features=validate_features,
    )
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 2865, in inplace_predict
    raise ValueError(
    ...<2 lines>...
    )
ValueError: Feature shape mismatch, expected: 8, got 9
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "POST /api/services/input_text/set_value HTTP/1.1" 200 331
2026-03-25 19:49:52 INFO: Loaded 6 secrets from ../data/secrets.json
2026-03-25 19:49:52 INFO: Validating configuration with ConfigurationV0
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "GET /api/ HTTP/1.1" 200 34
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "GET /api/config HTTP/1.1" 200 2420
2026-03-25 19:49:52 debug: hass/api/config: {"allowlist_external_dirs":["/media","/config/www"],"allowlist_external_urls":[],"components":["light","nederlandse_spoorwegen.sensor","derivative","tuya.sensor","version.binary_sensor","filter.sensor","auto_backup.button","ical","proxmoxve.sensor","tuya.number","homeassistant","my","auto_backup","mqtt.select","sessy.button","alarm_control_panel","tuya.event","localtuya","input_boolean","tuya.light","samsungtv_smart.media_player","proxmoxve.binary_sensor","spook.time","sessy.select","panel_custom","wake_word","history","persistent_notification","lovelace","nodered.number","mqtt.binary_sensor","adguard","spotifyplus","browser_mod.light","buienradar.weather","trace","sql","history_stats.sensor","climate","generic_thermostat.climate","media_source","number","google_generative_ai_conversation.conversation","zwave_js.siren","tuya.climate","spook.sensor","google_generative_ai_conversation.tts","zwave_js.binary_sensor","solaredgeoptimizers.sensor","cloud.stt","smartthings.event","blueprint","ping.sensor","solaredge_modbus","zwave_js.number","github","tado_hijack.binary_sensor","systemmonitor","zwave_js.sensor","ping.binary_sensor","conversation","recorder","tuya","sessy.switch","fan","workday.binary_sensor","mqtt.sensor","samsungtv.remote","local_todo","smartthings","tuya.alarm_control_panel","afvalwijzer.sensor","nodered.sensor","tado_hijack.sensor","github.sensor","tado_hijack.climate","tado_hijack.switch","wake_on_lan.switch","smartthings.binary_sensor","mpd","text","web_rtc","solaredge_modbus.sensor","template.select","smartthings.light","smartthings.climate","http","twinkly","mqtt.switch","tado_local","smartthings.water_heater","smartthings.number","camera","local_calendar.calendar","schedule","min_max.sensor","cloud","auto_backup.binary_sensor","zwave_js.humidifier","afvalwijzer","auth","tuya.valve","hacs","co2signal.sensor","notify","hacs.switch","cover","labs","esphome","buienradar.sensor","spook.switch","dsmr_reader","template.switch","image_upload","watchman.sensor","nodered.text","smartthings.valve","utility_meter","weather","workday.calendar","spotifyplus.media_player","onboarding","mqtt.number","solaredge_modbus.number","systemmonitor.sensor","tado_hijack.button","cloud.binary_sensor","esphome_designer","local_todo.todo","mqtt.event","smartthings.scene","tuya.vacuum","tod","mqtt","ical.sensor","zone","input_number","esphome.event","utility_meter.select","tibber","bluetooth","switch_as_x.light","media_player","wake_on_lan","esphome.cover","hassio.switch","browser_mod.binary_sensor","scene","smartthings.sensor","sessy.number","mobile_app.notify","energy_meter.sensor","intent","hassio.sensor","esphome.media_player","forecast_solar.sensor","adguard.sensor","cast.media_player","openweathermap.weather","tado_hijack.water_heater","ai_task","assist_pipeline","smartthings.select","diagnostics","input_datetime","pvoutput.sensor","logbook","ping","solaredgeoptimizers","mpd.media_player","zwave_js","spook","input_text","lock","siren","sun.sensor","mobile_app.binary_sensor","openweathermap.sensor","tuya.select","zwave_js.button","adguard.switch","plant","search","spook.button","api","zwave_js.update","network","mqtt.text","localtuya.number","group","rest","localtuya.sensor","repairs","tado_hijack.select","unifi","device_automation","tuya.humidifier","threshold.binary_sensor","kleenex_pollenradar","mobile_app.device_tracker","homeassistant.scene","nodered","button","browser_mod.sensor","config","statistics","integration.sensor","counter","nodered.select","spotify","nodered.time","utility_meter.sensor","smartthings.fan","esphome.camera","google_generative_ai_conversation","samsungtv","input_button","adguard.update","systemmonitor.binary_sensor","watchman.button","samsungtv_smart","zwave_js.fan","cloud.tts","esphome.switch","integration","watchman.text","tuya.camera","usb","tibber.sensor","spook.event","sensor","ffmpeg","remote","smartthings.lock","utility_meter_next_gen","websocket_api","sessy","script","zeroconf","binary_sensor","statistics.sensor","version.sensor","nederlandse_spoorwegen","smartthings.vacuum","samsungtv.media_player","ical.calendar","hassio.binary_sensor","zwave_js.light","buienradar","utility_meter_next_gen.sensor","esphome.number","tuya.button","backup.sensor","tuya.cover","auto_backup.sensor","nederlandse_spoorwegen.binary_sensor","zwave_js.select","humidifier","ssdp","smartthings.media_player","scheduler.switch","frontend","template.binary_sensor","sun","forecast_solar","tuya.binary_sensor","smartthings.update","calendar","energy.sensor","esphome.sensor","watchman","smartthings.cover","backup.event","tado_local.sensor","switch","tag","pvoutput","browser_mod.camera","timer","energy","smartthings.switch","event","universal.media_player","spook.binary_sensor","sql.sensor","command_line","rest.sensor","system_log","backup","mobile_app","openweathermap","mobile_app.sensor","template.sensor","rest_command","tado_local.climate","stt","threshold","mqtt.climate","scheduler","sessy.update","smart_thermostat.climate","buienalarm","time","smartthings.button","spotify.media_player","esphome.light","samsungtv_smart.remote","analytics","input_select","file_upload","tado_hijack.number","dsmr_reader.sensor","command_line.sensor","zwave_js.switch","esphome.select","tuya.siren","todo","hardware","tuya.switch","esphome.button","sessy.sensor","buienalarm.sensor","mqtt.light","min_max","select","buienradar.camera","system_health","tuya.fan","kleenex_pollenradar.sensor","proxmoxve","automation","valve","browser_mod","tts","application_credentials","sun.binary_sensor","energy_meter","esphome.binary_sensor","device_tracker","tado_hijack","ping.device_tracker","hassio","zwave_js.event","water_heater","nodered.switch","group.notify","localtuya.switch","bluetooth_adapters","co2signal","tuya.scene","nodered.button","group.light","zwave_js.climate","switch_as_x","logger","solaredge_modbus.select","google_generative_ai_conversation.ai_task","zwave_js.lock","version","local_calendar","nodered.binary_sensor","time_date.sensor","spook.select","tibber.notify","workday","browser_mod.media_player","cast","sessy.binary_sensor","derivative.sensor","vacuum","proxmoxve.button","webhook","mqtt.fan","spook.number","update","hassio.update","person","tado_local.text","hacs.update","tibber.binary_sensor","zwave_js.cover","tod.binary_sensor","shell_command","brands","esphome.update","template","google_generative_ai_conversation.stt","sessy.time"],"config_dir":"/config","config_source":"storage","country":"NL","currency":"EUR","debug":false,"elevation":0,"external_url":null,"internal_url":null,"language":"en","latitude":52.01789586139738,"location_name":"Home","longitude":4.3583106994628915,"radius":100,"recovery_mode":false,"safe_mode":false,"state":"RUNNING","time_zone":"Europe/Amsterdam","unit_system":{"length":"km","accumulated_precipitation":"mm","area":"m²","mass":"g","pressure":"Pa","temperature":"°C","volume":"L","wind_speed":"m/s"},"version":"2026.3.4","whitelist_external_dirs":["/media","/config/www"]}
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "GET /api/states/input_select.dao_strategy HTTP/1.1" 200 429
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 323
2026-03-25 19:49:52 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 198 in /root/dao/prog/da_base.py
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4707, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4678, in main
    da_calc.run_task_function("calc_optimum_met_debug")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 694, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 538, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 288, in calc_optimum
    solar_prog = self.calc_solar_predictions(
        self.solar[s], start_interval_dt, end, self.interval
    )
  File "/root/dao/prog/da_base.py", line 587, in calc_solar_predictions
    solar_prog = solar_predictor.predict_solar_device(
        solar_option, vanaf, tot
    )
  File "/root/dao/prog/solar_predictor.py", line 1024, in predict_solar_device
    prediction = self.predict(weather_data)
  File "/root/dao/prog/solar_predictor.py", line 702, in predict
    prediction = self.model.predict(featured_df)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/sklearn.py", line 1446, in predict
    predts = self.get_booster().inplace_predict(
        data=X,
    ...<4 lines>...
        validate_features=validate_features,
    )
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 2865, in inplace_predict
    raise ValueError(
    ...<2 lines>...
    )
ValueError: Feature shape mismatch, expected: 8, got 9
Ik heb de model.lp verwijderd maar dat hielp niet. Ik heb meteo en e-prijzen opgehaald.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
{
  "config_version": 0,
  
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "entsoe_api_key": "!secret entsoe-api-key",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.12286,
      "2025-09-01": 0.12286
    },
    "energy_taxes_production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.12286,
      "2025-09-01": 0.12286
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0182,
      "2025-09-01": 0.020496,
      "2026-01-01": 0.020496
    },
    "cost_supplier_production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0182,
      "2025-09-01": 0.020496,
      "2026-01-01": -0.020496
    },
    "vat_consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21,
      "2026-01-01": 21
    },
    "vat_production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21,
      "2026-01-01": 21
    },
    "last_invoice": "2026-01-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
  "logging_level": "debug",
  "use_calc_baseload": false,
  "baseload_calc_periode": 42,
  "baseload": [
    0.15,
    0.15,
    0.15,
    0.15,
    0.15,
    0.15,
    0.15,
    0.25,
    0.3,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.8,
    0.8,
    0.5,
    0.2,
    0.2,
    0.15
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": true,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "input_select.dao_strategy",
  "max_gap": 0.005,
  "notifications": {
    "notification_entity": "input_text.notification_dao",
    "opstarten": false,
    "berekening": true,
    "last_activity_entity": "input_datetime.dao_last_activity"
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Sessys",
      "entity_actual_level": "sensor.sessy_all_state_of_charge",
      "capacity": 10.0,
      "upper_limit": 100,
      "lower_limit": 0,
      "optimal_lower_level": 0,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 120.0,
          "efficiency": 0.7
        },
        {
          "power": 220.0,
          "efficiency": 0.758
        },
        {
          "power": 440.0,
          "efficiency": 0.85
        },
        {
          "power": 660.0,
          "efficiency": 0.892
        },
        {
          "power": 880.0,
          "efficiency": 0.912
        },
        {
          "power": 1320.0,
          "efficiency": 0.933
        },
        {
          "power": 1760.0,
          "efficiency": 0.942
        },
        {
          "power": 2200.0,
          "efficiency": 0.946
        },
        {
          "power": 2640.0,
          "efficiency": 0.942
        },
        {
          "power": 3080.0,
          "efficiency": 0.938
        },
        {
          "power": 3520.0,
          "efficiency": 0.929
        },
        {
          "power": 3960.0,
          "efficiency": 0.921
        },
        {
          "power": 4400.0,
          "efficiency": 0.908
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 120.0,
          "efficiency": 0.7
        },
        {
          "power": 170.0,
          "efficiency": 0.735
        },
        {
          "power": 340.0,
          "efficiency": 0.829
        },
        {
          "power": 510.0,
          "efficiency": 0.882
        },
        {
          "power": 680.0,
          "efficiency": 0.921
        },
        {
          "power": 1020.0,
          "efficiency": 0.943
        },
        {
          "power": 1360.0,
          "efficiency": 0.957
        },
        {
          "power": 1700.0,
          "efficiency": 0.957
        },
        {
          "power": 2040.0,
          "efficiency": 0.953
        },
        {
          "power": 2380.0,
          "efficiency": 0.943
        },
        {
          "power": 2720.0,
          "efficiency": 0.936
        },
        {
          "power": 3060.0,
          "efficiency": 0.929
        },
        {
          "power": 3400.0,
          "efficiency": 0.925
        }
      ],
      "reduced_hours": {
        "0": 1000,
        "1": 1000,
        "2": 1000,
        "3": 1000,
        "4": 1000,
        "5": 1000,
        "6": 1000,
        "20": 1000,
        "21": 1000,
        "22": 1000,
        "23": 1000
      },
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 100,
      "dc_to_bat_efficiency": 1.0,
      "dc_to_bat_max_power": 2200.0,
      "bat_to_dc_efficiency": 1.0,
      "cycle_cost": 0.03,
      "entity_set_power_feedin": "input_number.sessy_charge_setpoint_from_dao_dummy",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_balance_switch": "input_boolean.sessy_dao_controlled_nom_aan_dummy",
      "entity_from_battery": "input_number.sessy_calculated_power_next_hour_dummy",
      "entity_calculated_soc": "input_number.sessy_calculated_soc_from_dao_dummy",
      "solar": [],
      "bat_to_dc max power": 1700
    }
  ],
  "solar": [
    {
      "name": "Solaredge",
      "tilt": 10.0,
      "orientation": 146.0,
      "capacity": 0.405,
      "yield_factor": 0.000931658,
      "strings": [],
      "ml_prediction": true,
      "entities_sensors": [
        "sensor.solaredge_modbus_ac_energy_kwh"
      ],
      "max_power": 3.0
    }
  ],
  "electric_vehicle": [],
  "machines": [],
  "boiler": {
    "boiler_present": false
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": [
      "sensor.dsmr_reading_electricity_delivered_1",
      "sensor.dsmr_reading_electricity_delivered_2"
    ],
    "entities_grid_production": [
      "sensor.dsmr_reading_electricity_returned_1",
      "sensor.dsmr_reading_electricity_returned_2"
    ],
    "entities_solar_production_ac": [
      "sensor.solaredge_modbus_ac_energy_kwh"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": [],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.sessy_links_charged_energy",
      "sensor.sessy_rechts_charged_energy"
    ],
    "entities_battery_production": [
      "sensor.sessy_links_discharged_energy",
      "sensor.sessy_rechts_discharged_energy"
    ],
    "entities_machine_consumption": [],
    "entity co2-intensity": [
      "sensor.electricity_maps_co2_intensity"
    ]
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "1037",
        "action": "get_meteo_data"
      },
      {
        "time": "1250",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1350",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1450",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1550",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1634",
        "action": "get_meteo_data"
      },
      {
        "time": "1650",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "2222",
        "action": "get_meteo_data"
      },
      {
        "time": "2359",
        "action": "clean_data"
      },
      {
        "time": "0437",
        "action": "get_meteo_data"
      },
      {
        "time": "1948",
        "action": "train_ml_predictions"
      }
    ]
  },
  "heater": {
    "heater present": "false"
  }
}

  • simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
balk schreef op woensdag 25 maart 2026 @ 19:55:
[...]

Ik krijg deze fout:

[...]

Ik heb de model.lp verwijderd maar dat hielp niet. Ik heb meteo en e-prijzen opgehaald.

[...]
Heb je de ML modellen wel opnieuw getraind?

  • balk
  • Registratie: Januari 2000
  • Laatst online: 08:03
simnet schreef op woensdag 25 maart 2026 @ 19:59:
[...]

Heb je de ML modellen wel opnieuw getraind?
Daar gaat het mis denk ik. Wel poging daartoe. Handmatig krijg ik een time-out. Met de scheduler gaat het ook niet goed; er wordt geen nieuwe model.lp aangemaakt.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
..knip
2026-03-25 20:06:01 debug: Save record: 2026-03-23 22:00 temp 1774299600 8.1
2026-03-25 20:06:01 debug: Save record: 2026-03-23 22:00 gr 1774299600 0.0
2026-03-25 20:06:01 debug: Save record: 2026-03-23 22:00 winds 1774299600 2.0
2026-03-25 20:06:01 debug: Save record: 2026-03-23 23:00 temp 1774303200 7.7
2026-03-25 20:06:01 debug: Save record: 2026-03-23 23:00 gr 1774303200 0.0
2026-03-25 20:06:01 debug: Save record: 2026-03-23 23:00 winds 1774303200 3.0
2026-03-25 20:06:01 debug: Save record: 2026-03-24 00:00 temp 1774306800 6.9
2026-03-25 20:06:01 debug: Save record: 2026-03-24 00:00 gr 1774306800 0.0
2026-03-25 20:06:01 debug: Save record: 2026-03-24 00:00 winds 1774306800 3.0
2026-03-25 20:06:01 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 312 in /root/dao/lib/db_manager.py
2026-03-25 20:06:01 debug: query get column data da:
 SELECT strftime(?, datetime("values".time, ?, ?)) AS uur, "values".time AS time, "values".time AS utc, "values".value AS value 
FROM "values", variabel 
WHERE variabel.code = ? AND "values".variabel = variabel.id AND "values".time >= strftime(?, ?, ?) AND "values".time < strftime(?, ?, ?) ORDER BY time
2026-03-25 20:06:01 debug: query get column data da:
 SELECT strftime(?, datetime("values".time, ?, ?)) AS uur, "values".time AS time, "values".time AS utc, "values".value AS value 
FROM "values", variabel 
WHERE variabel.code = ? AND "values".variabel = variabel.id AND "values".time >= strftime(?, ?, ?) AND "values".time < strftime(?, ?, ?) ORDER BY time
2026-03-25 20:06:01 debug: query get column data da:
 SELECT strftime(?, datetime("values".time, ?, ?)) AS uur, "values".time AS time, "values".time AS utc, "values".value AS value 
FROM "values", variabel 
WHERE variabel.code = ? AND "values".variabel = variabel.id AND "values".time >= strftime(?, ?, ?) AND "values".time < strftime(?, ?, ?) ORDER BY time
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "GET /api/ HTTP/1.1" 200 34
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "GET /api/config HTTP/1.1" 200 2420
<knip>
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "GET /api/states/input_select.dao_strategy HTTP/1.1" 200 429
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 10
2026-03-25 20:06:01 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 198 in /root/dao/prog/da_base.py
2026-03-25 20:06:01 debug: query get sensor data:
 SELECT to_char(to_timestamp(t2.start_ts), %(to_char_1)s) AS uur, to_char(to_timestamp(t2.start_ts), %(to_char_2)s) AS tijd, to_char(to_timestamp(t2.start_ts), %(to_char_3)s) AS tot, t2.start_ts AS utc, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE %(param_1)s END AS solar_kwh, v1.unit_of_measurement AS dim 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + %(start_ts_1)s JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = %(statistic_id_1)s AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= EXTRACT(epoch FROM to_timestamp(%(to_timestamp_1)s, %(to_timestamp_2)s)) - %(param_2)s AND t1.start_ts < EXTRACT(epoch FROM to_timestamp(%(to_timestamp_3)s, %(to_timestamp_4)s)) - %(param_3)s
balk schreef op woensdag 25 maart 2026 @ 20:07:
[...]

Daar gaat het mis denk ik. Wel poging daartoe. Handmatig krijg ik een time-out. Met de scheduler gaat het ook niet goed; er wordt geen nieuwe model.lp aangemaakt.


[...]
Kun je die ml training via scheduler nog eens doen met loglevel op info?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
KC27 schreef op woensdag 25 maart 2026 @ 19:06:
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.
Breaking change
The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:
  • Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
  • Then install the new release (or when you allready have installed restart the addon/app)
  • Look in the logging off the app/addon if you see errors during the conversion.
Most important changes in the config/options.json:<br>
  • all booleans are now noted as true or false: no "True" or "False" anymore.
  • changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
  • removed "show_graph" from settings
  • implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
  • (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"
These errors are fixed:
  • defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
  • default for ev "entity stop charging" (none)
  • boiler activate service must have a value if boiler activate entity is set
  • removed the requirement off stages from heating when adjustement is on/off
  • when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
  • if scheduler active = true is not present it will be set to true
Hmm ik wil van 2026.03.1.rc3 upgraden en de stappen volgen maar het onderstaande is mij nog niet helemaal duidelijk.
code:
1
Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
er is geen options_unversioned.json. Moet ik options.json kopieren naar options_unversioned.json of moet ik toch echt eerst upgrade en dan de kopie doen. :?

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
Mirabis schreef op woensdag 25 maart 2026 @ 23:23:
[...]

Hmm ik wil van 2026.03.1.rc3 upgraden en de stappen volgen maar het onderstaande is mij nog niet helemaal duidelijk.
code:
1
Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
er is geen options_unversioned.json. Moet ik options.json kopieren naar options_unversioned.json of moet ik toch echt eerst upgrade en dan de kopie doen. :?
options_unversioned.json bestaat alleen als je al een keer een 2026.03.3.rcX hebt gedraait.
Die specifieke instructie is alleen voor mensen die hiervoor al een rc van deze versie draaiden.

  • DaBit
  • Registratie: Januari 2000
  • Laatst online: 05-05 22:14
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
=> directory dao_data exist
=> /root/dao/data doesn't exist, made
=> /root/dao/webserver/app/static/data exist
2026-03-26 08:40:25 INFO: Configuration needs migration from unversioned to v0
2026-03-26 08:40:25 INFO: Saved backup configuration to ../data/options_unversioned.json
2026-03-26 08:40:25 INFO: Migrating unversioned configuration to v0
2026-03-26 08:40:25 INFO: Added config_version=0 to unversioned configuration
2026-03-26 08:40:25 INFO: Migrated scheduler: active=True, 9 schedule entries
2026-03-26 08:40:25 INFO: Coerced boiler.boiler present from 'False' to boolean
2026-03-26 08:40:25 INFO: Coerced heating.heater present from 'False' to boolean
2026-03-26 08:40:25 INFO: Configuration at version 0
Error loading configuration: 3 validation errors for ConfigurationV0
battery.0.dc_to_bat max power
  Input should be a valid number, unable to parse string as a number [type=float_parsing, input_value='sensor.ess_max_chargepower', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/float_parsing
solar.0.strings.0.orientation
  Input should be less than or equal to 180 [type=less_than_equal, input_value=270, input_type=int]
    For further information visit https://errors.pydantic.dev/2.12/v/less_than_equal
solar.5.orientation
  Input should be less than or equal to 180 [type=less_than_equal, input_value=270, input_type=int]
    For further information visit https://errors.pydantic.dev/2.12/v/less_than_equal
Van die 270 kan ik ook wel -90 maken. Had al eerder moeten gebeuren zo te zien.
Die battery.0.dc_to_bat max power die een entiteit niet accepteert is wel fout.
Overigens doet de "bat_to_dc max power": "sensor.ess_max_dischargepower" het wel.

Met de 270 veranderd naar -90 en tijdelijke een getal op de plek van de entiteit start het door. ML-training ging ook goed.

[ Voor 5% gewijzigd door DaBit op 26-03-2026 09:04 ]


  • DaBit
  • Registratie: Januari 2000
  • Laatst online: 05-05 22:14
code:
1
2
3
4
5
..
2026-03-26 08:59:46 waarschuwing: Gebruik 'prices consumption' ipv `prices delivery'
2026-03-26 08:59:46 waarschuwing: Gebruik 'prices production' ipv `prices redelivery'
2026-03-26 08:59:46 waarschuwing: Gebruik 'average consumption' ipv `average delivery'
..
Deze melding in de log van een berekening: gewoon naampje aanpassen en klaar?
DaBit schreef op donderdag 26 maart 2026 @ 08:46:
[...]


Van die 270 kan ik ook wel -90 maken. Had al eerder moeten gebeuren zo te zien.
Die battery.0.dc_to_bat max power die een entiteit niet accepteert is wel fout.
Overigens doet de "bat_to_dc max power": "sensor.ess_max_dischargepower" het wel.

Met de 270 veranderd naar -90 en tijdelijke een getal op de plek van de entiteit start het door. ML-training ging ook goed.
Dank je wel voor het testen en melden.
Die battery.0.dc_to_bat max power passen we aan!
Ik zal overleggen met @simnet of we die twee meldingen (270->-90 en delivery->consumption) niet standaard kunnen meenemen in de "conversie".

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • DaBit
  • Registratie: Januari 2000
  • Laatst online: 05-05 22:14
Ik denk dat erover discussieren langer duurt dan het maar gewoon implementeren...

  • rescla
  • Registratie: November 2012
  • Laatst online: 06:52
Deze krijg ik nog met de laatste versie:
code:
1
2
3
4
Error loading configuration: 1 validation error for ConfigurationV0
boiler.1
  Value error, Boiler must have "activate entity" or "switch entity" to be configured [type=value_error, input_value={'boiler present': True, ...48, 'elec. power': 3750}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.12/v/value_error
Op zich correct, maar voor testen/inplannen kan het wellicht ook een warning zijn? Voor nu maak ik er wel even een helpertje voor.

-edit-
Heb hem voor nu even op present false gezet, maar nu krijg ik deze:
code:
1
2
3
4
5
6
7
8
9
10
11
2026-03-26 10:51:33 INFO: Configuration needs migration from unversioned to v0
2026-03-26 10:51:33 INFO: Saved backup configuration to ../data/options_unversioned.json
2026-03-26 10:51:33 INFO: Migrating unversioned configuration to v0
2026-03-26 10:51:33 INFO: Added config_version=0 to unversioned configuration
2026-03-26 10:51:33 INFO: Migrated scheduler: active=True, 12 schedule entries
2026-03-26 10:51:33 INFO: Migrated prices.vat: set vat consumption and vat production to {'2022-01-01': 21, '2022-07-01': 9, '2023-01-01': 21}
2026-03-26 10:51:33 INFO: Coerced boiler.boiler present from 'false' to boolean
2026-03-26 10:51:33 INFO: Coerced heating.heater present from 'true' to boolean
2026-03-26 10:51:33 INFO: Configuration at version 0
Error loading configuration: Error calling function `serialize_flex_value`: AttributeError: 'int' object has no attribute 'value'
check_db.py failed, exiting
Denk dat dit een algemene is voor flex value, maar als je de config moet hebben laat maar weten.

[ Voor 51% gewijzigd door rescla op 26-03-2026 10:54 ]


  • thesaxofonist
  • Registratie: November 2016
  • Laatst online: 09:10
Ik heb een eerste generatie thuisbatterij zonder slimme logica. Zodra er overschot is gaat hij laden en bij een tekort gaat hij ontladen. Dat doet hij op basis van een kWh-meter in de meterkast. Ik wil dat slimmer maken door de signalen van de kWh-meter te simuleren door home assistant en DAO te gebruiken.

Bij 'minimize consumption' voorzie ik geen problemen. Maar gaat het ook goed werken bij 'minimize cost'? Ik kan immers niet laden vanuit het net. Is daar een instelling voor of een slimme work-around? Anders kom ik waarschijnlijk toch bij emhass of ViveroEopti uit. Of zelf iets maken met node-red.

  • Joos74
  • Registratie: Januari 2025
  • Laatst online: 08:56
Ik krijg deze foutmelding als ik op 'Reports' klik:
[2026-03-26 12:44:45,616] fout in app: Exception on / [POST]
Traceback (most recent call last):
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
response = self.full_dispatch_request()
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
rv = self.dispatch_request()
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/root/dao/webserver/app/routes.py", line 316, in menu
return reports("reports")
File "/root/dao/webserver/app/routes.py", line 574, in reports
report_df = report.get_grid_data(active_period, _tot=tot)
File "/root/dao/prog/da_report.py", line 2204, in get_grid_data
df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
File "/root/dao/prog/da_report.py", line 3033, in get_price_data
df_da = self.db_da.get_column_data(
"values", "da", start=start, end=end, agg_func=agg_func
)
File "/root/dao/lib/db_manager.py", line 497, in get_column_data
end = end.strftime("%Y-%m-%d %H:%M")
File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime
Zowel in de TESTING- als in de laatste productieversie. Iemand enig idee?
Joos74 schreef op donderdag 26 maart 2026 @ 12:46:
Ik krijg deze foutmelding als ik op 'Reports' klik:


[...]


Zowel in de TESTING- als in de laatste productieversie. Iemand enig idee?
Kun je wel een berekening doen met DAO, dus: Run\Optimaliseringsberekening met debug?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

thesaxofonist schreef op donderdag 26 maart 2026 @ 12:08:
Ik heb een eerste generatie thuisbatterij zonder slimme logica. Zodra er overschot is gaat hij laden en bij een tekort gaat hij ontladen. Dat doet hij op basis van een kWh-meter in de meterkast. Ik wil dat slimmer maken door de signalen van de kWh-meter te simuleren door home assistant en DAO te gebruiken.

Bij 'minimize consumption' voorzie ik geen problemen. Maar gaat het ook goed werken bij 'minimize cost'? Ik kan immers niet laden vanuit het net. Is daar een instelling voor of een slimme work-around? Anders kom ik waarschijnlijk toch bij emhass of ViveroEopti uit. Of zelf iets maken met node-red.
Als je de batterij kunt laten luisteren naar (de waarde van) een entity in Home Assistant (ipv de kWh-meter) dan moet het DAO kunnen. DAO schrijft aan het begin van ieder uur (of kwartier) het te laden/ontladen vermogen (in W) voor dat uur/kwartier naar een HA-entity (laden is een positief getal, ontladen is een negatief getal).
Als je met een template sensor dat omdraait en je biedt dat getal aan de batterij aan als zijnde het vermogen dat wordt afgenomen van of teruggeleverd aan het grid dan kan hij dat "compenseren" door met dat vermogen te gaan laden/ontladen.
Is dat iets?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • thesaxofonist
  • Registratie: November 2016
  • Laatst online: 09:10
KC27 schreef op donderdag 26 maart 2026 @ 13:33:
[...]

Als je de batterij kunt laten luisteren naar (de waarde van) een entity in Home Assistant (ipv de kWh-meter) dan moet het DAO kunnen. DAO schrijft aan het begin van ieder uur (of kwartier) het te laden/ontladen vermogen (in W) voor dat uur/kwartier naar een HA-entity (laden is een positief getal, ontladen is een negatief getal).
Als je met een template sensor dat omdraait en je biedt dat getal aan de batterij aan als zijnde het vermogen dat wordt afgenomen van of teruggeleverd aan het grid dan kan hij dat "compenseren" door met dat vermogen te gaan laden/ontladen.
Is dat iets?
Ik weet niet of we elkaar goed begrijpen. Ik kan DAO gebruiken (als input) om de batterij aan te sturen. Dat gaat me wel lukken en is het probleem niet.

Maar mijn batterij kan niet laden vanuit het net. Ik wil voorkomen dat DAO de batterij ontlaadt (omdat het tarief hoog is) en de lege batterij even later wil opladen vanuit het net (bijvoorbeeld omdat het tarief dan negatief is). Mijn batterij zal keurig gaan ontladen, maar het laden lukt hem niet (behalve als er op dat moment ook PV is).

DAO wil slim laden en ontladen. Maar het laden is bij mij beperkt tot de PV-opbrengst.

Mijn vraag is of ik dat ergens in het model kan invoeren. Kan er bijvoorbeeld ingesteld worden dat grid-to-battery maximaal nul mag zijn? Bijvoorbeeld bij de hybride omvormer? Of gaat hij er vanuit dat max-grid-to-battery gelijk is aan max-PV-to-battery?

  • Joos74
  • Registratie: Januari 2025
  • Laatst online: 08:56
KC27 schreef op donderdag 26 maart 2026 @ 13:24:
[...]

Kun je wel een berekening doen met DAO, dus: Run\Optimaliseringsberekening met debug?
Ja, de berekeningen uitvoeren gaat allemaal prima.

  • simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
rescla schreef op donderdag 26 maart 2026 @ 10:50:
Deze krijg ik nog met de laatste versie:
code:
1
2
3
4
Error loading configuration: 1 validation error for ConfigurationV0
boiler.1
  Value error, Boiler must have "activate entity" or "switch entity" to be configured [type=value_error, input_value={'boiler present': True, ...48, 'elec. power': 3750}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.12/v/value_error
Op zich correct, maar voor testen/inplannen kan het wellicht ook een warning zijn? Voor nu maak ik er wel even een helpertje voor.

-edit-
Heb hem voor nu even op present false gezet, maar nu krijg ik deze:

[...]


Denk dat dit een algemene is voor flex value, maar als je de config moet hebben laat maar weten.
Ik ben wel benieuwd naar je config. Kun je die toch even delen?
Edit: niet nodig, ik heb 'm al gevonden :)

  • f.welvering
  • Registratie: Oktober 2009
  • Laatst online: 06-05 15:28
Ik krijg na de rc5 helemaal geen optimalisatie berekening meer.
Hij eindigd met de volgende fout:
code:
1
2
3
4
5
6
7
8
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 6 leaked semlock objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 2 leaked folder objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_f9deac5f342b477fb01aa3b6e99612d0: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_1b08dc821ed840f5937291e4edf5ae71: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
Volledige log:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
dao  | 2026-03-26 15:30:00 info: Day Ahead Optimalisering versie: 2026.03.3.rc5
dao  | 2026-03-26 15:30:00 info: Day Ahead Optimalisering gestart op: 26-03-2026 15:30:00
dao  | 2026-03-26 15:30:00 info: Day Ahead Optimalisatie gestart: 26-03-2026 15:30:00 taak: calc_optimum
dao  | 2026-03-26 15:30:00 info: Debug = False
dao  | 2026-03-26 15:30:00 info: Zelf berekende baseload
dao  | 2026-03-26 15:30:00 info: ML prediction Oost
dao  |                    date_time  prediction
dao  | 0  2026-03-26 15:00:00+01:00       0.917
dao  | 1  2026-03-26 16:00:00+01:00       0.883
dao  | 2  2026-03-26 17:00:00+01:00       0.420
dao  | 3  2026-03-26 18:00:00+01:00       0.053
dao  | 4  2026-03-26 19:00:00+01:00       0.004
dao  | 5  2026-03-26 20:00:00+01:00       0.004
dao  | 6  2026-03-26 21:00:00+01:00       0.004
dao  | 7  2026-03-26 22:00:00+01:00       0.004
dao  | 8  2026-03-26 23:00:00+01:00       0.004
dao  | 9  2026-03-27 00:00:00+01:00       0.004
dao  | 10 2026-03-27 01:00:00+01:00       0.013
dao  | 11 2026-03-27 02:00:00+01:00       0.013
dao  | 12 2026-03-27 03:00:00+01:00       0.010
dao  | 13 2026-03-27 04:00:00+01:00       0.010
dao  | 14 2026-03-27 05:00:00+01:00       0.010
dao  | 15 2026-03-27 06:00:00+01:00       0.029
dao  | 16 2026-03-27 07:00:00+01:00       0.888
dao  | 17 2026-03-27 08:00:00+01:00       2.566
dao  | 18 2026-03-27 09:00:00+01:00       4.730
dao  | 19 2026-03-27 10:00:00+01:00       5.554
dao  | 20 2026-03-27 11:00:00+01:00       5.380
dao  | 21 2026-03-27 12:00:00+01:00       4.647
dao  | 22 2026-03-27 13:00:00+01:00       2.886
dao  | 23 2026-03-27 14:00:00+01:00       1.236
dao  | 24 2026-03-27 15:00:00+01:00       1.096
dao  | 25 2026-03-27 16:00:00+01:00       0.788
dao  | 26 2026-03-27 17:00:00+01:00       0.265
dao  | 27 2026-03-27 18:00:00+01:00       0.005
dao  | 28 2026-03-27 19:00:00+01:00       0.004
dao  | 29 2026-03-27 20:00:00+01:00       0.004
dao  | 30 2026-03-27 21:00:00+01:00       0.004
dao  | 31 2026-03-27 22:00:00+01:00       0.004
dao  | 32 2026-03-27 23:00:00+01:00       0.004
dao  | 2026-03-26 15:30:00 info: Start waarden:
dao  |        uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
dao  | 0    15:30 2026-03-26 15:30:00 0.037 0.186 0.045 0.132  0.228      0
dao  | 1    15:45 2026-03-26 15:45:00 0.071 0.227 0.086 0.134  0.226      0
dao  | 2    16:00 2026-03-26 16:00:00 0.037 0.186 0.045 0.129  0.231      0
dao  | 3    16:15 2026-03-26 16:15:00 0.072 0.228 0.087 0.131  0.229      0
dao  | 4    16:30 2026-03-26 16:30:00 0.080 0.238 0.097 0.134  0.226      0
dao  | 5    16:45 2026-03-26 16:45:00 0.111 0.275 0.134 0.180  0.198      0
dao  | 6    17:00 2026-03-26 17:00:00 0.077 0.234 0.093 0.264  0.147      0
dao  | 7    17:15 2026-03-26 17:15:00 0.109 0.273 0.132 0.310  0.118      0
dao  | 8    17:30 2026-03-26 17:30:00 0.128 0.296 0.155 0.356  0.089      0
dao  | 9    17:45 2026-03-26 17:45:00 0.150 0.322 0.181 0.382  0.066      0
dao  | 10   18:00 2026-03-26 18:00:00 0.123 0.290 0.149 0.405  0.043      0
dao  | 11   18:15 2026-03-26 18:15:00 0.144 0.315 0.174 0.430  0.020      0
dao  | 12   18:30 2026-03-26 18:30:00 0.160 0.335 0.194 0.456  0.000      0
dao  | 13   18:45 2026-03-26 18:45:00 0.181 0.360 0.219 0.428  0.000      0
dao  | 14   19:00 2026-03-26 19:00:00 0.164 0.339 0.198 0.356  0.005      0
dao  | 15   19:15 2026-03-26 19:15:00 0.167 0.343 0.203 0.328  0.002      0
dao  | 16   19:30 2026-03-26 19:30:00 0.169 0.345 0.204 0.299  0.000      0
dao  | 17   19:45 2026-03-26 19:45:00 0.166 0.341 0.201 0.282  0.000      0
dao  | 18   20:00 2026-03-26 20:00:00 0.170 0.347 0.206 0.273  0.001      0
dao  | 19   20:15 2026-03-26 20:15:00 0.155 0.329 0.188 0.256  0.001      0
dao  | 20   20:30 2026-03-26 20:30:00 0.147 0.319 0.178 0.239  0.001      0
dao  | 21   20:45 2026-03-26 20:45:00 0.140 0.311 0.170 0.225  0.001      0
dao  | 22   21:00 2026-03-26 21:00:00 0.147 0.318 0.178 0.216  0.001      0
dao  | 23   21:15 2026-03-26 21:15:00 0.133 0.301 0.161 0.202  0.001      0
dao  | 24   21:30 2026-03-26 21:30:00 0.124 0.291 0.150 0.189  0.001      0
dao  | 25   21:45 2026-03-26 21:45:00 0.118 0.284 0.143 0.167  0.001      0
dao  | 26   22:00 2026-03-26 22:00:00 0.131 0.299 0.159 0.137  0.001      0
dao  | 27   22:15 2026-03-26 22:15:00 0.122 0.288 0.147 0.116  0.001      0
dao  | 28   22:30 2026-03-26 22:30:00 0.124 0.291 0.150 0.094  0.001      0
dao  | 29   22:45 2026-03-26 22:45:00 0.121 0.287 0.147 0.087  0.001      0
dao  | 30   23:00 2026-03-26 23:00:00 0.124 0.291 0.150 0.073  0.001      0
dao  | 31   23:15 2026-03-26 23:15:00 0.121 0.287 0.147 0.066  0.001      0
dao  | 32   23:30 2026-03-26 23:30:00 0.139 0.309 0.168 0.059  0.001      0
dao  | 33   23:45 2026-03-26 23:45:00 0.121 0.287 0.146 0.124  0.001      0
dao  | 34   00:00 2026-03-27 00:00:00 0.125 0.291 0.151 0.271  0.001      0
dao  | 35   00:15 2026-03-27 00:15:00 0.120 0.287 0.146 0.336  0.001      0
dao  | 36   00:30 2026-03-27 00:30:00 0.117 0.283 0.142 0.401  0.001      0
dao  | 37   00:45 2026-03-27 00:45:00 0.116 0.281 0.140 0.355  0.001      0
dao  | 38   01:00 2026-03-27 01:00:00 0.122 0.289 0.148 0.213  0.003      0
dao  | 39   01:15 2026-03-27 01:15:00 0.120 0.285 0.145 0.166  0.003      0
dao  | 40   01:30 2026-03-27 01:30:00 0.119 0.285 0.144 0.119  0.004      0
dao  | 41   01:45 2026-03-27 01:45:00 0.117 0.283 0.142 0.119  0.004      0
dao  | 42   02:00 2026-03-27 02:00:00 0.121 0.287 0.146 0.153  0.003      0
dao  | 43   02:15 2026-03-27 02:15:00 0.118 0.284 0.143 0.153  0.003      0
dao  | 44   02:30 2026-03-27 02:30:00 0.115 0.280 0.140 0.152  0.003      0
dao  | 45   02:45 2026-03-27 02:45:00 0.115 0.280 0.139 0.152  0.003      0
dao  | 46   03:00 2026-03-27 03:00:00 0.117 0.282 0.141 0.155  0.003      0
dao  | 47   03:15 2026-03-27 03:15:00 0.119 0.285 0.145 0.155  0.003      0
dao  | 48   03:30 2026-03-27 03:30:00 0.117 0.282 0.142 0.155  0.002      0
dao  | 49   03:45 2026-03-27 03:45:00 0.118 0.284 0.143 0.146  0.002      0
dao  | 50   04:00 2026-03-27 04:00:00 0.118 0.283 0.142 0.132  0.003      0
dao  | 51   04:15 2026-03-27 04:15:00 0.119 0.284 0.144 0.123  0.003      0
dao  | 52   04:30 2026-03-27 04:30:00 0.121 0.287 0.146 0.115  0.003      0
dao  | 53   04:45 2026-03-27 04:45:00 0.124 0.290 0.150 0.106  0.003      0
dao  | 54   05:00 2026-03-27 05:00:00 0.120 0.286 0.145 0.094  0.002      0
dao  | 55   05:15 2026-03-27 05:15:00 0.129 0.297 0.156 0.085  0.002      0
dao  | 56   05:30 2026-03-27 05:30:00 0.144 0.315 0.174 0.077  0.002      0
dao  | 57   05:45 2026-03-27 05:45:00 0.153 0.326 0.185 0.082  0.003      0
dao  | 58   06:00 2026-03-27 06:00:00 0.152 0.325 0.184 0.082  0.000      0
dao  | 59   06:15 2026-03-27 06:15:00 0.169 0.345 0.204 0.088  0.000      0
dao  | 60   06:30 2026-03-27 06:30:00 0.179 0.357 0.217 0.093  0.000      0
dao  | 61   06:45 2026-03-27 06:45:00 0.190 0.371 0.230 0.160  0.048      0
dao  | 62   07:00 2026-03-27 07:00:00 0.204 0.387 0.246 0.295  0.129      0
dao  | 63   07:15 2026-03-27 07:15:00 0.191 0.372 0.231 0.362  0.182      0
dao  | 64   07:30 2026-03-27 07:30:00 0.171 0.348 0.207 0.429  0.236      0
dao  | 65   07:45 2026-03-27 07:45:00 0.140 0.310 0.169 0.412  0.341      0
dao  | 66   08:00 2026-03-27 08:00:00 0.194 0.376 0.235 0.321  0.477      0
dao  | 67   08:15 2026-03-27 08:15:00 0.152 0.324 0.184 0.305  0.581      0
dao  | 68   08:30 2026-03-27 08:30:00 0.137 0.307 0.166 0.288  0.686      0
dao  | 69   08:45 2026-03-27 08:45:00 0.108 0.272 0.131 0.318  0.822      0
dao  | 70   09:00 2026-03-27 09:00:00 0.137 0.307 0.166 0.392  1.001      0
dao  | 71   09:15 2026-03-27 09:15:00 0.123 0.289 0.148 0.421  1.136      0
dao  | 72   09:30 2026-03-27 09:30:00 0.110 0.274 0.133 0.451  1.271      0
dao  | 73   09:45 2026-03-27 09:45:00 0.088 0.248 0.107 0.441  1.323      0
dao  | 74   10:00 2026-03-27 10:00:00 0.103 0.265 0.125 0.398  1.327      0
dao  | 75   10:15 2026-03-27 10:15:00 0.091 0.251 0.110 0.388  1.378      0
dao  | 76   10:30 2026-03-27 10:30:00 0.088 0.247 0.106 0.379  1.430      0
dao  | 77   10:45 2026-03-27 10:45:00 0.072 0.227 0.087 0.383  1.419      0
dao  | 78   11:00 2026-03-27 11:00:00 0.086 0.245 0.104 0.402  1.370      0
dao  | 79   11:15 2026-03-27 11:15:00 0.079 0.237 0.096 0.407  1.359      0
dao  | 80   11:30 2026-03-27 11:30:00 0.071 0.226 0.086 0.412  1.348      0
dao  | 81   11:45 2026-03-27 11:45:00 0.062 0.215 0.075 0.404  1.302      0
dao  | 82   12:00 2026-03-27 12:00:00 0.073 0.229 0.088 0.365  1.247      0
dao  | 83   12:15 2026-03-27 12:15:00 0.067 0.222 0.081 0.357  1.201      0
dao  | 84   12:30 2026-03-27 12:30:00 0.062 0.216 0.075 0.349  1.155      0
dao  | 85   12:45 2026-03-27 12:45:00 0.057 0.210 0.069 0.428  1.045      0
dao  | 86   13:00 2026-03-27 13:00:00 0.062 0.216 0.075 0.612  0.885      0
dao  | 87   13:15 2026-03-27 13:15:00 0.059 0.212 0.071 0.691  0.775      0
dao  | 88   13:30 2026-03-27 13:30:00 0.057 0.210 0.069 0.769  0.665      0
dao  | 89   13:45 2026-03-27 13:45:00 0.060 0.213 0.072 0.689  0.562      0
dao  | 90   14:00 2026-03-27 14:00:00 0.058 0.211 0.071 0.479  0.440      0
dao  | 91   14:15 2026-03-27 14:15:00 0.067 0.222 0.081 0.399  0.337      0
dao  | 92   14:30 2026-03-27 14:30:00 0.079 0.236 0.095 0.319  0.234      0
dao  | 93   14:45 2026-03-27 14:45:00 0.085 0.243 0.102 0.286  0.225      0
dao  | 94   15:00 2026-03-27 15:00:00 0.079 0.236 0.095 0.284  0.290      0
dao  | 95   15:15 2026-03-27 15:15:00 0.092 0.252 0.111 0.252  0.281      0
dao  | 96   15:30 2026-03-27 15:30:00 0.095 0.256 0.115 0.219  0.272      0
dao  | 97   15:45 2026-03-27 15:45:00 0.103 0.266 0.125 0.209  0.253      0
dao  | 98   16:00 2026-03-27 16:00:00 0.091 0.251 0.110 0.200  0.229      0
dao  | 99   16:15 2026-03-27 16:15:00 0.100 0.262 0.121 0.189  0.210      0
dao  | 100  16:30 2026-03-27 16:30:00 0.101 0.263 0.122 0.178  0.191      0
dao  | 101  16:45 2026-03-27 16:45:00 0.120 0.286 0.145 0.225  0.158      0
dao  | 102  17:00 2026-03-27 17:00:00 0.098 0.259 0.118 0.324  0.111      0
dao  | 103  17:15 2026-03-27 17:15:00 0.122 0.289 0.148 0.370  0.078      0
dao  | 104  17:30 2026-03-27 17:30:00 0.139 0.309 0.168 0.417  0.046      0
dao  | 105  17:45 2026-03-27 17:45:00 0.173 0.350 0.209 0.428  0.030      0
dao  | 106  18:00 2026-03-27 18:00:00 0.140 0.311 0.170 0.424  0.022      0
dao  | 107  18:15 2026-03-27 18:15:00 0.153 0.326 0.185 0.435  0.005      0
dao  | 108  18:30 2026-03-27 18:30:00 0.163 0.338 0.197 0.446  0.000      0
dao  | 109  18:45 2026-03-27 18:45:00 0.167 0.343 0.202 0.413  0.000      0
dao  | 110  19:00 2026-03-27 19:00:00 0.192 0.374 0.233 0.343  0.001      0
dao  | 111  19:15 2026-03-27 19:15:00 0.177 0.355 0.214 0.310  0.001      0
dao  | 112  19:30 2026-03-27 19:30:00 0.158 0.332 0.191 0.278  0.001      0
dao  | 113  19:45 2026-03-27 19:45:00 0.144 0.315 0.174 0.264  0.001      0
dao  | 114  20:00 2026-03-27 20:00:00 0.175 0.352 0.211 0.266  0.001      0
dao  | 115  20:15 2026-03-27 20:15:00 0.150 0.322 0.181 0.252  0.001      0
dao  | 116  20:30 2026-03-27 20:30:00 0.127 0.294 0.153 0.239  0.001      0
dao  | 117  20:45 2026-03-27 20:45:00 0.119 0.285 0.144 0.224  0.001      0
dao  | 118  21:00 2026-03-27 21:00:00 0.123 0.290 0.149 0.210  0.001      0
dao  | 119  21:15 2026-03-27 21:15:00 0.122 0.289 0.148 0.195  0.001      0
dao  | 120  21:30 2026-03-27 21:30:00 0.120 0.286 0.145 0.181  0.001      0
dao  | 121  21:45 2026-03-27 21:45:00 0.110 0.273 0.133 0.164  0.001      0
dao  | 122  22:00 2026-03-27 22:00:00 0.123 0.290 0.149 0.142  0.001      0
dao  | 123  22:15 2026-03-27 22:15:00 0.118 0.283 0.143 0.125  0.001      0
dao  | 124  22:30 2026-03-27 22:30:00 0.118 0.283 0.142 0.108  0.001      0
dao  | 125  22:45 2026-03-27 22:45:00 0.108 0.272 0.131 0.100  0.001      0
dao  | 126  23:00 2026-03-27 23:00:00 0.114 0.278 0.138 0.098  0.001      0
dao  | 127  23:15 2026-03-27 23:15:00 0.107 0.270 0.129 0.090  0.001      0
dao  | 128  23:30 2026-03-27 23:30:00 0.105 0.268 0.127 0.082  0.001      0
dao  | 129  23:45 2026-03-27 23:45:00 0.098 0.260 0.119 0.073  0.001      0
dao  | 2026-03-26 15:30:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
dao  | 2026-03-26 15:30:00 info: Instellingen voor laden van EV: Jeep Avenger Elektro
dao  | 2026-03-26 15:30:00 info: Direct laden is uit
dao  | 2026-03-26 15:30:00 info:  Ampere  Effic. Grid kW Accu kW
dao  | 2026-03-26 15:30:00 info:    0.00    1.00    0.00    0.00
dao  | 2026-03-26 15:30:00 info:    6.00    0.95    4.14    3.93
dao  | 2026-03-26 15:30:00 info:   10.00    1.00    6.90    6.90
dao  | 2026-03-26 15:30:00 info:   13.00    0.95    8.97    8.52
dao  | 2026-03-26 15:30:00 info:   16.00    0.92   11.04   10.16
dao  | 2026-03-26 15:30:00 info: Capaciteit accu: 58.0 kWh
dao  | 2026-03-26 15:30:00 info: Maximaal laadvermogen: 11.04 kW
dao  | 2026-03-26 15:30:00 info: Klaar met laden op: 27-03-2026 07:00:00
dao  | 2026-03-26 15:30:00 info: Huidig laadniveau: 44.0 %
dao  | 2026-03-26 15:30:00 info: Gewenst laadniveau:100.0 %
dao  | 2026-03-26 15:30:00 info: Marge voor het laden: 1 %
dao  | 2026-03-26 15:30:00 info: Locatie: home
dao  | 2026-03-26 15:30:00 info: Ingeplugged:False
dao  | 2026-03-26 15:30:00 info: Benodigde netto energie: 32.480 kWh
dao  | 2026-03-26 15:30:00 info: Tijd nodig om te laden: 3:12 uur
dao  | 2026-03-26 15:30:00 info: Afgerond naar hele intervallen: 13 kwartier
dao  | 2026-03-26 15:30:00 info: Stand laden schakelaar: off
dao  | 2026-03-26 15:30:00 info: Stand aantal ampere laden: 10.0 A
dao  | 2026-03-26 15:30:00 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd.
dao  | 2026-03-26 15:30:00 info: Gewogen graaddagen vandaag: 12.9 K.day
dao  | 2026-03-26 15:30:00 info: Gewogen graaddagen morgen: 11.1 K.day
dao  | 2026-03-26 15:30:00 info: Gewogen graaddagen totaal: 24.0 K.day
dao  | 2026-03-26 15:30:00 info: Degree days factor: 4.8 kWh/K.day
dao  | 2026-03-26 15:30:00 info: Totaal benodigde warmte: 114.8 kWh
dao  | 2026-03-26 15:30:00 info: Reeds geproduceerde warmte: 31.4 kWh
dao  | 2026-03-26 15:30:00 info: Nog benodigde warmte: 83.4 kWh
dao  | 2026-03-26 15:30:00 info: Regeling warmtepomp: on/off
dao  | 2026-03-26 15:30:00 info: Actuele warmtevraag: max
dao  | 2026-03-26 15:30:00 info: Minimale runlengte 1 uur
dao  | 2026-03-26 15:30:00 info: Beschikbaar zijn: 32 uur
dao  | 2026-03-26 15:30:00 info: On/off warmtepomp wordt ingepland
dao  | 2026-03-26 15:30:00 info: Gem. buitentemperatuur vandaag: 3.1 °C
dao  | 2026-03-26 15:30:00 info: Gem. buitentemperatuur morgen: 4.9 °C
dao  | 2026-03-26 15:30:00 info: Voorspelde gemiddelde buiten temperatuur: 4.0 °C
dao  | 2026-03-26 15:30:00 info: COP: 4.2
dao  | 2026-03-26 15:30:00 info: Elektrisch vermogen: 0.9 kW-e
dao  | 2026-03-26 15:30:00 info: Thermisch vermogen: 3.8 kW-th
dao  | 2026-03-26 15:30:00 info: Ingepland worden: 23 uur
dao  | 2026-03-26 15:30:00 info: Warmtepomp draait al minimaal 5 uur
dao  | 2026-03-26 15:30:00 info: Eerste blok van 1 uur
dao  | 2026-03-26 15:30:00 info: Dan nog 22 blokken van 1 uur
dao  | 2026-03-26 15:30:00 info: Totaal aantal blokken: 23
dao  | 2026-03-26 15:30:00 info: Apparaat wasmachine direct starten staat uit
dao  | 2026-03-26 15:30:00 info: Apparaat wasmachine met programma 'Donker 40 graden' wordt ingepland tussen 2026-03-26 15:30 en 2026-03-26 18:00.
dao  | 2026-03-26 15:30:00 info: Strategie: minimale kosten
dao  | 2026-03-26 15:30:00 info: Maximale fout (maximal gap): 0.005000 euro
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 6 leaked semlock objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 2 leaked folder objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_f9deac5f342b477fb01aa3b6e99612d0: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_1b08dc821ed840f5937291e4edf5ae71: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")

WP: DeWarmte PompAO 6.4Kw Hybrid, CV Intergas, Thermostaat Netatmo, 70m2 vvw, PV: 34x 325wp solaredge omvormer en optimizers,Wan ip adres weten? https://mijnips.eu

Joos74 schreef op donderdag 26 maart 2026 @ 14:06:
[...]


Ja, de berekeningen uitvoeren gaat allemaal prima.
Dit vind ik heel uitzonderlijk.
Dezelfde functie wordt ook aangeroepen als je een berekening uitvoert.
En dan geen fouten.
Heb je de prijzen van morgen al opgehaald?
Zou je misschien de prijzen van vandaag en morgen opnieuw willen ophalen: forceren door het eerste datumveld in te vullen.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

f.welvering schreef op donderdag 26 maart 2026 @ 16:08:
Ik krijg na de rc5 helemaal geen optimalisatie berekening meer.
Hij eindigd met de volgende fout:
code:
1
2
3
4
5
6
7
8
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 6 leaked semlock objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 2 leaked folder objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_f9deac5f342b477fb01aa3b6e99612d0: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_1b08dc821ed840f5937291e4edf5ae71: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
Volledige log:

[...]
Rekent ie nog wel in de productie versie?
Heb je daar ook een log van van ongeveer hetzelfde tijdstip?
Ik heb (na testen) de nieuwste versie van mip in rc5 opgenomen.
Misschien dat die fout gaat.
Vandaar mijn vraag naar het rekenen in de productieversie.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
f.welvering schreef op donderdag 26 maart 2026 @ 16:08:
Ik krijg na de rc5 helemaal geen optimalisatie berekening meer.
Hij eindigd met de volgende fout:
code:
1
2
3
4
5
6
7
8
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 6 leaked semlock objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:359: UserWarning: resource_tracker: There appear to be 2 leaked folder objects to clean up at shutdown
dao  |   warnings.warn(
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_f9deac5f342b477fb01aa3b6e99612d0: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
dao  | /root/dao/venv/day_ahead/lib/python3.13/site-packages/joblib/externals/loky/backend/resource_tracker.py:375: UserWarning: resource_tracker: /tmp/joblib_memmapping_folder_13_f1c1c51773d443138cc61d7cefdce0ce_1b08dc821ed840f5937291e4edf5ae71: FileNotFoundError(2, 'No such file or directory')
dao  |   warnings.warn(f"resource_tracker: {name}: {e!r}")
Volledige log:

[...]
Die joblib meldingen is exact op het punt dat de mip solver runt.
Het enige wat ik me hier bij kan voorstellen is dat er iets is met de update van python-mip

@KC27 heb jij enig idee? We hebben wel een update gedaan van mip van 1.17.5 naar 1.17.6.

  • Joos74
  • Registratie: Januari 2025
  • Laatst online: 08:56
KC27 schreef op donderdag 26 maart 2026 @ 19:48:
[...]

Dit vind ik heel uitzonderlijk.
Dezelfde functie wordt ook aangeroepen als je een berekening uitvoert.
En dan geen fouten.
Heb je de prijzen van morgen al opgehaald?
Zou je misschien de prijzen van vandaag en morgen opnieuw willen ophalen: forceren door het eerste datumveld in te vullen.
Ik vind het ook raar - heb al het een en ander geprobeerd, zoals de productieversie opnieuw installeren (en dan ook opnieuw de day ahead-prijzen en weerprognose ophalen), de laatste release candidate geïnstalleerd, enzovoort. Dat lijkt allemaal geen verschil te maken - steeds dezelfde fout als ik op 'Reports' klik.

Het enige wat mij opvalt is dat er in de foutmelding sprake is van interval="1hour", terwijl ik DAO op kwartierintervallen heb ingesteld. Misschien is dat niet zoals het hoort? Geen idee, eerlijk gezegd.

Hieronder het laatste deel van de logging voor een berekening zonder debug:
2026-03-26 20:29:08 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 696 in /root/dao/prog/da_base.py
2026-03-26 20:29:08 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 4703 in /root/dao/webserver/../prog/day_ahead.py
2026-03-26 20:28:58 INFO: Loaded 6 secrets from ../data/secrets.json
2026-03-26 20:28:58 INFO: Validating configuration with ConfigurationV0
2026-03-26 20:28:58 debug: Starting new HTTP connection (1): supervisor:80
2026-03-26 20:28:58 debug: http://supervisor:80 "GET /core/api/ HTTP/1.1" 200 26
2026-03-26 20:28:58 debug: Starting new HTTP connection (1): supervisor:80
2026-03-26 20:28:58 debug: http://supervisor:80 "GET /core/api/config HTTP/1.1" 200 3505
2026-03-26 20:28:58 debug: hass/api/config: {"allowlist_external_dirs":["/media","/config/www"],"allowlist_external_urls":[],"components":["zha.lock","persistent_notification","update","timer","tag","zha.cover","homeassistant_hardware","home_connect.button","sun.sensor","home_connect.sensor","person","input_boolean","number","plugwise.number","config","diagnostics","counter","event","history","mobile_app","zha.switch","frigate.select","influxdb","hardware","homeconnect_ws.binary_sensor","mobile_app.device_tracker","frigate.camera","zha.binary_sensor","home_connect.light","zha.alarm_control_panel","sun","dhcp","fan","tts","assist_pipeline","hassio.sensor","modbus.sensor","ffmpeg","frontend","usage_prediction","ipp","onboarding","input_text","home_connect","mobile_app.notify","ipp.sensor","alarm_control_panel","bluetooth","renault.select","webhook","siren","renault.device_tracker","search","renault.binary_sensor","frigate.binary_sensor","zha.sensor","homeassistant_alerts","system_log","hacs.update","input_datetime","my","light","backup.event","zone","plugwise.sensor","home_connect.binary_sensor","sun.binary_sensor","lock","file_upload","enphase_envoy.select","auth","enphase_envoy.binary_sensor","zha.button","scene","awair.sensor","zha.fan","enphase_envoy","template.switch","button","notify","usb","integration","home_connect.switch","intent","input_button","brother.sensor","hassio.switch","dsmr","http","weather","backup","renault.sensor","enphase_envoy.sensor","renault.button","upnp","device_automation","media_source","zha.siren","brother","ssdp","homeassistant","image_upload","homeconnect_ws.sensor","met.weather","plugwise.climate","template","wake_word","sensor","homeconnect_ws","lovelace","home_connect.number","homeconnect_ws.switch","input_number","home_connect.select","energy","frigate.number","plugwise.button","recorder","system_health","climate","hassio","homeconnect_ws.button","labs","frigate","modbus","go2rtc","hassio.binary_sensor","plugwise.binary_sensor","repairs","zha.climate","web_rtc","hassio.update","plugwise.switch","network","upnp.sensor","utility_meter.sensor","select","homeassistant.scene","image","brands","stream","device_tracker","integration.sensor","zha.number","blueprint","mobile_app.sensor","mqtt.sensor","mobile_app.binary_sensor","template.sensor","mqtt","renault","cover","homeconnect_ws.select","script","zha.light","plugwise","frigate.image","zha.select","dsmr.sensor","cloud","logger","binary_sensor","zha.update","energy.sensor","cloud.tts","utility_meter","analytics","rest_command","switch","zha","frigate.switch","met","stt","file","trace","homeconnect_ws.number","plugwise.select","frigate.update","upnp.binary_sensor","application_credentials","hacs","default_config","zha.device_tracker","awair","automation","frigate.sensor","logbook","schedule","enphase_envoy.number","api","enphase_envoy.switch","zeroconf","hacs.switch","input_select","conversation","websocket_api","backup.sensor","camera"],"config_dir":"/config","config_source":"storage","country":"NL","currency":"EUR","debug":false,"elevation":0,"external_url":null,"internal_url":null,"language":"en-GB","latitude":52.26866785354114,"location_name":"Home","longitude":6.192913530383817,"radius":34,"recovery_mode":false,"safe_mode":false,"state":"RUNNING","time_zone":"Europe/Amsterdam","unit_system":{"length":"km","accumulated_precipitation":"mm","area":"m²","mass":"g","pressure":"Pa","temperature":"°C","volume":"L","wind_speed":"m/s"},"version":"2026.3.4","whitelist_external_dirs":["/media","/config/www"]}
2026-03-26 20:28:58 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 198 in /root/dao/prog/da_base.py
Joos74 schreef op donderdag 26 maart 2026 @ 20:32:
[...]


Ik vind het ook raar - heb al het een en ander geprobeerd, zoals de productieversie opnieuw installeren (en dan ook opnieuw de day ahead-prijzen en weerprognose ophalen), de laatste release candidate geïnstalleerd, enzovoort. Dat lijkt allemaal geen verschil te maken - steeds dezelfde fout als ik op 'Reports' klik.

Het enige wat mij opvalt is dat er in de foutmelding sprake is van interval="1hour", terwijl ik DAO op kwartierintervallen heb ingesteld. Misschien is dat niet zoals het hoort? Geen idee, eerlijk gezegd.

Hieronder het laatste deel van de logging voor een berekening zonder debug:


[...]
Welke database engine gebruik je?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Joos74
  • Registratie: Januari 2025
  • Laatst online: 08:56
KC27 schreef op donderdag 26 maart 2026 @ 20:49:
[...]

Welke database engine gebruik je?
Volgens mij gewoon SQLite:
{
"config_version": 0,
"homeassistant": {
"ip_address": "supervisor",
"protocol_api": "http"
},
"database_ha": {
"engine": "sqlite",
"db_path": "/homeassistant",
"database": "home-assistant_v2.db"
},
"database_da": {
"engine": "sqlite",
"db_path": "../data",
"database": "day_ahead.db"
},
"meteoserver_key": "!secret meteoserver-key",
"meteoserver_model": "harmonie",
"meteoserver_attemps": 2,
"prices": {
"source_day_ahead": "nordpool",
"energy_taxes_consumption": {
"2022-01-01": 0.06729,
"2023-01-01": 0.12599,
"2024-01-01": 0.1088,
"2025-01-01": 0.10154
},
"energy_taxes_production": {
"2022-01-01": 0.06729,
"2023-01-01": 0.12599,
"2024-01-01": 0.1088,
"2025-01-01": 0.10154
},
"cost_supplier_consumption": {
"2022-01-01": 0.002,
"2023-03-01": 0.018,
"2024-04-01": 0.0175,
"2024-08-01": 0.020496
},
"cost_supplier_production": {
"2022-01-01": 0.002,
"2023-03-01": 0.018,
"2024-04-01": 0.0175,
"2024-08-01": 0.020496
},
"vat_consumption": {
"2022-01-01": 21,
"2022-07-01": 9,
"2023-01-01": 21
},
"vat_production": {
"2022-01-01": 21,
"2022-07-01": 9,
"2023-01-01": 21
},
"last_invoice": "2025-09-01",
"tax_refund": true
},
"logging_level": "debug",
"use_calc_baseload": true,
"baseload_calc_periode": 40,
"baseload": [
0.3,
0.3,
0.3,
0.3,
0.3,
0.3,
0.4,
0.45,
0.45,
0.4,
0.4,
0.4,
0.4,
0.4,
0.4,
0.45,
0.5,
0.9,
0.9,
0.7,
0.5,
0.5,
0.4,
0.3
],
"graphical_backend": "",
"graphics": {
"style": "Solarize_Light2",
"battery_balance": true,
"prices_consumption": true,
"prices_production": false,
"prices_spot": true,
"average_consumption": true,
"show": "true"
},
"interval": "15min",
"strategy": "minimize cost",
"max_gap": 0.005,
"notifications": {
"opstarten": false,
"berekening": false
},
"grid": {
"max_power": 17.0
},
"history": {
"save_days": 7
},
"dashboard": {
"port": 5000
},
"battery": [
{
"name": "Marstek Venus-E",
"entity_actual_level": "sensor.my_battery_battery_soc",
"capacity": 5.12,
"upper_limit": 100,
"lower_limit": 12,
"penalty_low_soc": 0.0025,
"charge_stages": [
{
"power": 0.0,
"efficiency": 1.0
},
{
"power": 200.0,
"efficiency": 0.5
},
{
"power": 300.0,
"efficiency": 0.71
},
{
"power": 500.0,
"efficiency": 0.82
},
{
"power": 1000.0,
"efficiency": 0.91
},
{
"power": 2000.0,
"efficiency": 0.945
},
{
"power": 2500.0,
"efficiency": 0.948
}
],
"discharge_stages": [
{
"power": 0.0,
"efficiency": 1.0
},
{
"power": 500.0,
"efficiency": 0.7855
},
{
"power": 1000.0,
"efficiency": 0.8414
},
{
"power": 2500.0,
"efficiency": 0.8514
}
],
"reduce_power_low_soc": [],
"reduce_power_high_soc": [],
"minimum_power": 300,
"dc_to_bat_efficiency": 0.935,
"dc_to_bat_max_power": 2500.0,
"bat_to_dc_efficiency": 0.935,
"cycle_cost": 0.0005,
"entity_set_power_feedin": "input_number.my_battery_discharging_charging_power",
"entity_set_operating_mode": "input_select.dao_marstek1_mode",
"entity_set_operating_mode_on": "Aan",
"entity_set_operating_mode_off": "Uit",
"entity_stop_inverter": "input_datetime.dao_entity_stop_inverter",
"entity_calculated_soc": "input_number.dao_entity_calculated_soc",
"solar": [],
"bat_to_dc max power": 2500
}
],
"solar": [
{
"name": "WHL",
"tilt": 35.0,
"orientation": 0.0,
"capacity": 5.85,
"yield_factor": 0.0115,
"strings": [],
"ml_prediction": false,
"entities_sensors": [
"sensor.kwh_from_pv"
]
}
],
"electric_vehicle": [
{
"name": "Megane",
"capacity": 9.8,
"entity_position": "input_select.dao_megane_position",
"charge_three_phase": "false",
"charge_stages": [
{
"ampere": 0,
"efficiency": 0.0
},
{
"ampere": 10,
"efficiency": 0.9
}
],
"entity_actual_level": "sensor.r388bf_battery",
"entity_plugged_in": "input_boolean.dao_megane_plugged_in",
"charge_scheduler": {
"entity_set_level": "input_number.dao_megane_target_soc",
"level_margin": 4,
"entity_ready_datetime": "input_datetime.dao_megane_charged_at"
},
"charge_switch": "input_boolean.dao_megane_charge_switch",
"entity_set_charging_ampere": "input_number.dao_megane_charge_ampere"
}
],
"machines": [
{
"name": "vaatwasser",
"programs": [
{
"name": "off",
"power": []
},
{
"name": "eco",
"power": [
25.0,
1500.0,
1750.0,
25.0,
25.0,
25.0,
25.0,
25.0,
25.0,
25.0,
1900.0,
10.0,
10.0,
10.0,
10.0
]
}
],
"entity_start_window": "input_datetime.start_window_vaatwasser",
"entity_end_window": "input_datetime.end_window_vaatwasser",
"entity_selected_program": "input_select.dao_program_vaatwasser",
"entity_calculated_start": "input_datetime.calculated_start_vaatwasser",
"entity_calculated_end": "input_datetime.calculated_stop_vaatwasser"
}
],
"boiler": {
"boiler_present": false,
"entity actual temp.": "sensor.boiler_gemeten",
"entity setpoint": "sensor.boiler_ingesteld",
"entity hysterese": "sensor.hysterese_hot_water",
"cop": 2.9,
"cooling rate": 0.4,
"volume": 180,
"heating allowed below": 44,
"elec. power": 1500,
"activate service": "press",
"activate entity": "input_button.hw_trigger"
},
"heating": {
"heater_present": false,
"degree days factor": 3.6,
"stages": [
{
"max_power": 225,
"cop": 7.1
},
{
"max_power": 300,
"cop": 7.0
},
{
"max_power": 400,
"cop": 6.5
},
{
"max_power": 500,
"cop": 6.0
},
{
"max_power": 600,
"cop": 5.5
},
{
"max_power": 750,
"cop": 5.0
},
{
"max_power": 1000,
"cop": 4.5
},
{
"max_power": 1250,
"cop": 4.0
}
],
"entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
"adjustment factor": 0.04
},
"tibber": {
"api_token": "!secret tibber_api_token",
"api_url": "https://api.tibber.com/v1-beta/gql"
},
"xgboost": {
"tune_hyperparameters": true
},
"report": {
"entities_grid_consumption": [
"sensor.electricity_meter_energy_consumption_tarifd_1",
"sensor.electricity_meter_energy_consumption_tariff_2"
],
"entities_grid_production": [
"sensor.electricity_meter_energy_consumption_tariff_1",
"sensor.electricity_meter_energy_consumption_tariff_2"
],
"entities_solar_production_ac": [
"sensor.envoy_122023044357_lifetime_energy_production"
],
"entities_solar_production_dc": [],
"entities_ev_consumption": [
"sensor.tz3000_266azbg3_ts011f_summation_delivered"
],
"entities_wp_consumption": [],
"entities_boiler_consumption": [],
"entities_battery_consumption": [
"sensor.my_battery_charging_in_kwh"
],
"entities_battery_production": [
"sensor.my_battery_discharging_in_kwh"
],
"entities_machine_consumption": []
},
"scheduler": {
"active": true,
"schedule": [
{
"time": "xx00",
"action": "calc_optimum"
},
{
"time": "xx15",
"action": "calc_optimum"
},
{
"time": "xx30",
"action": "calc_optimum"
},
{
"time": "xx45",
"action": "calc_optimum"
},
{
"time": "0425",
"action": "get_meteo_data"
},
{
"time": "1025",
"action": "get_meteo_data"
},
{
"time": "1625",
"action": "get_meteo_data"
},
{
"time": "2225",
"action": "get_meteo_data"
},
{
"time": "1255",
"action": "get_day_ahead_prices"
},
{
"time": "1355",
"action": "get_day_ahead_prices"
},
{
"time": "1455",
"action": "get_day_ahead_prices"
},
{
"time": "1555",
"action": "get_day_ahead_prices"
},
{
"time": "1655",
"action": "get_day_ahead_prices"
},
{
"time": "2231",
"action": "calc_baseloads"
},
{
"time": "2301",
"action": "train_ml_predictions"
},
{
"time": "2359",
"action": "clean_data"
}
]
}
}
Ik heb HAOS draaien in een VM op Proxmox, met DAO als addon / app. Niks speciaals, dacht ik.

  • simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
Joos74 schreef op donderdag 26 maart 2026 @ 20:51:
[...]


Volgens mij gewoon SQLite:


[...]


Ik heb HAOS draaien in een VM op Proxmox, met DAO als addon / app. Niks speciaals, dacht ik.
Ik heb een vermoeden waar het zit. Kom er op terug!
Joos74 schreef op donderdag 26 maart 2026 @ 20:51:
[...]


Volgens mij gewoon SQLite:


[...]


Ik heb HAOS draaien in een VM op Proxmox, met DAO als addon / app. Niks speciaals, dacht ik.
Hebben deze sensoren allemaal waarden voor vandaag:
code:
1
2
3
4
5
6
7
8
"entities_grid_consumption": [
"sensor.electricity_meter_energy_consumption_tarifd_1",
"sensor.electricity_meter_energy_consumption_tariff_2"
],
"entities_grid_production": [
"sensor.electricity_meter_energy_consumption_tariff_1",
"sensor.electricity_meter_energy_consumption_tariff_2"
],
Staat er geen typo in :"sensor.electricity_meter_energy_consumption_tarifd_1",

Heb je ze ook in het Energy Dashboard van HA en staan ze daar ook allemaal in?
Worden er ook gelijkblijvende standen in de database opgeslagen als er geen verbruik/productie in dat uur is?

[ Voor 14% gewijzigd door KC27 op 26-03-2026 22:01 ]

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • balk
  • Registratie: Januari 2000
  • Laatst online: 08:03
KC27 schreef op woensdag 25 maart 2026 @ 21:07:
[...]

Kun je die ml training via scheduler nog eens doen met loglevel op info?
dat werkt wel!
En werkt de rest nu ook allemaal goed?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Joos74
  • Registratie: Januari 2025
  • Laatst online: 08:56
KC27 schreef op donderdag 26 maart 2026 @ 21:51:
[...]

Hebben deze sensoren allemaal waarden voor vandaag:
code:
1
2
3
4
5
6
7
8
"entities_grid_consumption": [
"sensor.electricity_meter_energy_consumption_tarifd_1",
"sensor.electricity_meter_energy_consumption_tariff_2"
],
"entities_grid_production": [
"sensor.electricity_meter_energy_consumption_tariff_1",
"sensor.electricity_meter_energy_consumption_tariff_2"
],
Staat er geen typo in :"sensor.electricity_meter_energy_consumption_tarifd_1",

Heb je ze ook in het Energy Dashboard van HA en staan ze daar ook allemaal in?
Worden er ook gelijkblijvende standen in de database opgeslagen als er geen verbruik/productie in dat uur is?
Sowieso twee fouten: de typo, en sensor.electricity_meter_energy_production_tariff_1 (ipv sensor.electricity_meter_energy_consumption_tariff_1)... Komt door mijn aanpassingen ivm het overstappen naar een 3-fasen-aansluiting.

Ik ga kijken naar de waarden in het energy dashboard, en in de database.

Dank alvast!
thesaxofonist schreef op donderdag 26 maart 2026 @ 13:48:
[...]

Ik weet niet of we elkaar goed begrijpen. Ik kan DAO gebruiken (als input) om de batterij aan te sturen. Dat gaat me wel lukken en is het probleem niet.

Maar mijn batterij kan niet laden vanuit het net. Ik wil voorkomen dat DAO de batterij ontlaadt (omdat het tarief hoog is) en de lege batterij even later wil opladen vanuit het net (bijvoorbeeld omdat het tarief dan negatief is). Mijn batterij zal keurig gaan ontladen, maar het laden lukt hem niet (behalve als er op dat moment ook PV is).

DAO wil slim laden en ontladen. Maar het laden is bij mij beperkt tot de PV-opbrengst.

Mijn vraag is of ik dat ergens in het model kan invoeren. Kan er bijvoorbeeld ingesteld worden dat grid-to-battery maximaal nul mag zijn? Bijvoorbeeld bij de hybride omvormer? Of gaat hij er vanuit dat max-grid-to-battery gelijk is aan max-PV-to-battery?
Nu valt het kwartje: je hebt een hybride pv-omvormer waarop je pv-panelen en een batterij zijn aangesloten.
Die omvormer kan alleen terugleveren.
Dat kun je in DAO vrij eenvoudig definiëren door maar 1 charge-stage te definiëren:
code:
1
2
3
4
5
6
"charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        }
 ]
En je configureert je panelen natuurlijk binnen de batterij.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Karpertje
  • Registratie: Januari 2013
  • Laatst online: 06-05 14:37
KC27 schreef op woensdag 25 maart 2026 @ 19:06:
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.
Breaking change
The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:
  • Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
  • Then install the new release (or when you allready have installed restart the addon/app)
  • Look in the logging off the app/addon if you see errors during the conversion.
Most important changes in the config/options.json:<br>
  • all booleans are now noted as true or false: no "True" or "False" anymore.
  • changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
  • removed "show_graph" from settings
  • implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
  • (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"
These errors are fixed:
  • defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
  • default for ev "entity stop charging" (none)
  • boiler activate service must have a value if boiler activate entity is set
  • removed the requirement off stages from heating when adjustement is on/off
  • when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
  • if scheduler active = true is not present it will be set to true
Top dat wind is toegevoegd! Heb de test versie geinstalleerd en één dag aan het draaien (testopstelling zonder de accu aan te sturen) maar lijkt aardig goed te gaan. Het is wel zo dat de PV panelen snachts in de ML berekening ook nog aan het leveren zijn omdat wind is toegevoegd, het is niet veel maar wel een beetje. Ook levert de windmolen iets wanneer het windstil is en de zon schijnt, het is ook niet veel maar wel een beetje.
Binnenkort zal ik de accu rechtstreeks proberen aan te sturen met DAO, maar wil eerst zien wat er allemaal gebeurt omdat wij niet kunnen salderen, maar wel dynamische energieprijzen hebben. Daarom heb ik in de strategy ook op minimize consumption staan.

Het enige waar ik nu tegen aan loop is dat er bij ons verschil in zit wat wij van het net mogen gebruiken en wat wij terug mogen leveren qua kWh. Ik zie dat grid max_power voor zowel terugleveren als leveren ingesteld wordt. Is hier een manier voor om dit apart in te stellen? Of zie ik wat over het hoofd?

  • simnet
  • Registratie: Januari 2020
  • Laatst online: 06-05 19:32
Karpertje schreef op vrijdag 27 maart 2026 @ 10:07:
[...]


Top dat wind is toegevoegd! Heb de test versie geinstalleerd en één dag aan het draaien (testopstelling zonder de accu aan te sturen) maar lijkt aardig goed te gaan. Het is wel zo dat de PV panelen snachts in de ML berekening ook nog aan het leveren zijn omdat wind is toegevoegd, het is niet veel maar wel een beetje. Ook levert de windmolen iets wanneer het windstil is en de zon schijnt, het is ook niet veel maar wel een beetje.
Dat is een sideeffect van de machine learning. Dat had @KC27 ondervangen door te filteren op zon stralin, maar in jouw geval is dat juist niet gewenst.
Ik zie een ml_options met een optionele: ml_filter: [ solar | wind ] optie nog wel gebeuren. Die filtert dan op de juiste waardes. Misschien zelfs het toevoegen van een ml_filter_threshold (ook solar heeft een minimaal vermogen nodig omdat de inverters vaak vanuit de panelen gevoed worden.)
Maar dat lijkt me een feature request voor @KC27

  • BertSmelik
  • Registratie: Oktober 2022
  • Laatst online: 04-05 16:22

Marstek via HBC aansturen vanuit DAO

Een vraag over het aansturen van Marstek batterijen door DAO via HBC.
Heeft iemand hier ooit naar gekeken?
Achtergrond
Ik heb 2 x Venus 3 batterijen die ik nu aanstuur met HBC (Home Battery Control).
Deze HA applicatie stuurt de batterijen aan via Modbus en dat gaat best erg goed.
Waar HBC niet zo sterk in is in het inventariseren van het hele energieplaatje van je huis en op basis daarvan te plannen wat je wanneer moet doen. Daarin is DAO veel beter.
Wat ik nu wil doen is DAO te laten plannen, waarbij beide batterijen als één batterij wordt behandeld. De resultaten van DAO wil ik dan aanbieden aan HBC om die uiteindelijk de batterijen aan te sturen.
HBC laadstrategiëen
HBC heeft de volgende strategiëen:
  1. Full stop
  2. Self-consumtion
  3. Timed
  4. Dynamic
  5. Charge
  6. Charge PV
  7. Sell
een paar toelichtingen:
Self-consumtion
deze strategie mikt vooral op NOM. Er wordt geladen/ontladen afhankelijk wat de P1 meter aangeeft. Geprobeerd wordt om de opgewekte energie in de batterij op te slaan en niet naar het net te sturen. Uiteraard dus ook om de energie in de batterij voor eigen gebruik in te zetten.
Timed
laden/ontladen volgens een vast tijdschema
Dynamic
laden/ontladen op de tijden dat stroom goedkoop resp. duur is (lijkt een beetje op wat DAO doet maar lang niet zo krachtig)
Charge
recht vooruit laden (dus van het net én vanuit de PV's)
Charge PV
Laden vanaf alleen de PV's (dus niet van het net).
Sell
hierin wordt voluit ontlaten, dus ook (en vooral) naar het net.
Vragen
Ik zou graag weten welke uitslagen van DAO gekoppeld kunnen worden aan de strategiëen van HBC.
Met name zou ik beter willen begrijpen wat "Balance" precies betekent.
Ideëen en suggesties zijn meer dan welkom!

  • Dogooder
  • Registratie: April 2004
  • Laatst online: 09:00

Dogooder

dus...

Als DAO balanceren aanzet zal je je batterij op wat jij noemt self consumption zetten. Dat komt overeen.
Daarnaast zal je via een automation je charge en sell moeten sturen op basis van Dao power feedin.
Als je niet kan regelen in de power, dan moet je bij power stages slecht 1 stage definiëren. Dan zal Dao de stop inverter gebruiken zodat jij de inverter kan stoppen op het moment dat de juiste hoeveelheid energie is geladen/ontladen in dat kwartier/uur.

  • ErnstH
  • Registratie: September 2003
  • Niet online
Bij mij ontbreken er een aantal waarden voor de day ahead prijzen van morgen (overgang naar zomertijd denk ik), en daarom breekt DAO de berekening af. Wat is de beste manier om hiermee om te gaan?

Ik zie nu dat er ook in October problemen waren met overgang naar wintertijd.. :)

[ Voor 26% gewijzigd door ErnstH op 28-03-2026 14:10 ]


  • Karpertje
  • Registratie: Januari 2013
  • Laatst online: 06-05 14:37
ErnstH schreef op zaterdag 28 maart 2026 @ 14:07:
Bij mij ontbreken er een aantal waarden voor de day ahead prijzen van morgen (overgang naar zomertijd denk ik), en daarom breekt DAO de berekening af. Wat is de beste manier om hiermee om te gaan?

Ik zie nu dat er ook in October problemen waren met overgang naar wintertijd.. :)
Ik heb precies hetzelfde. Heb net de testversie aangezet zodat dao ook de accu kan aansturen, en zat al behoorlijk te klooien om het nu aan de gang te krijgen omdat de day ahead prijzen niet binnen komen van vandaag en morgen tegelijk. Nu breekt hij de berekening inderdaad af.

  • rescla
  • Registratie: November 2012
  • Laatst online: 06:52
Met noordpool kreeg ik een foutmelding vanuit dao, entsoe had een serverfout. Maar met entsoe heb ik nu prijsdata.

  • ErnstH
  • Registratie: September 2003
  • Niet online
rescla schreef op zaterdag 28 maart 2026 @ 15:26:
Met noordpool kreeg ik een foutmelding vanuit dao, entsoe had een serverfout. Maar met entsoe heb ik nu prijsdata.
Ik heb wel prijsdata, maar hier ontbreken dus de uren in tussen 2 en 3 uur 's nachts (wat klopt ivm zomertijd). Volgens mij klapt DAO daarop dus eruit.

  • BertSmelik
  • Registratie: Oktober 2022
  • Laatst online: 04-05 16:22
rescla schreef op zaterdag 28 maart 2026 @ 15:26:
Met noordpool kreeg ik een foutmelding vanuit dao, entsoe had een serverfout. Maar met entsoe heb ik nu prijsdata.
Heb ik ook.
melding: "Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken" .

Vraag: gebruik jij Entsoe als backup? Zo ja, hoe definieer je dat?

  • Karpertje
  • Registratie: Januari 2013
  • Laatst online: 06-05 14:37
rescla schreef op zaterdag 28 maart 2026 @ 15:26:
Met noordpool kreeg ik een foutmelding vanuit dao, entsoe had een serverfout. Maar met entsoe heb ik nu prijsdata.
Heb entsoe ook even geprobeerd, maar dezelfde foutmelding krijg ik.

  • Hvdort
  • Registratie: Mei 2021
  • Laatst online: 30-04 19:56
Inderdaad werkt het met entsoe waarbij er netjes een melding is dat er voor een uur geen prijs informatie is.
Entsoe werkte bij mij in het verleden ook niet altijd. Misschien een idee om beide te kunnen definiëren waarbij automatisch teruggevallen kan worden op een tweede als de eerste hapert?

  • BertSmelik
  • Registratie: Oktober 2022
  • Laatst online: 04-05 16:22
Hvdort schreef op zaterdag 28 maart 2026 @ 15:48:
Inderdaad werkt het met entsoe waarbij er netjes een melding is dat er voor een uur geen prijs informatie is.
Entsoe werkte bij mij in het verleden ook niet altijd. Misschien een idee om beide te kunnen definiëren waarbij automatisch teruggevallen kan worden op een tweede als de eerste hapert?
@KC27 Goed idee!
Er komt binnen uur een nieuwe stabiele versie aan, die de zomertijd->wintertijd fout corrigeert.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Sorry ik krijg het niet zo snel voor elkaar om een nieuwe stabiele versie te maken (blijft hangen in een GitHub workflow).
Je kunt de fout omzeilen door tijdelijk je interval op "1hour" te zetten. Na vannacht 2 uur kun je het weer op 15min zetten.
Sorry voor het ongemak.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Noshi
  • Registratie: Januari 2007
  • Laatst online: 06:42
KC27 schreef op zaterdag 28 maart 2026 @ 16:46:
Sorry ik krijg het niet zo snel voor elkaar om een nieuwe stabiele versie te maken (blijft hangen in een GitHub workflow).
Je kunt de fout omzeilen door tijdelijk je interval op "1hour" te zetten. Na vannacht 2 uur kun je het weer op 15min zetten.
Sorry voor het ongemak.
Ik gebruik al 1 uur interval en bij mij werkt DAO ook niet (geen data voor morgen). Bedoel je dit misschien andersom?

  • BertSmelik
  • Registratie: Oktober 2022
  • Laatst online: 04-05 16:22
KC27 schreef op zaterdag 28 maart 2026 @ 16:46:
Sorry ik krijg het niet zo snel voor elkaar om een nieuwe stabiele versie te maken (blijft hangen in een GitHub workflow).
Je kunt de fout omzeilen door tijdelijk je interval op "1hour" te zetten. Na vannacht 2 uur kun je het weer op 15min zetten.
Sorry voor het ongemak.
Ik krijg deze fouten in de Supervisor log bij het upgraden:
code:
1
2
3
4
5
2026-03-28 16:44:49.063 INFO (MainThread) [supervisor.docker.addon] Updating image ghcr.io/corneel27/dao-amd64:2026.03.2 to ghcr.io/corneel27/dao-amd64:2026.03.4
2026-03-28 16:44:49.439 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/corneel27/dao-amd64:2026.03.4 - 404
2026-03-28 16:44:49.440 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/corneel27/dao-amd64 with tag 2026.03.4.
2026-03-28 16:44:50.059 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/corneel27/dao-amd64:2026.03.4: [404] manifest unknown
2026-03-28 16:44:50.060 ERROR (MainThread) [supervisor.addons.addon] Could not pull image to update addon 1f491d2b_day_ahead_opt: Can't install ghcr.io/corneel27/dao-amd64:2026.03.4: [404] manifest unknown
Helpt dat met je github workflow?

  • balk
  • Registratie: Januari 2000
  • Laatst online: 08:03
Ik kan bevestigen: bij werkt het na instellen van '"interval": "1hour"'

  • UsernameIsInUse
  • Registratie: Juli 2023
  • Laatst online: 06-05 13:15
Mijn standaard config stond al op '"interval": "1hour"'.
Een tijdelijke switch naar 15min loste het probleem niet op.
Bij teruggang naar '"interval": "1hour"' blijft er de foutmelding in de berekening.

  • wmc
  • Registratie: November 2012
  • Laatst online: 08:07

wmc

balk schreef op zaterdag 28 maart 2026 @ 17:28:
Ik kan bevestigen: bij werkt het na instellen van '"interval": "1hour"'
Hier werkt een uur ook prima

  • ErnstH
  • Registratie: September 2003
  • Niet online
wmc schreef op zaterdag 28 maart 2026 @ 18:20:
[...]

Hier werkt een uur ook prima
Hier werkt het ook. Bedankt voor de workaround!

  • Voogel
  • Registratie: April 2016
  • Laatst online: 04-05 19:44
code:
1
2026-03-28 19:00:00 fout: Er ontbreken kwartier- of uurwaarden van de day-ahead tarieven, de berekening wordt afgebroken
Valt dit te omzeilen?

7 zonnepanelen, 4kWh thuis accu en binnenkort een Flint op een huisje uit 1896


  • thewhi
  • Registratie: April 2021
  • Laatst online: 08:30
BertSmelik schreef op zaterdag 28 maart 2026 @ 16:55:
[...]

Ik krijg deze fouten in de Supervisor log bij het upgraden:
code:
1
2
3
4
5
2026-03-28 16:44:49.063 INFO (MainThread) [supervisor.docker.addon] Updating image ghcr.io/corneel27/dao-amd64:2026.03.2 to ghcr.io/corneel27/dao-amd64:2026.03.4
2026-03-28 16:44:49.439 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/corneel27/dao-amd64:2026.03.4 - 404
2026-03-28 16:44:49.440 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/corneel27/dao-amd64 with tag 2026.03.4.
2026-03-28 16:44:50.059 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/corneel27/dao-amd64:2026.03.4: [404] manifest unknown
2026-03-28 16:44:50.060 ERROR (MainThread) [supervisor.addons.addon] Could not pull image to update addon 1f491d2b_day_ahead_opt: Can't install ghcr.io/corneel27/dao-amd64:2026.03.4: [404] manifest unknown
Helpt dat met je github workflow?
Hier hetzelfde issue...

  • Animal
  • Registratie: Maart 2002
  • Laatst online: 24-04 13:36
Hier ook 2026-03-29 12:00:00 fout: Er ontbreken kwartier- of uurwaarden van de day-ahead tarieven, de berekening wordt afgebroken
Dit was eergisteren ook trouwens. Is er een mogelijkheid om meerdere bronnen te day ahead prijzen binnen te krijgen? Het systeem is nu volledig afhankelijk van 1 bron

  • Kenwood960
  • Registratie: December 2021
  • Laatst online: 04:26
Ik gebruik een andere integratie, en deze werkt ook niet voor de moment.


Heeft alles te maken met het schakelen naar zomeruur.... Denk dat het morgen gewoon wel weer werkt

  • Noshi
  • Registratie: Januari 2007
  • Laatst online: 06:42
Animal schreef op zondag 29 maart 2026 @ 13:25:
Hier ook 2026-03-29 12:00:00 fout: Er ontbreken kwartier- of uurwaarden van de day-ahead tarieven, de berekening wordt afgebroken
Dit was eergisteren ook trouwens. Is er een mogelijkheid om meerdere bronnen te day ahead prijzen binnen te krijgen? Het systeem is nu volledig afhankelijk van 1 bron
Je moet even handmatig de day ahead prijzen binnenhalen via de interface, dan werkt het weer.

  • mgroen81
  • Registratie: September 2010
  • Laatst online: 05-05 08:55
Hier weer terug naar "15min" even data ophalen en het werkt weer.

Mitsubishi PUHZ-W50VHA + EHPT20X-VM2C / 30x JASolar 265Wp oost/west + SolarEdge 7K


  • mgroen81
  • Registratie: September 2010
  • Laatst online: 05-05 08:55
@KC27
Ik heb sinds kort 2 compleet verschillende accu systemen. DAO kiest soms op 1 van de 2 maar soms ook op beide "Balanceren" aan te zetten. Dat werkt niet lekker. Zou het een idee zijn dat DAO altijd maar 1 van de accu's kiest voor balanceren? Een Accu kan makkelijk het hele huis voorzien namelijk.
Met een optie misschien? Of is hier iets anders voor bedacht?
Ik krijg dit heel lastig met automations geregeld.
Bedankt. Nog steeds heel blij met de DAO!

Mitsubishi PUHZ-W50VHA + EHPT20X-VM2C / 30x JASolar 265Wp oost/west + SolarEdge 7K

mgroen81 schreef op zondag 29 maart 2026 @ 14:23:
@KC27
Ik heb sinds kort 2 compleet verschillende accu systemen. DAO kiest soms op 1 van de 2 maar soms ook op beide "Balanceren" aan te zetten. Dat werkt niet lekker. Zou het een idee zijn dat DAO altijd maar 1 van de accu's kiest voor balanceren? Een Accu kan makkelijk het hele huis voorzien namelijk.
Met een optie misschien? Of is hier iets anders voor bedacht?
Ik krijg dit heel lastig met automations geregeld.
Bedankt. Nog steeds heel blij met de DAO!
Eigenlijk zou balanceren maar een keer ergens aangezet mogen worden, want twee kapiteins op een schip werkt niet. Maar soms weet DAO het ook niet. Ik zo geen extra regel bedenken om DAO hierbij te helpen of in een bepaalde richting te duwen.
@DaBit heeft hier mooie PI-regelingen in HA voor draaien, waarbij er wel twee balanceerders (batterij en auto) naast elkaar werken.
In jouw geval zou ik ervoor kiezen het in HA te regelen afhankelijk van het rendement van de batterijen en een gegeven een te balanceren vermogen. Je kunt er ook voor kiezen om de helft van het te balanceren vermogen door een van de batterijen "constant" te laten (terug)leveren en de andere helft door de andere batterij in "balans-mode". Je zou hier een beslissingsboom in HA voor kunnen optuigen.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Voogel
  • Registratie: April 2016
  • Laatst online: 04-05 19:44
Afbeeldingslocatie: https://tweakers.net/i/nQol3rJ317PrODPZWAr15K3IFrY=/x800/filters:strip_exif()/f/image/joB1r8m1klNcmac9dNpTdIXi.png?f=fotoalbum_large
Ik gebruik nordpool en het lijkt er op dat er een uur verschuiving in de data zit.

7 zonnepanelen, 4kWh thuis accu en binnenkort een Flint op een huisje uit 1896


  • kiekerjan
  • Registratie: September 2000
  • Laatst online: 05-05 17:59
Ik heb een probleem waarbij ik niet snap hoe DAO de tijden van de tarieven toepast.

Ik zie de volgende optimalisatie. Voor mij lijkt het er op dat DAO beweert dat de tariefpiek tussen 1200 en 1600 ligt.
Afbeeldingslocatie: https://tweakers.net/i/C9NxhVIMDdXEGub38o4treUO0ZA=/x800/filters:strip_exif()/f/image/WgNNUiyuXbc3Q1DUHcNLgKni.png?f=fotoalbum_large

Volgens mij ligt deze piek tussen 19:00 en 23:00:
Afbeeldingslocatie: https://tweakers.net/i/F9z7Y-71-nOjIvjIWfeki8bgxEI=/800x/filters:strip_exif()/f/image/9lzSN6y2rPZcNIbrbsQZ1JLM.png?f=fotoalbum_large

Dit komt ook overeen met de opgehaalde prijzen. De hoogste prijzen zijn tussen 17:00 en 21:00. Dat is UTC en komt dus overeen met 19:00 en 23:00
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
2026-03-29 17:18:14 info: Day ahead prijzen van Nordpool:
 [ { 'end': datetime.datetime(2026, 3, 29, 23, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 29, 22, 0, tzinfo=tzutc()),
    'value': 9.61},
  { 'end': datetime.datetime(2026, 3, 30, 0, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 29, 23, 0, tzinfo=tzutc()),
    'value': 3.94},
  { 'end': datetime.datetime(2026, 3, 30, 1, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 0, 0, tzinfo=tzutc()),
    'value': 4.55},
  { 'end': datetime.datetime(2026, 3, 30, 2, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 1, 0, tzinfo=tzutc()),
    'value': 3.14},
  { 'end': datetime.datetime(2026, 3, 30, 3, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 2, 0, tzinfo=tzutc()),
    'value': 3.59},
  { 'end': datetime.datetime(2026, 3, 30, 4, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 3, 0, tzinfo=tzutc()),
    'value': 16.94},
  { 'end': datetime.datetime(2026, 3, 30, 5, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 4, 0, tzinfo=tzutc()),
    'value': 63.52},
  { 'end': datetime.datetime(2026, 3, 30, 6, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 5, 0, tzinfo=tzutc()),
    'value': 92.99},
  { 'end': datetime.datetime(2026, 3, 30, 7, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 6, 0, tzinfo=tzutc()),
    'value': 112.0},
  { 'end': datetime.datetime(2026, 3, 30, 8, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 7, 0, tzinfo=tzutc()),
    'value': 98.85},
  { 'end': datetime.datetime(2026, 3, 30, 9, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 8, 0, tzinfo=tzutc()),
    'value': 75.08},
  { 'end': datetime.datetime(2026, 3, 30, 10, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 9, 0, tzinfo=tzutc()),
    'value': 46.0},
  { 'end': datetime.datetime(2026, 3, 30, 11, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 10, 0, tzinfo=tzutc()),
    'value': 24.38},
  { 'end': datetime.datetime(2026, 3, 30, 12, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 11, 0, tzinfo=tzutc()),
    'value': 10.64},
  { 'end': datetime.datetime(2026, 3, 30, 13, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 12, 0, tzinfo=tzutc()),
    'value': 7.55},
  { 'end': datetime.datetime(2026, 3, 30, 14, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 13, 0, tzinfo=tzutc()),
    'value': 12.94},
  { 'end': datetime.datetime(2026, 3, 30, 15, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 14, 0, tzinfo=tzutc()),
    'value': 33.69},
  { 'end': datetime.datetime(2026, 3, 30, 16, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 15, 0, tzinfo=tzutc()),
    'value': 69.86},
  { 'end': datetime.datetime(2026, 3, 30, 17, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 16, 0, tzinfo=tzutc()),
    'value': 100.0},
  { 'end': datetime.datetime(2026, 3, 30, 18, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 17, 0, tzinfo=tzutc()),
    'value': 125.07},
  { 'end': datetime.datetime(2026, 3, 30, 19, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 18, 0, tzinfo=tzutc()),
    'value': 129.52},
  { 'end': datetime.datetime(2026, 3, 30, 20, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 19, 0, tzinfo=tzutc()),
    'value': 129.9},
  { 'end': datetime.datetime(2026, 3, 30, 21, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 20, 0, tzinfo=tzutc()),
    'value': 135.78},
  { 'end': datetime.datetime(2026, 3, 30, 22, 0, tzinfo=tzutc()),
    'start': datetime.datetime(2026, 3, 30, 21, 0, tzinfo=tzutc()),
    'value': 115.75}]
Het rare vind ik dat de verschuiving dan 7 uur zou zijn, maar ik kan niet verklaren waarom. Het is niet het uurtje verschil met wintertijd, of 2 uur tijdsverschil met UTC. Home Assistant staat ingesteld op Amsterdam (GMT+1) en ik gebruik de Maria DB addon, die ook op de goede tijd lijkt te staan.

Update. Als ik 2 berekeningen naast elkaar leg, lijkt het erop dat de spot prijzen niet goed meegenomen worden in de berekeningen: kijk in de spot kolom. De base kolom waarden blijven hetzelfde bij dezelfde uren, maar de spot prijzen (en p_l en p_t?) veranderen bij het 18:00 tijdslot. Dat lijkt niet te kloppen.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
2026-03-29 17:55:43 info: Start waarden: 
      uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
0   17:00 2026-03-29 17:00:00 0.010 0.144 0.129 0.700      0  0.018
1   18:00 2026-03-29 18:00:00 0.004 0.138 0.122 1.500      0  0.122
2   19:00 2026-03-29 19:00:00 0.005 0.138 0.123 0.900      0  0.034
3   20:00 2026-03-29 20:00:00 0.003 0.137 0.121 0.600      0  0.000
4   21:00 2026-03-29 21:00:00 0.004 0.137 0.122 0.600      0  0.000
5   22:00 2026-03-29 22:00:00 0.017 0.153 0.138 0.600      0  0.000
6   23:00 2026-03-29 23:00:00 0.064 0.210 0.194 0.600      0  0.000
7   00:00 2026-03-30 00:00:00 0.093 0.245 0.230 0.600      0  0.000
8   01:00 2026-03-30 01:00:00 0.112 0.268 0.253 0.250      0  0.000
9   02:00 2026-03-30 02:00:00 0.099 0.252 0.237 0.250      0  0.000
10  03:00 2026-03-30 03:00:00 0.075 0.224 0.208 0.250      0  0.000
11  04:00 2026-03-30 04:00:00 0.046 0.188 0.173 0.250      0  0.000
12  05:00 2026-03-30 05:00:00 0.024 0.162 0.147 0.250      0  0.000
13  06:00 2026-03-30 06:00:00 0.011 0.146 0.130 0.600      0  0.000
14  07:00 2026-03-30 07:00:00 0.008 0.142 0.126 0.300      0  0.034
15  08:00 2026-03-30 08:00:00 0.013 0.148 0.133 0.100      0  0.101
16  09:00 2026-03-30 09:00:00 0.034 0.174 0.158 0.500      0  0.115
17  10:00 2026-03-30 10:00:00 0.070 0.217 0.202 0.500      0  0.226
18  11:00 2026-03-30 11:00:00 0.100 0.254 0.238 0.500      0  0.617
19  12:00 2026-03-30 12:00:00 0.125 0.284 0.269 0.500      0  0.699
20  13:00 2026-03-30 13:00:00 0.130 0.290 0.274 0.500      0  0.578
21  14:00 2026-03-30 14:00:00 0.130 0.290 0.275 0.500      0  0.143
22  15:00 2026-03-30 15:00:00 0.136 0.297 0.282 0.500      0  0.645
23  16:00 2026-03-30 16:00:00 0.116 0.273 0.257 0.500      0  0.647


2026-03-29 18:03:36 info: Start waarden: 
      uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
0   18:00 2026-03-29 18:00:00 0.010 0.144 0.129 1.500      0  0.115
1   19:00 2026-03-29 19:00:00 0.004 0.138 0.122 0.900      0  0.034
2   20:00 2026-03-29 20:00:00 0.005 0.138 0.123 0.600      0  0.000
3   21:00 2026-03-29 21:00:00 0.003 0.137 0.121 0.600      0  0.000
4   22:00 2026-03-29 22:00:00 0.004 0.137 0.122 0.600      0  0.000
5   23:00 2026-03-29 23:00:00 0.017 0.153 0.138 0.600      0  0.000
6   00:00 2026-03-30 00:00:00 0.064 0.210 0.194 0.600      0  0.000
7   01:00 2026-03-30 01:00:00 0.093 0.245 0.230 0.250      0  0.000
8   02:00 2026-03-30 02:00:00 0.112 0.268 0.253 0.250      0  0.000
9   03:00 2026-03-30 03:00:00 0.099 0.252 0.237 0.250      0  0.000
10  04:00 2026-03-30 04:00:00 0.075 0.224 0.208 0.250      0  0.000
11  05:00 2026-03-30 05:00:00 0.046 0.188 0.173 0.250      0  0.000
12  06:00 2026-03-30 06:00:00 0.024 0.162 0.147 0.600      0  0.000
13  07:00 2026-03-30 07:00:00 0.011 0.146 0.130 0.300      0  0.034
14  08:00 2026-03-30 08:00:00 0.008 0.142 0.126 0.100      0  0.101
15  09:00 2026-03-30 09:00:00 0.013 0.148 0.133 0.500      0  0.115
16  10:00 2026-03-30 10:00:00 0.034 0.174 0.158 0.500      0  0.226
17  11:00 2026-03-30 11:00:00 0.070 0.217 0.202 0.500      0  0.617
18  12:00 2026-03-30 12:00:00 0.100 0.254 0.238 0.500      0  0.699
19  13:00 2026-03-30 13:00:00 0.125 0.284 0.269 0.500      0  0.578
20  14:00 2026-03-30 14:00:00 0.130 0.290 0.274 0.500      0  0.143
21  15:00 2026-03-30 15:00:00 0.130 0.290 0.275 0.500      0  0.645
22  16:00 2026-03-30 16:00:00 0.136 0.297 0.282 0.500      0  0.647
23  17:00 2026-03-30 17:00:00 0.116 0.273 0.257 0.700      0  0.300

[ Voor 29% gewijzigd door kiekerjan op 29-03-2026 18:07 ]

These are my principles. If you don't like them I have others.


  • Marcjeno1
  • Registratie: Juli 2007
  • Laatst online: 05-05 09:11
Bij mij kloppen de tijden ook niet meer in DAO. De accu gaat nu op verkeerde tijden laden. Gaat ergens iets mis geloof ik
Dit zijn bij mij de prijzen (laatste grafiek):
Afbeeldingslocatie: https://tweakers.net/i/YdMzVl20KqEVKPINZ0JJCA9lcpA=/x800/filters:strip_exif()/f/image/t0NuGfLU0VvbMlzFifegRcyK.png?f=fotoalbum_large
Dit komt toch aardig overeen zoals ze zouden moeten zijn.
Ik reken dus per kwartier en haal de data op bij Nordpool.
Hoe hebben jullie het interval staan?
Wat is jullie prijzen-leverancier: Entsoe of Nordpool?
Misschien een keer "handmatig" geforceerd ophalen per dag (vandaag en morgen) via het run-menu en dan de eerste datum invullen?

[ Voor 34% gewijzigd door KC27 op 29-03-2026 19:14 ]

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • balk
  • Registratie: Januari 2000
  • Laatst online: 08:03
Ik draai 2026.03.2. Wanneer ik onder Home op Tabel klik (ipv default grafieken) krijg ik dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
2026-03-29 00:24:29,845 fout dao.webserver.app MainThread : Exception on /api/report/cons/vandaag_en_morgen [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 812, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
  File "/root/dao/prog/da_report.py", line 3355, in get_api_data
    df["time_ts"] = df["time"].dt.tz_localize(time_zone)
                    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/accessor.py", line 127, in f
    return self._delegate_method(name, *args, **kwargs)
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/accessors.py", line 126, in _delegate_method
    result = method(*args, **kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/datetimes.py", line 543, in tz_localize
    arr = self._data.tz_localize(tz, ambiguous, nonexistent)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/arrays/_mixins.py", line 83, in method
    return meth(self, *args, **kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/arrays/datetimes.py", line 1107, in tz_localize
    new_dates = tzconversion.tz_localize_to_utc(
        self.asi8,
    ...<3 lines>...
        creso=self._creso,
    )
  File "pandas/_libs/tslibs/tzconversion.pyx", line 430, in pandas._libs.tslibs.tzconversion.tz_localize_to_utc
ValueError: 2026-03-29 02:00:00 is a nonexistent time due to daylight savings time. Try using the 'nonexistent' argument.
2026-03-29 00:24:32,957 fout dao.webserver.app MainThread : Exception on /api/report/prod/vandaag_en_morgen [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 812, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
  File "/root/dao/prog/da_report.py", line 3355, in get_api_data
    df["time_ts"] = df["time"].dt.tz_localize(time_zone)
                    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/accessor.py", line 127, in f
    return self._delegate_method(name, *args, **kwargs)
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/accessors.py", line 126, in _delegate_method
    result = method(*args, **kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/datetimes.py", line 543, in tz_localize
    arr = self._data.tz_localize(tz, ambiguous, nonexistent)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/arrays/_mixins.py", line 83, in method
    return meth(self, *args, **kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/arrays/datetimes.py", line 1107, in tz_localize
    new_dates = tzconversion.tz_localize_to_utc(
        self.asi8,
    ...<3 lines>...
        creso=self._creso,
    )
Helpt dit bij bug hunten?
kiekerjan schreef op zondag 29 maart 2026 @ 17:48:
Ik heb een probleem waarbij ik niet snap hoe DAO de tijden van de tarieven toepast.

Ik zie de volgende optimalisatie. Voor mij lijkt het er op dat DAO beweert dat de tariefpiek tussen 1200 en 1600 ligt.
[Afbeelding]

Volgens mij ligt deze piek tussen 19:00 en 23:00:
[Afbeelding]

Dit komt ook overeen met de opgehaalde prijzen. De hoogste prijzen zijn tussen 17:00 en 21:00. Dat is UTC en komt dus overeen met 19:00 en 23:00

[...]


Het rare vind ik dat de verschuiving dan 7 uur zou zijn, maar ik kan niet verklaren waarom. Het is niet het uurtje verschil met wintertijd, of 2 uur tijdsverschil met UTC. Home Assistant staat ingesteld op Amsterdam (GMT+1) en ik gebruik de Maria DB addon, die ook op de goede tijd lijkt te staan.

Update. Als ik 2 berekeningen naast elkaar leg, lijkt het erop dat de spot prijzen niet goed meegenomen worden in de berekeningen: kijk in de spot kolom. De base kolom waarden blijven hetzelfde bij dezelfde uren, maar de spot prijzen (en p_l en p_t?) veranderen bij het 18:00 tijdslot. Dat lijkt niet te kloppen.

[...]
Als ik naar je grafiek kijk, lijkt het erop dat er voor vandaag geen energieprijzen zijn en dat DAO (onbegrijpelijkerwijs) de eerste aanwezige data van morgen naar voren haalt (om 17:00uur).
Ik zou je toch willen adviseren de data van vandaag en morgen een voor een opnieuw(bij Nordpool) geforceerd op te halen.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • kiekerjan
  • Registratie: September 2000
  • Laatst online: 05-05 17:59
KC27 schreef op zondag 29 maart 2026 @ 19:29:
[...]

Als ik naar je grafiek kijk, lijkt het erop dat er voor vandaag geen energieprijzen zijn en dat DAO (onbegrijpelijkerwijs) de eerste aanwezige data van morgen naar voren haalt (om 17:00uur).
Ik zou je toch willen adviseren de data van vandaag en morgen een voor een opnieuw(bij Nordpool) geforceerd op te halen.
Dat lijkt het inderdaad op te lossen. Prijzen voor vandaag opgehaald, en nu is de grafiek compleet voor vandaag en voor morgen, zonder verschoven tijden. (y)

These are my principles. If you don't like them I have others.


  • Voogel
  • Registratie: April 2016
  • Laatst online: 04-05 19:44
@KC27 los ophalen van beide dagen was inderdaad de oplossing!

7 zonnepanelen, 4kWh thuis accu en binnenkort een Flint op een huisje uit 1896


  • balk
  • Registratie: Januari 2000
  • Laatst online: 08:03
balk schreef op zondag 29 maart 2026 @ 19:22:
Ik draai 2026.03.2. Wanneer ik onder Home op Tabel klik (ipv default grafieken) krijg ik dit:


[...]

Helpt dit bij bug hunten?
Opgelost door de prijzen per dag even op te halen.

  • thesaxofonist
  • Registratie: November 2016
  • Laatst online: 09:10
KC27 schreef op donderdag 26 maart 2026 @ 22:23:
[...]

Nu valt het kwartje: je hebt een hybride pv-omvormer waarop je pv-panelen en een batterij zijn aangesloten.
Die omvormer kan alleen terugleveren.
Dat kun je in DAO vrij eenvoudig definiëren door maar 1 charge-stage te definiëren:
code:
1
2
3
4
5
6
"charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        }
 ]
En je configureert je panelen natuurlijk binnen de batterij.
Dit werkt helaas niet. Hij vindt nooit een oplossing.

Ik heb de desbetreffende solar binnen de batterij geconfigureerd en één charge-state van 0.0 gemaakt. Precies zoals je adviseerde. Dan vindt hij geen oplossing. Ook heb ik "dc_to_bat max power": 2000 toegevoegd, maar dat hielp ook niet.

Als ik er een charge-state bij maak van 1000, dan werkt het (overdag) wel (en zal de solar gebruikt worden, want hij kan niet anders). Maar dan wil DAO ook 's nachts gaan laden en dat lukt de omvormer natuurlijk niet.

  • wmc
  • Registratie: November 2012
  • Laatst online: 08:07

wmc

Ik vroeg me af hoe jullie omgaan met de legionella run op de boiler? Normaliter wordt mijn warm water (~50C) gemaakt door de warmtepomp, dit wordt netjes ingepland door DAO. Hiervoor heb ik een vaste COP ingevoerd. Echter, als ik naar een hogere temperatuur ga (~60C) voor een legionella run, wordt het elektrisch element bijgeschakeld, waardoor de COP significant inkakt. Ik zou hier graag rekening mee willen houden.

Een van de ideeën die ik heb is om een machine te gebruiken voor de incidentele legionellarun, maar het probleem is dat het niet 100% te garanderen is dat dit juist wordt ingepland.

  • Impossibl3
  • Registratie: November 2012
  • Laatst online: 08:08
@wmc ik heb de vaste cop maar geaccepteerd. Het zou mooi zijn als er ook voor tapwater met verschillende stages kan worden gewerkt. Maar ik begreep dat de originele ontwikkelaar van dit onderdeel (niet @KC27) een bodem warmtepomp heeft en daarom geen last hiervan heeft.

PV 5.590 Wp Enphase, 2.700 Wp Growatt - Easee laadpaal - Itho Amber 95 WP


  • timminater
  • Registratie: Augustus 2006
  • Laatst online: 05-05 23:10
Ik heb nu een tijdje getest met de DAO maar heb een vraagje over de gekozen strategy:

Momenteel kan ik kiezen uit:
minimize cost: Accu probeert zo veel mogelijk vol en leeg te laden voor maximale winst, een deel van mijn eigen verbruik word nu uit het net ingekocht omdat later verkopen meer winst is.
minimize consumption: maximaal eigen verbruik, maar batterij word nu niet meer uit het net geladen als de huidige accu inhoud voldoet.

Is het mogelijk hier een tussenweg voor in te stellen? Ik heb nu 16kWh accu, en mijn eigenverbruik is ongeveer 10kwH per dag. Ik zou graag hebben dat de resterende accu gebruikt word voor laden uit het net en verkopen. Dus maximale winst, maar wel na maximaal eigenverbuik.

  • Mirabis
  • Registratie: Juli 2013
  • Niet online
timminater schreef op maandag 30 maart 2026 @ 12:23:
Ik heb nu een tijdje getest met de DAO maar heb een vraagje over de gekozen strategy:

Momenteel kan ik kiezen uit:
minimize cost: Accu probeert zo veel mogelijk vol en leeg te laden voor maximale winst, een deel van mijn eigen verbruik word nu uit het net ingekocht omdat later verkopen meer winst is.
minimize consumption: maximaal eigen verbruik, maar batterij word nu niet meer uit het net geladen als de huidige accu inhoud voldoet.

Is het mogelijk hier een tussenweg voor in te stellen? Ik heb nu 16kWh accu, en mijn eigenverbruik is ongeveer 10kwH per dag. Ik zou graag hebben dat de resterende accu gebruikt word voor laden uit het net en verkopen. Dus maximale winst, maar wel na maximaal eigenverbuik.
Maar waarom dan? Financieel ga je er niet op vooruit en als je dat weet en toch wilt testen voordat het 2027 is dan doet 'minimize consumption' het testen toch al? Ik ben er niet per se tegen hoor maar vraag me gewoon af waarom.

Als je voor "nood" ruimte in de accu wil laten kan je ook optimal level hoger zetten? Momenteel hangt de juiste keuze nog een beetje af of je jouw verbruik nog kunt salderen of niet.

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • arjenhiemstra
  • Registratie: Oktober 2003
  • Laatst online: 09:06
Mirabis schreef op maandag 30 maart 2026 @ 13:14:
[...]

Maar waarom dan? Financieel ga je er niet op vooruit en als je dat weet en toch wilt testen voordat het 2027 is dan doet 'minimize consumption' het testen toch al? Ik ben er niet per se tegen hoor maar vraag me gewoon af waarom.

Als je voor "nood" ruimte in de accu wil laten kan je ook optimal level hoger zetten? Momenteel hangt de juiste keuze nog een beetje af of je jouw verbruik nog kunt salderen of niet.
Ik begrijp de vraag wel. Wat ik merkt met het instellen van "optimal level" is dat DAO prima aangeeft te stoppen met ontladen. Vervolgens stel ik mijn omvormer in op zero export/import en gaat de batt. ontladen. DAO detecteert dit en gaat op een gegeven moment zijn optimal level weer proberen te herstellen. Gevolg laden/ontladen/laden/ontladen tot de volgende inkoop/verkoop cycle weer voorbij komt.

Eigenlijk zou ik DAO dus tijdelijk moeten "ontkoppelen" als het "optimal level" bereikt is bij ontladen en weer koppelen zodra er weer gehandeld moet worden oid maar daar heb ik nog niet iets voor gevonden.
Mirabis schreef op maandag 30 maart 2026 @ 13:14:
[...]

Maar waarom dan? Financieel ga je er niet op vooruit en als je dat weet en toch wilt testen voordat het 2027 is dan doet 'minimize consumption' het testen toch al? Ik ben er niet per se tegen hoor maar vraag me gewoon af waarom.

Als je voor "nood" ruimte in de accu wil laten kan je ook optimal level hoger zetten? Momenteel hangt de juiste keuze nog een beetje af of je jouw verbruik nog kunt salderen of niet.
In principe zou DAO dat moet doen met de strategie "minimize consumption", maar dat is sterk afhankelijk wat je extra kosten zijn voor gebruik van je accu. Dat heb je zelf in de hand met je instellingen van:
- penalty cost
- cycle cost
- efficiency laden/ontladen
Als de eerste twee hoog staan en je efficiencies staan/zijn laag dan zal het laden/ontladen alleen aantrekkelijk zijn als de prijsverschillen tussen de betrokken periodes hoog genoeg zijn.
Je kunt een vergelijking maken tussen twee berekeningen met twee verschillende strategieën en dan de grafieken van beide berekeningen hier delen.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • wmc
  • Registratie: November 2012
  • Laatst online: 08:07

wmc

Impossibl3 schreef op maandag 30 maart 2026 @ 08:44:
@wmc ik heb de vaste cop maar geaccepteerd. Het zou mooi zijn als er ook voor tapwater met verschillende stages kan worden gewerkt. Maar ik begreep dat de originele ontwikkelaar van dit onderdeel (niet @KC27) een bodem warmtepomp heeft en daarom geen last hiervan heeft.
In theorie zou een zelfde implementatie als een on/off warmtepomp voldoende moeten zijn. Het verschil is dan dat de benodigde energie berekend wordt op basis van de watercapaciteit en temperatuurverschil, in plaats van graaddagen en de vermenigvuldigingsfactor. @KC27 is dat een haalbare implementatie voor de boiler?

  • Mirabis
  • Registratie: Juli 2013
  • Niet online
Toch maar de stap gemaakt om te updaten naar 2026.03.3.rc5 maar loop tegen wat probleempjes aan.

1. config automatisch overzetten gaat stuk ivm validatie error
code:
1
2
3
4
5
"vat production": {
      "2023-01-01": 21,
      "2026-01-22": 33.1,
      "2027-01-01": 0
    },
resulteert in
[code]
check_db.py failed, exiting

=> directory dao_data exist

=> /root/dao/data exist

=> /root/dao/webserver/app/static/data exist

2026-03-31 13:23:58 INFO: Configuration needs migration from unversioned to v0

2026-03-31 13:23:58 INFO: Saved backup configuration to ../data/options_unversioned.json

2026-03-31 13:23:58 INFO: Migrating unversioned configuration to v0

2026-03-31 13:23:58 INFO: Added config_version=0 to unversioned configuration

2026-03-31 13:23:58 INFO: Migrated scheduler: active=True, 15 schedule entries

2026-03-31 13:23:58 INFO: Coerced boiler.boiler present from 'False' to boolean

2026-03-31 13:23:58 INFO: Coerced heating.heater present from 'False' to boolean

2026-03-31 13:23:58 INFO: Configuration at version 0

Error loading configuration: 2 validation errors for ConfigurationV0

prices.vat production.2026-01-22

Input should be a valid integer, got a number with a fractional part [type=int_from_float, input_value=33.1, input_type=float]

For further information visit https://errors.pydantic.dev/2.12/v/int_from_float

baseload

List should have at least 24 items after validation, not 0 [type=too_short, input_value=[], input_type=list]

For further information visit https://errors.pydantic.dev/2.12/v/too_short


[code]
33.1 = 33.1% mag dus niet? Afwijkend percentage ivm met zonneplan zonnebonus en ontbreken andere manier om dat te verwerken. Pas ik dat aan naar 33 krijg ik een volgende foutmelding:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
=> directory dao_data exist

=> /root/dao/data exist

=> /root/dao/webserver/app/static/data exist

2026-03-31 13:27:26 INFO: Configuration needs migration from unversioned to v0

2026-03-31 13:27:26 INFO: Saved backup configuration to ../data/options_unversioned.json

2026-03-31 13:27:26 INFO: Migrating unversioned configuration to v0

2026-03-31 13:27:26 INFO: Added config_version=0 to unversioned configuration

2026-03-31 13:27:26 INFO: Migrated scheduler: active=True, 15 schedule entries

2026-03-31 13:27:26 INFO: Coerced boiler.boiler present from 'False' to boolean

2026-03-31 13:27:26 INFO: Coerced heating.heater present from 'False' to boolean

2026-03-31 13:27:26 INFO: Configuration at version 0

Error loading configuration: 1 validation error for ConfigurationV0

baseload

  List should have at least 24 items after validation, not 0 [type=too_short, input_value=[], input_type=list]

    For further information visit https://errors.pydantic.dev/2.12/v/too_short

check_db.py failed, exiting
Hierbij lijkt het stuk te gaan op een empty baseload zelfs wanneer "use_calc_baseload" = true is.
code:
1
2
"baseload": [],
"use_calc_baseload": "True"
Werkt niet maar het volgende (baseload niet definieren) werkt wel:
code:
1
"use_calc_baseload": "True"

[ Voor 29% gewijzigd door Mirabis op 31-03-2026 13:30 ]

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh

Er was vertraging bij epex in het vaststellen van de marktprijzen voor morgen.
Nu (13:40) zijn ze er (in ieder geval bij Nordpool).

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • thesaxofonist
  • Registratie: November 2016
  • Laatst online: 09:10
Ik heb een feature request. Graag zou ik zien dat DAO ook geschikt wordt gemaakt voor batterijen die alleen kunnen worden geladen vanuit solar, dus bijvoorbeeld (oudere) geïntegreerde systemen, all-in-one-systemen, de in Duitsland veel gebruikte balkonsystemen of systemen met micro-omvormers.

Vaak kunnen deze systemen alleen terugleveren naar grid, maar er niet vanuit laden (dat doen ze alleen via de aangesloten zonnepanelen).

Ik heb veel geprobeerd, maar krijg het in DAO niet werkend. Ik heb de solar binnen de desbetreffende batterij geconfigureerd, dc_to_bat max power ingesteld en charge-state op 0 gezet. DAO vindt dan nooit een oplossing bij minimum cost. Dat lukt pas als ik een extra charge-state toevoeg. Maar de gevonden oplossing is dan vaak gebaseerd op (ook) AC-laden en dat kan de omvormer niet.

Het zou fijn zijn als er (bijvoorbeeld) een ac_to_bat max power ingesteld kan worden. Maar andere opties zijn natuurlijk ook prima. Mogelijk zie ik iets over het hoofd of heeft er iemand nog suggesties. Dat probeer ik dan graag.

[ Voor 4% gewijzigd door thesaxofonist op 31-03-2026 17:12 ]


  • Noshi
  • Registratie: Januari 2007
  • Laatst online: 06:42
thesaxofonist schreef op dinsdag 31 maart 2026 @ 17:11:
Ik heb een feature request. Graag zou ik zien dat DAO ook geschikt wordt gemaakt voor batterijen die alleen kunnen worden geladen vanuit solar, dus bijvoorbeeld (oudere) geïntegreerde systemen, all-in-one-systemen, de in Duitsland veel gebruikte balkonsystemen of systemen met micro-omvormers.

Vaak kunnen deze systemen alleen terugleveren naar grid, maar er niet vanuit laden (dat doen ze alleen via de aangesloten zonnepanelen).

Ik heb veel geprobeerd, maar krijg het in DAO niet werkend. Ik heb de solar binnen de desbetreffende batterij geconfigureerd, dc_to_bat max power ingesteld en charge-state op 0 gezet. DAO vindt dan nooit een oplossing bij minimum cost. Dat lukt pas als ik een extra charge-state toevoeg. Maar de gevonden oplossing is dan vaak gebaseerd op (ook) AC-laden en dat kan de omvormer niet.

Het zou fijn zijn als er (bijvoorbeeld) een ac_to_bat max power ingesteld kan worden. Maar andere opties zijn natuurlijk ook prima. Mogelijk zie ik iets over het hoofd of heeft er iemand nog suggesties. Dat probeer ik dan graag.
Wat als je bijvoorbeeld de charge state op 1W of 10W zet? Dan wordt er wel laden ingepland maar zonder significante bijdrage.

  • thesaxofonist
  • Registratie: November 2016
  • Laatst online: 09:10
Noshi schreef op dinsdag 31 maart 2026 @ 17:48:
[...]


Wat als je bijvoorbeeld de charge state op 1W of 10W zet? Dan wordt er wel laden ingepland maar zonder significante bijdrage.
Dan vindt hij geen oplossing. Ik heb de indruk dat hij de charge-state gebruikt voor DC en AC samen. Als ik de waarde verhoog, dan vindt hij uiteindelijk wel een oplossing. In sommige situaties gaat dat goed. Maar zoals gezegd wil hij dan ook vaak AC-laden.

[ Voor 3% gewijzigd door thesaxofonist op 31-03-2026 17:54 ]

thesaxofonist schreef op dinsdag 31 maart 2026 @ 17:51:
[...]


Dan vindt hij geen oplossing. Ik heb de indruk dat hij de charge-state gebruikt voor DC en AC samen. Als ik de waarde verhoog, dan vindt hij uiteindelijk wel een oplossing. In sommige situaties gaat dat goed. Maar zoals gezegd wil hij dan ook vaak AC-laden.
Goed punt: ik ga ernaar kijken!

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Mirabis schreef op dinsdag 31 maart 2026 @ 13:24:
Toch maar de stap gemaakt om te updaten naar 2026.03.3.rc5 maar loop tegen wat probleempjes aan.

1. config automatisch overzetten gaat stuk ivm validatie error
code:
1
2
3
4
5
"vat production": {
      "2023-01-01": 21,
      "2026-01-22": 33.1,
      "2027-01-01": 0
    },
resulteert in

[...]

33.1 = 33.1% mag dus niet? Afwijkend percentage ivm met zonneplan zonnebonus en ontbreken andere manier om dat te verwerken. Pas ik dat aan naar 33 krijg ik een volgende foutmelding:


[...]

Hierbij lijkt het stuk te gaan op een empty baseload zelfs wanneer "use_calc_baseload" = true is.
code:
1
2
"baseload": [],
"use_calc_baseload": "True"
Werkt niet maar het volgende (baseload niet definieren) werkt wel:
code:
1
"use_calc_baseload": "True"
Dit is een fout aan de kant van DAO.
Wordt in de volgende versie hersteld.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Pagina: 1 ... 34 ... 39 Laatste