• KVan
  • Registratie: April 2015
  • Laatst online: 19:06
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
  • Registratie: Januari 2020
  • Laatst online: 28-09 14:08
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
  • Registratie: November 2001
  • Laatst online: 19:05

Beekforel

Is eigenlijk geen vis

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

  • dannyll
  • Registratie: September 2025
  • Laatst online: 21:53
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

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner


  • KVan
  • Registratie: April 2015
  • Laatst online: 19:06
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
  • Registratie: Januari 2020
  • Laatst online: 28-09 14:08
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
  • Registratie: Mei 2021
  • Laatst online: 10-09 19:56
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
  • Registratie: April 2004
  • Laatst online: 23:54

Dogooder

dus...

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
  • Registratie: Mei 2021
  • Laatst online: 10-09 19:56
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
  • Registratie: Mei 2021
  • Laatst online: 10-09 19:56
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
  • Registratie: Juli 2023
  • Laatst online: 28-09 13:00
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?
@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

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


  • mgroen81
  • Registratie: September 2010
  • Laatst online: 27-09 12:59
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.

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


  • simnet
  • Registratie: Januari 2020
  • Laatst online: 28-09 14:08
Ter info: https://epexpredictor.batzill.com/docs
Wellicht een goede toevoeging als prijs provider.

  • Wilin
  • Registratie: December 2012
  • Laatst online: 27-09 13:04
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
  • Registratie: Juni 2013
  • Laatst online: 22:20
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
  • Registratie: December 2012
  • Laatst online: 27-09 13:04

  • KVan
  • Registratie: April 2015
  • Laatst online: 19:06
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
  • Registratie: Januari 2011
  • Laatst online: 20:22
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
  • Registratie: December 2012
  • Laatst online: 27-09 13:04
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
   "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
  • Registratie: Juli 2008
  • Laatst online: 28-09 15:00
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
  • Registratie: Mei 2013
  • Laatst online: 22:24

Aardedraadje

Met kabelschoen

Vraagje als dat mag :D

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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
"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
  • Registratie: April 2004
  • Laatst online: 23:54

Dogooder

dus...

@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
  • Registratie: Mei 2013
  • Laatst online: 22:24

Aardedraadje

Met kabelschoen

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:
Afbeeldingslocatie: https://tweakers.net/i/5P2tLfhACwEcXPo-xLIfd1egtqI=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/ZxbpHlnlYnrG0URWjNdMkSVt.png?f=user_large
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
  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
  • Registratie: Mei 2005
  • Laatst online: 20:57
@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:
1
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
  • Registratie: Februari 2004
  • Laatst online: 20:07
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
  • Registratie: April 2015
  • Laatst online: 19:06
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
  • Registratie: Februari 2004
  • Laatst online: 20:07
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?

Afbeeldingslocatie: https://tweakers.net/i/Z8LSn4sZnddqhDJAQ09lTVVhxmk=/800x/filters:strip_icc():strip_exif()/f/image/QcZ99ViiTns9fJHEZGCAWxmD.jpg?f=fotoalbum_large

  • anboni
  • Registratie: Maart 2004
  • Laatst online: 00:03
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
  • Registratie: Februari 2004
  • Laatst online: 20:07
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
Afbeeldingslocatie: https://tweakers.net/i/ExgvQt5xdaAs7qAueMx6cTB3dIc=/x800/filters:strip_icc():strip_exif()/f/image/IXnM2buW7vdOhObVVFWjvavB.jpg?f=fotoalbum_large

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
  • Registratie: Januari 2000
  • Laatst online: 21:08
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
  • Registratie: Februari 2004
  • Laatst online: 20:07
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_
  • Registratie: November 2006
  • Laatst online: 24-09 13:32
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:
1
2
3
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:
1
2
3
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
  "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.

Afbeeldingslocatie: https://tweakers.net/i/QdqMs617UTDLdB-QVAJpf7I4POE=/x800/filters:strip_exif()/f/image/rDC40ihbyMH9i5oXUb2h4Ka8.png?f=fotoalbum_large

  • Dogooder
  • Registratie: April 2004
  • Laatst online: 23:54

Dogooder

dus...

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

  • Aardedraadje
  • Registratie: Mei 2013
  • Laatst online: 22:24

Aardedraadje

Met kabelschoen

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_
  • Registratie: November 2006
  • Laatst online: 24-09 13:32
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
  • Registratie: September 2005
  • Laatst online: 21:42

DualDevil

Venice 3000+ @ 9x324=2916Mhz

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?

| AMD S939 3000+ @9x324 Mhz=2916 Mhz| Asus A8N-E | PCI-E Sapphire X800 GTO2@X850(XT PE nog niet) | Twinmos 1024x2 CL 2.5 PC3200 | Antec TX 1050B (+500 watt modulaire PSU) | Thermaltake Big Typhoon | Logitech G-15 | Logitech MX-510 Gaming mouse|


  • anboni
  • Registratie: Maart 2004
  • Laatst online: 00:03
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
  • Registratie: Juli 2007
  • Laatst online: 26-09 10:04
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
  • Registratie: December 2012
  • Laatst online: 27-09 13:04
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__
  • Registratie: November 2001
  • Laatst online: 28-09 09:31
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
  • Registratie: Juli 2007
  • Laatst online: 26-09 10:04
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
  • Registratie: September 2013
  • Laatst online: 28-09 15:03
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
  • Registratie: Juni 2013
  • Laatst online: 22:20
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
  • Registratie: Juni 2004
  • Laatst online: 28-09 14:06
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
  • Registratie: September 2025
  • Laatst online: 21:53
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.

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner


  • KVan
  • Registratie: April 2015
  • Laatst online: 19:06
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
  • Registratie: Februari 2004
  • Laatst online: 20:07
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
  • Registratie: Januari 2000
  • Laatst online: 21:08
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
  • Registratie: Februari 2004
  • Laatst online: 20:07
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
  • Registratie: Februari 2026
  • Laatst online: 21:10
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:
1
2
3
4
5
"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?

PV: 5,6 kWp | EV: Toyota Bz4X ‘23


  • Wilin
  • Registratie: December 2012
  • Laatst online: 27-09 13:04
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
  • Registratie: Juni 2013
  • Laatst online: 22:20
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:
1
2
3
4
5
"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
  • Registratie: Januari 2011
  • Laatst online: 20:22
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
  • Registratie: September 2003
  • Niet online
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
  • Registratie: Juli 2015
  • Laatst online: 23:00
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
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

Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal


  • thomvh
  • Registratie: September 2013
  • Laatst online: 28-09 15:03
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
  • Registratie: Juli 2015
  • Laatst online: 23:00
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 ]

Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal


  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 23:00
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.

Afbeeldingslocatie: https://tweakers.net/i/bo68R2lrF_ijoobdPrBo7y8pxIQ=/x800/filters:strip_exif()/f/image/iK4GXmE7SO2lvbNZvXi7FVlp.png?f=fotoalbum_large

Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal


  • nklsn
  • Registratie: Februari 2026
  • Laatst online: 21:10
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.

PV: 5,6 kWp | EV: Toyota Bz4X ‘23


  • dingo35
  • Registratie: Februari 2008
  • Laatst online: 20:25
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
  • Registratie: Juni 2013
  • Laatst online: 22:20
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?

  • dingo35
  • Registratie: Februari 2008
  • Laatst online: 20:25
