Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[tomvandepoel3]

Ik draai nog steeds schaduw (2026.8.0) met Minimize Consumption + Batterij + EV (ter voorbereiding op afschaffing salderingsregeling).

DAO zet soms grid balanceren op AAN wanneer de EV slechts gedurende een deel van het interval wordt geladen. Ik vraag me af of balanceren ("entity_balance_switch") in zo'n situatie niet beter op UIT gezet kan worden omdat het grid setpoint gedurende het eerste deel van zo'n interval (EV laadt) veel hoger is dan 0W en gedurende het tweede deel van zo'n interval (EV is gestopt met laden) juist veel lager.

Door gedurende het volledige interval met een grid setpoint van 0W te balanceren wordt de Batterij (als ik het goed heb) juist onnodig belast doordat er binnen dat korte interval zowel fors wordt geladen als wordt ontladen (tegen hetzelfde tarief en met aanzienlijke efficiency verliezen).

Gedetaileerd voorbeeld:
Situatie om 07:00 & 07:15 vanochtend: EV laden (+ baseload) is in balans met Batterij ontladen (+ PV) als DAO de EV laat laden met een vermogen van 1.6 kW. Maar omdat de EV hier altijd met minimaal 6A (3 fase) = 4.1 kW laadt gebruikt DAO "entity_stop_charging" om het laden na 5 minuten te stoppen.

code:

   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 07:00    0.00     0.41   0.00   0.00   0.03   0.00   0.00   0.40   0.01   0.00   -0.00  20.00
...
2026-09-03 07:15:04 info: Grid balanceren: on
...
2026-09-03 07:00:04 info: Berekeningsuitkomst voor opladen van EV:
2026-09-03 07:00:04 info: - aantal ampere 6.0A (was 0.0A)
2026-09-03 07:00:04 info: - stand schakelaar 'on' (was 'off')
2026-09-03 07:00:04 info: - stop laden op 2026-09-03 07:05


   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 07:15    0.00     0.41   0.00   0.00   0.04   0.00   0.00   0.40   0.02   0.00   -0.00  20.00
...
2026-09-03 07:15:04 info: Grid balanceren: on
...
2026-09-03 07:15:04 info: Berekeningsuitkomst voor opladen van EV:
2026-09-03 07:15:04 info: - aantal ampere 6.0A (was 6.0A)
2026-09-03 07:15:04 info: - stand schakelaar 'on' (was 'off')
2026-09-03 07:15:04 info: - stop laden op 2026-09-03 07:20

Dit "EV laden gedurende een deel van een interval in combinatie met Batterij ontladen" komt ook voor bij de andere EV laadstromen (6A,8A,10A,12A,14A&16A). Het toevoegen van extra "charge_stages" (7A,9A, ...) zal de frequentie waarmee dit gebeurt wel wat reduceren maar kan niet voorkomen dat DAO, bij "minimize consumption", ook vaak wil laden met minder dan 4.1 kW zoals in dit voorbeeld. Dus misschien is het beter om niet te balanceren in deze situaties?

Een andere insteek is misschien om de waarde van "entity_stop_charging" te negeren en de EV altijd gedurende een volledig interval te laden (dat is op dit moment nog wat ik doe bij "minimize cost"). Dan wordt er natuurlijk meer geconsumeerd dan strikt noodzakelijk is; iets dat ik vanaf volgend jaar graag wil voorkomen.

Hoe denken anderen hier mee om te gaan?

[tomvandepoel3]

KC27 schreef op woensdag 2 september 2026 @ 23:41:
Vanavond is een nieuwe testversie gepubliceerd: 2026.9.0.rc1

Dit staat in de changelog:

• Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3)
• Added "wget" to succeed a local build of miplib (reported by @stat)
• Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"

Het is geen grote update t.o.v. de vorige versie, maar alle gemelde foutjes zijn gefixed.

Misschien zie ik iets over het hoofd maar ik krijg de nieuwe rc niet aan de praat...

code:

2026-09-03 15:53:17 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 570, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 3258, in calc_optimum
    max_gap = abs(self.config.max_gap.resolve(ha_getter))
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/home/tom/day-ahead/dao/prog/config/models/base.py", line 173, in resolve
    state_value = ha_state_getter(self.value)
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 73, in ha_getter
    return self.get_state(eid).state
           ^^^^
NameError: name 'self' is not defined

[KC27]

tomvandepoel3 schreef op donderdag 3 september 2026 @ 16:03:
[...]

Misschien zie ik iets over het hoofd maar ik krijg de nieuwe rc niet aan de praat...

code:

2026-09-03 15:53:17 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 570, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 3258, in calc_optimum
    max_gap = abs(self.config.max_gap.resolve(ha_getter))
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/home/tom/day-ahead/dao/prog/config/models/base.py", line 173, in resolve
    state_value = ha_state_getter(self.value)
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 73, in ha_getter
    return self.get_state(eid).state
           ^^^^
NameError: name 'self' is not defined

Fijn dat je dit hebt getest.
Ik ga het onderzoeken.
Hoe heb jij gap geconfigureerd in settings?

[tomvandepoel3]

KC27 schreef op donderdag 3 september 2026 @ 19:19:
[...]

Fijn dat je dit hebt getest.
Ik ga het onderzoeken.
Hoe heb jij gap geconfigureerd in settings?

Als flex setting:
"max_gap": "input_number.dao_max_gap",
Waarde van de HA helper is 0.2

[KC27]

Zojuist is er een nieuwe testversie gepubliceerd: 2026.9.0.rc2.
Hierin is de error gemeld door tomvandepoel3 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO" gerepareerd.

[SnarfW]

Ik draai DAO nu een aantal dagen. Hoe gaat de tool om met de kostprijs van energie die in de batterij is opgeslagen?

Elk uur of kwartier wordt een nieuwe optimalisatie uitgevoerd. Stel dat de batterij in de vorige periode met energie van het net is opgeladen. Neemt DAO bij de volgende optimalisatie mee dat aan die opgeslagen energie al kosten verbonden zijn? Of weet de tool dat niet en wordt de energie bij de volgende berekening beschouwd als gratis energie?

[memorynl]

SnarfW schreef op vrijdag 4 september 2026 @ 13:29:
Ik draai DAO nu een aantal dagen. Hoe gaat de tool om met de kostprijs van energie die in de batterij is opgeslagen?

Elk uur of kwartier wordt een nieuwe optimalisatie uitgevoerd. Stel dat de batterij in de vorige periode met energie van het net is opgeladen. Neemt DAO bij de volgende optimalisatie mee dat aan die opgeslagen energie al kosten verbonden zijn? Of weet de tool dat niet en wordt de energie bij de volgende berekening beschouwd als gratis energie?

Wat telt is de (geschatte) TOEKOMSTIGE waarde van de energie in de batterij, daarop optimaliseer je.

Is het voordeliger om de energie te laten zitten voor later, of nu het net op sturen. Die vraag wordt continue beantwoord. Ook in het verleden, en blijkbaar was het toen ooit voordeliger (geschat) de energie op te slaan voor later en niet direct te verkopen.

Dit relateert volgens mij aan de sunk cost falacy. Maar dan met opbrengsten ofzo.

[KC27]

@SnarfW @memorynl
Voor de optimalisatie berekening wordt de inhoud van de accu gewaardeerd op de gemiddelde inkoopwaarde over de hele optimalisering periode.
Maar dat gebeurt voor de inhoud van accu aan het einde van die periode.
Na afloop van de salderingsregeling (vanaf 1-1-2027) is die waardering te hoog en zal deze ergens tussen het gemiddelde inkooptarief en het gemiddelde teruglevertarief in moeten liggen. Deze waardering zal instelbaar worden (iedereen heeft daar waarschijnlijk een eigen mening over).
Kies je hem te hoog dan zal de accu aan het einde vol zijn. Kies je hem te laag dan is ie aan het einde leeg.

[KC27]

Er zijn geen problemen meer gemeld met testversie 2026.9.0.rc2.
Nu is productieversie 2026.9.0 gepubliceerd.
Functioneel is deze gelijk aan: 2026.9.0.rc2.
Dit staat in de changelog (t.o.v. 2026.8.0):

• Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3 )
• Added "wget" to succeed a local build of miplib (reported by @stat )
• Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"

[stat]

KC27 schreef op vrijdag 4 september 2026 @ 23:27:
Er zijn geen problemen meer gemeld met testversie 2026.9.0.rc2.
Nu is productieversie 2026.9.0 gepubliceerd.
Functioneel is deze gelijk aan: 2026.9.0.rc2.
Dit staat in de changelog (t.o.v. 2026.8.0):

• Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3 )
• Added "wget" to succeed a local build of miplib (reported by @stat )
• Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"

Heb hem geinstalleerd, helaas bij builden miplib nu de error dat hij git niet kan vinden.

[Hvdort]

Ik heb zojuist ook 2026.9.0 getest. Opnieuw een libcbc error. Daarom maar weer roll back gedaan naar 2026.6.0. Ik heb ooit het advies gevolgd om die miplib handmatig te compileren. Zit dat nu in de weg of wordt dat automatisch overschreven bij een nieuwe versie van de container in HA?

[Dogooder]

Ik weet niet precies hoe het zit met je eigen miplib compileren en HA containers. Maar in de huidige versie is Python mip hard gepinned op versie 1.17.6/cbcbox 2.929.

Dit omdat de nieuwere versie van cbcbox (2.935) crashed. En ik weet niet of de bug in cbcbox zit of verder upstream in CBC zelf.

[thewhi]

KC27 schreef op vrijdag 4 september 2026 @ 21:38:
@SnarfW @memorynl
Voor de optimalisatie berekening wordt de inhoud van de accu gewaardeerd op de gemiddelde inkoopwaarde over de hele optimalisering periode.
Maar dat gebeurt voor de inhoud van accu aan het einde van die periode.
Na afloop van de salderingsregeling (vanaf 1-1-2027) is die waardering te hoog en zal deze ergens tussen het gemiddelde inkooptarief en het gemiddelde teruglevertarief in moeten liggen. Deze waardering zal instelbaar worden (iedereen heeft daar waarschijnlijk een eigen mening over).
Kies je hem te hoog dan zal de accu aan het einde vol zijn. Kies je hem te laag dan is ie aan het einde leeg.

DAO had wel wat moeite om te starten. Handmatige herstart heeft gewerkt

[ Voor 5% gewijzigd door thewhi op 05-09-2026 15:49 ]

[thewhi]

De scheduler van de laatste versie lijkt toch niet te werken. Tips?

[Mvdw]

thewhi schreef op zaterdag 5 september 2026 @ 20:02:
De scheduler van de laatste versie lijkt toch niet te werken. Tips?

Hier ook problemen met de scheduler. Werkt vaker niet dan wel sinds de recente update. Valt mij ook op dat een berekening soms wel 5-10 minuten kan duren waar dit voorheen ruim een minuut duurde.

Draai de laatste versie en de calc_optimum staat ingesteld om elk kwartier te draaien.

Voor nu opgelost door elk kwartier een calc_zonder_debug run via de API aan te roepen. Hiervoor een simpele automatisering gemaakt.

[ Voor 13% gewijzigd door Mvdw op 05-09-2026 22:00 ]

[rescla]

Bij mij werkt de scheduler wel. Heb eerder, op een oudere versie, wel meerdere keren problemen gehad met de scheduler. Maar daar lag elke keer een probleem met de supervisor aan ten grondslag. Om dat te fixen moet ik in de terminal app of via ssh dan de volgende commands draaien:

code:

ha supervisor repair 
ha supervisor restart

Edit: ik zit nog op 2026.8.0, logisch dat het nog werkt.

[ Voor 9% gewijzigd door rescla op 05-09-2026 23:29 ]

[KC27]

Als je opstartproblemen met de nieuwe versie hebt helpt het vaak om DAO handmatig te herstarten:
In HA ga naar Instellingen/Apps, kies DAO, klik op "Herstarten".
Je kunt daar ook op het tabblad Logboek kijken. Dat geeft ook vaak informatie wat er aan de hand is

[ Voor 24% gewijzigd door KC27 op 05-09-2026 22:14 ]

[thewhi]

Kreeg deze analyse over het niet functioneren van de scheduler:

Uit de changelog: "Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler." Voorheen draaide de scheduler elke taak in-process (run_task_function). Nu start hij per taak een subprocess. De nieuwe code in da_scheduler.py:
Python
Waarom de scheduler daardoor vastloopt
stdout=PIPE gecombineerd met proc.wait() zonder de pipe te lezen is een deadlock-patroon waar de Python-docs expliciet voor waarschuwen. De OS-pipebuffer is ~64 kB. Het kindproces (day_ahead.py calc) logt naar het logbestand én via een StreamHandler naar stdout, en sinds 2026.8.0 gaat ook de CBC-solveroutput mee. Een calc_optimum-run produceert daar ruim meer dan 64 kB van. Zodra de buffer vol is blokkeert het kind op een write(), de scheduler blokkeert op wait(), en beide hangen voor eeuwig. De watchdog ziet het schedulerproces nog "leven" en herstart dus niets. Gevolg: de eerste (grotere) run na de update draait nog wel, maar daarna gebeurt er niets meer, ook geen prices/meteo op de volgende tijdstippen.
Twee kleinere bijeffecten van dezelfde wijziging:
De output van runs verschijnt niet meer in de add-on-log (hij verdwijnt in de pipe).
De taak clean werkt nu niet: het cmd stuurt argument clean_data, maar main() in day_ahead.py kijkt naar clean, dus de scheduler-run doet stilletjes niets.
Wat je nu kunt doen
Optie 1 (snelst): terug naar 2026.8.0 tot er een fix is.
Optie 2: zelf patchen in /root/dao/prog/da_scheduler.py