Dit is wat de source code zegt:
code:
1
2
3
4
5
6
7
8
9
    cost_supplier_production: dict[str, float] = Field(
        alias="cost supplier production",
        description="Supplier costs for production by date (YYYY-MM-DD -> euro/kWh ex VAT)",
        json_schema_extra={
            "x-help": "Supplier fees for feed-in/production (excluding VAT) indexed by effective date. May be negative (credit). Format: {'2024-01-01': -0.02}.",
            "x-unit": "€/kWh",
            "x-ui-section": "Cost",
            "x-validation-hint": "Dict with YYYY-MM-DD keys, float values (ex VAT)",
        },
Dus als de help tekst klopt, moet je voor een credit een negatief getal invoeren.

EDIT: In de rekencode staat dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
        salderen = self.prices_options.tax_refund if self.prices_options else True
        for row in df_da.itertuples():
            if pd.isnull(row.time):
                continue
            dag_str = row.time[:10]
            if dag_str != old_dagstr:
                ol_l = get_value_from_dict(dag_str, self.ol_l_def)
                ol_t = get_value_from_dict(dag_str, self.ol_t_def)
                taxes_l = get_value_from_dict(dag_str, self.taxes_l_def)
                taxes_t = get_value_from_dict(dag_str, self.taxes_t_def)
                btw_l = get_value_from_dict(dag_str, self.btw_l_def)
                btw_t = get_value_from_dict(dag_str, self.btw_t_def)
                multiplier_l = get_value_from_dict(dag_str, self.multiplier_l_def)
                multiplier_t = get_value_from_dict(dag_str, self.multiplier_t_def)
                old_dagstr = dag_str
            da_cons = (row.value * multiplier_l + taxes_l + ol_l) * (1 + btw_l / 100)
            if salderen:
                da_prod = (row.value * multiplier_t + taxes_t + ol_t) * (
                        1 + btw_t / 100
                )
            else:
                da_prod = (row.value + ol_t) * (1 + btw_t / 100)
De waarde waar het om gaat is ol_t; die wordt dus bij de productie opgeteld, dus als ik het goed beredeneer moet een verhoogde teruggave dus een positief getal voor een credit zijn.

@KC27 Maak ik een redeneer fout of is dit een foutje in hetzij de helptekst hetzij de formule?

[ Voor 60% gewijzigd door dingo35 op 17-09-2026 10:03 ]

dingo35 schreef op donderdag 17 september 2026 @ 09:55:
Dit is wat de source code zegt:
code:
1
2
3
4
5
6
7
8
9
    cost_supplier_production: dict[str, float] = Field(
        alias="cost supplier production",
        description="Supplier costs for production by date (YYYY-MM-DD -> euro/kWh ex VAT)",
        json_schema_extra={
            "x-help": "Supplier fees for feed-in/production (excluding VAT) indexed by effective date. May be negative (credit). Format: {'2024-01-01': -0.02}.",
            "x-unit": "€/kWh",
            "x-ui-section": "Cost",
            "x-validation-hint": "Dict with YYYY-MM-DD keys, float values (ex VAT)",
        },
Dus als de help tekst klopt, moet je voor een credit een negatief getal invoeren.

EDIT: In de rekencode staat dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
        salderen = self.prices_options.tax_refund if self.prices_options else True
        for row in df_da.itertuples():
            if pd.isnull(row.time):
                continue
            dag_str = row.time[:10]
            if dag_str != old_dagstr:
                ol_l = get_value_from_dict(dag_str, self.ol_l_def)
                ol_t = get_value_from_dict(dag_str, self.ol_t_def)
                taxes_l = get_value_from_dict(dag_str, self.taxes_l_def)
                taxes_t = get_value_from_dict(dag_str, self.taxes_t_def)
                btw_l = get_value_from_dict(dag_str, self.btw_l_def)
                btw_t = get_value_from_dict(dag_str, self.btw_t_def)
                multiplier_l = get_value_from_dict(dag_str, self.multiplier_l_def)
                multiplier_t = get_value_from_dict(dag_str, self.multiplier_t_def)
                old_dagstr = dag_str
            da_cons = (row.value * multiplier_l + taxes_l + ol_l) * (1 + btw_l / 100)
            if salderen:
                da_prod = (row.value * multiplier_t + taxes_t + ol_t) * (
                        1 + btw_t / 100
                )
            else:
                da_prod = (row.value + ol_t) * (1 + btw_t / 100)
De waarde waar het om gaat is ol_t; die wordt dus bij de productie opgeteld, dus als ik het goed beredeneer moet een verhoogde teruggave dus een positief getal voor een credit zijn.

@KC27 Maak ik een redeneer fout of is dit een foutje in hetzij de helptekst hetzij de formule?
De rekenregels kloppen. De helptekst is niet voor eenduidige interpretatie vatbaar en zal worden aangepast:
- negatief: jij ontvangt minder terug
- positief: jij ontvangt meer terug

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


  • dingo35
  • Registratie: Februari 2008
  • Laatst online: 20:25
Bedankt, aangepast in m'n config.

Ik draai noodgedwongen de docker versie van HA, en draai dan dus ook noodgedwongen de docker versie van DAO; latest is gepint op 2026.6.0, terwijl laatste stable release 2026.9.1 is.

Ik vind het zelf altijd vervelend als mensen vragen / bugreports insturen en dan nog met oude versies draaien; kan ik DAO ook zo installeren dat ik niet op die docker update hoef te wachten (docs zeggen van niet?), of is er een andere work-around?

[ Voor 3% gewijzigd door dingo35 op 18-09-2026 09:20 ]


  • dotcom87
  • Registratie: Januari 2011
  • Laatst online: 20:22
Ik ben er in geslaagd mijn geothermische Vaillant warmtepomp te koppelen aan Home Assistant via een eBUSd/MQTT setup. Ik krijg nu een hoop controls, waarvan ik er hopelijk kan gebruiken om de warmtepomp correct aan te sturen via DAO.
Ik zie dat er verschillende adjustment opties zijn in DAO voor de heating: "on/off", "power" of "heating curve".

Er is een control in HA genaamd hc1heatcurve, die nu een waarde had van 0.3
Ik kan deze zelf overschrijven (dat heb ik getest door naar 0.4 te gaan).

Is dit de waarde die DAO dan moet gaan controleren?
dingo35 schreef op vrijdag 18 september 2026 @ 09:20:
Bedankt, aangepast in m'n config.

Ik draai noodgedwongen de docker versie van HA, en draai dan dus ook noodgedwongen de docker versie van DAO; latest is gepint op 2026.6.0, terwijl laatste stable release 2026.9.1 is.

Ik vind het zelf altijd vervelend als mensen vragen / bugreports insturen en dan nog met oude versies draaien; kan ik DAO ook zo installeren dat ik niet op die docker update hoef te wachten (docs zeggen van niet?), of is er een andere work-around?
We zijn overgestapt op een andere wijze van builden van de packages.
Voor HA-app gebruikers heeft dat geen gevolgen, maar wel voor gebruikers die DAO draaien in een aparte container.
Misschien moet je in je docker de url veranderen naar:
code:
1
docker pull ghcr.io/corneel27/dao
(dus zonder processor aanduiding)
Samen met de packages wordt een manifest gepubliceerd en Docker zoekt het goede package zelf uit m.b.v. dat manifest.

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

dotcom87 schreef op vrijdag 18 september 2026 @ 10:46:
Ik ben er in geslaagd mijn geothermische Vaillant warmtepomp te koppelen aan Home Assistant via een eBUSd/MQTT setup. Ik krijg nu een hoop controls, waarvan ik er hopelijk kan gebruiken om de warmtepomp correct aan te sturen via DAO.
Ik zie dat er verschillende adjustment opties zijn in DAO voor de heating: "on/off", "power" of "heating curve".

Er is een control in HA genaamd hc1heatcurve, die nu een waarde had van 0.3
Ik kan deze zelf overschrijven (dat heb ik getest door naar 0.4 te gaan).

Is dit de waarde die DAO dan moet gaan controleren?
Voordat hier iets over kan worden gezegd moet wel duidelijk worden wat "hc1 heatcurve" precies doet. Is daar documentatie over beschikbaar?

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


  • dingo35
  • Registratie: Februari 2008
  • Laatst online: 20:25
@KC27 Bedankt, niet alleen voor je snelle antwoord maar óók voor deze mooie software; echt heel mooi!!

Mbt de docker url, misschien even deze pagina updaten met de info die je zojuist gaf, dat scheelt weer vragen in de toekomst:
https://github.com/cornee...tie-en-basis-configuratie

  • wouwi
  • Registratie: Oktober 2018
  • Laatst online: 22:44
KC27 schreef op vrijdag 18 september 2026 @ 11:47:
[...]

Voordat hier iets over kan worden gezegd moet wel duidelijk worden wat "hc1 heatcurve" precies doet. Is daar documentatie over beschikbaar?
Dat is de stooklijn, oftewel de curve die bepaald wat de gewenste aanvoertemperatuur van de warmtepomp moet zijn bij een bepaalde buitentemperatuur. Een hogere waarde geeft een stijlere lijn en dus een hogere aanvoer temperatuur van de warmtepomp. Verwarmen gaat dan sneller, maar wel met een lagere efficiëntie.

Normaal wil je een zo laag mogelijke stooklijn, want dan draait de warmtepomp efficiënt en stabiel. Maar bij lage prijzen kan het handig zijn om tijdelijk met een hogere stooklijn te draaien en zo een soort boost te geven.
wouwi schreef op vrijdag 18 september 2026 @ 19:31:
[...]

Dat is de stooklijn, oftewel de curve die bepaald wat de gewenste aanvoertemperatuur van de warmtepomp moet zijn bij een bepaalde buitentemperatuur. Een hogere waarde geeft een stijlere lijn en dus een hogere aanvoer temperatuur van de warmtepomp. Verwarmen gaat dan sneller, maar wel met een lagere efficiëntie.

Normaal wil je een zo laag mogelijke stooklijn, want dan draait de warmtepomp efficiënt en stabiel. Maar bij lage prijzen kan het handig zijn om tijdelijk met een hogere stooklijn te draaien en zo een soort boost te geven.
In dat geval kun je met "adjustment": "heating curve" werken.
Je moet daarnaast nog twee zaken instellen:
"entity_adjust_heating_curve"
"adjustment_factor"
Vooral die laatste is belangrijk om goed in te stellen.
Dit is formule in DAO die de bijstelling berekent (vereenvoudigd):
adjustment = -adjustment_factor * (price_act - price_avg) * 100 / price_avg
price_act: de actuele prijs van dat uur/kwartier
price_avg: de gemiddelde prijs over de berekeningsperiode
Voor iedere procent afwijking wordt de bijstelling met de adjustment_factor omhoog of omlaag berekend, dus bij 10 procent dus 10 keer!.
Je zult dit met een goede instelling en met een automation in HA moeten aanpassen voordat je het naar je wp stuurt.

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


  • dingo35
  • Registratie: Februari 2008
  • Laatst online: 20:25
Ik draai nu een paar dagen op "cost_minimum" , eigenlijk alleen PV en thuisbatterij geconfigureerd; gisteren liep alles volgens verwachting, bij lage kWh prijs ging de thuisbatterij laden en bij hoge kWh prijs ging hij ontladen.

Maar vandaag gebeurt er niets, elk kwartier begint hij met een nul regel op de planning, en daarna plant hij het laden van de thuisbatterij in, maar het volgend kwartier doet hij hetzelfde, dus per saldo laadt hij nooit....

Log:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
 2026-09-19 12:30:53 info: Day Ahead Optimalisering versie: 2026.9.1
2026-09-19 12:30:53 info: Day Ahead Optimalisering gestart op: 19-09-2026 12:30:53
2026-09-19 12:30:53 info: Day Ahead Optimalisatie gestart: 19-09-2026 12:30:53 taak: calc_optimum
2026-09-19 12:30:53 info: Debug = False
2026-09-19 12:30:54 info: Baseload uit instellingen
2026-09-19 12:30:55 info: ML prediction totaal
                   date_time  prediction
0  2026-09-19 12:00:00+02:00       1.058
1  2026-09-19 13:00:00+02:00       3.045
2  2026-09-19 14:00:00+02:00       3.037
3  2026-09-19 15:00:00+02:00       1.846
4  2026-09-19 16:00:00+02:00       1.290
5  2026-09-19 17:00:00+02:00       0.395
6  2026-09-19 18:00:00+02:00       0.380
7  2026-09-19 19:00:00+02:00       0.219
8  2026-09-19 20:00:00+02:00       0.158
9  2026-09-19 21:00:00+02:00       0.208
10 2026-09-19 22:00:00+02:00       0.182
11 2026-09-19 23:00:00+02:00       0.182
2026-09-19 12:30:59 info: No reduced hours applied for Deye 12kW
2026-09-19 12:30:59 info: No reduced power applied during discharging at low soc
2026-09-19 12:30:59 info: No reduced power applied during charging at high soc
2026-09-19 12:30:59 info: Startwaarde SoC Deye 12kW: 31.0%

2026-09-19 12:30:59 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2026-09-19 12:30:59 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-09-19 12:30:59 info: Strategie: minimale kosten
2026-09-19 12:30:59 info: Maximale fout (maximal gap): 0.001000 euro
2026-09-19 12:31:02 info: Rekentijd: 2.53  sec
2026-09-19 12:31:02 info: Het programma heeft een optimale oplossing gevonden.
2026-09-19 12:31:02 info: In- en uitgaande energie per kwartier batterij Deye 12kW
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 12:30   0.00     --   0.00   0.00   0.00     --   0.00     --  31.00
 12:45   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  35.64
 13:00   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  40.28
 13:15   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  44.92
 13:30   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  49.56
 13:45   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  54.20
 14:00   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  58.83
 14:15   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  63.47
 14:30   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  68.11
 14:45   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  72.75
 15:00   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  77.39
 15:15   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  82.03
 15:30   1.56  97.60   1.52   0.00   1.52  97.50   1.48  95.16  86.67
 15:45   1.12  97.39   1.09   0.00   1.09  97.50   1.07  94.95  90.00
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 16:15   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 16:30   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 17:30   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 17:45   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 18:15   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 18:30   0.00     --   0.00   0.00   0.00     --   0.00     --  90.00
 18:45  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  84.88
 19:00  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  79.75
 19:15  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  74.63
 19:30  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  69.51
 19:45  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  64.39
 20:00  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  59.26
 20:15  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  54.14
 20:30  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  49.02
 20:45  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  43.89
 21:00  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  38.77
 21:15  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  33.65
 21:30  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  28.52
 21:45   0.00     --   0.00   0.00   0.00     --   0.00     --  28.52
 22:00   0.00     --   0.00   0.00   0.00     --   0.00     --  28.52
 22:15   0.00     --   0.00   0.00   0.00     --   0.00     --  28.52
 22:30  -1.04  97.60  -1.06   0.00  -1.06  97.50  -1.09  95.16  25.12
 22:45  -1.56  97.60  -1.60   0.00  -1.60  97.50  -1.64  95.16  20.00
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
Totaal  -1.47         -2.48   0.00  -2.48         -3.52              
2026-09-19 12:31:17 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 12:30    0.00     0.00   0.00   0.23   0.08   0.00   0.00   0.00   0.31   0.00   -0.03  20.00
 12:45    1.56     0.00   1.18   0.00   0.07   0.00   0.00   0.00   0.45   0.15   -0.00  20.00
 13:00    1.56     0.00   1.02   0.00   0.06   0.00   0.00   0.00   0.61   0.13   -0.00  20.00
 13:15    1.56     0.00   0.89   0.00   0.06   0.00   0.00   0.00   0.73   0.12   -0.00  20.00
 13:30    1.56     0.00   0.76   0.00   0.05   0.00   0.00   0.00   0.85   0.10   -0.00  20.00
 13:45    1.56     0.00   0.76   0.00   0.06   0.00   0.00   0.00   0.85   0.10   -0.00  20.00
 14:00    1.56     0.00   0.84   0.00   0.06   0.00   0.00   0.00   0.78   0.11   -0.00  20.00
 14:15    1.56     0.00   0.85   0.00   0.07   0.00   0.00   0.00   0.78   0.11   -0.00  20.00
 14:30    1.56     0.00   0.85   0.00   0.07   0.00   0.00   0.00   0.78   0.11   -0.00  20.00
 14:45    1.56     0.00   0.92   0.00   0.06   0.00   0.00   0.00   0.70   0.12   -0.00  20.00
 15:00    1.56     0.00   1.05   0.00   0.06   0.00   0.00   0.00   0.56   0.14   -0.00  20.00
 15:15    1.56     0.00   1.12   0.00   0.05   0.00   0.00   0.00   0.49   0.15   -0.00  20.00
 15:30    1.56     0.00   1.20   0.00   0.05   0.00   0.00   0.00   0.41   0.16   -0.00  20.00
 15:45    1.12     0.00   0.79   0.00   0.05   0.00   0.00   0.00   0.38   0.10   -0.00  20.00
 16:00    0.00     0.00   0.00   0.33   0.05   0.00   0.00   0.00   0.38   0.00   -0.04  20.00
 16:15    0.00     0.00   0.00   0.30   0.05   0.00   0.00   0.00   0.35   0.00   -0.04  20.00
 16:30    0.00     0.00   0.00   0.26   0.05   0.00   0.00   0.00   0.31   0.00   -0.03  20.00
 16:45    0.00     0.00   0.00   0.19   0.07   0.00   0.00   0.00   0.25   0.00   -0.02  20.00
 17:00    0.00     0.00   0.00   0.06   0.11   0.00   0.00   0.00   0.17   0.00   -0.01  20.00
 17:15    0.00     0.00   0.02   0.00   0.13   0.00   0.00   0.00   0.11   0.00   -0.00  20.00
 17:30    0.00     0.00   0.10   0.00   0.15   0.00   0.00   0.00   0.06   0.01   -0.00  20.00
 17:45    0.00     0.00   0.08   0.00   0.14   0.00   0.00   0.00   0.06   0.01   -0.00  20.00
 18:00    0.00     0.00   0.00   0.01   0.09   0.00   0.00   0.00   0.10   0.00   -0.00  20.00
 18:15    0.00     0.00   0.00   0.03   0.07   0.00   0.00   0.00   0.10   0.00   -0.01  20.00
 18:30    0.00     0.00   0.00   0.04   0.05   0.00   0.00   0.00   0.10   0.00   -0.01  20.00
 18:45    0.00     1.56   0.00   1.59   0.05   0.00   0.00   0.00   0.09   0.00   -0.44  20.00
 19:00    0.00     1.56   0.00   1.56   0.07   0.00   0.00   0.00   0.07   0.00   -0.43  20.00
 19:15    0.00     1.56   0.00   1.55   0.07   0.00   0.00   0.00   0.06   0.00   -0.47  20.00
 19:30    0.00     1.56   0.00   1.54   0.07   0.00   0.00   0.00   0.05   0.00   -0.49  20.00
 19:45    0.00     1.56   0.00   1.54   0.06   0.00   0.00   0.00   0.04   0.00   -0.50  20.00
 20:00    0.00     1.56   0.00   1.54   0.06   0.00   0.00   0.00   0.04   0.00   -0.49  20.00
 20:15    0.00     1.56   0.00   1.54   0.06   0.00   0.00   0.00   0.04   0.00   -0.46  20.00
 20:30    0.00     1.56   0.00   1.54   0.05   0.00   0.00   0.00   0.04   0.00   -0.43  20.00
 20:45    0.00     1.56   0.00   1.55   0.05   0.00   0.00   0.00   0.04   0.00   -0.41  20.00
 21:00    0.00     1.56   0.00   1.56   0.05   0.00   0.00   0.00   0.05   0.00   -0.46  20.00
 21:15    0.00     1.56   0.00   1.56   0.05   0.00   0.00   0.00   0.05   0.00   -0.42  20.00
 21:30    0.00     1.56   0.00   1.57   0.05   0.00   0.00   0.00   0.05   0.00   -0.42  20.00
 21:45    0.00     0.00   0.00   0.01   0.05   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
 22:00    0.00     0.00   0.00   0.00   0.05   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
 22:15    0.00     0.00   0.00   0.00   0.05   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
 22:30    0.00     1.04   0.00   1.04   0.04   0.00   0.00   0.00   0.04   0.00   -0.27  20.00
 22:45    0.00     1.56   0.00   1.56   0.04   0.00   0.00   0.00   0.04   0.00   -0.43  20.00
 23:00    0.00     0.00   0.00   0.00   0.04   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
 23:15    0.00     0.00   0.00   0.00   0.04   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
 23:30    0.00     0.00   0.00   0.01   0.04   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
 23:45    0.00     0.00   0.00   0.01   0.04   0.00   0.00   0.00   0.05   0.00   -0.00  20.00
Totaal   19.84    21.32  12.44  22.74   2.87   0.00   0.00   0.00  11.70   1.62   -6.34    NaN

2026-09-19 12:31:17 info: Consumption              12.44 (kWh)
2026-09-19 12:31:17 info: Cost consumption          1.62 (€)
2026-09-19 12:31:17 info: Tariff consumption        0.130 (€/kWh)
2026-09-19 12:31:17 info: Production               22.74 (kWh)
2026-09-19 12:31:17 info: Profit production        -6.34 (€)
2026-09-19 12:31:17 info: Tariff production         0.279 (€/kWh)

2026-09-19 12:31:17 info: 
Calculation profit after optimize in €
Cost before optimize             -1.14
Cost consumption      1.62
Bat cycle cost        0.82
Bat penalty cost      0.00
EV switch costs       0.00
EV low soc costs      0.00
Battery storage       0.65
Boiler storage        0.00
Profit production    -6.34
Total                -3.25
Cost after optimize              -3.25
Profit:                           2.11
2026-09-19 12:31:17 info: Doorzetten van alle settings naar HA
2026-09-19 12:31:17 info: Grid balanceren: off
2026-09-19 12:31:17 info: Grid set point: -994.0 W
2026-09-19 12:31:17 info: Cycle cost Deye 12kW: 0.82 euro
2026-09-19 12:31:17 info: Netto vermogen naar(+)/uit(-) omvormer Deye 12kW: 0 W 
2026-09-19 12:31:17 info: Vermogen uit batterij: 0W
2026-09-19 12:31:17 info: Vermogen dat binnenkomt van pv: 0W
2026-09-19 12:31:17 info: Vermogen dat binnenkomt van ac: 0W
2026-09-19 12:31:17 info: Waarde SoC na eerste uur: 31.0%
config:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "localhost",
    "ip port": 8123,
    "protocol_api": "http",
    "token": "!secret ha_api_token"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "interval": "15min",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161
    },
    "energy_taxes_production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161,
      "2027-01-01": 0.0
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-01-01": 0.01652893
    },
    "cost_supplier_production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-01-01": 0.0,
      "2026-01-01": 0.01652893
    },
    "vat_consumption": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "vat_production": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0,
      "2026-01-01": 1.1
    },
    "last_invoice": "2026-11-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
  "logging_level": "info",
  "use_calc_baseload": false,
  "baseload_calc_periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": false,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "minimize cost",
  "//strategy": "minimize consumption",
  "//max_gap": 0.005,
  "max_gap": 0.001,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
    "name": "Deye 12kW",
    "capacity" : 32,
    "entity actual level": "sensor.deye_battery",
    "upper limit": 90,
    "lower limit": 20,
    "charge stages": [
        {"power": 0,     "efficiency": 1.0},
        {"power": 600,   "efficiency": 0.92},
        {"power": 1200,  "efficiency": 0.955},
        {"power": 2400,  "efficiency": 0.965},
        {"power": 3600,  "efficiency": 0.972},
        {"power": 6240,  "efficiency": 0.976}
    ],
    "discharge stages" : [
        {"power": 0,     "efficiency": 1.0},
        {"power": 600,   "efficiency": 0.92},
        {"power": 1200,  "efficiency": 0.955},
        {"power": 2400,  "efficiency": 0.965},
        {"power": 3600,  "efficiency": 0.972},
        {"power": 6240,  "efficiency": 0.976}
    ],
    "//minimum power" : 500,
    "minimum power" : 0,
    "dc_to_bat efficiency" : 0.975,
    "bat_to_dc efficiency": 0.975,
    "cycle cost" : 0.02,
    "entity set power feedin": "input_number.dao_charge_power",
    "solar": [ ]
   }
  ],
  "solar": [
   {
    "name": "totaal",
    "ml_prediction": true,
    "ml_training_start_date": "2026-05-01",
    "entities sensors": "sensor.goodwe4200_energy_today",
    "max power": 11,
    "tilt": 35,
    "orientation": 45,
    "capacity": 11,
    "yield": 0.023375
   }
  ],
  "//electric_vehicle": [],
  "//electric_vehicle": [
   {
      "name": "Enyaq",
      "capacity": 78,
      "switch_cost": 0.10,
      "//entity position": "device_tracker.smartevse_6697",
      "entity position": "input_select.day_ahead_enyaq_thuis",
      "entity max amperage": "sensor.smartevse_51446_maxcurrent",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  0.1},
        {"ampere":  6, "efficiency" :  0.95},
        {"ampere":  8, "efficiency" :  0.96},
        {"ampere": 10, "efficiency" :  0.97},
        {"ampere": 12, "efficiency" :  0.975},
        {"ampere": 14, "efficiency" :  0.98},
        {"ampere": 16, "efficiency" :  0.99}
      ],
      "//entity actual level": "input_number.day_ahead_soc_enyaq",
      "entity actual level": "sensor.skoda_enyaq_accupercentage",
      "//entity plugged in": "binary_sensor.skoda_enyaq_laadkabel",
      "//entity plugged in": "sensor.smartevse_51446_evplugstate",
      "entity plugged in": "binary_sensor.day_ahead_ev_plugged_in",
      "charge scheduler": {
        "entity set level": "input_number.day_ahead_soc_enyaq_wanted",
        "level margin": 2,
        "entity ready datetime": "input_datetime.day_ahead_enyaq_ready_time"
      },
      "charge switch": "input_boolean.day_ahead_smartevse_charge_switch",
      "entity set charging ampere" : "input_number.day_ahead_smartevse_charge_current",
      "//entity set charging ampere" : "number.smartevse_51446_chargecurrentoverride",
      "//entity stop charging": "input_datetime.dao_zoe_stop_laden_ev"
    }
   ],
  "machines": [],
  "boiler": {
    "boiler_present": false,
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater_present": false,
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "tibber": {
    "api_token": "!secret tibber_api_token",
    "api_url": "https://api.tibber.com/v1-beta/gql"
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": [
      "sensor.sensorbox_101110_energydeliveredtariff1",
      "sensor.sensorbox_101110_energydeliveredtariff2"
    ],
    "entities_grid_production": [
      "sensor.sensorbox_101110_energyreturnedtariff1",
      "sensor.sensorbox_101110_energyreturnedtariff2"
    ],
    "entities_solar_production_ac": [
      "sensor.goodwe4200_total_energy"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": [
      "sensor.smartevse_51446_evimportactiveenergy"
    ],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.deye_total_battery_charge"
    ],
    "entities_battery_production": [
      "sensor.deye_total_battery_discharge"
    ],
    "entities_machine_consumption": []
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0425",
        "action": "get_meteo_data"
      },
      {
        "time": "1025",
        "action": "get_meteo_data"
      },
      {
        "time": "1625",
        "action": "get_meteo_data"
      },
      {
        "time": "2225",
        "action": "get_meteo_data"
      },
      {
        "time": "1255",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1355",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1455",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1554",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1655",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "xx15",
        "action": "calc_optimum"
      },
      {
        "time": "xx30",
        "action": "calc_optimum"
      },
      {
        "time": "xx45",
        "action": "calc_optimum"
      },
      {
        "time": "2359",
        "action": "clean_data"
      }
    ]
  },
  "meteoserver_attempts": 2
}
Grok adviseerde me om max_gap van 0.005 naar 0.001 te verlagen, en minimum_power van 500W naar 0, maar dat hielp niets.

Iemand enig idee wat hier aan de hand is?

  • Domba
  • Registratie: Januari 2005
  • Laatst online: 01:43
@dingo35 ik denk dat dit een correctie benodigd
"cost_supplier_production": {
"2022-01-01": 0.002,
"2023-03-01": 0.018,
"2024-04-01": 0.0175,
"2024-08-01": 0.020496,
"2026-01-01": 0.0,
"2026-01-01": 0.01652893

Eilandbedrijf met netondersteuning , all-electric || Deye 12KSG04LP3 met 580Ah-LFP 51,2V (Seplos 3x48100-10C +48200-10E) || hulp-Deye 12k SG04LP3 met 280Ah-LFP 51,2V || 19.4 kWp PV || Zonneplan EPEX-klant


  • dotcom87
  • Registratie: Januari 2011
  • Laatst online: 20:22
KC27 schreef op vrijdag 18 september 2026 @ 19:46:
[...]

In dat geval kun je met "adjustment": "heating curve" werken.
Je moet daarnaast nog twee zaken instellen:
"entity_adjust_heating_curve"
"adjustment_factor"
Vooral die laatste is belangrijk om goed in te stellen.
Dit is formule in DAO die de bijstelling berekent (vereenvoudigd):
adjustment = -adjustment_factor * (price_act - price_avg) * 100 / price_avg
price_act: de actuele prijs van dat uur/kwartier
price_avg: de gemiddelde prijs over de berekeningsperiode
Voor iedere procent afwijking wordt de bijstelling met de adjustment_factor omhoog of omlaag berekend, dus bij 10 procent dus 10 keer!.
Je zult dit met een goede instelling en met een automation in HA moeten aanpassen voordat je het naar je wp stuurt.
Uhm nu hoor ik het in Keulen donderen vrees ik 😄

Vooral de entity_adjust_heating_curve en de adjustment_factor snap ik niet.

  • stat
  • Registratie: Mei 2005
  • Laatst online: 20:57
Ik loop tegen iets aan. Laat vandaag om 14:20 DAO berekenen wanneer de vaatwasser aan moet. Als window geef ik mee dat het tussen 14:22 en 17:00 moet gebeuren, maar hij komt terug met 14:15, maar dat is het dan al geweest.

Dat lijkt me niet de bedoeling. Zou misschien nog kunnen liggen aan het einde dat ik te krap heb gekozen ivm programmaduur van 3 uur (ga ik aanpassen), maar toch geen handige uitkomst lijkt me.

  • Knielen
  • Registratie: December 2009
  • Laatst online: 21:18
stat schreef op zondag 20 september 2026 @ 18:21:
Ik loop tegen iets aan. Laat vandaag om 14:20 DAO berekenen wanneer de vaatwasser aan moet. Als window geef ik mee dat het tussen 14:22 en 17:00 moet gebeuren, maar hij komt terug met 14:15, maar dat is het dan al geweest.

Dat lijkt me niet de bedoeling. Zou misschien nog kunnen liggen aan het einde dat ik te krap heb gekozen ivm programmaduur van 3 uur (ga ik aanpassen), maar toch geen handige uitkomst lijkt me.
Dat is toch precies het blok waarin hij mag beginnen? 14:22 ligt in het blok van 14:15 tot 14:30. Gelijk starten dus.

  • stat
  • Registratie: Mei 2005
  • Laatst online: 20:57
Hmm ja dat klinkt op zich logisch, alleen gebruik ik die tijd als trigger voor een automation om de afwasmachine aan te zetten, en dan is het niet zo handig ;-). Maar dat moet ik dan misschien anders aanpakken.

  • stat
  • Registratie: Mei 2005
  • Laatst online: 20:57