[Mvdw]

rescla schreef op zaterdag 5 september 2026 @ 22:06:
Bij mij werkt de scheduler wel. Heb eerder, op een oudere versie, wel meerdere keren problemen gehad met de scheduler. Maar daar lag elke keer een probleem met de supervisor aan ten grondslag. Om dat te fixen moet ik in de terminal app of via ssh dan de volgende commands draaien:

code:

ha supervisor repair 
ha supervisor restart

Geprobeerd, helaas geen oplossing. Dank voor de suggestie!

[Mvdw]

KC27 schreef op zaterdag 5 september 2026 @ 22:12:
Als je opstartproblemen met de nieuwe versie hebt helpt het vaak om DAO handmatig te herstarten:
In HA ga naar Instellingen/Apps, kies DAO, klik op "Herstarten".
Je kunt daar ook op het tabblad Logboek kijken. Dat geeft ook vaak informatie wat er aan de hand is

Geprobeerd maar lost het niet op. De eerste run gaat goed, daarna niet meer.

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "POST /core/api/services/input_text/set_value HTTP/1.1" 200 473

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "GET /core/api/states/input_text.dao_melding HTTP/1.1" 200 471

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 730 in /root/dao/prog/da_base.py

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 5146 in /root/dao/webserver/../prog/day_ahead.py

De run komt tot hier.

[KC27]

Mvdw schreef op zaterdag 5 september 2026 @ 23:12:
[...]

Geprobeerd maar lost het niet op. De eerste run gaat goed, daarna niet meer.

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "POST /core/api/services/input_text/set_value HTTP/1.1" 200 473

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "GET /core/api/states/input_text.dao_melding HTTP/1.1" 200 471

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 730 in /root/dao/prog/da_base.py

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 5146 in /root/dao/webserver/../prog/day_ahead.py

De run komt tot hier.

Ik wil dit graag op korte termijn oplossen.
Een paar vragen:

• kun je in je settings "logging_level": "info" zetten, heeft dat effect
• hoe ziet je "homeassistant" setting eruit?
• draai je DAO als HA-app(add-on) of in een losse container?

[KC27]

We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:

• removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
• added git and nano to installed packages
• corrected finish day_ahead.py on arm64 to prevent crash with error -4

[thewhi]

KC27 schreef op zaterdag 5 september 2026 @ 23:40:
[...]

Ik wil dit graag op korte termijn oplossen.
Een paar vragen:

• kun je in je settings "logging_level": "info" zetten, heeft dat effect
• hoe ziet je "homeassistant" setting eruit?
• draai je DAO als HA-app(add-on) of in een losse container?

Na aanpassen van logging level naar info deed de scheduler het hier inderdaad weer!

[stat]

KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:

• removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
• added git and nano to installed packages
• corrected finish day_ahead.py on arm64 to prevent crash with error -4

Ik wil graag testen maar als ik voor het installeren van de testversie als app in HAOS de instructies op de wiki volg dan gaat het mis bij het toevoegen van de repository:

code:

Cmd('git') failed due to: exit code(128) cmdline: git clone -v --recursive --branch=addon --depth=1 --shallow-submodules -- https://github.com/corneel27/day-ahead /data/apps/git/c7ff724d stderr: 'Cloning into '/data/apps/git/c7ff724d'... POST git-upload-pack (344 bytes) fatal: Remote branch addon not found in upstream origin '

Kan iemand me verder helpen?

[Mvdw]

KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:

• removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
• added git and nano to installed packages
• corrected finish day_ahead.py on arm64 to prevent crash with error -4

Bedankt! Ik ga het z.s.m. testen. Logging stond eerder op Info en toen werkte het niet, daarom op debug gezet om te begrijpen waar het misgaat.

DAO draait als add-on.

"config_version": 2,