Domme vraag misschien: ik heb een Zendure Solarflow 800 plus gekocht en wil die integreren in DAO. Maar hoe meer ik er over nadenk, hoe meer ik denk dat gewoon NOM draaien voor mij het handigst is als salderen eraf is (want: zonnepanelen en vast contract).

Of maak ik een denkfout?
stat schreef op dinsdag 22 september 2026 @ 21:48:
Domme vraag misschien: ik heb een Zendure Solarflow 800 plus gekocht en wil die integreren in DAO. Maar hoe meer ik er over nadenk, hoe meer ik denk dat gewoon NOM draaien voor mij het handigst is als salderen eraf is (want: zonnepanelen en vast contract).

Of maak ik een denkfout?
Je kunt proefberekeningen maken, maar helaas biedt DAO (nog) geen ondersteuning voor vaste contracten.
Wat denken jullie: is er behoefte aan ondersteuning van vaste contracten?

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

dotcom87 schreef op zaterdag 19 september 2026 @ 14:27:
[...]

Uhm nu hoor ik het in Keulen donderen vrees ik 😄

Vooral de entity_adjust_heating_curve en de adjustment_factor snap ik niet.
Bij entity_adjust_heating_curve vul je bij de instellingen van DAO de naam van de sensor (meestal een helper in de vorm van een input_nummer) waar DAO de berekende bijstelling van de stooklijn in opslaat.
De adjustment_factor is de factor die DAO gebruikt om een afwijking van de actuele prijs t.o.v. de gemiddelde prijs om te rekenen naar de bijstelling van de stooklijn. (zie de gebruikte formule).

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 28-09 16:38
KC27 schreef op dinsdag 22 september 2026 @ 22:17:
[...]

Je kunt proefberekeningen maken, maar helaas biedt DAO (nog) geen ondersteuning voor vaste contracten.
Wat denken jullie: is er behoefte aan ondersteuning van vaste contracten?
Ik vraag me af wat er dan beter zou zijn dan NoM? Zeker vanaf 1 januari. Planbare apparaten kun je standaard in de middag starten, veel meer winst is er dan niet te halen imo.

Dan DAO draaien voegt alleen complexiteit toe zonder duidelijk voordeel. Maar mocht ik iets over het hoofd zien, dan hoor ik het graag.

"Chaos kan niet uit de hand lopen"


  • anboni
  • Registratie: Maart 2004
  • Laatst online: 00:03
KC27 schreef op dinsdag 22 september 2026 @ 22:17:
[...]

Je kunt proefberekeningen maken, maar helaas biedt DAO (nog) geen ondersteuning voor vaste contracten.
Wat denken jullie: is er behoefte aan ondersteuning van vaste contracten?
Misschien als er wel variabele, tijd-gebaseerde netwerkkosten komen (ik geloof dat ik in het day ahead topic zoiets last vanaf 2029, maar de details zijn me nog niet helemaal duidelijk). Anders lijkt DAO voor vaste contracten weinig zinvol.

Waar ik nog wel aan zat te denken, misschien zou integratie van meerdaagse verwachtingen nog interessante dingen kunnen opleveren. Als je een indicatieve verwachting weet voor over 3 dagen, zou je nu je acties kunnen voorbereiden (bij veel zonneopwek je accu leegmaken, bij verwachte hogere prijzen juist de thuisaccu zo vol mogelijk laden/houden)

  • stat
  • Registratie: Mei 2005
  • Laatst online: 20:57