"homeassistant": {

"ip_address": "supervisor",

"protocol_api": "http"

[Mvdw]

KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:

• removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
• added git and nano to installed packages
• corrected finish day_ahead.py on arm64 to prevent crash with error -4

Probleem is opgelost na het installeren van de testversie. De runs worden netjes afgerond binnen ongeveer 1,5 minuut.

[Frankvbr]

Batavia schreef op zondag 30 augustus 2026 @ 08:48:
[...]

Je balance switch zegt dat ie accu in net balancing mode moet gaan

Daar bovenop kan je altijd eigen automation maken op basis van wat dao zegt. Dao dingen 100% direct laten aansturen is niet altijd een goed idee.

Je kan bijvoorbeeld je accu in net balance mode zetten als de prijs boven het daggemiddelde zit. Heb je verder dao niet voor nodig

Dank. Uiteindelijk ook gevonden op de wiki, is toch even zoeken ook daar naar de juiste voorbeelden.

Mijn insteek is toch echt wel DAO zoveel mogelijk te laten aansturen, zou ook niet weten waarom je dat niet zou willen? Idee is dat het zoveel mogelijk vanzelf gaat. Ik kan wel met automations gaan werken i.c.m. prijzen, maar DAO moet voorspellen wat mijn resterende accu waarde zal zijn, mijn opwek etc.

Zal natuurlijk wel zoveel mogelijk DAO moeten voeden. Accu en panelen lijken nu wel goed samen te werken. Warmtepomp wordt complex omdat je ook zit met optimale tijden qua verwarmen (warmste momenten van de dag), maar omdat het een propaan warmtepomp is, is het boilervat verwarmen als het buiten te warm is, soms weer nadelig (dan gebruikt hij elektrisch element, dus cop=1).

Voor de vaatwasser wil ik het nu alsvolgt doen:
- Standaard de verwachte begintijd om 22.00 uur zetten in DAO
- Standaard het meest frequent gebruikte programma rekening mee houden.
Als ik de vaatwasser inruim plus 'aanzet' kies ik uitgestelde start (1, 2 of 3 uur) als die niet direct klaar moet zijn.
Dat triggert een automation die vervolgens een nieuwe begintijd aan DAO doorgeeft.
Uitgestelde start 1 uur = Volgende ochtend moet vaatwasser klaar zijn
Uitgestelde start 2 uur = Vaatwasser moet voor 22.30 klaar zijn
Uitgestelde start 3 uur = Vaatwasser moet voor 18.00 klaar zijn
Vervolgens kan DAO bepalen wat de optimale tijd is om te draaien.

Op deze manier houdt DAO in ieder geval altijd rekening met het verbruik.
Als ik dat niet wil (bijvoorbeeld tijdens vakantieperiodes), kan ik dan simpelweg het begin/eindtijdstip leeghouden of beter het programma leeghouden?

Edit: entity calculated end > bij machines lijkt een verplicht veld. Anders dan in de wiki staat. Ik kreeg er een crash op.

[ Voor 3% gewijzigd door Frankvbr op 06-09-2026 23:43 ]

[anboni]

Frankvbr schreef op zondag 6 september 2026 @ 22:45:
[...]

Mijn insteek is toch echt wel DAO zoveel mogelijk te laten aansturen, zou ook niet weten waarom je dat niet zou willen? Idee is dat het zoveel mogelijk vanzelf gaat. Ik kan wel met automations gaan werken i.c.m. prijzen, maar DAO moet voorspellen wat mijn resterende accu waarde zal zijn, mijn opwek etc.

DAO is de dirigent. Die zet de maat, maar de muzikanten (je automations) bedienen de instrumenten. DAO zet de balance switch, je automation triggert daarop om je aansturing van de accu's op Net Zero te zetten.

[Probydoby]

Ik ben er nog niet over uit hoe ik komend stookseizoen de L/L warmtepomp (airco's) will laten aansturen door DAO. Naar wat ik begreep zit er wel een model in die de stooklijn kan sturen van een L/W warmtepomp, maar hoe zou ik deze functionaliteit kunnen gebruiken voor de L/L warmtepomp?

Ik zat eraan te denken om de output van die functionaliteit te gebruiken om de setpoint van de Airco te verhogen en zo mijn huis te veranderen in een soort van thermische batterij. Stroom relatief goedkoop? setpoint omhoog, Relatief duur? Setpoint omlaag.

Heeft iemand inspiratie voor mij hoe je DAO hier het beste voor kan inzetten?

[marnie]

Hallo, ik probeer DAO te installeren als HA app maar krijg het niet voor elkaar. Ik krijg een database not found error, echter deze database staat netjes in de aangegeven folder. Ik draai HAOS in Proxmox.

code:

[11:48:52] INFO: => directory dao_data exist
[11:48:52] INFO: => /root/dao/data doesn't exist, made
[11:48:52] INFO: => /root/dao/webserver/app/static/data exist
2026-09-07 11:48:56 INFO: Loaded 6 secrets from ../data/secrets.json
2026-09-07 11:48:56 INFO: Validating configuration with ConfigurationV2
Starting scheduler...
Scheduler PID: 30
Starting gunicorn...
Gunicorn PID: 31
[2026-09-07 11:48:57 +0200] [31] [INFO] Starting gunicorn 26.2.0
[2026-09-07 11:48:57 +0200] [31] [INFO] Listening at: http://0.0.0.0:5000 (31)
[2026-09-07 11:48:57 +0200] [31] [INFO] Using worker: sync
[2026-09-07 11:48:57 +0200] [37] [INFO] Booting worker with pid: 37
[2026-09-07 11:48:57 +0200] [38] [INFO] Booting worker with pid: 38
[2026-09-07 11:48:57 +0200] [31] [INFO] Control socket listening at /root/.gunicorn/gunicorn.ctl
2026-09-07 11:49:04 INFO: Loaded 6 secrets from ../data/secrets.json
2026-09-07 11:49:04 INFO: Validating configuration with ConfigurationV2
2026-09-07 11:49:04 ERROR: Home Assistant database not found: /homeassistant/home-assistant_v2.db
Traceback (most recent call last):
  File "/root/dao/prog/da_scheduler.py", line 74, in <module>
    main()
    ~~~~^^
  File "/root/dao/prog/da_scheduler.py", line 69, in main
    da_sched = DaScheduler("../data/options.json")
  File "/root/dao/prog/da_scheduler.py", line 10, in __init__
    super().__init__(file_name)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 118, in __init__
    raise RuntimeError('No database connection for Home Assistant')
RuntimeError: No database connection for Home Assistant
Scheduler crashed with exit code 1
Stopping gunicorn...
[2026-09-07 11:49:07 +0200] [31] [INFO] Handling signal: term
[2026-09-07 11:49:09 +0200] [37] [INFO] Worker exiting (pid: 37)
[2026-09-07 11:49:09 +0200] [38] [INFO] Worker exiting (pid: 38)
[2026-09-07 11:49:09 +0200] [31] [INFO] Shutting down: Master
Scheduler crashed with exit code 1
Scheduler crashed with exit code 1

[KVan]

Probydoby schreef op maandag 7 september 2026 @ 10:08:
Ik ben er nog niet over uit hoe ik komend stookseizoen de L/L warmtepomp (airco's) will laten aansturen door DAO. Naar wat ik begreep zit er wel een model in die de stooklijn kan sturen van een L/W warmtepomp, maar hoe zou ik deze functionaliteit kunnen gebruiken voor de L/L warmtepomp?

Ik zat eraan te denken om de output van die functionaliteit te gebruiken om de setpoint van de Airco te verhogen en zo mijn huis te veranderen in een soort van thermische batterij. Stroom relatief goedkoop? setpoint omhoog, Relatief duur? Setpoint omlaag.

Heeft iemand inspiratie voor mij hoe je DAO hier het beste voor kan inzetten?

Ik heb hier hetzelfde. 5 L/L airco's die ik tot voor ik DAO gebruikte aanstuurde zodra ik zonnestroom op overschot had door het setpunt omhoog of omlaag te zetten (winter vs zomer). Hoe eea het best functioneerd in combinatie met batterijen en kosten optimalizatie is me nog ook niet helemaal duidelijk. Ik ga eerst de typische kost curves in de winter eens bestuderen maar wat ik tot nu gezien heb is dat vergelijkbaar met de zomer: goedkoop in de namiddag en snachts. Dus ergens tussen 14 en 17 uur de thermostaat omhoog en de rest van de dag constant laten staan, eventueel aan het eind van de nacht nog even omhoog. Op die manier gaan ze tussen 6 en 11 als de prijs hoog is nauwelijks vermogen trekken en kan vanuit de batterij maximaal teruggelevert worden.

Als volgend jaar de BTW teruggaaf er af gaat verandert het beeld wellicht. Dan wordt terugleveren uit de batterij een stuk minder interessant en ga je vermoed ik juist enkel tijdens de avond vol verwarmen of koelen. De dagen dat terugleveren wel interessant is moetten er dan tussenuit geplukt worden en de strategie er op aangepast.

[Probydoby]

KVan schreef op maandag 7 september 2026 @ 12:00:
[...]

Ik heb hier hetzelfde. 5 L/L airco's die ik tot voor ik DAO gebruikte aanstuurde zodra ik zonnestroom op overschot had door het setpunt omhoog of omlaag te zetten (winter vs zomer). Hoe eea het best functioneerd in combinatie met batterijen en kosten optimalizatie is me nog ook niet helemaal duidelijk. Ik ga eerst de typische kost curves in de winter eens bestuderen maar wat ik tot nu gezien heb is dat vergelijkbaar met de zomer: goedkoop in de namiddag en snachts. Dus ergens tussen 14 en 17 uur de thermostaat omhoog en de rest van de dag constant laten staan, eventueel aan het eind van de nacht nog even omhoog. Op die manier gaan ze tussen 6 en 11 als de prijs hoog is nauwelijks vermogen trekken en kan vanuit de batterij maximaal teruggelevert worden.

Als volgend jaar de BTW teruggaaf er af gaat verandert het beeld wellicht. Dan wordt terugleveren uit de batterij een stuk minder interessant en ga je vermoed ik juist enkel tijdens de avond vol verwarmen of koelen. De dagen dat terugleveren wel interessant is moetten er dan tussenuit geplukt worden en de strategie er op aangepast.

Ik denk dat deze aanpak vooral interessant is in de zomer, althans mijn PV opwek is op moment dat ik intensief moet verwarmen verwaarloosbaar en daar valt weinig te halen. Het zal vooral op basis van de day-ahead prijzen moeten gebeuren.

Het liefst zet ik het volledig in DAO, zodat de airco niet meer onderdeel is van de baseload maar een volledig planbaar apparaat.

[KVan]

Probydoby schreef op maandag 7 september 2026 @ 12:24:
[...]


Ik denk dat deze aanpak vooral interessant is in de zomer, althans mijn PV opwek is op moment dat ik intensief moet verwarmen verwaarloosbaar en daar valt weinig te halen. Het zal vooral op basis van de day-ahead prijzen moeten gebeuren.

Het liefst zet ik het volledig in DAO, zodat de airco niet meer onderdeel is van de baseload maar een volledig planbaar apparaat.

Om de airco's uit de baseload to halen plan ik ze elk van een Shelly plug of schakelaar met stroommeting te voorzien. Het moet ook mogelijk zijn om mijn Mitsubishi's via hun interne poort aan te sturen en er een hoop ifo zoals load er uit te halen, echter ik ben er nog niet in geslaagd de ESPhome sketch te compileren (krijg telkens foutmeldingen).

[Probydoby]

KVan schreef op maandag 7 september 2026 @ 13:31:
[...]

Om de airco's uit de baseload to halen plan ik ze elk van een Shelly plug of schakelaar met stroommeting te voorzien. Het moet ook mogelijk zijn om mijn Mitsubishi's via hun interne poort aan te sturen en er een hoop ifo zoals load er uit te halen, echter ik ben er nog niet in geslaagd de ESPhome sketch te compileren (krijg telkens foutmeldingen).

Ja dat kan, maar je moet ze dan ook als planbaar apparaat configureren anders onderschat je je load, immers komen ze dan niet in de baseload voor maar ze worden ook niet gepland ( en ondertussen draai je ze wel). En hoe je dat nou configureert dat je ze ook kan inplannen en aansturen met DAO & HA is de grote vraag. (simpelweg on/off, met de ingebouwde stooklijn functionaliteit en daarop een vertaling naar L/L setpoints binnen HA, enz).

[CSB]

Interessante discussie over DAO i.c.m. L/L warmtepomp, ik zit met exact hetzelfde, dus ik ga meelezen (en denken).

[Beekforel]

The Source schreef op zondag 23 augustus 2026 @ 19:38:
Ik heb Claude Pro (kan ook gratis) via HA-MCP verbonden aan HA, damn erg handig. Pas dit aan, doe dat, het kan het allemaal. Helaas krijg ik steeds minder zicht op hoe het werkt, maar het kan wel alles verwezenlijken wat in mijn hoofd zat, maar mij weken/maanden zou kosten om te maken.

Ik log al jaren alle data in Influx en hier kan Claude ook enorm veel details mee uitrekenen, zoals de COP van mijn warmtepomp en de COP-buckets bepalen, maar bv ook het warmteverlies van de woning.

Helaas kan Claude niet bij de DAO-config, dus dit gedeelte is nog copy/paste. (hint) .

DAO kon vanmiddag geen prijzen ophalen en de auto kon niet ingepland worden. Door logfiles te voeden, zijn een boel dingen opgelost en het lag aan de core-update die ik uitgevoerd had. Vandaag tijd (en zon) gehad om mijn laadpaal te checken en alles een beetje af te stemmen. Nou ja... ik keek, Claude deed het werk.

Ik heb Claude Pro als extension in VSCode server en heb hem een long lived access token naar HA gegeven. Misschien wat roekeloos, maar damn dat is krachtig. Hij kan overal bij.

Hij kan dan dus ook de options.json van DAO aanpassen en alles begrijpen. Ik heb ook best wat jaren data in HA dus daar kan hij ook wel wat mee.

Heb vanavond wat aanpassingen doorgevoerd in de baseload calculatie, nu weer even een paar weken wachten of dat gaat helpen. Claude heeft wel met de data die hij tot zijn beschikking heeft de baseload herberekend en gecorrigeerd, ik had deze veel te voorzichtig ingevuld. Ben benieuwd hoeveel invloed dit heeft op de berekeningen.

Ik heb eerder al eens een CLAUDE.md opgezet in de root van mijn HA bestanden, hier staan wat richtlijnen in over hoe ik wil dat dingen geconfigureerd worden en wat wel en niet mag. Erg nutttig.

[Frankvbr]

Ik heb in de zomer een beetje getest met voorkoelen van de woning (dus echt urenlang) en vervolgens tijdelijk uitzetten (we hadden toen paar uur dat dynamische tarief rond een euro lag). De temperatuur ging weer neem rap omhoog.

Denk dat het andersom hetzelfde werkt. Je warmt geen massa op tenzij je misschien zeer langdurig verwarmt. Ik denk dat airco juist goedkoper is als je deze gebruikt als je aanwezig bent (ook snel warm gevoel) en voor de rest uit zet.

[Probydoby]

Frankvbr schreef op dinsdag 8 september 2026 @ 00:19:
Ik heb in de zomer een beetje getest met voorkoelen van de woning (dus echt urenlang) en vervolgens tijdelijk uitzetten (we hadden toen paar uur dat dynamische tarief rond een euro lag). De temperatuur ging weer neem rap omhoog.

Denk dat het andersom hetzelfde werkt. Je warmt geen massa op tenzij je misschien zeer langdurig verwarmt. Ik denk dat airco juist goedkoper is als je deze gebruikt als je aanwezig bent (ook snel warm gevoel) en voor de rest uit zet.

Omdat zelfs een paar uur voorkoelen geen zoden aan de dijk zet en de thermische massa van je meubels + huis de lucht weer verwarmd.

In winter moet je 24/7 het warmteverlies compenseren, met een warmtepomp het liefst zo steady mogelijk, maar met dynamische tarieven wellicht gestuurd door DAO om het zo kosteneffectief mogelijk te doen. Zeker als je niet de hele dag hoeft te verwarmen om het totale warmteverlies te compenseren (in de herfst/lente bijvoorbeeld).

[KVan]

Frankvbr schreef op dinsdag 8 september 2026 @ 00:19:
Ik heb in de zomer een beetje getest met voorkoelen van de woning (dus echt urenlang) en vervolgens tijdelijk uitzetten (we hadden toen paar uur dat dynamische tarief rond een euro lag). De temperatuur ging weer neem rap omhoog.

Denk dat het andersom hetzelfde werkt. Je warmt geen massa op tenzij je misschien zeer langdurig verwarmt. Ik denk dat airco juist goedkoper is als je deze gebruikt als je aanwezig bent (ook snel warm gevoel) en voor de rest uit zet.

Mee eens.

Ik heb de afgelopen jaren gespeeld met de regeling (met een vast contract dus enkel naar totaal verbruik gekeken) en constant draaien is qua totaal verbruik het zuinigst. Met dynamische tarieven spelen wat extra dingen. In de zomer maakt het niet uit want de airco draait wanneer de zonschijnt en dus de stroom het goedkoopst is.

In de winter is dat precies tegenovergesteld. Een paar uur voorverwarmen levert idd heel weinig op. Wat denk ik wel werkt is om de thermostaat de hele periode overdag dat de stroom gunstig is 2 of 3 graden hoger in te stellen en dan s'avonds de thermostaat weer op normaal niveau in te stellen (eventueel getrapt omlaag). Daarmee stopt de airco niet maar gaat wel op een veel lager vermogen draaien. Waarmee we dan vast de avond doorkomen en snachts pikt hij dan weer op normaal niveau op.

Dat geld denk ik tot 1 Jan. Vanaf 1 Jan wordt teruglevern van stroom niet of nauwelijks nog interessant en gaan de accu's voor de stroom voor de airco's zorgen. Dus opladen wanneer goedkoop en de airco's simpelweg constant laten draaien. Het verdienmodel van het net opladen en weer terugleveren enkele uren later is dat toch grotendeels verdwenen.

Praktisch in mijn geval heb ik op koude dagen een verbruik van 50 kWh/24u in totaal. Met 36 kWh accus moet ik dan prima de dure momenten kunnen bufferen en laden wanneer de stroom goedkoper is. Heb je kleinere accu's dan kan de voorverwarm truck met verlaging van het setpunt op de dure momenten alsnog goed uitpakken.

Hoe dit vanuit DAO aan te sturen is weet ik ook nog niet maar ik vermoed dat een machine aanmaken die dan via de entities calculated start and stop het setpunt omhoog zet. Een automatizering kan dan het setpunt getrapt omhoog en omlaag zetten om in het COP gunstige gebied te blijven.

[simnet]

Het grote probleem is dat thermische massa (precies dat wat je nodig hebt om kou of warmte vast te houden) omgekeerd evenredig moeilijk op te warmen of af te koelen is. Hoe meer thermische massa je hebt, hoe langzamer het proces.

En een huis heeft al snel zo veel massa dat je aan een paar uurtjes niet genoeg hebt om enig verschil te bereiken.

Edit: dit is nog even afgezien van de zeer inefficiënte manier om lucht te gebruiken om warmte in of uit je muren te krijgen.
(De warmtecapaciteit van lucht is richting de 2000x lager dan dat van steen)

[ Voor 22% gewijzigd door simnet op 08-09-2026 15:26 ]

[Beekforel]

Hoe gaat dat eigenlijk vanaf 1 januari, moeten we iets aanpassen in de DAO configuratie dat salderen niet meer bestaat?

[dannyll]

Beekforel schreef op dinsdag 8 september 2026 @ 15:41:
Hoe gaat dat eigenlijk vanaf 1 januari, moeten we iets aanpassen in de DAO configuratie dat salderen niet meer bestaat?

Dan ga je nieuwe prijzen invoeren in je config...en gaat DAO anders rekenen vermoed ik. Nu wordt balance switch bij mij nog niet gebruikt, maar zal dan wel belangrijk(er) worden

[KVan]

simnet schreef op dinsdag 8 september 2026 @ 15:17:
Het grote probleem is dat thermische massa (precies dat wat je nodig hebt om kou of warmte vast te houden) omgekeerd evenredig moeilijk op te warmen of af te koelen is. Hoe meer thermische massa je hebt, hoe langzamer het proces.

En een huis heeft al snel zo veel massa dat je aan een paar uurtjes niet genoeg hebt om enig verschil te bereiken.

Edit: dit is nog even afgezien van de zeer inefficiënte manier om lucht te gebruiken om warmte in of uit je muren te krijgen.
(De warmtecapaciteit van lucht is richting de 2000x lager dan dat van steen)

Inefficient is het verwarmen van steen met lucht niet, er gaat geen energie verloren. Inefectief of niet heel snel wel.
Dat was een beetje mierenneuken, maar het klopt dat je niet heel veel warmte opgeslagen krijgt in korte tijd. Hoeveel je opslaat hangt ook nog eens heel sterk af van de "thermische vertraging" van de materialen in je woning (bijvoorbeeld hoog bij kalkzandsteen en laag bij beton). Daarom zei ik eerder ook dat je de airco's zeker enkele graden omhoog moet zetten voor een flinke tijd, veel meer dan een uurtje of 2, meer 6 tot 8 uur.

Een lucht/water warmtepomp heeft overigens hetzelfde probleem. Je kan het water wel voorverwarmen maar om enige buffer op te bouwen heb je wel een erg groot buffervat nodig. Mijn airco's verstoken ~20kWh op een koude dag, dus ~60kWh warmte om dan in de avond 5 uur te overbruggen zou je 12.5kWh buffer moeten hebben. Dat zou een boilervat van 500l met een beschikbare deltaT van 25 graden zijn.

Met kalkzandsteen muren heb je een capaciteit van 0.05 kWh/m2K. Als ik de temperatuur 3 graden opvoer gedurende 6 uur en aanneem dat ik de steen voor 50% heb opgewarmd (wilde aanname) dan heb ik 0.075 kWh/m2 opgeslagen. Dan zou ik 167m2 nodig hebben om diezelfde 5 uur te overbruggen. Zonder vloeren en plafonds mee te rekenen heb ik in huis op de benedenverdieping grofweg 125m2 beschikbaar. Dat zou een aardig eind kunnen komen. En komt aardig overeen met mijn ervaring dat mijn huis na een hele dag verwarmen s'nachts ongeveer 3 graden afkoelt (dan heeft de verwarming ongeveer 16 uur gedraaid en 8 uur staan afkoelen).

Neem deze rekensom met een flinke korrel zout want er zitten stevige aannames in! eea hangt heel sterk af van hoe goed een huis geisoleerd is, mijn rekensom is voor mijn goed geisoleerd huis.

Wat altijd zal opgaan is dat wanneer de thermostaat tijdens de avond trapsgewijs omlaag gezet wordt de airco's op een lagere last en dus met wat hogere COP zullen draaien. Maar of dit allemaal ook comfortabel is weet ik niet, zullen we moeten ondervinden.

[simnet]

Ok, niet effectief. Klopt.

Je aanname klopt alleen niet helemaal. Om je muur zodanig op te warmen - met lucht - dat hij die 3 graden verval aankan heb je een veel hogere luchttemperatuur nodig dan comfortabel is.
Je berekening klopt, maar alleen is de warmteoverdracht vanuit de lucht naar je kalkzandsteen zodanig laag, dat je al snel een verschil van 5 graden moet volhouden als je een gemiddelde temperatuur van 21 graden wil bereiken. Dat is best oncomfortabel.

[Hvdort]

KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:

• removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
• added git and nano to installed packages
• corrected finish day_ahead.py on arm64 to prevent crash with error -4

Ik heb, ook na het updaten van HA naar de laatste versie nog steeds deze foutmelding:

2026-09-08 19:26:25 fout: An error occurred while loading the CBC library: cannot load library '/root/dao/prog/miplib/lib/libCbc.so': libnauty-2.8.9.so: cannot open shared object file: No such file or directory. Additionally, ctypes.util.find_library() did not manage to locate a library called '/root/dao/prog/miplib/lib/libCbc.so'

Ik heb het gechecked maar de optie "use_self_compiled_miplib" staat uit. Dit probleem had ik in versie 2026.8 en nu ook in 2026.9, maar nog niet in 2026.6. Doe ik wat fout?

[Dogooder]

Hvdort schreef op dinsdag 8 september 2026 @ 19:43:
[...]

Ik heb, ook na het updaten van HA naar de laatste versie nog steeds deze foutmelding:

2026-09-08 19:26:25 fout: An error occurred while loading the CBC library: cannot load library '/root/dao/prog/miplib/lib/libCbc.so': libnauty-2.8.9.so: cannot open shared object file: No such file or directory. Additionally, ctypes.util.find_library() did not manage to locate a library called '/root/dao/prog/miplib/lib/libCbc.so'

Ik heb het gechecked maar de optie "use_self_compiled_miplib" staat uit. Dit probleem had ik in versie 2026.8 en nu ook in 2026.9, maar nog niet in 2026.6. Doe ik wat fout?

Op wat voor hardware architectuur draai je je docker?

Heb je toevallig nog ergens docker mounts staan naar lege mappen op de schijf?

[Hvdort]

Op een Intel NUC en Proxmox en daarbinnen HA. DAO is een container binnen HA. Ik heb mogelijk zojuist wel iets gevonden: er was nog een (ooit zelf gecompileerde) miplib folder achtergebleven die in dezelfde folder staat als dao_data. Mogelijk wordt die nog automatisch gemapped als die bestaat? Anyway, ik heb de folder hernoemd en een herstart gedaan van de huidige werkende versie 2026.6. Die werkt gelukkig nog steeds.
Ik hoop straks opnieuw de upgrade te doen naar 2026.9 om te kijken of dan het probleem weg is...

[ Voor 5% gewijzigd door Hvdort op 08-09-2026 20:47 ]

[Hvdort]

Bingo! Probleem is nu weg. Dus vind er inderdaad nog een automatische mapping plaats van de miplib folder als die bestaat, ondanks de setting "use_self_compiled_miplib" die uit staat.

[UsernameIsInUse]

Mijn DAO is afgelopen dagen automatisch geupdate naar versie 2026.09. (auto-update van deze app inmiddels uitgeschakeld)
Maar ik loop er tegenaan dat mijn (elk kwartier) geschedulede taken niet meer worden uitgevoerd.
De oplossing om het logging level op "info" te zetten heeft geen effect.
Ik lees dat rc 2026.09.1 mogelijk een oplossing geeft, maar ik ben niet de persoon om met rc versies aan de slag te gaan.
Is er op korte termijn zicht op een andere oplossing, bijvoorbeeld dat de rc versie gereleased wordt naar productie?

[KC27]

@UsernameIsInUse: je wordt op je wenken bediend:
Vanavond is de nieuwe stabiele versie gepubliceerd: 2026.9.1
Deze versie is functioneel exact hetzelfde als testversie 2026.9.1.rc1
Dit staat in de changelog:

• removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
• added git and nano to installed packages
• corrected finish day_ahead.py on arm64 to prevent crash with error -4

[mgroen81]

De testversie 2026.9.1.rc1 werkt inderdaad.
Wat ik wel vreemd vind is dat de logging nu zon'n 16 seconden na het kwartier begint.
Is dit nog een fout? Dit was voorheen niet zo.

[simnet]

Ter info: https://epexpredictor.batzill.com/docs
Wellicht een goede toevoeging als prijs provider.

[Wilin]

Ik heb de afgelopen week wat beginnen met configureren van DAO voor mijn situatie. Ik zit vanaf 1 oktober op dynamisch tarief met 15 min intervallen. Tot nog toe vind ik dit alvast een super app.

Enkele vragen:

Hoe werkt het systeem van Machines? Ik wil het gebruiken voor het inplannen van vaatwas, wasmachine en droogkast die ik wel manueel moet inplannen (met half uur incrementen). Het idee is om een slot te laten berekenen en dan zo dicht mogelijk erbij het toestel te laten starten.

1. hoe weet DAO dat een machine wel degelijk is gestart wanneer het ingepland was? Gaat het daar gewoon van uit? Misschien moeten we op één of andere manier doorgeven wanneer het echt is gestart?
2. Wanneer zet ik best de modus van de machine terug op "Uit"?
3. is het een goed idee om wanneer de machine echt start, de "start nu" boolean op true te zetten en een herberekening te triggeren?

Is er een mogelijkheid om de berekende prijs per kwartier door te geven aan HomeAssistant om te gebruiken in het energy dashboard? Dan hoef ik niet nog eens de belpex info binnen te halen.

Ik heb al veel van de wiki geleerd en wil zeker wel teruggeven door wat extra voorbeelden te schrijven op basis van wat ik heb bij mij en wat ik tot nog toe geleerd heb. Hoe start ik daar best mee?

[Torch1969]

Wilin schreef op donderdag 10 september 2026 @ 20:37:


Is er een mogelijkheid om de berekende prijs per kwartier door te geven aan HomeAssistant om te gebruiken in het energy dashboard? Dan hoef ik niet nog eens de belpex info binnen te halen.

Ophalen via de api? https://github.com/corneel27/day-ahead/wiki/6.-Gebruik-van-de-API#bij-variable-kun-je-één-van-de-volgende-gebruiken

[Wilin]

Torch1969 schreef op donderdag 10 september 2026 @ 20:57:
[...]

Ophalen via de api? https://github.com/corneel27/day-ahead/wiki/6.-Gebruik-van-de-API#bij-variable-kun-je-één-van-de-volgende-gebruiken

Ooh, dat deel van de wiki heb ik duidelijk nog niet goed genoeg gelezen. Dank !

[KVan]

Wilin schreef op donderdag 10 september 2026 @ 20:37:
Ik heb de afgelopen week wat beginnen met configureren van DAO voor mijn situatie. Ik zit vanaf 1 oktober op dynamisch tarief met 15 min intervallen. Tot nog toe vind ik dit alvast een super app.

Enkele vragen:

Hoe werkt het systeem van Machines? Ik wil het gebruiken voor het inplannen van vaatwas, wasmachine en droogkast die ik wel manueel moet inplannen (met half uur incrementen). Het idee is om een slot te laten berekenen en dan zo dicht mogelijk erbij het toestel te laten starten.

1. hoe weet DAO dat een machine wel degelijk is gestart wanneer het ingepland was? Gaat het daar gewoon van uit? Misschien moeten we op één of andere manier doorgeven wanneer het echt is gestart?
2. Wanneer zet ik best de modus van de machine terug op "Uit"?
3. is het een goed idee om wanneer de machine echt start, de "start nu" boolean op true te zetten en een herberekening te triggeren?

Is er een mogelijkheid om de berekende prijs per kwartier door te geven aan HomeAssistant om te gebruiken in het energy dashboard? Dan hoef ik niet nog eens de belpex info binnen te halen.

Ik heb al veel van de wiki geleerd en wil zeker wel teruggeven door wat extra voorbeelden te schrijven op basis van wat ik heb bij mij en wat ik tot nog toe geleerd heb. Hoe start ik daar best mee?

Ik heb net vanavond mijn eerste machine, de vaatwasser aangemaakt. Ik heb een Siemens die via de home connect integratie in HA zit.

De uit stand zet ik aan het eind van de wasbeurt met een automatisering door de uit trigger van de machine te volgen. Verder een tweede automatisering die automatisch de eerstvolgende 8 uur als startperiode zet en het programma op auto zet. Daarna kan je manueel de periode of het programma aanpassen.

Ik kan morgen de automatisering posten als je wil.

[dotcom87]

Ik was afgelopen week begonnen met EMHASS maar de leercurve is wel zeer stijl. Maar ik heb begrepen dat DAO niet ideaal is om in België te gebruiken, owv de weersvoorspellingen etc? Klopt dit? Of zijn er Belgen hier (ik woon in Limburg) die DAO gebruiken?

[Wilin]

dotcom87 schreef op vrijdag 11 september 2026 @ 09:16:
Ik was afgelopen week begonnen met EMHASS maar de leercurve is wel zeer stijl. Maar ik heb begrepen dat DAO niet ideaal is om in België te gebruiken, owv de weersvoorspellingen etc? Klopt dit? Of zijn er Belgen hier (ik woon in Limburg) die DAO gebruiken?

Voor weersvoorspellingen kun je de europese api kiezen als je je meteoserver API key aanmaakt. Dat lijkt te werken voor mij. De prijsstructuur in Vlaanderen werkt voor mij ook. Voor Ecopower Burgerstroom Dynamisch:

YAML: options.json

   "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2026-09-01": 0.1132064
    },
    "energy_taxes_production": {
      "2026-09-01": 0.0017510
    },
    "cost_supplier_consumption": {
      "2026-09-01": 0.004
    },
    "cost_supplier_production": {
      "2026-09-01": -0.015
    },
    "vat_consumption": {
      "2026-09-01": 6.0
    },
    "vat_production": {
      "2026-09-01": 0
    },
    "multiplier_consumption": {
      "2026-09-01": 1.02
    },
    "multiplier_production": {
      "2026-09-01": 0.98
    },
    "last_invoice": "2026-09-01",
    "tax_refund": false,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },

[Altijdgriep]

Is het al mogelijk DOA in een ander land dan Nederland te gebruiken? Ik had al wel gelezen dat doa de locatie uit de instellingen van HA haalt maar hier in Zweden hebben we 4 verschillende zones en dus wordt er geen data opgehaald.

Het zou mooi zijn als doa gewoon de data haalt uit de nordpool integratie in HA, die staat namelijk al goed geconfigureerd.

[ Voor 21% gewijzigd door Altijdgriep op 11-09-2026 14:26 ]

[Aardedraadje]

Vraagje als dat mag

Ik heb sinds een paar dagen DAO draaien i.c.m. een Zendure SF2400AC. Dat werkt fantastisch. Ik heb alleen een vraag over de aansturing van het vermogen van de batterij, en de berekening van laad- en ontlaadtijd.

Voor zover ik in docs.md en settings.md kan vinden, zijn de instellingen voor het vermogen van de batterij in DC watts. De SF2400AC en de aansturing daarvan (via zijn API) gebeurt in AC. Max. AC-vermogen is 2400W beide kanten op.

Nu heb ik mijn batterij in DAO als volgt ingesteld:

code:

"battery":[
   {
      "name":"SF2400AC",
      "entity actual level":"sensor.zendure_2400_ac_laadpercentage",
      "capacity":14.4,
      "upper limit":100,
      "lower limit":10,
      "entity min soc end opt":"input_number.dao_min_soc_einde_opt",
      "entity max soc end opt":"input_number.dao_max_soc_einde_opt",
      "optimal lower level":15,
      "charge stages":[
         {
            "power":0.0,
            "efficiency":1
         },
         {
            "power":50,
            "efficiency":0
         },
         {
            "power":100,
            "efficiency":0.45
         },
         {
            "power":200,
            "efficiency":0.6
         },
         {
            "power":350,
            "efficiency":0.75
         },
         {
            "power":500.0,
            "efficiency":0.82
         },
         {
            "power":800.0,
            "efficiency":0.89
         },
         {
            "power":1200.0,
            "efficiency":0.92
         },
         {
            "power":2000.0,
            "efficiency":0.93
         },
         {
            "power":2400.0,
            "efficiency":0.92
         }
      ],
      "discharge stages":[
         {
            "power":0.0,
            "efficiency":1
         },
         {
            "power":50,
            "efficiency":0.47
         },
         {
            "power":100,
            "efficiency":0.64
         },
         {
            "power":150,
            "efficiency":0.73
         },
         {
            "power":200,
            "efficiency":0.8
         },
         {
            "power":350,
            "efficiency":0.85
         },
         {
            "power":500.0,
            "efficiency":0.89
         },
         {
            "power":800.0,
            "efficiency":0.92
         },
         {
            "power":1200.0,
            "efficiency":0.93
         },
         {
            "power":2000.0,
            "efficiency":0.94
         },
         {
            "power":2400.0,
            "efficiency":0.93
         }
      ],
      "reduced hours":{
         
      },
      "minimum power":50,
      "dc_to_bat efficiency":1,
      "bat_to_dc efficiency":1,
      "cycle cost":0.015,
      "solar":[
         
      ],
      "entity set power feedin":"input_number.dao_set_power_feedin",
      "entity set operating mode":"input_select.dao_set_operation_mode",
      "entity stop inverter":"input_datetime.dao_stop_inverter",
      "entity balance switch":"input_boolean.dao_balance_switch"
   }],

Echter schat DAO nu in dat bij 2400 laden (DC dus) er meer van het net komt, en er dus daadwerkelijk 2400W de accu ingaat. Dat is te optimistisch, omdat laden gebeurt met max 2400W AC. Andersom schat hij ontladen te pessimistisch in.

Een oplossing lijkt me om de charge stages en discharge stages als DC in te vullen en in home assistant de feedin entity weer om te rekenen van DC naar AC alvorens de SF2400AC aan te sturen. Maar is dit nou de juiste aanpak?

[Dogooder]

@Aardedraadje Ik weet vrij zeker dat DAO alle waardes in AC heeft. AC voor de charge en discharge stages en power feedin is ook in AC de batterij uit.
Daarbij rekent DAO alle efficiencies en verliezen zelf uit.
Er zijn optionele entities beschikbaar als entity from batterij of entity from ac met DC vermogen voor als je je batterij anders aanstuurt dan AC vermogen aan de uitgang.
Als je echt denk dat het fout zit post dan eens de log en dan met name de tabel in- en uitgaande energie.

[Aardedraadje]

Dogooder schreef op vrijdag 11 september 2026 @ 17:42:
@Aardedraadje Ik weet vrij zeker dat DAO alle waardes in AC heeft. AC voor de charge en discharge stages en power feedin is ook in AC de batterij uit.
Daarbij rekent DAO alle efficiencies en verliezen zelf uit.
Er zijn optionele entities beschikbaar als entity from batterij of entity from ac met DC vermogen voor als je je batterij anders aanstuurt dan AC vermogen aan de uitgang.
Als je echt denk dat het fout zit post dan eens de log en dan met name de tabel in- en uitgaande energie.

Dankjewel, ik ben er nog eens ingedoken en het lijkt erop dat mijn eerste conclusie inderdaad gewoon niet klopte. Ik was op het verkeerde spoor gezet door deze afbeelding op de homepage:

Hier lijkt het alsof er tijdens het laden overdags 2400W van AC wordt afgenomen, er iets minder de DC-kant ingaat. Dat klopt.

Kijk je vervolgens naar ontladen morgenavond, dan zie je aan zowel de DC-kant (logisch) maar ook aan de AC-kant een hoger vermogen geschetst. Dat klopt niet.

Maar duik ik de report in:

code:

  uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 19:30  -0.57  93.00  -0.62   0.00  -0.62 100.00  -0.62  93.00  53.71
 19:45  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  49.23
 20:00  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  44.75
 20:15  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  40.27
 20:30  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  35.79
 20:45  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  31.31
 21:00  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  26.83
 21:15  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  23.13
 21:30  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  19.44
 21:45  -0.10  94.00  -0.11   0.00  -0.11 100.00  -0.11  94.00  18.69
 22:00  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  15.00
 22:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 22:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 22:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 23:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 23:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 23:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 00:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 00:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 00:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 00:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 01:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 01:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 01:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 01:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 02:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 02:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 02:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 02:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 03:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 03:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 03:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 03:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 04:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 04:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 04:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 04:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 05:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 05:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 05:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 05:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 06:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 06:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 06:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 06:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 07:00   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 07:15   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 07:30   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 07:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
 08:00  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  11.31
 08:15   0.00     --   0.00   0.00   0.00     --   0.00     --  11.31
 08:30   0.00     --   0.00   0.00   0.00     --   0.00     --  11.31
 08:45   0.00     --   0.00   0.00   0.00     --   0.00     --  11.31
 09:00  -0.18  94.00  -0.19   0.00  -0.19 100.00  -0.19  94.00  10.00
 09:15   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 09:30   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 09:45   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 10:15   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 10:30   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
 10:45   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  13.83
 11:00   0.30  92.00   0.28   0.00   0.28 100.00   0.28  92.00  15.75
 11:15   0.59  92.12   0.54   0.00   0.54 100.00   0.54  92.12  19.50
 11:30   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  23.33
 11:45   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  27.17
 12:00   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  31.00
 12:15   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  34.83
 12:30   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  38.67
 12:45   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  42.50
 13:00   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  46.33
 13:15   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  50.17
 13:30   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  54.00
 13:45   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  57.83
 14:00   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  61.67
 14:15   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  65.50
 14:30   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  69.33
 14:45   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  73.17
 15:00   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  77.00
 15:15   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  80.83
 15:30   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  84.67
 15:45   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  88.50
 16:00   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  92.33
 16:15   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00  96.17
 16:30   0.60  92.00   0.55   0.00   0.55 100.00   0.55  92.00 100.00
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:15  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  96.31
 18:30  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  92.61
 18:45  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  88.13
 19:00  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  83.65
 19:15  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  79.17
 19:30  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  74.69
 19:45  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  70.21
 20:00  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  65.73
 20:15  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  61.25
 20:30  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  56.77
 20:45  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  52.29
 21:00  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  47.81
 21:15  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  43.33
 21:30  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  38.85
 21:45  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  35.15
 22:00  -0.60  93.00  -0.65   0.00  -0.65 100.00  -0.65  93.00  30.67
 22:15  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  26.98
 22:30  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  23.29
 22:45   0.00     --   0.00   0.00   0.00     --   0.00     --  23.29
 23:00  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  19.59
 23:15  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  15.90
 23:30  -0.30  94.00  -0.32   0.00  -0.32 100.00  -0.32  94.00  13.69
 23:45  -0.50  94.00  -0.53   0.00  -0.53 100.00  -0.53  94.00  10.00

Bij zowel laden als ontladen tikken AC-waardes maximaal 0.6 kWh per kwartier aan, wat klopt met de max 2400W AC.

Het lijkt er dus op dat er een tekenfout zit in het genereren van de grafiek die bij de data hoort, maar de daadwerkelijke berekening klopt gewoon.

[stat]

@KC27
Heb nu 9.1 draaien en het goede nieuws is dat ik mijn eerdere error niet meer krijg 'cbclib is not defined'). Dank!

Heb voor de volledigheid builden van de miplib nog wel getest, daarbij krijg ik nu deze error:

code:

checking for LAPACK... configure: error: "Cannot check for existence of module lapack without pkgconf"

Laat me weten als ik iets kan doen om te helpen

[ Voor 28% gewijzigd door stat op 12-09-2026 09:25 ]

[TheMystery]

mgroen81 schreef op woensdag 9 september 2026 @ 22:43:
De testversie 2026.9.1.rc1 werkt inderdaad.
Wat ik wel vreemd vind is dat de logging nu zon'n 16 seconden na het kwartier begint.
Is dit nog een fout? Dit was voorheen niet zo.

Hier net geupdate en de calculatie begint idd 10 tot 15 seconden later en hierdoor resultaat natuurlijk ook later, heb mijn automatiseringen hierop aangepast aangezien deze elke 15 min 10sec over lopen nu dus naar 20 moeten zetten anders werkte mijn automatisering niet meer.
Lijkt mij een bug.

Edit: heb het even bekeken maar het komt dat de scheduler nu voor elke taak een apart proces opstart en alles in moet laden. Geen idee of daarvoor nog iets te cachen valt om het te versnellen.

[ Voor 14% gewijzigd door TheMystery op 12-09-2026 20:16 ]

[KVan]