@KC27 @storeman

Ik dacht dat je met de strategie minimize consumption, en dan de batterij helemaal buiten DAO laten al een heel eind bent toch? Dan worden de apparaten zo gepland dat ze zoveel mogelijk zonnestroom gebruiken, en wat er dan overblijft gaat de batterij in.

@anboni

Het verhaal wordt inderdaad heel anders als er variabele netwerkkosten komen.

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 23:00
hemertje schreef op woensdag 16 september 2026 @ 08:17:
Goedemorgen,

nav onderstaande berekening


[...]

Niemand?


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.

[Afbeelding]

Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal


  • edterbak
  • Registratie: Maart 2006
  • Laatst online: 02:57
Hoi allen,

Ik heb een 3tal marstek batterijen. Het belangrijkste vind ik eigen zonnestroom gebruiken. Maar de aankomende periode wordt dat lastig uiteraard als de zon minder aanwezig is.
Ik heb DAO ingesteld op "minimize consumption".

Ik heb deze week veel tijd gestoken om helpers te maken in home assistant en de DAO hier aan te verbinden. Zo kan ik nu eerst even zien wat DAO doet, zonder daarbij definitief de controle daadwerkelijk te geven.
Ik heb nu per batterij deze helper:
  • input_datetime.dao_batterij_18cedf99179d_stop_inverter_datetime
  • input_number.dao_batterij_18cedf99179d_set_power
  • input_select.dao_batterij_18cedf99179d_set_operating_mode
Ook heb ik 1 globale helper
  • input_boolean.dao_batterij_global_balance_switch
Mijn usecase story (wat vast niet voor het eerst beschreven wordt) is als volgt:
  • Basis modus = NoM
  • Als er zonnestroom is, batterij vullen met dat uiteraard
  • Als er onvoldoende zon is, batterij vullen met goedkope stroom.
De config van de batterijen ziet er zo uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
"interval": "15min",
  "strategy": "minimize consumption",
  "max_gap": 0.005,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 17.0,
    "entity_balance_switch": "input_boolean.dao_batterij_global_balance_switch"
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Marstek Venus E1",
      "entity_actual_level": "sensor.marstek_battery_18cedf99179d_battery_soc",
        "entity_stop_inverter": "input_datetime.dao_batterij_18cedf99179d_stop_inverter_datetime",
      "capacity": 5.12,
      "upper_limit": 100,
      "lower_limit": 12,
      "optimal_lower_level": 15,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.79
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8975
        },
        {
          "power": 1000.0,
          "efficiency": 0.8933
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.901
        },
        {
          "power": 2500.0,
          "efficiency": 0.8933
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.989
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced_hours": {},
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 50,
      "dc_to_bat_efficiency": 0.935,
      "dc_to_bat_max_power": 2500.0,
      "bat_to_dc_efficiency": 0.935,
      "bat_to_dc_max_power": 2500.0,
      "cycle_cost": 0.0237,
      "entity_set_power_feedin": "input_number.dao_batterij_18cedf99179d_set_power",
      "entity_set_operating_mode": "input_select.dao_batterij_18cedf99179d_set_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "solar": []
    },
    {
      "name": "Marstek Venus E2",
      "entity_actual_level": "sensor.marstek_battery_3c1accbaa19d_battery_soc",
        "entity_stop_inverter": "input_datetime.dao_batterij_3c1accbaa19d_stop_inverter_datetime",
      "capacity": 5.12,
      "upper_limit": 100,
      "lower_limit": 12,
      "optimal_lower_level": 15,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.36
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8975
        },
        {
          "power": 1000.0,
          "efficiency": 0.8933
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.901
        },
        {
          "power": 2500.0,
          "efficiency": 0.9017
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.989
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced_hours": {},
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 50,
      "dc_to_bat_efficiency": 0.935,
      "dc_to_bat_max_power": 2500.0,
      "bat_to_dc_efficiency": 0.935,
      "bat_to_dc_max_power": 2500.0,
      "cycle_cost": 0.0237,
      "entity_set_power_feedin": "input_number.dao_batterij_3c1accbaa19d_set_power",
      "entity_set_operating_mode": "input_select.dao_batterij_3c1accbaa19d_set_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "solar": []
    },
    {
      "name": "Marstek Venus A",
      "entity_actual_level": "sensor.marstek_battery_bc2a33ad4061_battery_soc",
      "entity_stop_inverter": "input_datetime.dao_batterij_bc2a33ad4061_stop_inverter_datetime",
      "capacity": 4.16,
      "upper_limit": 100,
      "lower_limit": 12,
      "optimal_lower_level": 15,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.36
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8975
        },
        {
          "power": 1000.0,
          "efficiency": 0.8933
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.989
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        }
      ],
      "reduced_hours": {},
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 50,
      "dc_to_bat_efficiency": 0.935,
      "dc_to_bat_max_power": 1500.0,
      "bat_to_dc_efficiency": 0.935,
      "bat_to_dc_max_power": 1500.0,
      "cycle_cost": 0.0234,
      "entity_set_power_feedin": "input_number.dao_batterij_bc2a33ad4061_set_power",
      "entity_set_operating_mode": "input_select.dao_batterij_bc2a33ad4061_set_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "solar": []
    }
  ],
Nu zie ik dit in Home assistant:
Afbeeldingslocatie: https://tweakers.net/i/Y7TtmHHGrZoiWWOupm6PCIX_ySM=/800x/filters:strip_exif()/f/image/vo4kh1tji6751CoYuDGRxvft.png?f=fotoalbum_large

Het valt mij op dat DAO nogal vaak de batterij aanstuurt en vrijgeeft. (bovenstaande afbeelding, links)
In DAO is de grafiek als volgt:
Afbeeldingslocatie: https://tweakers.net/i/99Ml0ayAEpLjm0IZ1NVPqb2N_s0=/232x232/filters:strip_exif()/f/image/qJddBuDqiaJfy7hmBnSIapw0.png?f=fotoalbum_tile
Klik om te vergroten...

Ik hoop eigenlijk te zien dat DAO op enkele momenten de regie pakt over de batterij.
Dat gebeurt nu te vaak. 11x vandaag. Dat lijkt dus niet op wat ik graag wil.

Maar ik heb het gevoel dat ik er bijna ben, ik weet alleen niet waar ik het moet zoeken.
is het de stroomprijs, de laadcyclus kosten, iets anders.
Ik zou een beetje sturing van experts hier kunnen gebruiken voordat ik het in mijn eentje in de soep weet te draaien :)

  • oscaarbasgitaar
  • Registratie: Januari 2026
  • Laatst online: 00:20
Hallo allen,

ik ben hier ook even aan het doorworstelen met het idee om dit misschien te gebruiken voor mijn geothermische warmtepomp.

Een eerste vraagje, ik woon in belgië.
op zich lopen onze epexspot prijzen relatief gelijk, maar niet altijd.
Ik zie geen optie (of ik heb iets over het hoofd gezien) om een regio te definiëren?
oscaarbasgitaar schreef op woensdag 23 september 2026 @ 21:16:
Hallo allen,

ik ben hier ook even aan het doorworstelen met het idee om dit misschien te gebruiken voor mijn geothermische warmtepomp.