TheMystery schreef op zaterdag 12 september 2026 @ 19:40:
[...]


Hier net geupdate en de calculatie begint idd 10 tot 15 seconden later en hierdoor resultaat natuurlijk ook later, heb mijn automatiseringen hierop aangepast aangezien deze elke 15 min 10sec over lopen nu dus naar 20 moeten zetten anders werkte mijn automatisering niet meer.

Je kan ook triggeren op "state change". Ik laat dao de "dao last activity" schrijven dan triggert hij na elke betekening.

[TheMystery]

KVan schreef op zaterdag 12 september 2026 @ 21:18:
[...]

Je kan ook triggeren op "state change". Ik laat dao de "dao last activity" schrijven dan triggert hij na elke betekening.

Doe kende ik nog niet, heb hem eens in mijn config gezet, maar zie dat ie bij 1 berekening 2x getriggerd wordt, is dat normaal?

[anboni]

TheMystery schreef op zaterdag 12 september 2026 @ 23:25:
[...]


Doe kende ik nog niet, heb hem eens in mijn config gezet, maar zie dat ie bij 1 berekening 2x getriggerd wordt, is dat normaal?

[Afbeelding]

Gaat 'ie in dat rode streepje misschien tijdelijk naar unavailable oid terwijl de waardes opnieuw worden berekend? Bij het aanmaken kun je ook nog een tijd instellen, dan activeert de automation pas als de state x seconden (minuten/uren) op de nieuwe waarde staat. Vul daar 10s in en je krijgt netjes maar 1 trigger per berekening.

[TheMystery]

anboni schreef op zondag 13 september 2026 @ 00:19:
[...]

Gaat 'ie in dat rode streepje misschien tijdelijk naar unavailable oid terwijl de waardes opnieuw worden berekend? Bij het aanmaken kun je ook nog een tijd instellen, dan activeert de automation pas als de state x seconden (minuten/uren) op de nieuwe waarde staat. Vul daar 10s in en je krijgt netjes maar 1 trigger per berekening.

Nee gaat niet naar unavailable, maar hij wordt ook elke 10min nog getriggerd vanaf 3 over terwijl er op dat tijdstip niets in de logging te vinden is, en er in de task scheduler niets draait


Heb het er ook bij mijn ouders in de config gezet en daar triggerd die alleen elk kwartier maar dan weer 3x wat bij mij 2x is. Dus lastig om in een automation als trigger te gaan gebruiken.

[balk]

TheMystery schreef op zaterdag 12 september 2026 @ 19:40:
[...]


Hier net geupdate en de calculatie begint idd 10 tot 15 seconden later en hierdoor resultaat natuurlijk ook later, heb mijn automatiseringen hierop aangepast aangezien deze elke 15 min 10sec over lopen nu dus naar 20 moeten zetten anders werkte mijn automatisering niet meer.
Lijkt mij een bug.

Edit: heb het even bekeken maar het komt dat de scheduler nu voor elke taak een apart proces opstart en alles in moet laden. Geen idee of daarvoor nog iets te cachen valt om het te versnellen.

Ik snap niet helemaal wat je probeert te bereiken? Ik trigger mijn hoofd-automation op het input_number setpoint van DAO en de input_boolean die DAO schakelt voor NoM (en ook elk kwartier en op soc en een kill switch, maar die zijn secundair). Werkt prima, al is het wel een vrij complexe automation geworden.

[TheMystery]

balk schreef op zondag 13 september 2026 @ 08:26:
[...]

Ik snap niet helemaal wat je probeert te bereiken? Ik trigger mijn hoofd-automation op het input_number setpoint van DAO en de input_boolean die DAO schakelt voor NoM (en ook elk kwartier en op soc en een kill switch, maar die zijn secundair). Werkt prima, al is het wel een vrij complexe automation geworden.

Ik heb een alphaess en daarbij moet je een tijd ingeven hoe lang die een bepaalde actie moet duren. Aangezien ik niet weet hoe lang een actie gaat duren draait mijn automatisering elk kwartier en stelt een draaitijd van een kwartier in, dus kan niet zomaar op state change van input number from battery de automatisering draaien.

[Shaq_]

KC27 schreef op woensdag 14 mei 2025 @ 22:39:
@georgeboot @Bravo @arro3038 @simnet
[snip]

1. balance switch Ik voorzag dat er soms situaties zijn en zeker komen na afloop van de saldering dat je "nul op de meter" wil handhaven met je thuisbatterij. DAO zet deze (meestal een input_boolean) aan en ik heb een automation gemaakt die door deze switch wordt getriggerd en iedere seconde uit mijn p1-meter het netto vermogen binnen krijgt en op basis daarvan de ess feedin power bijstelt (soort mini pid-regeling).

[snip]

Ik wil ook graag de balance switch gebruiken om mijn omvormer in NOM modus te zetten. Ik krijg het echter niet voor elkaar om DAO de juiste helper in HA om te laten zetten.

Ik zie dat "balance switch" in de logging op tijden veranderen, dus dat zit goed:

Bijvoorbeeld

code:

2026-09-12 11:00:17 info: Doorzetten van alle settings naar HA
2026-09-12 11:00:17 info: Grid balanceren: off
2026-09-12 11:00:17 info: Grid set point: -1809.0 W

code:

2026-09-12 20:00:20 info: Doorzetten van alle settings naar HA
2026-09-12 20:00:20 info: Grid balanceren: on
2026-09-12 20:00:20 info: Grid set point: 0.0 W

De definitie van de balance switch op regel 6.

code:

  "battery": [
    {
      "name": "Dyness",
      "entity actual level": "sensor.growatt_sph_3_phase_battery_state_of_charge",
      "entity from battery": "input_number.dao_entity_from_battery",
      "entity balance switch": "input_boolean.dao_balance_switch",
      "entity set power feedin": "input_number.battery_entity_setpoint",
      "entity from pv": "input_number.dao_entity_from_pv",
      "entity from ac": "input_number.dao_entity_from_ac",
      "entity set operating mode on": "On",
      "entity set operating mode off": "Off",
      "entity set operating mode": "input_select.dao_entity_pv_aanuit",
      "capacity": 40.96,
      "upper limit": 100,
      "lower limit": 10,
      "optimal lower level": 10,
      "penalty low soc": 0.0025,
      "charge_stages": [ 
       {
         "power": 0.0,
         "efficiency": 1.0
       },
       {
         "power": 8000.0,
         "efficiency": 0.975
       }
     ], 
     "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 8000.0,
          "efficiency": 0.975
        }
      ],
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 2000.0,
      "dc_to_bat_efficiency": 0.975,
      "dc_to_bat_max_power": 7000.0,
      "bat_to_dc_efficiency": 0.975,
      "bat_to_dc_max_power": 8000.0,
      "cycle_cost": 0.03,
      "solar": []
    }
  ],

Maar in HA wordt de switch niet omgezet. Definitie entity in HA hieronder.

Wie weet wat er mogelijk fout gaat? De andere entiteiten worden nl. wel gezet.

[Dogooder]

@Shaq_ entity balance switch hoort onder grid te staan, niet onder battery.

[Aardedraadje]

Dogooder schreef op zondag 13 september 2026 @ 12:16:
@Shaq_ entity balance switch hoort onder grid te staan, niet onder battery.

In settings.md (die zou actueel moeten zijn) staat dit inderdaad zo aangegeven. @Shaq_ in docs.md staat de balance switch inderdaad onder Battery. Ik vermoed dat dit gedateerd is.

[Shaq_]

Aardedraadje schreef op zondag 13 september 2026 @ 13:19:
[...]

In settings.md (die zou actueel moeten zijn) staat dit inderdaad zo aangegeven. @Shaq_ in docs.md staat de balance switch inderdaad onder Battery. Ik vermoed dat dit gedateerd is.

Dank @Dogooder en @Aardedraadje - ik zie dat ik het niet op de goede plek gedefinieerd heb. Werkte inderdaad vanaf de (outdated?) docs.md. Op de wiki staat het idd onder grid. Ik ga ermee aan de slag - blij mee!

[DualDevil]

Ik wil hiermee aan de slag, tof project. Kan iemand mij vertellen of ik de scheduler ook kan gebruiken om teruglevering te plannen, en voor de periode waarin hij probeert naar baseload gaat niet de wattages uit Dao laat komen (dus niet scheduled) maar gewoon de batterijmodus omschakel naar Nom?

Als ik dat doe heb ik volgens mij beste van beiden: prijs-gebaseerd laden en ontladen als de verschillen flink zijn, en als belasting en laad/ontlaadverliezen te groot zijn om te handelen naar Nom maar dan direct, en niet via een Dao schatting.

Klopt mijn redenering überhaupt, hoe lossen jullie dit op?

[anboni]

DualDevil schreef op zondag 13 september 2026 @ 13:54:
Ik wil hiermee aan de slag, tof project. Kan iemand mij vertellen of ik de scheduler ook kan gebruiken om teruglevering te plannen, en voor de periode waarin hij probeert naar baseload gaat niet de wattages uit Dao laat komen (dus niet scheduled) maar gewoon de batterijmodus omschakel naar Nom?

Als ik dat doe heb ik volgens mij beste van beiden: prijs-gebaseerd laden en ontladen als de verschillen flink zijn, en als belasting en laad/ontlaadverliezen te groot zijn om te handelen naar Nom maar dan direct, en niet via een Dao schatting.

Klopt mijn redenering überhaupt, hoe lossen jullie dit op?

De drie posts boven de jouwe gaan precies over dat onderwerp, je zoekt de "entity balance switch" setting.

[Marcjeno1]

Een vraagje,

Ik gebruik al een tijd DAO en het werkt bijna perfect. Ik heb het op handelen staan. Ik merk dat de afgelopen dagen het ontladen steeds wordt uitgesteld omdat de volgende dag de prijzen dan beter zijn. Maar nu loop ik wel een ontlaad cycle mis. Als hij ontladen had en op goedkoopste tijden volgende dag had opgeladen had hij daar toch winst mee kunnen draaien.

Iemand hier iets op verzonnen?

[Wilin]

Marcjeno1 schreef op zondag 13 september 2026 @ 17:03:
...Maar nu loop ik wel een ontlaad cycle mis. ...

Blijkbaar heeft het algoritme met de waarden die je hebt ingegeven berekent dat wachten meer opbrengt dan een nieuwe cyclus. Wat kom je handmatig uit als je alles uitrekent voor toch een cyclus te doen? In rekening nemen je cyclus kost, import en export kost en efficientie?

[__fred__]

Wilin schreef op zondag 13 september 2026 @ 17:55:
[...]

Blijkbaar heeft het algoritme met de waarden die je hebt ingegeven berekent dat wachten meer opbrengt dan een nieuwe cyclus. Wat kom je handmatig uit als je alles uitrekent voor toch een cyclus te doen? In rekening nemen je cyclus kost, import en export kost en efficientie?

Dit inderdaad. De basisprijs was de afgelopen dagen vrij hoog (30ct) en de maximale delta 10ct ofzo. Bij 80% efficiency en 3ct aan afschrijving per kWh per cycle ga je het niet redden (30 / 0,8) + 3 = 40,5 cent.

Hij slaat bij mij ook vanavond over om morgenochtend tegen 50ct te dumpen.

[Marcjeno1]

Wilin schreef op zondag 13 september 2026 @ 17:55:
[...]

Blijkbaar heeft het algoritme met de waarden die je hebt ingegeven berekent dat wachten meer opbrengt dan een nieuwe cyclus. Wat kom je handmatig uit als je alles uitrekent voor toch een cyclus te doen? In rekening nemen je cyclus kost, import en export kost en efficientie?

Gisteren was de prijs 13ct. Hij zou toen eerst diezelfde avond nog ontladen. Toen kwamen de prijzen van vandaag en was het ontladen uitgesteld tot vanavond. Toen kwamen de prijzen van morgen en is het wederom uitgesteld.

Nu mis je toch gewoon een hele cycle? Hij had vandaag dan voor 30 cent kunnen laden en die morgen kwijt.

[thomvh]

Marcjeno1 schreef op zondag 13 september 2026 @ 18:33:
[...]

Gisteren was de prijs 13ct. Hij zou toen eerst diezelfde avond nog ontladen. Toen kwamen de prijzen van vandaag en was het ontladen uitgesteld tot vanavond. Toen kwamen de prijzen van morgen en is het wederom uitgesteld.

Nu mis je toch gewoon een hele cycle? Hij had vandaag dan voor 30 cent kunnen laden en die morgen kwijt.

50-30 is een 20 cent delta. Die is voorzover ik het begrijp niet groot genoeg met je verlies etc.

[Torch1969]

Marcjeno1 schreef op zondag 13 september 2026 @ 18:33:
[...]

Gisteren was de prijs 13ct. Hij zou toen eerst diezelfde avond nog ontladen. Toen kwamen de prijzen van vandaag en was het ontladen uitgesteld tot vanavond. Toen kwamen de prijzen van morgen en is het wederom uitgesteld.

Nu mis je toch gewoon een hele cycle? Hij had vandaag dan voor 30 cent kunnen laden en die morgen kwijt.

Als hadden komt, is hebben te laat. Terugkijkend zijn beslissing vaak heel logisch, maar op dat moment niet. DAO kijkt steeds op een moment alleen naar de toekomst (voor zover de prijzen bekend zijn) en berekend dan opnieuw de meest optimale verdeling. Daarbij wordt de vulling van de batterij gewaardeerd op een gemiddelde toekomstige prijs (bron), dus niet op de prijs waarvoor die geladen is. Als je dat begrijpt, dan is de gekozen strategie steeds logisch, maar achteraf bekeken misschien niet optimaal.

[Deikke]

Ik zat al een hele tijd raar te kijken waarom de hele tijd negatieve baseloads berekend worden. Hele database nagespit op rare waarden in de sensors. Maar wat nu blijkt worden DC PV productie niet meegerekend in de baseloads. Deze sensor toevoegen aan de AC PV productie lostte direct het probleem op.

[ Voor 3% gewijzigd door Deikke op 14-09-2026 12:23 ]

[dannyll]

Torch1969 schreef op zondag 13 september 2026 @ 19:59:
[...]

Als hadden komt, is hebben te laat. Terugkijkend zijn beslissing vaak heel logisch, maar op dat moment niet. DAO kijkt steeds op een moment alleen naar de toekomst (voor zover de prijzen bekend zijn) en berekend dan opnieuw de meest optimale verdeling. Daarbij wordt de vulling van de batterij gewaardeerd op een gemiddelde toekomstige prijs (bron), dus niet op de prijs waarvoor die geladen is. Als je dat begrijpt, dan is de gekozen strategie steeds logisch, maar achteraf bekeken misschien niet optimaal.

Ja, precies. Zat er eerst ook raar naar te kijken maar het is een beslissing van DAO die klopt als je naar de toekomst kijkt. Ik ben blij met het systeem...
ik worstel alleen nog met mijn Warmtepomp. Ik heb hem wel in de rapportage opgenomen, maar kan hem niet automatische laten aansturen. Dat gaat straks als het kouder wordt natuurlijk nog meer invloed hebben op mijn dagelijks verbruik.

[KVan]

TheMystery schreef op zaterdag 12 september 2026 @ 23:25:
[...]


Doe kende ik nog niet, heb hem eens in mijn config gezet, maar zie dat ie bij 1 berekening 2x getriggerd wordt, is dat normaal?

[Afbeelding]

Beetje late reactie nadat nog anderen ditzelfde melden, maar bij mij staat hij ook telkens 2 keer in de lijst heel reproduceerbaar 4 en 10 seconden na het triggeren van de optimalisatie berekening.

Bijzonder is dat ophalen van meteodata dit gedrag niet vertoont maar calc baseloads en train ml predictions wel, train ml predictions zelfs 3 keer.

Dit verklaart mogelijk waarom heel af en toe de settings in de Deye omvormer niet goed staan. De Deye kan niet de hele reeks settings in 1 keer verwerken (bus is te traag) en daar heb ik dus een 5 sec delay voor ingebouwd. De timing van de events lijkt af en toe ongelukkig te vallen waardoor 1 van de settings niet door de Deye overgenomen wordt.

Ik heb inmiddels de automatisering change mode op restart gezet en een 10 seconden delay als eerste actie gezet. Op deze manier draait hij effectief maar 1 keer. Dat de automatisering ook getriggert wordt door de andere acties is niet zo een issue omdat die meer dan genoeg gespatieerd zijn met de optimalisatie berekening.

[ Voor 12% gewijzigd door KVan op 14-09-2026 16:28 ]

[TheMystery]

KVan schreef op maandag 14 september 2026 @ 15:41:
[...]

Beetje late reactie nadat nog anderen ditzelfde melden, maar bij mij staat hij ook telkens 2 keer in de lijst heel reproduceerbaar 4 en 10 seconden na het triggeren van de optimalisatie berekening.

Bijzonder is dat ophalen van meteodata dit gedrag niet vertoont maar calc baseloads en train ml predictions wel, train ml predictions zelfs 3 keer.

Dit verklaart mogelijk waarom heel af en toe de settings in de Deye omvormer niet goed staan. De Deye kan niet de hele reeks settings in 1 keer verwerken (bus is te traag) en daar heb ik dus een 5 sec delay voor ingebouwd. De timing van de events lijkt af en toe ongelukkig te vallen waardoor 1 van de settings niet door de Deye overgenomen wordt.

Ik heb inmiddels de automatisering change mode op restart gezet en een 10 seconden delay als eerste actie gezet. Op deze manier draait hij effectief maar 1 keer. Dat de automatisering ook getriggert wordt door de andere acties is niet zo een issue omdat die meer dan genoeg gespatieerd zijn met de optimalisatie berekening.

Ik snap alleen bij mijn installatie niet waarom er ook elke 10 min nog een verandering komt terwijl dat bij mij ouders en bij jou ook niet is. Er staat op dat tijdstip ook helemaal niets in de logging dat dao wat aan het doen is. Ik hou het denk ik maar op mijn vaste trigger elke 15min en 25sec in mijn automatisering

[balk]

TheMystery schreef op zondag 13 september 2026 @ 08:32:
[...]


Ik heb een alphaess en daarbij moet je een tijd ingeven hoe lang die een bepaalde actie moet duren. Aangezien ik niet weet hoe lang een actie gaat duren draait mijn automatisering elk kwartier en stelt een draaitijd van een kwartier in, dus kan niet zomaar op state change van input number from battery de automatisering draaien.

Zoek eens in dit topic. Je bent vast niet de enige met een Aphaess

[TheMystery]

balk schreef op maandag 14 september 2026 @ 21:09:
[...]

Zoek eens in dit topic. Je bent vast niet de enige met een Aphaess

Volgens mij ben ik de enige die automations van een alpha gepost heeft en een aantal anderen gebruiken deze ook.

[nklsn]

Ik heb DAO al een tijdje op de achtergrond draaien, vooral om te leren hoe het werkt. Vanaf januari stap ik over naar een dynamisch contract en wil ik DAO dan actief in gebruik gaan nemen.

Ik heb tot nu toe alleen een PV-opstelling en een EV geconfigureerd en probeer vooral te ontdekken welke instelling welk effect heeft. Nu loop ik echter tegen iets aan waarbij ik twijfel of ik het goed geconfigureerd heb, of dat mijn interpretatie van wat het doet niet klopt (ik denk het laatste).

Het gaat mij om de "entity grid setpoint" en "entity balance switch".

code:

"grid": {
    "max_power": 17,
    "entity grid setpoint": "input_number.dao_grid_setpoint",
    "entity balance switch": "input_boolean.dao_grid_balance"
  },

Zoals ik het begrijp, wordt de "entity grid setpoint" gezet op het verwachte gemidddelde vermogen voor het komende kwartier dat wordt geïmporteerd (+) of geëxporteerd (-). Dit lijkt goed overeen te komen met mijn andere meters, want nu er wat zon is, zie ik hier -1255W staan.

De "entity balance switch" vind ik onduidelijker en heb daar twee vragen over:

• Klopt mijn interpretatie dat deze op OFF komt te staan wanneer DAO besluit om actief stroom ergens naartoe te sturen, bijvoorbeeld om mijn EV te laden, en op ON komt te staan wanneer hij eigenlijk niets actiefs te doen heeft? Om aan te geven dat je dan een nul-op-de-meter-automatisering zou kunnen starten?
• Bij mij blijft de instelling echter altijd op OFF staan, terwijl ik bij -1255W zou verwachten dat hij op ON zou springen, zodat ik de 'solar'-modus van mijn laadpaal zou kunnen starten. Hoe kan dat?

Daarnaast heb ik het probleem dat mijn input_boolean.dao_grid_balance op unmanaged komt te staan bij Devices/Helpers zodra DAO een run gedaan heeft. Zou het ook kunnen zijn dat er een configuratie fout in zit?

[Wilin]

nklsn schreef op dinsdag 15 september 2026 @ 13:33:
Klopt mijn interpretatie dat deze op OFF komt te staan wanneer DAO besluit om actief stroom ergens naartoe te sturen, bijvoorbeeld om mijn EV te laden, en op ON komt te staan wanneer hij eigenlijk niets actiefs te doen heeft? Om aan te geven dat je dan een nul-op-de-meter-automatisering zou kunnen starten?

Nee dit klop niet. "entity_balance_switch" dient om aan te geven of het algoritme verwacht dat alles Nul op de meter draait (dus proberen geen import/export), dit is dus vooral een signaal voor je batterijen. Als "entity_balance_switch" aan staat, zou in principe "entity grid setpoint" 0 moeten zijn.

[Torch1969]

nklsn schreef op dinsdag 15 september 2026 @ 13:33:
Ik heb DAO al een tijdje op de achtergrond draaien, vooral om te leren hoe het werkt. Vanaf januari stap ik over naar een dynamisch contract en wil ik DAO dan actief in gebruik gaan nemen.

Ik heb tot nu toe alleen een PV-opstelling en een EV geconfigureerd en probeer vooral te ontdekken welke instelling welk effect heeft. Nu loop ik echter tegen iets aan waarbij ik twijfel of ik het goed geconfigureerd heb, of dat mijn interpretatie van wat het doet niet klopt (ik denk het laatste).

Het gaat mij om de "entity grid setpoint" en "entity balance switch".

code:

"grid": {
    "max_power": 17,
    "entity grid setpoint": "input_number.dao_grid_setpoint",
    "entity balance switch": "input_boolean.dao_grid_balance"
  },

Zoals ik het begrijp, wordt de "entity grid setpoint" gezet op het verwachte gemidddelde vermogen voor het komende kwartier dat wordt geïmporteerd (+) of geëxporteerd (-). Dit lijkt goed overeen te komen met mijn andere meters, want nu er wat zon is, zie ik hier -1255W staan.

De "entity balance switch" vind ik onduidelijker en heb daar twee vragen over:

• Klopt mijn interpretatie dat deze op OFF komt te staan wanneer DAO besluit om actief stroom ergens naartoe te sturen, bijvoorbeeld om mijn EV te laden, en op ON komt te staan wanneer hij eigenlijk niets actiefs te doen heeft? Om aan te geven dat je dan een nul-op-de-meter-automatisering zou kunnen starten?
• Bij mij blijft de instelling echter altijd op OFF staan, terwijl ik bij -1255W zou verwachten dat hij op ON zou springen, zodat ik de 'solar'-modus van mijn laadpaal zou kunnen starten. Hoe kan dat?

Daarnaast heb ik het probleem dat mijn input_boolean.dao_grid_balance op unmanaged komt te staan bij Devices/Helpers zodra DAO een run gedaan heeft. Zou het ook kunnen zijn dat er een configuratie fout in zit?

Met de balance switch geeft DAO de opdracht om dmv je eigen sturing op “nul op de meter” te gaan sturen (dit kan een modus van je batterij zijn, of een eigen automatisering). Dit komt weinig voor als je strategie minimaliseren van kosten is. Is je strategie minimaliseren van teruglevering, dan zal het vaker voorkomen. Ook als salderen stopt zal de strategie minimaliseren kosten vaker op balanceren uitkomen (je kunt je batterij stroom dan in veel gevallen beter gebruiken voor eigen verbruik, dan voor teruglevering).

Bij mij is de helper in HA ook steeds unmanaged, geen idee waarom, maar hij werkt wel gewoon, dus ik ben er verder niet in gedoken.

[dotcom87]

Is er iemand die een Vaillant warmtepomp met ebusd gekoppeld heeft aan DAO?
Ik ben wat zoekende welke entities van de vaillant warmtepomp nodig zijn voor DAO om zijn werk te kunnen doen.

[ErnstH]

Wilin schreef op dinsdag 15 september 2026 @ 18:29:
[...]

Nee dit klop niet. "entity_balance_switch" dient om aan te geven of het algoritme verwacht dat alles Nul op de meter draait (dus proberen geen import/export), dit is dus vooral een signaal voor je batterijen. Als "entity_balance_switch" aan staat, zou in principe "entity grid setpoint" 0 moeten zijn.

Bij NoM staat het setpoint op wat DAO verwacht te laden of ontladen.

[hemertje]

ik zie soms in DOA alleen de grafiek van de meteo data ipv de accuberekening?
nu ook weer

✅ Opdracht 'Optimaliseringsberekening zonder debug' succesvol afgerond

code:

2026-09-15 22:08:07 INFO: Loaded 6 secrets from ../data/secrets.json
2026-09-15 22:08:07 INFO: Validating configuration with ConfigurationV2
2026-09-15 22:08:08 info: Day Ahead Optimalisering versie: 2026.9.1
2026-09-15 22:08:08 info: Day Ahead Optimalisering gestart op: 15-09-2026 22:08:08
2026-09-15 22:08:08 info: Day Ahead Optimalisatie gestart: 15-09-2026 22:08:08 taak: calc_optimum
2026-09-15 22:08:08 info: Debug = False
2026-09-15 22:08:08 info: Zelf berekende baseload
2026-09-15 22:08:09 info: ML prediction SolarEdge_8kW
                   date_time  prediction
0  2026-09-15 22:00:00+02:00       0.003
1  2026-09-15 23:00:00+02:00       0.003
2  2026-09-16 00:00:00+02:00       0.010
3  2026-09-16 01:00:00+02:00       0.010
4  2026-09-16 02:00:00+02:00       0.002
5  2026-09-16 03:00:00+02:00       0.002
6  2026-09-16 04:00:00+02:00       0.002
7  2026-09-16 05:00:00+02:00       0.002
8  2026-09-16 06:00:00+02:00       0.000
9  2026-09-16 07:00:00+02:00       0.011
10 2026-09-16 08:00:00+02:00       0.599
11 2026-09-16 09:00:00+02:00       1.886
12 2026-09-16 10:00:00+02:00       3.827
13 2026-09-16 11:00:00+02:00       4.312
14 2026-09-16 12:00:00+02:00       2.171
15 2026-09-16 13:00:00+02:00       1.542
16 2026-09-16 14:00:00+02:00       1.795
17 2026-09-16 15:00:00+02:00       2.760
18 2026-09-16 16:00:00+02:00       4.253
19 2026-09-16 17:00:00+02:00       2.131
20 2026-09-16 18:00:00+02:00       1.264
21 2026-09-16 19:00:00+02:00       0.064
22 2026-09-16 20:00:00+02:00       0.006
23 2026-09-16 21:00:00+02:00       0.005
24 2026-09-16 22:00:00+02:00       0.005
25 2026-09-16 23:00:00+02:00       0.004
2026-09-15 22:08:11 info: No reduced hours applied for Zendure 3x SolarFlow 2400 AC+
2026-09-15 22:08:11 info: No reduced power applied during discharging at low soc
2026-09-15 22:08:11 info: No reduced power applied during charging at high soc
2026-09-15 22:08:11 info: Startwaarde SoC Zendure 3x SolarFlow 2400 AC+: 67.0%

2026-09-15 22:08:11 info: Boiler direct opwarmen staat uit
2026-09-15 22:08:11 info: Boiler setpoint 52.0 °C
2026-09-15 22:08:11 info: Boiler hysterese 12.0 K
2026-09-15 22:08:11 info: Boiler cooling rate 0.3 K/uur
2026-09-15 22:08:11 info: Boiler heating allowed below 47.0 °C
2026-09-15 22:08:11 info: Boiler opwarmen wordt ingepland tussen: 2026-09-16 04:30 en 2026-09-16 23:00
2026-09-15 22:08:11 info: Boiler verbruik in 1 kwartier: 0.75 kWh
2026-09-15 22:08:11 info: Prognose boiler:
                   tijd  act_temp  heat  elec  interval  cost  end_temp  end_value  netto_cost