Een eerste vraagje, ik woon in belgië.
op zich lopen onze epexspot prijzen relatief gelijk, maar niet altijd.
Ik zie geen optie (of ik heb iets over het hoofd gezien) om een regio te definiëren?
DAO neemt je regio over van Home Assistant.

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


  • oscaarbasgitaar
  • Registratie: Januari 2026
  • Laatst online: 00:20
Wilin schreef op vrijdag 11 september 2026 @ 12:15:
[...]

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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
   "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
  },
Het contract van Ecopower is met kwartierwaarden, dit is mijn code:
YAML: options.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
   "prices": {
    "source_day_ahead": "nordpool",
    "interval": "15min",
    "energy_taxes_consumption": {
      "2026-01-01": 0.1212
    },
    "energy_taxes_production": {
      "2026-01-01": -0.015
    },
    "cost_supplier_consumption": {
      "2026-01-01": 0.0
    },
    "cost_supplier_production": {
      "2026-01-01": 0.0
    },
    "vat_consumption": {
      "2026-01-01": 6.0
    },
    "vat_production": {
      "2026-01-01": 0.0
    },
    "multiplier_consumption": {
      "2026-01-01": 1.02
    },
    "multiplier_production": {
      "2026-01-01": 0.98
    },
    "last_invoice": "2026-09-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
Maar als ik dan de prijzen opvraag krijg ik volgende output:
Afbeeldingslocatie: https://tweakers.net/i/vB0vMmLKoxqaEdSjvYxFzxG_Rtg=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/K7xBjp1bSmkqi8iw1pwCEZov.png?f=user_large

Iemand een idee waar het foutloopt?
oscaarbasgitaar schreef op donderdag 24 september 2026 @ 13:46:
[...]

Het contract van Ecopower is met kwartierwaarden, dit is mijn code:
YAML: options.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
   "prices": {
    "source_day_ahead": "nordpool",
    "interval": "15min",
    "energy_taxes_consumption": {
      "2026-01-01": 0.1212
    },
    "energy_taxes_production": {
      "2026-01-01": -0.015
    },
    "cost_supplier_consumption": {
      "2026-01-01": 0.0
    },
    "cost_supplier_production": {
      "2026-01-01": 0.0
    },
    "vat_consumption": {
      "2026-01-01": 6.0
    },
    "vat_production": {
      "2026-01-01": 0.0
    },
    "multiplier_consumption": {
      "2026-01-01": 1.02
    },
    "multiplier_production": {
      "2026-01-01": 0.98
    },
    "last_invoice": "2026-09-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
Maar als ik dan de prijzen opvraag krijg ik volgende output:
[Afbeelding]

Iemand een idee waar het foutloopt?
"interval" hoort niet onder prices, maar is een basisinstelling.

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


  • oscaarbasgitaar
  • Registratie: Januari 2026
  • Laatst online: 00:20
dom van me, inderdaad, het staat letterlijk een paar regels lager |:(

Enfin, we zullen er nog wel even mee zoet zijn, maar alvast bedankt voor al je moeite @KC27 !
Met de stijgende energieprijzen is dit als HA-noob alle gevloek wel waard

  • balk
  • Registratie: Januari 2000
  • Laatst online: 21:08
edterbak schreef op woensdag 23 september 2026 @ 20:19:
Hoi allen,

Ik heb een 3tal marstek batterijen. Het belangrijkste vind ik eigen zonnestroom gebruiken. Maar de aankomende periode wordt dat lastig uiteraard als de zon minder aanwezig is.
Ik heb DAO ingesteld op "minimize consumption".

Ik heb deze week veel tijd gestoken om helpers te maken in home assistant en de DAO hier aan te verbinden. Zo kan ik nu eerst even zien wat DAO doet, zonder daarbij definitief de controle daadwerkelijk te geven.
Ik heb nu per batterij deze helper:
  • input_datetime.dao_batterij_18cedf99179d_stop_inverter_datetime
  • input_number.dao_batterij_18cedf99179d_set_power
  • input_select.dao_batterij_18cedf99179d_set_operating_mode
Ook heb ik 1 globale helper
  • input_boolean.dao_batterij_global_balance_switch
Mijn usecase story (wat vast niet voor het eerst beschreven wordt) is als volgt:
  • Basis modus = NoM
  • Als er zonnestroom is, batterij vullen met dat uiteraard
  • Als er onvoldoende zon is, batterij vullen met goedkope stroom.
De config van de batterijen ziet er zo uit:


[...]

Nu zie ik dit in Home assistant:
[Afbeelding]

Het valt mij op dat DAO nogal vaak de batterij aanstuurt en vrijgeeft. (bovenstaande afbeelding, links)
In DAO is de grafiek als volgt:
[Afbeelding]
Klik om te vergroten...

Ik hoop eigenlijk te zien dat DAO op enkele momenten de regie pakt over de batterij.
Dat gebeurt nu te vaak. 11x vandaag. Dat lijkt dus niet op wat ik graag wil.

Maar ik heb het gevoel dat ik er bijna ben, ik weet alleen niet waar ik het moet zoeken.
is het de stroomprijs, de laadcyclus kosten, iets anders.
Ik zou een beetje sturing van experts hier kunnen gebruiken voordat ik het in mijn eentje in de soep weet te draaien :)
Zie ik het goed dat DAO soms tegelijk accu in en uit dirigeert? Dus dat de ene accu leegloopt en de ander vult? Jouw E1 en E2 zijn hetzelfde? Die zou je al logisch kunnen koppelen. Meer accus geeft heel veel meer opties en dus ook meer kans op gekkigheden in de berekening.

Jouw "A" accu is anders. Ik weet niet hoe je die er bij kan voegen zodat je voor DAO nog maar 1 accu hebt? Misschien de capaciteiten optellen, en vermogens. En als DAO dan zegt: ontlaad met 5kW naar rato ontladen?
==edit==
ik zie ook dat E1 en E2 niet dezelfde charge efficiencies hebben. En dat je discharge efficiency erg hoog is. Klopt die wel?

[ Voor 3% gewijzigd door balk op 24-09-2026 21:37 ]


  • edterbak
  • Registratie: Maart 2006
  • Laatst online: 02:57
balk schreef op donderdag 24 september 2026 @ 21:20:
[...]

Zie ik het goed dat DAO soms tegelijk accu in en uit dirigeert? Dus dat de ene accu leegloopt en de ander vult? Jouw E1 en E2 zijn hetzelfde? Die zou je al logisch kunnen koppelen. Meer accus geeft heel veel meer opties en dus ook meer kans op gekkigheden in de berekening.
Ja, je hebt gelijk. Laden/ontladen tegelijk bij de ene of de ander.
Ik heb intussen het verdienmodel aangepast van minimize consumption naar minimize cost. Dit geeft al een wat beter beeld.

Het zijn 2x een Marstek venus E en 1x een marstek venus A.
Je adviseert dus om:
Een template sensor de batterij SoC samen te voegen.
Een number_input voor het gezamelijke vermogen +/-(2500+2500+1500W) dat DAO vraagt te laden/ontladen.
Op zich kan dat wel idd, maar dan verlies ik wel de veiligheidsmarge van 17A per batterij/fase. Dat kan ik elders wel oplossen.
Jouw "A" accu is anders. Ik weet niet hoe je die er bij kan voegen zodat je voor DAO nog maar 1 accu hebt? Misschien de capaciteiten optellen, en vermogens. En als DAO dan zegt: ontlaad met 5kW naar rato ontladen?
==edit==
ik zie ook dat E1 en E2 niet dezelfde charge efficiencies hebben. En dat je discharge efficiency erg hoog is. Klopt die wel?
Klopt ja, goed gezien. ik zal dat recht trekken.
het zijn simpele marstek batterijen. Ik heb niet echt een goed idee wat het hoort te zijn als ik eerlijk ben.

  • balk
  • Registratie: Januari 2000
  • Laatst online: 21:08
edterbak schreef op donderdag 24 september 2026 @ 22:06:
[...]


Ja, je hebt gelijk. Laden/ontladen tegelijk bij de ene of de ander.
Ik heb intussen het verdienmodel aangepast van minimize consumption naar minimize cost. Dit geeft al een wat beter beeld.

Het zijn 2x een Marstek venus E en 1x een marstek venus A.
Je adviseert dus om:
Een template sensor de batterij SoC samen te voegen.
Een number_input voor het gezamelijke vermogen +/-(2500+2500+1500W) dat DAO vraagt te laden/ontladen.
Op zich kan dat wel idd, maar dan verlies ik wel de veiligheidsmarge van 17A per batterij/fase. Dat kan ik elders wel oplossen.


[...]

Klopt ja, goed gezien. ik zal dat recht trekken.
het zijn simpele marstek batterijen. Ik heb niet echt een goed idee wat het hoort te zijn als ik eerlijk ben.
Ik heb twee identieke accus (Sessy) maar er zijn vast anderen met niet-identieke accus. @KC27 heb jij een advies hoe je dat aan zou kunnen pakken? (2 dezelfde en 1 eist kleinere; de ratio capaciteit/vermogen is ook niet hetzelfde)

Is er in het Marstek topic geen efficiency tabel te vinden?

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 23:00
edterbak schreef op donderdag 24 september 2026 @ 22:06:
[...]


Ja, je hebt gelijk. Laden/ontladen tegelijk bij de ene of de ander.
Ik heb intussen het verdienmodel aangepast van minimize consumption naar minimize cost. Dit geeft al een wat beter beeld.

Het zijn 2x een Marstek venus E en 1x een marstek venus A.
Je adviseert dus om:
Een template sensor de batterij SoC samen te voegen.
Een number_input voor het gezamelijke vermogen +/-(2500+2500+1500W) dat DAO vraagt te laden/ontladen.
Op zich kan dat wel idd, maar dan verlies ik wel de veiligheidsmarge van 17A per batterij/fase. Dat kan ik elders wel oplossen.


[...]

Klopt ja, goed gezien. ik zal dat recht trekken.
het zijn simpele marstek batterijen. Ik heb niet echt een goed idee wat het hoort te zijn als ik eerlijk ben.
ik heb ook 3 sets batterijen maar dan van Zendure
om de drie batterijen als 1 totaal te zien gebruik ik de @gast777 proxy

zie de logica hier: https://github.com/gast77...xy/blob/main/README.nl.md

Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal


  • edterbak
  • Registratie: Maart 2006
  • Laatst online: 02:57
balk schreef op donderdag 24 september 2026 @ 22:12:
[...]

Ik heb twee identieke accus (Sessy) maar er zijn vast anderen met niet-identieke accus. @KC27 heb jij een advies hoe je dat aan zou kunnen pakken? (2 dezelfde en 1 eist kleinere; de ratio capaciteit/vermogen is ook niet hetzelfde)

Is er in het Marstek topic geen efficiency tabel te vinden?
Exacte efficiencies, dat is finetuning. Ik heb nu er zojuist iets ingezet wat ai mij verteld heeft. Voor nu niet het belangrijkste denk ik.

Ik ben eigenlijk vooral benieuwd hoe de intended use is in deze situatie. Meerdere wegen naar Rome, maar welke heeft de voorkeur (en waarom) :)

edit
het ziet er nu al beter uit:
Afbeeldingslocatie: https://tweakers.net/i/TqQffJKkhQNNdJsNgvQW2pQBKVs=/232x232/filters:strip_exif()/f/image/IvF1g8Uv4Xs8UZR6puodnbwa.png?f=fotoalbum_tile
Dit lijkt beter, met "strategy": "minimize cost"

[ Voor 25% gewijzigd door edterbak op 24-09-2026 22:38 ]


  • thomvh
  • Registratie: September 2013
  • Laatst online: 28-09 15:03
Toch de keuze gemaakt om over te stappen naar Zonneplan van Tibber. De zonnebonus die lijkt alleen nog steeds niet goed mogelijk te zijn in DAO omdat het alleen tussen zons opgang en zons ondergang werkt natuurlijk. Of mis ik iets? Want de multiplier zou het altijd toepassen, wat natuurlijk niet correct is.

  • KVan
  • Registratie: April 2015
  • Laatst online: 19:06
Errors in machine berekening.
Ik heb een machine gedefinieerd die succesvol mijn vaatwasser gestuurd heeft, de laatste keer dat dit goed ging was op 24/9, daarna krijg ik volgende errors in berekening ZONDER debug:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
2026-09-27 12:29:55 info: Cycle cost BMS: 0.57 euro
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4236, in calc_optimum
    self.set_entity_option(
    ~~~~~~~~~~~~~~~~~~~~~~^
        "entity set operating mode", self.battery_options[b], new_state
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/root/dao/prog/da_base.py", line 526, in set_entity_option
    self.select_option(entity_id, value)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/services.py", line 49, in select_option
    return self.call_service("select_option", entity_id=entity_id, option=option)
           ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/services.py", line 28, in call_service
    self._post(
    ~~~~~~~~~~^
        endpoint=f"/services/{domain}/{service}",
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        entity_id=entity_id,
        ^^^^^^^^^^^^^^^^^^^^
        **kwargs,  # type: ignore
        ^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py", line 68, in _post
    return self._process_response(
           ~~~~~~~~~~~~~~~~~~~~~~^
        requests.post(
        ^^^^^^^^^^^^^^
    ...<5 lines>...
        )
        ^
    )
    ^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(
    ^^^^^^^^^^^^
        f"{status_code} status code returned from {url}",
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )  # type: ignore
    ^
hassapi.exceptions.InternalServerError: 500 status code returned from http://supervisor/core/api/services/input_select/select_option
2026-09-27 12:29:55 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 5154, in <module>
2026-09-27 12:29:55 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 5123, in main
2026-09-27 12:29:55 fout: File: /root/dao/prog/da_base.py, line 728, in run_task_function
2026-09-27 12:29:55 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 4478, in calc_optimum
2026-09-27 12:29:55 fout: File: /root/dao/prog/da_base.py, line 526, in set_entity_option
2026-09-27 12:29:55 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/services.py, line 49, in select_option
2026-09-27 12:29:55 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/services.py, line 28, in call_service
2026-09-27 12:29:55 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 68, in _post
2026-09-27 12:29:55 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 90, in _process_response
2026-09-27 12:29:55 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 95, in _raise_error
2026-09-27 12:29:55 fout: Onverwachte fout: 500 status code returned from http://supervisor/core/api/services/input_select/select_option
Het machine blok in ziet er als volgt uit:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  "machines" : [ 
    {
    "name" : "Vaatwas",
    "programs" : [
      {"name": "Uit", "power": []},
      {"name": "Auto", "power": [300, 2000, 200, 200, 200, 200, 200, 200, 1000, 500]},
      {"name": "Intensief 70°", "power": [300, 2000, 200, 200, 200, 200, 200, 200, 200, 200, 1000, 500]},
      {"name": "Speed 60°", "power": [300, 2000, 200, 1000]},
      {"name": "Voorspoelen", "power": [200, 200]}
    ],
    "entity start window": "input_datetime.dao_wasmachine_start_window",
    "entity end window": "input_datetime.dao_wasmachine_end_window",
    "entity selected program": "input_select.dao_wasmachine_programma",
    "entity calculated start": "input_datetime.dao_wasmachine_calculated_start",
    "entity calculated end": "input_datetime.dao_wasmachine_calculated_end"
    }
  ],
Zonder het machine blok zijn er geen errors. Ook werkt de rest van de sturing wel gewoon nog verder. De inputs heb ik geverifieerd, die staan in Home Assistant.

De begin en eind tijden worden niet gezet (en dus lopen de automatiseringen niet).

  • Knielen
  • Registratie: December 2009
  • Laatst online: 21:18
@KVan een wilde gok, maar haal die graden tekentjes eens weg uit je programma namen, werkt het dan wel?
@KVan
Zoals @Knielen ook zegt: de fout zit in de input_select, hij krijgt niet een goede "optie" terug.

[ Voor 15% gewijzigd door KC27 op 27-09-2026 14:04 ]

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


  • KVan
  • Registratie: April 2015
  • Laatst online: 19:06
Knielen schreef op zondag 27 september 2026 @ 14:00:
@KVan een wilde gok, maar haal die graden tekentjes eens weg uit je programma namen, werkt het dan wel?
Het graden tekentje weghalen levert nog steeds dezelfde foutmelding op (heb het ook in de input selector in HA weggehaald).

Eerden in de config is duidelijk dat hij wel de input_select gelezen heeft (zowel voor als na het weghalen van de graden tekens zag hij het auto programma geselecteerd staan:
Apparaat Vaatwas met programma 'Auto' wordt ingepland tussen 2026-09-27 14:09 en 2026-09-27 23:32.
Pagina: 1 ... 49 50 Laatste