0   2026-09-15 22:00:00    49.000 1.201 0.875         2 0.337    44.350     -0.429       0.766
1   2026-09-15 22:15:00    48.925 1.231 0.894         2 0.339    44.425     -0.422       0.761
2   2026-09-15 22:30:00    48.850 1.261 0.913         2 0.341    44.500     -0.415       0.756
3   2026-09-15 22:45:00    48.775 1.291 0.933         2 0.339    44.575     -0.408       0.747
4   2026-09-15 23:00:00    48.700 1.321 0.952         2 0.351    44.650     -0.401       0.752
5   2026-09-15 23:15:00    48.625 1.351 0.972         2 0.350    44.725     -0.394       0.744
6   2026-09-15 23:30:00    48.550 1.381 0.991         2 0.348    44.800     -0.387       0.735
7   2026-09-15 23:45:00    48.475 1.411 1.010         2 0.350    44.875     -0.381       0.730
8   2026-09-16 00:00:00    48.400 1.441 1.030         2 0.366    44.950     -0.374       0.739
9   2026-09-16 00:15:00    48.325 1.471 1.049         2 0.368    45.025     -0.367       0.735
10  2026-09-16 00:30:00    48.250 1.501 1.068         2 0.369    45.100     -0.360       0.729
11  2026-09-16 00:45:00    48.175 1.531 1.088         2 0.374    45.175     -0.353       0.727
12  2026-09-16 01:00:00    48.100 1.561 1.107         2 0.381    45.250     -0.346       0.727
13  2026-09-16 01:15:00    48.025 1.591 1.127         2 0.386    45.325     -0.339       0.725
14  2026-09-16 01:30:00    47.950 1.621 1.146         2 0.392    45.400     -0.332       0.724
15  2026-09-16 01:45:00    47.875 1.651 1.165         2 0.397    45.475     -0.325       0.722
16  2026-09-16 02:00:00    47.800 1.681 1.185         2 0.401    45.550     -0.318       0.719
17  2026-09-16 02:15:00    47.725 1.711 1.204         2 0.409    45.625     -0.311       0.720
18  2026-09-16 02:30:00    47.650 1.741 1.223         2 0.418    45.700     -0.304       0.722
19  2026-09-16 02:45:00    47.575 1.771 1.243         2 0.424    45.775     -0.297       0.721
20  2026-09-16 03:00:00    47.500 1.801 1.262         2 0.430    45.850     -0.291       0.720
21  2026-09-16 03:15:00    47.425 1.831 1.281         2 0.434    45.925     -0.284       0.718
22  2026-09-16 03:30:00    47.350 1.861 1.301         2 0.441    46.000     -0.277       0.717
23  2026-09-16 03:45:00    47.275 1.891 1.320         2 0.450    46.075     -0.270       0.719
24  2026-09-16 04:00:00    47.200 1.921 1.340         2 0.455    46.150     -0.263       0.718
25  2026-09-16 04:15:00    47.125 1.951 1.359         2 0.461    46.225     -0.256       0.717
26  2026-09-16 04:30:00    47.050 1.981 1.378         2 0.470    46.300     -0.249       0.720
27  2026-09-16 04:45:00    46.975 2.011 1.398         2 0.476    46.375     -0.242       0.718
28  2026-09-16 05:00:00    46.900 2.041 1.417         2 0.488    46.450     -0.235       0.723
29  2026-09-16 05:15:00    46.825 2.071 1.436         2 0.512    46.525     -0.228       0.740
30  2026-09-16 05:30:00    46.750 2.101 1.456         2 0.558    46.600     -0.221       0.780
31  2026-09-16 05:45:00    46.675 2.131 1.475         2 0.572    46.675     -0.214       0.786
32  2026-09-16 06:00:00    46.600 2.161 1.495         2 0.571    46.750     -0.208       0.779
33  2026-09-16 06:15:00    46.525 2.192 1.514         3 0.612    46.900     -0.194       0.805
34  2026-09-16 06:30:00    46.450 2.222 1.533         3 0.642    46.975     -0.187       0.828
35  2026-09-16 06:45:00    46.375 2.252 1.553         3 0.659    47.050     -0.180       0.838
36  2026-09-16 07:00:00    46.300 2.282 1.572         3 0.665    47.125     -0.173       0.838
37  2026-09-16 07:15:00    46.225 2.312 1.591         3 0.670    47.200     -0.166       0.836
38  2026-09-16 07:30:00    46.150 2.342 1.611         3 0.676    47.275     -0.159       0.835
39  2026-09-16 07:45:00    46.075 2.372 1.630         3 0.693    47.350     -0.152       0.845
40  2026-09-16 08:00:00    46.000 2.402 1.649         3 0.704    47.425     -0.145       0.849
41  2026-09-16 08:15:00    45.925 2.432 1.669         3 0.684    47.500     -0.138       0.822
42  2026-09-16 08:30:00    45.850 2.462 1.688         3 0.656    47.575     -0.131       0.787
43  2026-09-16 08:45:00    45.775 2.492 1.708         3 0.656    47.650     -0.125       0.780
44  2026-09-16 09:00:00    45.700 2.522 1.727         3 0.665    47.725     -0.118       0.782
45  2026-09-16 09:15:00    45.625 2.552 1.746         3 0.635    47.800     -0.111       0.745
46  2026-09-16 09:30:00    45.550 2.582 1.766         3 0.627    47.875     -0.104       0.730
47  2026-09-16 09:45:00    45.475 2.612 1.785         3 0.645    47.950     -0.097       0.742
48  2026-09-16 10:00:00    45.400 2.642 1.804         3 0.657    48.025     -0.090       0.747
49  2026-09-16 10:15:00    45.325 2.672 1.824         3 0.644    48.100     -0.083       0.727
50  2026-09-16 10:30:00    45.250 2.702 1.843         3 0.630    48.175     -0.076       0.706
51  2026-09-16 10:45:00    45.175 2.732 1.863         3 0.617    48.250     -0.069       0.687
52  2026-09-16 11:00:00    45.100 2.762 1.882         3 0.603    48.325     -0.062       0.666
53  2026-09-16 11:15:00    45.025 2.792 1.901         3 0.588    48.400     -0.055       0.643
54  2026-09-16 11:30:00    44.950 2.822 1.921         3 0.577    48.475     -0.048       0.626
55  2026-09-16 11:45:00    44.875 2.852 1.940         3 0.569    48.550     -0.042       0.610
56  2026-09-16 12:00:00    44.800 2.882 1.959         3 0.556    48.625     -0.035       0.591
57  2026-09-16 12:15:00    44.725 2.912 1.979         3 0.535    48.700     -0.028       0.562
58  2026-09-16 12:30:00    44.650 2.942 1.998         3 0.530    48.775     -0.021       0.550
59  2026-09-16 12:45:00    44.575 2.972 2.017         3 0.523    48.850     -0.014       0.537
60  2026-09-16 13:00:00    44.500 3.002 2.037         3 0.523    48.925     -0.007       0.530
61  2026-09-16 13:15:00    44.425 3.032 2.056         3 0.515    49.000      0.000       0.515
62  2026-09-16 13:30:00    44.350 3.062 2.076         3 0.520    49.075      0.007       0.513
63  2026-09-16 13:45:00    44.275 3.092 2.095         3 0.531    49.150      0.014       0.517
64  2026-09-16 14:00:00    44.200 3.122 2.114         3 0.547    49.225      0.021       0.527
65  2026-09-16 14:15:00    44.125 3.152 2.134         3 0.557    49.300      0.028       0.529
66  2026-09-16 14:30:00    44.050 3.182 2.153         3 0.566    49.375      0.035       0.531
67  2026-09-16 14:45:00    43.975 3.212 2.172         3 0.581    49.450      0.042       0.539
68  2026-09-16 15:00:00    43.900 3.242 2.192         3 0.605    49.525      0.048       0.557
69  2026-09-16 15:15:00    43.825 3.272 2.211         3 0.631    49.600      0.055       0.576
70  2026-09-16 15:30:00    43.750 3.302 2.231         3 0.649    49.675      0.062       0.586
71  2026-09-16 15:45:00    43.675 3.332 2.250         3 0.665    49.750      0.069       0.596
72  2026-09-16 16:00:00    43.600 3.362 2.269         4 0.701    49.900      0.083       0.618
73  2026-09-16 16:15:00    43.525 3.392 2.289         4 0.759    49.975      0.090       0.669
74  2026-09-16 16:30:00    43.450 3.422 2.308         4 0.803    50.050      0.097       0.706
75  2026-09-16 16:45:00    43.375 3.452 2.327         4 0.844    50.125      0.104       0.740
76  2026-09-16 17:00:00    43.300 3.482 2.347         4 0.871    50.200      0.111       0.760
77  2026-09-16 17:15:00    43.225 3.512 2.366         4 0.914    50.275      0.118       0.797
78  2026-09-16 17:30:00    43.150 3.542 2.385         4 0.931    50.350      0.125       0.807
79  2026-09-16 17:45:00    43.075 3.572 2.405         4 0.957    50.425      0.131       0.825
80  2026-09-16 18:00:00    43.000 3.603 2.424         4 0.984    50.500      0.138       0.846
81  2026-09-16 18:15:00    42.925 3.633 2.444         4 1.041    50.575      0.145       0.895
82  2026-09-16 18:30:00    42.850 3.663 2.463         4 1.067    50.650      0.152       0.914
83  2026-09-16 18:45:00    42.775 3.693 2.482         4 1.091    50.725      0.159       0.932
84  2026-09-16 19:00:00    42.700 3.723 2.502         4 1.102    50.800      0.166       0.936
85  2026-09-16 19:15:00    42.625 3.753 2.521         4 1.137    50.875      0.173       0.964
86  2026-09-16 19:30:00    42.550 3.783 2.540         4 1.155    50.950      0.180       0.975
87  2026-09-16 19:45:00    42.475 3.813 2.560         4 1.148    51.025      0.187       0.961
88  2026-09-16 20:00:00    42.400 3.843 2.579         4 1.127    51.100      0.194       0.934
89  2026-09-16 20:15:00    42.325 3.873 2.599         4 1.110    51.175      0.201       0.909
90  2026-09-16 20:30:00    42.250 3.903 2.618         4 1.104    51.250      0.208       0.896
91  2026-09-16 20:45:00    42.175 3.933 2.637         4 1.095    51.325      0.214       0.881
92  2026-09-16 21:00:00    42.100 3.963 2.657         4 1.077    51.400      0.221       0.856
93  2026-09-16 21:15:00    42.025 3.993 2.676         4 1.059    51.475      0.228       0.831
94  2026-09-16 21:30:00    41.950 4.023 2.695         4 1.047    51.550      0.235       0.812
95  2026-09-16 21:45:00    41.875 4.053 2.715         4 1.041    51.625      0.242       0.799
96  2026-09-16 22:00:00    41.800 4.083 2.734         4 1.043    51.700      0.249       0.794
97  2026-09-16 22:15:00    41.725 4.113 2.753         4 1.033    51.775      0.256       0.777
98  2026-09-16 22:30:00    41.650 4.143 2.773         4 1.032    51.850      0.263       0.769
99  2026-09-16 22:45:00    41.575 4.173 2.792         4 1.029    51.925      0.270       0.759
100 2026-09-16 23:00:00    41.500 4.203 2.812         4 1.018    52.000      0.277       0.741
101 2026-09-16 23:15:00    41.425 0.000 0.000         0 0.000     0.000      0.000       0.000
102 2026-09-16 23:30:00    41.350 0.000 0.000         0 0.000     0.000      0.000       0.000
103 2026-09-16 23:45:00    41.275 0.000 0.000         0 0.000     0.000      0.000       0.000

2026-09-15 22:08:11 info: Warmtepomp staat uit - warmtepomp wordt niet ingepland
2026-09-15 22:08:11 info: Strategie: minimale kosten
2026-09-15 22:08:11 info: Maximale fout (maximal gap): 0.005000 euro
2026-09-15 22:08:11 info: Rekentijd: 0.03  sec
2026-09-15 22:08:11 waarschuwing: Geen oplossing voor: minimize cost

[thomvh]

hemertje schreef op dinsdag 15 september 2026 @ 22:09:
ik zie soms in DOA alleen de grafiek van de meteo data ipv de accuberekening?
nu ook weer

✅ Opdracht 'Optimaliseringsberekening zonder debug' succesvol afgerond


[...]

Dan is je meteo data net ingeladen.

[hemertje]

thomvh schreef op dinsdag 15 september 2026 @ 22:11:
[...]

Dan is je meteo data net ingeladen.

Opgehaalde meteodata vanaf 15-09-2026 17:00

is wat ik zie met daaronder de J/cm2 grafiek

[ Voor 11% gewijzigd door hemertje op 15-09-2026 22:18 ]

[hemertje]

Goedemorgen,

nav onderstaande berekening

2026-09-15 22:08:11 info: Warmtepomp staat uit - warmtepomp wordt niet ingepland
2026-09-15 22:08:11 info: Strategie: minimale kosten
2026-09-15 22:08:11 info: Maximale fout (maximal gap): 0.005000 euro
2026-09-15 22:08:11 info: Rekentijd: 0.03 sec
2026-09-15 22:08:11 waarschuwing: Geen oplossing voor: minimize cost

Omdat er geen oplossing is wordt het beoogd verbruikt met de oplossing niet getoond?

Is het niet logischer om de beoorde verbruik (hoogste grafiek) en de andere normale grafieken te tonen met in de grafiek een melding 'Geen oplossing voor: minimize cost'

Dan weet je als gebruiker wat er aan de hand is ipv de meteo grafiek te tonen.

[nklsn]

Bedankt @Torch1969 en @Wilin

Ik heb een batterijsimulatie toegevoegd en dat maakt het met de strategy minimize consumption inderdaad een stuk duidelijker. Ik zie nu inderdaad dat als DAO besluit om de plus en min met de batterij af te dekken, hij de switch op ON zet, zodat ik bijvoorbeeld de batterij zo zou kunnen instellen dat ik nul-op-de-meter behaal.

Zonder batterij lijkt die functie dus niet of weinig te doen. Wel jammer, want mijn laadpaal heeft een vergelijkbare mogelijkheid en kan puur op overschot laden (minimaal 6A). Ik zou het wel fijn vinden als hij mijn auto ook zou laden met overschot, mits toereikend.

[dingo35]

Tvdl2000 schreef op zondag 23 augustus 2026 @ 21:07:
ben begonnen hoor. maar vrij snel kom ik al in de fout, terwijl ik nog maar weinig heb gedaan. ik voel me echt erg noob nu.


[...]


en dit is wat ik heb in de config


[...]


Qua devices e.d.
zonneplan, kwartierprijzen,
hanchu ESS thuis accu 21.4KWH op een hybride omvormer (ook Hanchu ESS) waar geen panelen aan zitten en 20 van de 24 zonnepanelen meet
Hoymiles DTU met 24 panelen
Polestar 2 Long range Dual motor
geen warmtepomp
shelly thermostaat en regeling van de CV
paar airco's die ook kunnen verwarmen

Volgens mij moet in je config de cost_supplier_production negatief zijn, "2026-01-01": -0.01652893", immers zonneplan geeft je de inkoopvergoeding terug.
En volgens mij moet je VAT production dus ook 21% zijn, zoals verderop in de thread ook al besproken is...
En de zonnebonus kun je emuleren door de multiplier op production op 1.1 te zetten.

EDIT: en je mist ook nog "interval": "15min" ....

[ Voor 7% gewijzigd door dingo35 op 16-09-2026 13:24 ]

[Torch1969]

dingo35 schreef op woensdag 16 september 2026 @ 12:58:
[...]

Volgens mij moet in je config de cost_supplier_production negatief zijn, "2026-01-01": -0.01652893", immers zonneplan geeft je de inkoopvergoeding terug.
En volgens mij moet je VAT production dus ook 21% zijn, zoals verderop in de thread ook al besproken is...
En de zonnebonus kun je emuleren door de multiplier op production op 1.1 te zetten.

EDIT: en je mist ook nog "interval": "15min" ....

Ik heb zonneplan en de cost supplier gewoon op positief bedrag staan. Bij productie zijn positieve bedragen teruggave en negatieve bedragen een aftrek op teruggave. Misschien kunnen mensen met terugleverkosten hun instelling delen?