• thomvh
  • Registratie: September 2013
  • Laatst online: 00:12
Frankvbr schreef op vrijdag 24 juli 2026 @ 18:54:
[...]

Eens in de grafiek. Maar de helper wordt niet gevoed met een negatief getal. Ook al heeft die gewoon een range van -2500 tot 2500
Hij doet het wel goed. Je batterij is leeg. Zie helemaal links op de grafiek. Hij wil dus bijladen om die 12% te komen die je hebt ingesteld.

De feedin verander alleen als je ook de berekening laat doen. Dus pas wanneer de scheduler de berekening draait om idk 22 uur de volgende dag zul je die waarde negatief zien.

[ Voor 19% gewijzigd door thomvh op 24-07-2026 21:53 ]


  • The Source
  • Registratie: April 2000
  • Laatst online: 22:24
Ik heb mijn batterij in DAO en ben nu mijn EVCC laadpaal aan het toevoegen. Probleem: Op dit moment gaat EVCC laden zodra mijn batterij aan het net begint terug te leveren, EVCC denkt solar beschikbaar :) . Nu kan ik dit makkelijk in het script stoppen, echter... kan DAO plannen dat de EV uit de batterij opgeladen moet worden? Of komt dat nooit voor?

Ik zit hier denk ik een beetje in dubio wie controle heeft over de laadpaal, DAO of EVCC... Enige praktijk tips (en automations ! ) zijn uiteraard welkom!

[ Voor 25% gewijzigd door The Source op 27-07-2026 21:13 ]


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
The Source schreef op maandag 27 juli 2026 @ 21:11:
Ik heb mijn batterij in DAO en ben nu mijn EVCC laadpaal aan het toevoegen. Probleem: Op dit moment gaat EVCC laden zodra mijn batterij aan het net begint terug te leveren, EVCC denkt solar beschikbaar :) . Nu kan ik dit makkelijk in het script stoppen, echter... kan DAO plannen dat de EV uit de batterij opgeladen moet worden? Of komt dat nooit voor?

Ik zit hier denk ik een beetje in dubio wie controle heeft over de laadpaal, DAO of EVCC... Enige praktijk tips (en automations ! ) zijn uiteraard welkom!
Als je jouw batterij ook in EVCC zet kan je instellen of je wel/niet vanuit je thuisbatterij wil laden. Dan is het toch opgelost? Ik gebruik EVCC voor het laden van mijn auto en DAO voor het aansturen van mijn thuisbatterij en heb hier nooit problemen mee.

Technisch gezien heb ik wel een fallback automation in HomeAssistant die ervoor zorgt dat de batterij niet kan ontladen als mijn auto laadt (mocht dat op hetzelfde tijdstip gepland worden).

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

Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc1

Dit staat in de changelog:

This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  2. @Dogooder has investigated and improved the mip-calculation of the ev-model of DAO. He also have build a test-suite for the ev-module under certain stress-circumstances.
I thank both contributors for their great efforts!!

The other changes in this release:
- when "stop_inverter" is not configured the calculated bat-power is now spread out over the hole interval.
- correct stop_omvormer when feedin > 0.0 (suggested by @Dogooder )
- correct index error with reduce_power_low_soc and reduce_power_high_soc
- added multithread so it uses all available cores during mip-calculation (thanks @Dogooder)
- correct baseload calculation for machine usage (thanks @gijs)
- updates of several used python modules

Je vindt de bijdrage van@storeman in het dashboard onder de optie "UI V2" (op je mobiel moet je misschien je scherm even draaien).
Dit is "work in progress". Er zitten nog een paar foutjes in (zoals bovenstaande), maar het geeft een goed indicatie welke kant het opgaat met het dashboard.
Graag testen en geef hier je commentaar: wat vind je leuk, fijn, slecht en wat moet/mag anders?

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


  • DaBit
  • Registratie: Januari 2000
  • Laatst online: 09-08 20:28
Icoontjes lijken niet te werken bij mij (er vanuit gaande dat daar icoontjes moesten komen)

Grafiek is 'dark mode', UI niet (van die grafieken ooit iets met apexcharts ofzo maken zou best een leuke verbetering zijn trouwens. Bij Reports is dat al wel gedaan dus het zal nog wel komen).

Afbeeldingslocatie: https://tweakers.net/i/4tCYs48tqdPpYVuusxIzMy-tK2U=/800x/filters:strip_exif()/f/image/TIWZDUboNw21zae91LDHKmTO.png?f=fotoalbum_large

Update tibber kan opzich best weg als je geen Tibber gebruikt.

Misschien hier geen 'Run' van maken maar 'Tasks'? Dan kun je daar ook eventuele toekomstige taken die niet direct 'run' zijn in kwijt. En als we toch aan het copuleren zijn met kleine ijverige beestjes: misschien is 'Execute' een betere term dan 'Run'?

Afbeeldingslocatie: https://tweakers.net/i/W6lfkzOOF8jmRWKmY4bXKSqNjYA=/800x/filters:strip_exif()/f/image/U1FmZYotijLWWk4IYPIhgGg5.png?f=fotoalbum_largeHet is goed werk in ieder geval!

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 14-08 18:41
Mirabis schreef op maandag 27 juli 2026 @ 22:07:
[...]

Als je jouw batterij ook in EVCC zet kan je instellen of je wel/niet vanuit je thuisbatterij wil laden. Dan is het toch opgelost? Ik gebruik EVCC voor het laden van mijn auto en DAO voor het aansturen van mijn thuisbatterij en heb hier nooit problemen mee.

Technisch gezien heb ik wel een fallback automation in HomeAssistant die ervoor zorgt dat de batterij niet kan ontladen als mijn auto laadt (mocht dat op hetzelfde tijdstip gepland worden).
Samen met @hemertje heb ik in de Wiki wat extra voorbeeld automations rond om dit thema toegevoegd.. Misschien helpt dit je nog een stapje verder Potentieel Conflict Battery + Electric Vehicle

Aanvullingen, suggesties, etc. blijven van harte welkom.

  • Mirabis
  • Registratie: Juli 2013
  • Niet online
KC27 schreef op maandag 27 juli 2026 @ 23:45:
Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc1

Dit staat in de changelog:

This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  2. @Dogooder has investigated and improved the mip-calculation of the ev-model of DAO. He also have build a test-suite for the ev-module under certain stress-circumstances.
I thank both contributors for their great efforts!!

The other changes in this release:
- when "stop_inverter" is not configured the calculated bat-power is now spread out over the hole interval.
- correct stop_omvormer when feedin > 0.0 (suggested by @Dogooder )
- correct index error with reduce_power_low_soc and reduce_power_high_soc
- added multithread so it uses all available cores during mip-calculation (thanks @Dogooder)
- correct baseload calculation for machine usage (thanks @gijs)
- updates of several used python modules

Je vindt de bijdrage van@storeman in het dashboard onder de optie "UI V2" (op je mobiel moet je misschien je scherm even draaien).
Dit is "work in progress". Er zitten nog een paar foutjes in (zoals bovenstaande), maar het geeft een goed indicatie welke kant het opgaat met het dashboard.
Graag testen en geef hier je commentaar: wat vind je leuk, fijn, slecht en wat moet/mag anders?
Proxmox LXC met docker geupdatet van 2026.6.0.rc1 naar 2026.7.0.rc1 geeft
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
2026-07-28 13:21:38 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'

2026-07-28 13:21:38 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 384, in calc_optimum
    model = Model()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/model.py", line 107, in __init__
    self.solver = mip.cbc.SolverCbc(self, name, sense)
                  ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/cbc.py", line 637, in __init__
    self._model = cbclib.Cbc_newModel()
                  ^^^^^^
NameError: name 'cbclib' is not defined
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 5007, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4980, in main
    da_calc.run_task_function("calc_optimum")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 384, in calc_optimum
    model = Model()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/model.py", line 107, in __init__
    self.solver = mip.cbc.SolverCbc(self, name, sense)
                  ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/cbc.py", line 637, in __init__
    self._model = cbclib.Cbc_newModel()
                  ^^^^^^
NameError: name 'cbclib' is not defined
Exception ignored in: <function SolverCbc.__del__ at 0x75eb9046cc20>
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/cbc.py", line 1642, in __del__
    cbclib.Cbc_deleteModel(self._model)
NameError: name 'cbclib' is not defined
Lijkt gerelateerd aan https://github.com/corneel27/day-ahead/pull/410

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


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

Dogooder

dus...

Mirabis schreef op dinsdag 28 juli 2026 @ 13:25:
[...]

Proxmox LXC met docker geupdatet van 2026.6.0.rc1 naar 2026.7.0.rc1 geeft


[...]

Lijkt gerelateerd aan https://github.com/corneel27/day-ahead/pull/410
Interessant, ik heb ook net mijn docker in lxc in proxmox geupdate naar 2026.7.0.rc1 maar ik heb dit niet.

Ik maak gebruik van dao-amd64:2026.7.0.rc1

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 14-08 18:41
KC27 schreef op maandag 27 juli 2026 @ 23:45:
Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc1

Dit staat in de changelog:

This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  2. @Dogooder has investigated and improved the mip-calculation of the ev-model of DAO. He also have build a test-suite for the ev-module under certain stress-circumstances.
I thank both contributors for their great efforts!!

The other changes in this release:
- when "stop_inverter" is not configured the calculated bat-power is now spread out over the hole interval.
- correct stop_omvormer when feedin > 0.0 (suggested by @Dogooder )
- correct index error with reduce_power_low_soc and reduce_power_high_soc
- added multithread so it uses all available cores during mip-calculation (thanks @Dogooder)
- correct baseload calculation for machine usage (thanks @gijs)
- updates of several used python modules

Je vindt de bijdrage van@storeman in het dashboard onder de optie "UI V2" (op je mobiel moet je misschien je scherm even draaien).
Dit is "work in progress". Er zitten nog een paar foutjes in (zoals bovenstaande), maar het geeft een goed indicatie welke kant het opgaat met het dashboard.
Graag testen en geef hier je commentaar: wat vind je leuk, fijn, slecht en wat moet/mag anders?
@KC27 , ik zie dat je, naast de dingen uit de change log, ook het EV laadgedrag dat ik in deze post had beschreven hebt verbeterd. Dank daarvoor.
Alles werkt nu zoals verwacht. Het valt me op dat er nu geen kleine stage factoren (0.0001) meer worden aangemaakt. Ook zie ik geen situaties meer waarbij meerdere laadstappen (b.v. 8A en 14A) tegelijk actief zijn. Uit het commentaar in de code begrijp ik dat dit komt door de introductie van een nieuwe exclusiviteits constraint. Mocht deze situaties onverhoopt toch nog een keer voorkomen dan worden beide zaken nu prima afgevangen. Super.
Daarnaast is ook de stop_laden logica aangepast aan de duur van het actieve interval. Zelf dacht ik hier naast de minuten ook de seconden (strftime("%Y-%m-%d %H:%M:%S")) nog nodig te hebben. Maar bij nader inzien verwacht ik dat de meeste gebruikers die 15min intervallen gebruiken het EV laden niet zullen gaan stoppen gedurende zo'n kort interval. Dus die seconden mogen met een gerust hart achterwege blijven.

Tenslotte kan ik bevestigen dat ook de "correct index error with reduce_power_low_soc and reduce_power_high_soc" waar ik eerder tegenaan liep nu is opgelost.

Nogmaals dank !!

  • balk
  • Registratie: Januari 2000
  • Laatst online: 14-08 16:06
@storeman mooi werk! Wat observaties van mijn kant
  • Ik doe een "Calc Optimize Debug" met missende data. Dat geeft keurig een groene balk met "optimize_debug: done, Started: 2026-07-28 17:01:50 || 4 seconds". Groen suggereert goed, en er zijn ook geen logs. Op de logs pagina zie ik wel een foutmelding. Hier kan nog wat gestroomlijnd worden
  • Icoontjes doen het bij mij wel
  • Reports V2 is nice!
  • ophalen Day Ahead prices heeft niet de mogelijkheid om datum op te geven. Na ophalen prijzen krijg ik dit in de log:
    2026-07-28 17:12:15 info: Day Ahead Optimalisatie gestart: 28-07-2026 17:12:15 taak: get_day_ahead_prices
    2026-07-28 17:12:15 info: Day ahead data already present

    en dan een debug run:
    2026-07-28 17:13:03 info: Day Ahead Optimalisering versie: 2026.7.0.rc1
    2026-07-28 17:13:03 info: Day Ahead Optimalisering gestart op: 28-07-2026 17:13:03
    2026-07-28 17:13:03 info: Day Ahead Optimalisatie gestart: 28-07-2026 17:13:03 taak: calc_optimum_met_debug
    2026-07-28 17:13:03 info: Debug = True
    2026-07-28 17:13:03 fout: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken

  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
Dank voor de feedback zover. Ik ga proberen om een en ander vanavond op te pakken.

@balk welke datum zou je dan willen/moeten opgeven?

@DaBit om de grafieken van de runs interactief te maken, is er veel werk te verzetten. Dan moeten alle data punten opgeslagen worden in de database en gekoppeld aan een run worden. Ik zie hier zeker meerwaarde, maar daar zullen wel een paar iteraties overheen gaan. Ik denk wel dat het wat data problemen uit de Reports V2 kan tackelen. Prognosewaardes lopen hier soms vreemd uit de pas, wat zou kunnen komen door een soort 'voortschrijdend inzicht' welke elk kwartier/uur er is.

"Chaos kan niet uit de hand lopen"


  • balk
  • Registratie: Januari 2000
  • Laatst online: 14-08 16:06
storeman schreef op dinsdag 28 juli 2026 @ 17:27:
Dank voor de feedback zover. Ik ga proberen om een en ander vanavond op te pakken.

@balk welke datum zou je dan willen/moeten opgeven?

@DaBit om de grafieken van de runs interactief te maken, is er veel werk te verzetten. Dan moeten alle data punten opgeslagen worden in de database en gekoppeld aan een run worden. Ik zie hier zeker meerwaarde, maar daar zullen wel een paar iteraties overheen gaan. Ik denk wel dat het wat data problemen uit de Reports V2 kan tackelen. Prognosewaardes lopen hier soms vreemd uit de pas, wat zou kunnen komen door een soort 'voortschrijdend inzicht' welke elk kwartier/uur er is.
De data voor vandaag mist in de SQLite database. Morgen zit er wel in. Ik heb deze test-app normaal uit staan en dus wordt er normaal geen data opgehaald. Bij een run gaat het dan fout (vanzelfsprekend).
tomvandepoel3 schreef op dinsdag 28 juli 2026 @ 15:42:
[...]


@KC27 , ik zie dat je, naast de dingen uit de change log, ook het EV laadgedrag dat ik in deze post had beschreven hebt verbeterd. Dank daarvoor.
Alles werkt nu zoals verwacht. Het valt me op dat er nu geen kleine stage factoren (0.0001) meer worden aangemaakt. Ook zie ik geen situaties meer waarbij meerdere laadstappen (b.v. 8A en 14A) tegelijk actief zijn. Uit het commentaar in de code begrijp ik dat dit komt door de introductie van een nieuwe exclusiviteits constraint. Mocht deze situaties onverhoopt toch nog een keer voorkomen dan worden beide zaken nu prima afgevangen. Super.
Daarnaast is ook de stop_laden logica aangepast aan de duur van het actieve interval. Zelf dacht ik hier naast de minuten ook de seconden (strftime("%Y-%m-%d %H:%M:%S")) nog nodig te hebben. Maar bij nader inzien verwacht ik dat de meeste gebruikers die 15min intervallen gebruiken het EV laden niet zullen gaan stoppen gedurende zo'n kort interval. Dus die seconden mogen met een gerust hart achterwege blijven.

Tenslotte kan ik bevestigen dat ook de "correct index error with reduce_power_low_soc and reduce_power_high_soc" waar ik eerder tegenaan liep nu is opgelost.

Nogmaals dank !!
Blij dat het allemaal beter werkt!
Het meeste rewrite-work van de ev-module is gedaan door @Dogooder , dus alle credits voor hem.

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 21:45

wmc

Ik kom interessant gedrag tegen het instellen van een vermogenslimiet als functie van de SOC. Het gedrag dat ik wil instelllen is:

SOC <= 94% P = 7200W
SOC>95% P=1800W

Zoals in de wiki nu interpreteer wordt er geëxtrapoleerd voorbij de ingestelde SOC waarde, oftewel, de helling die ik nu instel is (7200-1800) = 5400 W / % SOC, wat betekent dat er effectief boven de 95% SOC niet geladen wordt. Ik heb daarom een extra punt toegevoegd op 100% SOC, dat hetzelfde vermogen geeft als SOC 95%. De instelling die ik daarvoor heb gezet is:
code:
1
2
3
4
5
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800},
        { "soc": 100, "power": 1800}],
Dit levert hetvolgende gedrag op:

Afbeeldingslocatie: https://tweakers.net/i/RDkEFWlbSX_ShEwMkkLDXtGmHss=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/zpLFD2LObWtztG2WnRwOwAIK.png?f=user_large

Als ik de 100% SOC weghaal en dus de volgende instelling gebruik
code:
1
2
3
4
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800}],
krijg ik hetvolgende gedrag.

Afbeeldingslocatie: https://tweakers.net/i/LWPP35ruNAlDsK-8Z374eq0KVxU=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/CoJ0JC1Vil6uyheoKGrvxLLy.png?f=user_large


Waar zit mijn denkfout? Het lijkt er namelijk op dat met de eerste instelling het totale vermogen wordt beperkt op 1800W voor het hele SOC bereik.

  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
balk schreef op dinsdag 28 juli 2026 @ 19:00:
[...]

De data voor vandaag mist in de SQLite database. Morgen zit er wel in. Ik heb deze test-app normaal uit staan en dus wordt er normaal geen data opgehaald. Bij een run gaat het dan fout (vanzelfsprekend).
Ik heb dit net geprobeerd te reproduceren. Als ik de day-ahead data ophaal (zonder datums op te geven), dan wordt de data van vandaag (en morgen indien beschikbaar) gewoon opgehaald. Aan de run-logica zelf is niets gewijzigd. Het enige wat ik kan bedenken is dat bij het opgeven van datums, dat er geforceerd wordt opgehaald?

[ Voor 17% gewijzigd door storeman op 29-07-2026 10:10 ]

"Chaos kan niet uit de hand lopen"


  • balk
  • Registratie: Januari 2000
  • Laatst online: 14-08 16:06
storeman schreef op woensdag 29 juli 2026 @ 10:09:
[...]

Ik heb dit net geprobeerd te reproduceren. Als ik de day-ahead data ophaal (zonder datums op te geven), dan wordt de data van vandaag (en morgen indien beschikbaar) gewoon opgehaald. Aan de run-logica zelf is niets gewijzigd. Het enige wat ik kan bedenken is dat bij het opgeven van datums, dat er geforceerd wordt opgehaald?
@KC27 weet jij hoe dit werkt? Ik heb dit getest in de avond. Hierbij werden de prijzen van die dag niet opgehaald. @storeman heeft het zojuist getest en dan werkt het wel. Enig idee?

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 14-08 18:41
@storeman ziet er strak uit! Wat kleine observaties van mijn kant

Als je naar de laatste beschikbare Chart/Log kijkt zijn de "Next", "+6h" en "Last" buttons insensitive (logisch). Maar als je een kwartier wacht, en er dus ondertussen een nieuwe Chart/Log beschikbaar is gekomen, dan blijven deze buttons insensitive en moet je dus eerst ergens een refresh forceren voordat je de meest recente details kunt bekijken.

Bij het bekijken van de reporting charts zie ik af en toe waarschuwingen in de achtergrond langs komen (de data in mijn test database vertoont wat gaten...).
code:
1
2
/home/tom/day-ahead/dao/lib/da_graph.py:360: UserWarning: Attempting to set identical low and high ylims makes transformation singular; automatically expanding.
  ax.set_ylim([min(0, ymin_left), ymax_left])
Dit gebeurt vooral in deze situatie (waarbij ik niet snap waarom de chart leeg is):
Afbeeldingslocatie: https://tweakers.net/i/CFDF1YRHQpL_GbkQhK-qQ7goSZ0=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/rqz5lpnvgmv2PUj154oBXqRS.png?f=user_large

Nog zoiets onbelangrijks, de chart titels zijn in het Nederlands (b.v. Verbruik en kosten vandaag) terwijl de pull-down opties in het Engels zijn (b.v. Today).

Bij het bekijken van de "Last year" Grid Chart, krijg ik een reproduceerbare internal error (mijn test database zal geen data van vorig jaar bevatten...):
Afbeeldingslocatie: https://tweakers.net/i/dIqSMKWDjMMwS64CGwz5eOhkCOU=/800x/filters:strip_exif()/f/image/FepreQ4MLv1ZNfJ300kKQUvr.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/bvk11c_aHhchnFBbuH-7ncyqtr0=/800x/filters:strip_exif()/f/image/MH8qA0LVKe2XTyO4NdY134f8.png?f=fotoalbum_large

Bij de Savings tables zie ik regelmatig Not A Number (NaN) waarden voor de totalen (hierbij zijn de waarden (die waarschijnlijk ontbreken in de DB) in de tabel 0 ipv 0.000 overal elders):
Afbeeldingslocatie: https://tweakers.net/i/Y8nZLUAnLBdorj9kPVvyDX2HloM=/800x/filters:strip_exif()/f/image/rRZ3QlJvidOpbPdesWJuVmWQ.png?f=fotoalbum_large

Nogmaals enkel klein bier. Dank voor je inspanningen.

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 22:54
Ik heb de DHW-COP voor DAO dynamisch gemaakt. In plaats van een vaste COP 3.7 meet ik nu wekelijks de echte COP via de S0-meters en HeishaMon.

De thermische productie reken ik uit uit temperatuurverschil en flow, het elektrische verbruik komt van de pulsmeters.

Elke maandag wordt het weekgemiddelde bijgewerkt (75% oud, 25% nieuw) zodat de COP tbv de DHW het seizoen meebeweegt.

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
tomvandepoel3 schreef op woensdag 29 juli 2026 @ 15:37:
@storeman ziet er strak uit! Wat kleine observaties van mijn kant

Als je naar de laatste beschikbare Chart/Log kijkt zijn de "Next", "+6h" en "Last" buttons insensitive (logisch). Maar als je een kwartier wacht, en er dus ondertussen een nieuwe Chart/Log beschikbaar is gekomen, dan blijven deze buttons insensitive en moet je dus eerst ergens een refresh forceren voordat je de meest recente details kunt bekijken.

Bij het bekijken van de reporting charts zie ik af en toe waarschuwingen in de achtergrond langs komen (de data in mijn test database vertoont wat gaten...).
code:
1
2
/home/tom/day-ahead/dao/lib/da_graph.py:360: UserWarning: Attempting to set identical low and high ylims makes transformation singular; automatically expanding.
  ax.set_ylim([min(0, ymin_left), ymax_left])
Dit gebeurt vooral in deze situatie (waarbij ik niet snap waarom de chart leeg is):
[Afbeelding]

Nog zoiets onbelangrijks, de chart titels zijn in het Nederlands (b.v. Verbruik en kosten vandaag) terwijl de pull-down opties in het Engels zijn (b.v. Today).

Bij het bekijken van de "Last year" Grid Chart, krijg ik een reproduceerbare internal error (mijn test database zal geen data van vorig jaar bevatten...):
[Afbeelding]

[Afbeelding]

Bij de Savings tables zie ik regelmatig Not A Number (NaN) waarden voor de totalen (hierbij zijn de waarden (die waarschijnlijk ontbreken in de DB) in de tabel 0 ipv 0.000 overal elders):
[Afbeelding]

Nogmaals enkel klein bier. Dank voor je inspanningen.
Ik zal kijken of ik de knoppen automatisch kan enabelen bij nieuwe data. Voordeel nu is wel dat een F5 gewoon werkt zonder heraccordering van de POST. En, hoevaak zit je live naar deze output te kijken?

Qua gerenderde charts en de saving-table: werkt dit in de oude interface wel goed? Ik heb hier technisch geen wijzigingen in gemaakt. Hooguit parameters zouden incorrect doorgegeven kunnen worden. Dus hoe zie je die zaken in de oude setup?:
  • Foutmelding op achtergrond
  • Time-out data last year
  • NaN in de savings-tabel
Wat betreft namen: Nederlands en Engels lopen nog wat door elkaar. We moeten met elkaar en @KC27 afspreken wat we willen. Mijn voorkeur zou zijn alles in het Engels. Aan de andere kant is het project vooralsnog gefocused op NL/BE en wordt internationalisering niet per se eenvoudig, met alle verschillende regels.

"Chaos kan niet uit de hand lopen"


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 14-08 18:41
storeman schreef op donderdag 30 juli 2026 @ 10:23:
[...]

Ik zal kijken of ik de knoppen automatisch kan enabelen bij nieuwe data. Voordeel nu is wel dat een F5 gewoon werkt zonder heraccordering van de POST. En, hoevaak zit je live naar deze output te kijken?

Qua gerenderde charts en de saving-table: werkt dit in de oude interface wel goed? Ik heb hier technisch geen wijzigingen in gemaakt. Hooguit parameters zouden incorrect doorgegeven kunnen worden. Dus hoe zie je die zaken in de oude setup?:
  • Foutmelding op achtergrond
  • Time-out data last year
  • NaN in de savings-tabel
Wat betreft namen: Nederlands en Engels lopen nog wat door elkaar. We moeten met elkaar en @KC27 afspreken wat we willen. Mijn voorkeur zou zijn alles in het Engels. Aan de andere kant is het project vooralsnog gefocused op NL/BE en wordt internationalisering niet per se eenvoudig, met alle verschillende regels.
Zoals gezegd: allemaal klein bier.

Goede suggestie om het gedrag even te vergelijken met de oude setup (had ik natuurlijk zelf ook kunnen bedenken :( ):
- Foutmelding op de achtergrond is identiek in oude & nieuwe setup
- Time-out data last year; ook de oude setup geeft internal error
- NaN in savings-tabel; ook de oude setup geeft NaN waarden

Dus identiek gedrag
Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc2
Daarin zijn een aantal fouten in rc1 opgelost.
Dit staat er in de changelog:

A number of found issues in rc1 are fixed:
  • the combination of Instant start and a very tiny window from entity_ready_datetime from home assistant could let the CBC solver crash.
  • also the entity_ready_datetime still influenced the amount to charge at instant charge. Now it's behaving like described in the wiki.
  • support light/dark mode
  • fix legacy topnav on mobile
  • rename run to tasks
  • added date-picker on savings
  • fix error reduce_power_low_soc/reduce_power_high_soc "SocPowerLimit"

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


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
Dogooder schreef op dinsdag 28 juli 2026 @ 14:43:
[...]

Interessant, ik heb ook net mijn docker in lxc in proxmox geupdate naar 2026.7.0.rc1 maar ik heb dit niet.

Ik maak gebruik van dao-amd64:2026.7.0.rc1
Hmm vreemd ik heb het ook op 2026.7.0.rc2. Zou je wat over je Proxmox omgeving willen delen? Mijn omgeving:
code:
1
2
3
4
5
i5-13500 (20x 13th Gen Intel (R) Core
Kernel Linux 7.0.14-5-pve (2026-07-14T12:32Z)
Boot Manager EFI
Proxmox Manager Version pve-manager/9.2.5/20242970da7fbcef
LXC 14 CPUs / 8GB Mem / 2GB Swap / 60GB Bootdisk / Privileged

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
@Mirabis Kun je eens de exacte docker compose configuratie delen? Er is wel een en ander gewijzigd in de image build (multi-staged). Maar aangezien ik in ieder geval iets van 5 werkende situaties zie in dit draadje met RC1/2, moeten we goed naar de details gaan kijken.

Of heb je toevallig iets van een grafische kaart beschikbaar gesteld aan de machine/container waardoor het een wat specifiekere setup kan zijn?

"Chaos kan niet uit de hand lopen"


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
storeman schreef op donderdag 30 juli 2026 @ 21:51:
@Mirabis Kun je eens de exacte docker compose configuratie delen? Er is wel een en ander gewijzigd in de image build (multi-staged). Maar aangezien ik in ieder geval iets van 5 werkende situaties zie in dit draadje met RC1/2, moeten we goed naar de details gaan kijken.

Of heb je toevallig iets van een grafische kaart beschikbaar gesteld aan de machine/container waardoor het een wat specifiekere setup kan zijn?
Zie bijgevoegd. En nee, aan deze specifieke LXC geen /dev/dri e.d. Het draait alleen HomeAssistant + DAO
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
version: "3"
services:
  dao:
    image: ghcr.io/corneel27/dao-amd64:2026.7.0.rc2
    volumes:      
      - /root/hass_config/_data:/homeassistant
      - /root/dao_config:/config
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 5000:5000
    restart: unless-stopped
    env_file:
      - TZ=Europe/Amsterdam
PS: Ik heb het zojuist werkend gekregen door zelf de mips te compileren via exec in de container en het onderstaande toe te voegen. Waarom de defaults dan niet werken weet ik ook niet.
code:
1
2
LD_LIBRARY_PATH=/root/build/prog//lib
DYLD_LIBRARY_PATH=/root/build/prog//lib
EDIT 2: Iets te enthousiast. Krijg "geen oplsosing voor: minimize cost" met wat stack traces. Ik ga weer terug naar de laatst werkende versie. Logs van debug calc: https://pastebin.com/TkukHaSS

[ Voor 16% gewijzigd door Mirabis op 30-07-2026 22:32 ]

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


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

Dogooder

dus...

@Mirabis ik zie in je log wel dat jouw systeem 20 CBC threads opstart. Bij komt hij maar tot 2. Dat is wel een risico multiplier. CBC was orgineel single threaded.

Misschien multi threading een setting maken ipv altijd max? Of uit veiligheidsoverwegingen toch maar weer terug naar single? @KC27 jij een idee?

  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
Ik heb nog een ander vermoeden. Zou jij, @Mirabis er nog eens een nieuwe container er naast kunnen zetten? Met de testing image? Configuratie mag gewoon hetzelfde zijn (wel exclusief je env-fix), en de reguliere container stoppen.

"Chaos kan niet uit de hand lopen"


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
storeman schreef op vrijdag 31 juli 2026 @ 00:09:
Ik heb nog een ander vermoeden. Zou jij, @Mirabis er nog eens een nieuwe container er naast kunnen zetten? Met de testing image? Configuratie mag gewoon hetzelfde zijn (wel exclusief je env-fix), en de reguliere container stoppen.
Ik zal dat morgenochtend doen. Nog iets anders waar ik rekening mee moet houden? 'testing' is op moment van schrijven identiek aan 2026.7.0.rc2. Kan het gewoon naar dezelfde config e.d. wijzen of liever fresh?

Wat betreft de 20 threads, mijn LXCs hebben:
code:
1
2
Cores=blank (-> unlimited)
CPU_Limit=14

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
Mirabis schreef op vrijdag 31 juli 2026 @ 01:36:
[...]

Ik zal dat morgenochtend doen. Nog iets anders waar ik rekening mee moet houden? 'testing' is op moment van schrijven identiek aan 2026.7.0.rc2. Kan het gewoon naar dezelfde config e.d. wijzen of liever fresh?

Wat betreft de 20 threads, mijn LXCs hebben:
code:
1
2
Cores=blank (-> unlimited)
CPU_Limit=14
Dat is afhankelijk van wanneer je die cbc fout kreeg. Als het bij het starten van de container al was, dan graag fresh. Als het bij een run was, dan graag met (een kopie van) je DAO config/data map.

Proxmox kan niet direct docker containers draaien toch? (Omdat je het over LXCs hebt)

"Chaos kan niet uit de hand lopen"


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
storeman schreef op vrijdag 31 juli 2026 @ 07:34:
[...]

Dat is afhankelijk van wanneer je die cbc fout kreeg. Als het bij het starten van de container al was, dan graag fresh. Als het bij een run was, dan graag met (een kopie van) je DAO config/data map.

Proxmox kan niet direct docker containers draaien toch? (Omdat je het over LXCs hebt)
Ik heb even met Claude gekeken naar een oplossing.

1. Maak ik gebruik van eigen miplib dan krijg ik bij startup "[10:14:57] INFO: Copying saved miplib-binaries" en verder geen errors bij startup. Dus wanneer /root/dao_config/miplib bestaat in mijn mounted docker container.
2. Doe ik vervolgens een run dan krijg ik de eerder gedeelde error.
3. Als ik via de thread detectie aanpas van -1 naar 1 zijn de errors bij de runs verholpen. Het kan nogsteeds geen solution vinden maar de crashes zijn weg.
code:
1
sed -i 's/model\.threads = 1.*/model.threads = -1/' /root/dao/prog/day_ahead.py
4. Haal ik de hele /root/dao_config/miplib folder en envs weg dan krijg ik bij container start de onderstaande foutmelding mbt supervisor API dat het zoekt. Met HomeAssistant Container is er geen supervisor dus geen idee waarom het ernaar zoekt bij ontbreken van de mips folder. Zonder de folder is WebUI niet bruikbaar want dan zijn de checkboxes uitgeschakeld.
code:
1
2
3
4
5
6
7
8
9
[10:13:02] INFO: => directory dao_data exist
[10:13:02] INFO: => /root/dao/data exist
[10:13:02] INFO: => /root/dao/webserver/app/static/data exist
2026-07-31 10:13:05 INFO: Loaded 4 secrets from ../data/secrets.json
2026-07-31 10:13:05 INFO: Validating configuration with ConfigurationV2
curl: (6) Could not resolve host: supervisor
[10:13:13] ERROR: Something went wrong contacting the API
[10:13:13] ERROR: Failed to get addon config from Supervisor API
Starting scheduler...
Excuus voor het warrige verhaal... beetje tijdgebrek en heen en weer gecopy-paste. Ik zal kijken of ik van het weekend wat meer tijd heb om erin te duiken. Voor nu ben ik terug naar de stable versie.

[ Voor 5% gewijzigd door Mirabis op 31-07-2026 10:41 ]

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


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 14-08 18:41
Ik heb een nieuw hoofdstuk Notificaties voor beginnende DAO/HA gebruikers aan de Wiki pagina met voorbeelden toegevoegd.

Ik hoop dat het van waarde is.
Suggesties over zowel de structuur als de inhoud zijn wederom van harte welkom.

  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 13-08 15:02
Is er iemand die kan verklaren waarom er bij boiler_present=true soms geen oplossing gevonden kan worden ondanks dat er ook andere apparaten (meestal de batterij) gepland kunnen worden. als boiler_present op false zet dan kan hij wel een oplossing vinden.

Ik snap dat het een variabele in de reeks is, maar de boiler niet doen en de batterij wel is toch ook een oplossing (in mijn ogen dan)

Heeft iemand hier een logische verklaring voor?
of is het handig om bijvoorbeeld de hysterese te verlagen?

  • storeman
  • Registratie: April 2004
  • Laatst online: 00:20
Mirabis schreef op vrijdag 31 juli 2026 @ 10:23:
[...]

Ik heb even met Claude gekeken naar een oplossing.

1. Maak ik gebruik van eigen miplib dan krijg ik bij startup "[10:14:57] INFO: Copying saved miplib-binaries" en verder geen errors bij startup. Dus wanneer /root/dao_config/miplib bestaat in mijn mounted docker container.
2. Doe ik vervolgens een run dan krijg ik de eerder gedeelde error.
3. Als ik via de thread detectie aanpas van -1 naar 1 zijn de errors bij de runs verholpen. Het kan nogsteeds geen solution vinden maar de crashes zijn weg.
code:
1
sed -i 's/model\.threads = 1.*/model.threads = -1/' /root/dao/prog/day_ahead.py
4. Haal ik de hele /root/dao_config/miplib folder en envs weg dan krijg ik bij container start de onderstaande foutmelding mbt supervisor API dat het zoekt. Met HomeAssistant Container is er geen supervisor dus geen idee waarom het ernaar zoekt bij ontbreken van de mips folder. Zonder de folder is WebUI niet bruikbaar want dan zijn de checkboxes uitgeschakeld.
code:
1
2
3
4
5
6
7
8
9
[10:13:02] INFO: => directory dao_data exist
[10:13:02] INFO: => /root/dao/data exist
[10:13:02] INFO: => /root/dao/webserver/app/static/data exist
2026-07-31 10:13:05 INFO: Loaded 4 secrets from ../data/secrets.json
2026-07-31 10:13:05 INFO: Validating configuration with ConfigurationV2
curl: (6) Could not resolve host: supervisor
[10:13:13] ERROR: Something went wrong contacting the API
[10:13:13] ERROR: Failed to get addon config from Supervisor API
Starting scheduler...
Excuus voor het warrige verhaal... beetje tijdgebrek en heen en weer gecopy-paste. Ik zal kijken of ik van het weekend wat meer tijd heb om erin te duiken. Voor nu ben ik terug naar de stable versie.
Ik vind het moeilijk hier wat zinnigs over te zeggen en zou graag willen beginnen bij de basis: een kale, nieuwe container. Het hele idee van de containerization gaat nu een beetje onderuit, dat moet te verklaren zijn :).

Mocht de nieuwe container niet willen starten, zou je in de container dan eens kunnen doen:
apt-get update && apt-get install libnauty-2.8.9
En checken of dit de fix is?

"Chaos kan niet uit de hand lopen"

Dogooder schreef op donderdag 30 juli 2026 @ 23:58:
@Mirabis ik zie in je log wel dat jouw systeem 20 CBC threads opstart. Bij komt hij maar tot 2. Dat is wel een risico multiplier. CBC was orgineel single threaded.

Misschien multi threading een setting maken ipv altijd max? Of uit veiligheidsoverwegingen toch maar weer terug naar single? @KC27 jij een idee?
Ik vind wel dat we multi threading moeten blijven ondersteunen omdat daarmee de berekening bij veel gebruikers een stuk (geen procenten maar factoren) sneller gaat. Die snelheid hebben we straks nodig als we de"reken horizon" gaan uitbreiden met (betrouwbare) voorspellingen van de day-ahead tarieven.
Ik stel voor om er een optionele setting van te maken: default "max" of een getal tussen 1 en 20.
Wat vinden jullie daarvan?

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

Mirabis schreef op vrijdag 31 juli 2026 @ 10:23:
[...]

Ik heb even met Claude gekeken naar een oplossing.

1. Maak ik gebruik van eigen miplib dan krijg ik bij startup "[10:14:57] INFO: Copying saved miplib-binaries" en verder geen errors bij startup. Dus wanneer /root/dao_config/miplib bestaat in mijn mounted docker container.
2. Doe ik vervolgens een run dan krijg ik de eerder gedeelde error.
3. Als ik via de thread detectie aanpas van -1 naar 1 zijn de errors bij de runs verholpen. Het kan nogsteeds geen solution vinden maar de crashes zijn weg.
code:
1
sed -i 's/model\.threads = 1.*/model.threads = -1/' /root/dao/prog/day_ahead.py
4. Haal ik de hele /root/dao_config/miplib folder en envs weg dan krijg ik bij container start de onderstaande foutmelding mbt supervisor API dat het zoekt. Met HomeAssistant Container is er geen supervisor dus geen idee waarom het ernaar zoekt bij ontbreken van de mips folder. Zonder de folder is WebUI niet bruikbaar want dan zijn de checkboxes uitgeschakeld.
code:
1
2
3
4
5
6
7
8
9
[10:13:02] INFO: => directory dao_data exist
[10:13:02] INFO: => /root/dao/data exist
[10:13:02] INFO: => /root/dao/webserver/app/static/data exist
2026-07-31 10:13:05 INFO: Loaded 4 secrets from ../data/secrets.json
2026-07-31 10:13:05 INFO: Validating configuration with ConfigurationV2
curl: (6) Could not resolve host: supervisor
[10:13:13] ERROR: Something went wrong contacting the API
[10:13:13] ERROR: Failed to get addon config from Supervisor API
Starting scheduler...
Excuus voor het warrige verhaal... beetje tijdgebrek en heen en weer gecopy-paste. Ik zal kijken of ik van het weekend wat meer tijd heb om erin te duiken. Voor nu ben ik terug naar de stable versie.
Een paar opmerkingen/observaties van mijn kant:

Als je eigen gecompileerde mip-binaries gaat gebruiken dan worden tijdens de compilatie de gegenereerde binaries afgestemd op de cpu-configuratie. Als je daarna deze binaries gaat gebruiken in een gewijzigde cpu-configuratie dan zou het heel goed kunnen dat dit om deze reden fouten oplevert zoals in de gedeelde logging.

De melding
curl: (6) Could not resolve host: supervisor
duidt erop dat in je config het adres van je HA-container niet is opgenomen.
Dus neem of ip-adres of de dns-hostname van je HA-container op in de config van DAO.

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

jeroenribbink schreef op vrijdag 31 juli 2026 @ 20:58:
Is er iemand die kan verklaren waarom er bij boiler_present=true soms geen oplossing gevonden kan worden ondanks dat er ook andere apparaten (meestal de batterij) gepland kunnen worden. als boiler_present op false zet dan kan hij wel een oplossing vinden.

Ik snap dat het een variabele in de reeks is, maar de boiler niet doen en de batterij wel is toch ook een oplossing (in mijn ogen dan)

Heeft iemand hier een logische verklaring voor?
of is het handig om bijvoorbeeld de hysterese te verlagen?
Als het wel werkt als je boiler_present=false zet komt waarschijnlijk omdat er singulariteit (=ongerijmdheid) is in je actuele boiler situatie en je boiler-settings.
Kun je je boiler settings en de logging van een berekening zonder oplossing hier delen (met code en quote-tags)?

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


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
--delete--

[ Voor 98% gewijzigd door Mirabis op 01-08-2026 04:23 ]

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


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
--delete--

[ Voor 100% gewijzigd door Mirabis op 01-08-2026 04:23 ]

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


  • The Source
  • Registratie: April 2000
  • Laatst online: 22:24
jeroenribbink schreef op vrijdag 31 juli 2026 @ 20:58:
Is er iemand die kan verklaren waarom er bij boiler_present=true soms geen oplossing gevonden kan worden ondanks dat er ook andere apparaten (meestal de batterij) gepland kunnen worden. als boiler_present op false zet dan kan hij wel een oplossing vinden.

Ik snap dat het een variabele in de reeks is, maar de boiler niet doen en de batterij wel is toch ook een oplossing (in mijn ogen dan)

Heeft iemand hier een logische verklaring voor?
of is het handig om bijvoorbeeld de hysterese te verlagen?
Heel toevallig heb ik hetzelfde probleem.
Boiler = true , geen foutmelding, maar geen nieuwe grafiek op het homescherm.
Boiler = false, geen foutmelding, maar wel een nieuwe grafiek op het scherm.
Ik snap dat er geen planning voor de boiler is, deze hoeft niet opgewarmd te worden, maar ik verwacht dan welk een nieuwe planning voor mijn batterij en laadpaal.

Mijn config:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
  "boiler": {
    "boiler present": false,
    "entity actual temp.": "sensor.warmtepomp_ecodan_sww_huidige_temp",
    "entity setpoint": "sensor.warmtepomp_ecodan_sww_setpoint_waarde",
    "entity hysterese": "input_number.dao_hysterese_dhw",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 43,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "switch.ecodan_heatpump_force_dhw"
  },
waardes:
sensor.warmtepomp_ecodan_sww_huidige_temp = 54.5
sensor.warmtepomp_ecodan_sww_setpoint_waarde = 55.0
input_number.dao_hysterese_dhw = 0.0

[ Voor 9% gewijzigd door The Source op 02-08-2026 15:47 ]

The Source schreef op zondag 2 augustus 2026 @ 15:40:
[...]

Heel toevallig heb ik hetzelfde probleem.
Boiler = true , geen foutmelding, maar geen nieuwe grafiek op het homescherm.
Boiler = false, geen foutmelding, maar wel een nieuwe grafiek op het scherm.
Ik snap dat er geen planning voor de boiler is, deze hoeft niet opgewarmd te worden, maar ik verwacht dan welk een nieuwe planning voor mijn batterij en laadpaal.

Mijn config:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
  "boiler": {
    "boiler present": false,
    "entity actual temp.": "sensor.warmtepomp_ecodan_sww_huidige_temp",
    "entity setpoint": "sensor.warmtepomp_ecodan_sww_setpoint_waarde",
    "entity hysterese": "input_number.dao_hysterese_dhw",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 43,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "switch.ecodan_heatpump_force_dhw"
  },
waardes:
sensor.warmtepomp_ecodan_sww_huidige_temp = 54.5
sensor.warmtepomp_ecodan_sww_setpoint_waarde = 55.0
input_number.dao_hysterese_dhw = 0.0
Waarom heb je hysterese op 0 gezet?
Hysterese op 0 betekent dat er direct opgewarmd moet worden van 54.5 naar 55.0.
Wat staat er in de logging?

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


  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 13-08 15:02
KC27 schreef op vrijdag 31 juli 2026 @ 23:00:
[...]

Als het wel werkt als je boiler_present=false zet komt waarschijnlijk omdat er singulariteit (=ongerijmdheid) is in je actuele boiler situatie en je boiler-settings.
Kun je je boiler settings en de logging van een berekening zonder oplossing hier delen (met code en quote-tags)?
Dank voor je reactie.
je bent wel voor iedereen het zo aan het analyseren, wordt erg gewaardeerd ;)

Settings:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  "boiler": {
    "boiler_present": true,
    "entity actual temp.": "sensor.wemosd1mini_vissen_temperatuur", // 57 op het moment. dus binnen hysteres
    "entity setpoint": "input_number.dao_boiler_keuken_setpoint", // 60
    "entity hysterese": "input_number.dao_boiler_setpoint_afwijking", // 5, heb ook 10 gehad
    "entity boiler enabled": "input_boolean.dao_boiler_planning_ingeschakeld", // true
    "cop": 1,
    "cooling rate": 0.9,
    "volume": 10,
    "heating allowed below": 55,
    "elec. power": 400,
    "activate service": "turn_on",
    "activate entity": "switch.bedden"
  },
Logging:
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
2026-08-02 20:57:53 INFO: Loaded 6 secrets from ../data/secrets.json
2026-08-02 20:57:53 INFO: Validating configuration with ConfigurationV2
2026-08-02 20:57:53 info: Day Ahead Optimalisering versie: 2026.6.0
2026-08-02 20:57:53 info: Day Ahead Optimalisering gestart op: 02-08-2026 20:57:53
2026-08-02 20:57:53 info: Day Ahead Optimalisatie gestart: 02-08-2026 20:57:53 taak: calc_optimum
2026-08-02 20:57:53 info: Debug = False
2026-08-02 20:57:53 info: Baseload uit instellingen
2026-08-02 20:57:54 info: ML prediction Enphase
                   date_time  prediction
0  2026-08-02 20:00:00+02:00       0.445
1  2026-08-02 21:00:00+02:00       0.049
2  2026-08-02 22:00:00+02:00       0.048
3  2026-08-02 23:00:00+02:00       0.048
4  2026-08-03 00:00:00+02:00       0.048
5  2026-08-03 01:00:00+02:00       0.048
6  2026-08-03 02:00:00+02:00       0.000
7  2026-08-03 03:00:00+02:00       0.000
8  2026-08-03 04:00:00+02:00       0.000
9  2026-08-03 05:00:00+02:00       0.000
10 2026-08-03 06:00:00+02:00       0.057
11 2026-08-03 07:00:00+02:00       0.291
12 2026-08-03 08:00:00+02:00       0.538
13 2026-08-03 09:00:00+02:00       1.249
14 2026-08-03 10:00:00+02:00       1.269
15 2026-08-03 11:00:00+02:00       2.349
16 2026-08-03 12:00:00+02:00       3.586
17 2026-08-03 13:00:00+02:00       3.930
18 2026-08-03 14:00:00+02:00       3.817
19 2026-08-03 15:00:00+02:00       3.745
20 2026-08-03 16:00:00+02:00       3.157
21 2026-08-03 17:00:00+02:00       2.075
22 2026-08-03 18:00:00+02:00       1.471
23 2026-08-03 19:00:00+02:00       0.632
24 2026-08-03 20:00:00+02:00       0.350
25 2026-08-03 21:00:00+02:00       0.080
26 2026-08-03 22:00:00+02:00       0.063
27 2026-08-03 23:00:00+02:00       0.063
2026-08-02 20:57:54 info: Start waarden: 
       uur                tijd   spot   p_l   p_t  base  pv_ac  pv_dc
0    20:45 2026-08-02 20:45:00  0.192 0.364 0.344 0.218  0.010      0
1    21:00 2026-08-02 21:00:00  0.191 0.362 0.342 0.205  0.043      0
2    21:15 2026-08-02 21:15:00  0.182 0.350 0.330 0.195  0.018      0
3    21:30 2026-08-02 21:30:00  0.175 0.342 0.322 0.186  0.000      0
4    21:45 2026-08-02 21:45:00  0.165 0.331 0.311 0.164  0.000      0
5    22:00 2026-08-02 22:00:00  0.182 0.351 0.331 0.127  0.012      0
6    22:15 2026-08-02 22:15:00  0.169 0.335 0.315 0.105  0.012      0
7    22:30 2026-08-02 22:30:00  0.165 0.330 0.310 0.084  0.012      0
8    22:45 2026-08-02 22:45:00  0.158 0.322 0.302 0.084  0.012      0
9    23:00 2026-08-02 23:00:00  0.162 0.327 0.307 0.100  0.012      0
10   23:15 2026-08-02 23:15:00  0.156 0.320 0.300 0.100  0.012      0
11   23:30 2026-08-02 23:30:00  0.154 0.317 0.297 0.100  0.012      0
12   23:45 2026-08-02 23:45:00  0.144 0.306 0.286 0.100  0.012      0
13   00:00 2026-08-03 00:00:00  0.147 0.309 0.289 0.100  0.012      0
14   00:15 2026-08-03 00:15:00  0.143 0.304 0.284 0.100  0.012      0
15   00:30 2026-08-03 00:30:00  0.138 0.298 0.278 0.100  0.012      0
16   00:45 2026-08-03 00:45:00  0.135 0.294 0.274 0.100  0.012      0
17   01:00 2026-08-03 01:00:00  0.138 0.298 0.278 0.100  0.013      0
18   01:15 2026-08-03 01:15:00  0.135 0.294 0.274 0.100  0.013      0
19   01:30 2026-08-03 01:30:00  0.137 0.296 0.276 0.100  0.013      0
20   01:45 2026-08-03 01:45:00  0.134 0.293 0.273 0.100  0.010      0
21   02:00 2026-08-03 02:00:00  0.135 0.294 0.274 0.100  0.004      0
22   02:15 2026-08-03 02:15:00  0.133 0.292 0.272 0.100  0.001      0
23   02:30 2026-08-03 02:30:00  0.132 0.291 0.271 0.100  0.000      0
24   02:45 2026-08-03 02:45:00  0.132 0.290 0.270 0.100  0.000      0
25   03:00 2026-08-03 03:00:00  0.130 0.288 0.268 0.100  0.000      0
26   03:15 2026-08-03 03:15:00  0.129 0.287 0.267 0.100  0.000      0
27   03:30 2026-08-03 03:30:00  0.130 0.288 0.268 0.100  0.000      0
28   03:45 2026-08-03 03:45:00  0.132 0.291 0.271 0.100  0.000      0
29   04:00 2026-08-03 04:00:00  0.129 0.287 0.267 0.100  0.000      0
30   04:15 2026-08-03 04:15:00  0.132 0.290 0.270 0.100  0.000      0
31   04:30 2026-08-03 04:30:00  0.134 0.293 0.273 0.100  0.000      0
32   04:45 2026-08-03 04:45:00  0.138 0.298 0.278 0.100  0.000      0
33   05:00 2026-08-03 05:00:00  0.138 0.297 0.278 0.095  0.000      0
34   05:15 2026-08-03 05:15:00  0.142 0.302 0.282 0.095  0.000      0
35   05:30 2026-08-03 05:30:00  0.145 0.307 0.287 0.095  0.000      0
36   05:45 2026-08-03 05:45:00  0.152 0.315 0.295 0.114  0.003      0
37   06:00 2026-08-03 06:00:00  0.162 0.327 0.307 0.152  0.006      0
38   06:15 2026-08-03 06:15:00  0.170 0.336 0.316 0.170  0.010      0
39   06:30 2026-08-03 06:30:00  0.170 0.337 0.317 0.189  0.013      0
40   06:45 2026-08-03 06:45:00  0.165 0.330 0.310 0.189  0.028      0
41   07:00 2026-08-03 07:00:00  0.171 0.338 0.318 0.177  0.051      0
42   07:15 2026-08-03 07:15:00  0.166 0.332 0.312 0.177  0.065      0
43   07:30 2026-08-03 07:30:00  0.162 0.327 0.307 0.177  0.080      0
44   07:45 2026-08-03 07:45:00  0.156 0.319 0.299 0.168  0.095      0
45   08:00 2026-08-03 08:00:00  0.167 0.333 0.313 0.148  0.104      0
46   08:15 2026-08-03 08:15:00  0.157 0.321 0.301 0.139  0.120      0
47   08:30 2026-08-03 08:30:00  0.150 0.313 0.293 0.130  0.135      0
48   08:45 2026-08-03 08:45:00  0.126 0.283 0.263 0.133  0.180      0
49   09:00 2026-08-03 09:00:00  0.163 0.328 0.308 0.145  0.256      0
50   09:15 2026-08-03 09:15:00  0.135 0.294 0.274 0.148  0.301      0
51   09:30 2026-08-03 09:30:00  0.126 0.283 0.263 0.152  0.345      0
52   09:45 2026-08-03 09:45:00  0.120 0.277 0.257 0.155  0.346      0
53   10:00 2026-08-03 10:00:00  0.129 0.287 0.267 0.159  0.299      0
54   10:15 2026-08-03 10:15:00  0.117 0.272 0.253 0.162  0.300      0
55   10:30 2026-08-03 10:30:00  0.109 0.263 0.243 0.165  0.301      0
56   10:45 2026-08-03 10:45:00  0.089 0.239 0.219 0.165  0.369      0
57   11:00 2026-08-03 11:00:00  0.075 0.221 0.201 0.154  0.484      0
58   11:15 2026-08-03 11:15:00  0.037 0.176 0.156 0.154  0.551      0
59   11:30 2026-08-03 11:30:00  0.010 0.143 0.123 0.154  0.619      0
60   11:45 2026-08-03 11:45:00 -0.000 0.131 0.111 0.188  0.696      0
61   12:00 2026-08-03 12:00:00  0.031 0.168 0.148 0.257  0.795      0
62   12:15 2026-08-03 12:15:00  0.007 0.140 0.120 0.291  0.872      0
63   12:30 2026-08-03 12:30:00  0.000 0.131 0.111 0.326  0.949      0
64   12:45 2026-08-03 12:45:00  0.000 0.131 0.111 0.326  0.971      0
65   13:00 2026-08-03 13:00:00 -0.000 0.131 0.111 0.300  0.957      0
66   13:15 2026-08-03 13:15:00 -0.001 0.130 0.110 0.300  0.979      0
67   13:30 2026-08-03 13:30:00 -0.000 0.131 0.111 0.300  1.000      0
68   13:45 2026-08-03 13:45:00 -0.002 0.129 0.109 0.300  0.993      0
69   14:00 2026-08-03 14:00:00  0.000 0.131 0.111 0.295  0.964      0
70   14:15 2026-08-03 14:15:00  0.000 0.131 0.111 0.295  0.957      0
71   14:30 2026-08-03 14:30:00  0.001 0.132 0.112 0.295  0.950      0
72   14:45 2026-08-03 14:45:00  0.011 0.145 0.125 0.314  0.945      0
73   15:00 2026-08-03 15:00:00  0.001 0.132 0.112 0.339  0.951      0
74   15:15 2026-08-03 15:15:00  0.039 0.178 0.158 0.358  0.947      0
75   15:30 2026-08-03 15:30:00  0.056 0.199 0.179 0.377  0.942      0
76   15:45 2026-08-03 15:45:00  0.071 0.217 0.197 0.427  0.905      0
77   16:00 2026-08-03 16:00:00  0.088 0.238 0.218 0.513  0.852      0
78   16:15 2026-08-03 16:15:00  0.096 0.247 0.227 0.562  0.815      0
79   16:30 2026-08-03 16:30:00  0.107 0.261 0.241 0.613  0.779      0
80   16:45 2026-08-03 16:45:00  0.121 0.277 0.258 0.613  0.711      0
81   17:00 2026-08-03 17:00:00  0.117 0.273 0.253 0.592  0.613      0
82   17:15 2026-08-03 17:15:00  0.124 0.281 0.261 0.592  0.545      0
83   17:30 2026-08-03 17:30:00  0.146 0.307 0.287 0.592  0.477      0
84   17:45 2026-08-03 17:45:00  0.172 0.339 0.319 0.523  0.440      0
85   18:00 2026-08-03 18:00:00  0.150 0.312 0.292 0.391  0.428      0
86   18:15 2026-08-03 18:15:00  0.162 0.326 0.306 0.322  0.390      0
87   18:30 2026-08-03 18:30:00  0.168 0.334 0.314 0.253  0.353      0
88   18:45 2026-08-03 18:45:00  0.187 0.357 0.337 0.234  0.300      0
89   19:00 2026-08-03 19:00:00  0.173 0.340 0.320 0.248  0.228      0
90   19:15 2026-08-03 19:15:00  0.189 0.359 0.339 0.230  0.176      0
91   19:30 2026-08-03 19:30:00  0.205 0.379 0.359 0.211  0.123      0
92   19:45 2026-08-03 19:45:00  0.237 0.418 0.398 0.211  0.105      0
93   20:00 2026-08-03 20:00:00  0.200 0.373 0.353 0.227  0.114      0
94   20:15 2026-08-03 20:15:00  0.197 0.369 0.349 0.227  0.096      0
95   20:30 2026-08-03 20:30:00  0.194 0.366 0.346 0.227  0.079      0
96   20:45 2026-08-03 20:45:00  0.201 0.374 0.354 0.218  0.062      0
97   21:00 2026-08-03 21:00:00  0.198 0.370 0.350 0.205  0.041      0
98   21:15 2026-08-03 21:15:00  0.190 0.361 0.341 0.195  0.024      0
99   21:30 2026-08-03 21:30:00  0.185 0.355 0.335 0.186  0.008      0
100  21:45 2026-08-03 21:45:00  0.173 0.340 0.320 0.164  0.007      0
101  22:00 2026-08-03 22:00:00  0.185 0.354 0.334 0.127  0.017      0
102  22:15 2026-08-03 22:15:00  0.176 0.344 0.324 0.105  0.016      0
103  22:30 2026-08-03 22:30:00  0.174 0.341 0.321 0.084  0.015      0
104  22:45 2026-08-03 22:45:00  0.166 0.331 0.311 0.084  0.015      0
105  23:00 2026-08-03 23:00:00  0.167 0.333 0.313 0.100  0.016      0
106  23:15 2026-08-03 23:15:00  0.161 0.325 0.305 0.100  0.016      0
107  23:30 2026-08-03 23:30:00  0.156 0.320 0.300 0.100  0.016      0
108  23:45 2026-08-03 23:45:00  0.147 0.309 0.289 0.100  0.016      0
2026-08-02 20:57:54 info: No reduced hours applied for Marstek Venus-E
2026-08-02 20:57:54 info: No reduced power applied during discharging at low soc
2026-08-02 20:57:54 info: No reduced power applied during charging at high soc
2026-08-02 20:57:54 info: Startwaarde SoC Marstek Venus-E: 74.1%

2026-08-02 20:57:54 info: Boiler direct opwarmen staat uit
2026-08-02 20:57:54 info: Boiler setpoint 60.0 °C
2026-08-02 20:57:54 info: Boiler hysterese 5.0 K
2026-08-02 20:57:54 info: Boiler cooling rate 0.9 K/uur
2026-08-02 20:57:54 info: Boiler heating allowed below 55 °C
2026-08-02 20:57:54 info: Boiler opwarmen wordt ingepland tussen: 2026-08-02 23:00 en 2026-08-02 23:15
2026-08-02 20:57:54 info: Boiler verbruik in 1 kwartier: 0.1 kWh
2026-08-02 20:57:54 info: Prognose boiler:
                   tijd  act_temp  heat  elec  interval  cost  end_temp  end_value  netto_cost
0   2026-08-02 20:45:00    57.125 0.081 0.181         2 0.065    35.925     -0.171       0.235
1   2026-08-02 21:00:00    56.900 0.087 0.187         2 0.067    36.150     -0.169       0.236
2   2026-08-02 21:15:00    56.675 0.093 0.193         2 0.067    36.375     -0.167       0.234
3   2026-08-02 21:30:00    56.450 0.100 0.200         2 0.067    36.600     -0.165       0.233
4   2026-08-02 21:45:00    56.225 0.106 0.206         3 0.070    37.050     -0.162       0.232
5   2026-08-02 22:00:00    56.000 0.112 0.212         3 0.073    37.275     -0.160       0.233
6   2026-08-02 22:15:00    55.775 0.119 0.219         3 0.073    37.500     -0.158       0.231
7   2026-08-02 22:30:00    55.550 0.125 0.225         3 0.073    37.725     -0.156       0.230
8   2026-08-02 22:45:00    55.325 0.131 0.231         3 0.075    37.950     -0.154       0.229
9   2026-08-02 23:00:00    55.100 0.138 0.238         3 0.077    38.175     -0.153       0.229
10  2026-08-02 23:15:00    54.875 0.144 0.244         3 0.077    38.400     -0.151       0.228
11  2026-08-02 23:30:00    54.650 0.150 0.250         3 0.078    38.625     -0.149       0.227
12  2026-08-02 23:45:00    54.425 0.157 0.257         3 0.079    38.850     -0.147       0.226
13  2026-08-03 00:00:00    54.200 0.163 0.263         3 0.080    39.075     -0.145       0.225
14  2026-08-03 00:15:00    53.975 0.169 0.269         3 0.081    39.300     -0.144       0.224
15  2026-08-03 00:30:00    53.750 0.176 0.276         3 0.082    39.525     -0.142       0.224
16  2026-08-03 00:45:00    53.525 0.182 0.282         3 0.083    39.750     -0.140       0.223
17  2026-08-03 01:00:00    53.300 0.188 0.288         3 0.085    39.975     -0.138       0.224
18  2026-08-03 01:15:00    53.075 0.195 0.295         3 0.087    40.200     -0.136       0.223
19  2026-08-03 01:30:00    52.850 0.201 0.301         4 0.089    40.650     -0.133       0.221
20  2026-08-03 01:45:00    52.625 0.207 0.307         4 0.090    40.875     -0.131       0.221
21  2026-08-03 02:00:00    52.400 0.214 0.314         4 0.092    41.100     -0.129       0.221
22  2026-08-03 02:15:00    52.175 0.220 0.320         4 0.093    41.325     -0.127       0.220
23  2026-08-03 02:30:00    51.950 0.226 0.326         4 0.094    41.550     -0.125       0.220
24  2026-08-03 02:45:00    51.725 0.233 0.333         4 0.096    41.775     -0.124       0.220
25  2026-08-03 03:00:00    51.500 0.239 0.339         4 0.098    42.000     -0.122       0.220
26  2026-08-03 03:15:00    51.275 0.245 0.345         4 0.100    42.225     -0.120       0.220
27  2026-08-03 03:30:00    51.050 0.252 0.352         4 0.102    42.450     -0.118       0.220
28  2026-08-03 03:45:00    50.825 0.258 0.358         4 0.104    42.675     -0.116       0.220
29  2026-08-03 04:00:00    50.600 0.264 0.364         4 0.106    42.900     -0.115       0.221
30  2026-08-03 04:15:00    50.375 0.271 0.371         4 0.109    43.125     -0.113       0.222
31  2026-08-03 04:30:00    50.150 0.277 0.377         4 0.112    43.350     -0.111       0.223
32  2026-08-03 04:45:00    49.925 0.283 0.383         4 0.115    43.575     -0.109       0.224
33  2026-08-03 05:00:00    49.700 0.290 0.390         4 0.119    43.800     -0.107       0.226
34  2026-08-03 05:15:00    49.475 0.296 0.396         4 0.124    44.025     -0.106       0.229
35  2026-08-03 05:30:00    49.250 0.302 0.402         5 0.129    44.475     -0.102       0.231
36  2026-08-03 05:45:00    49.025 0.309 0.409         5 0.134    44.700     -0.100       0.234
37  2026-08-03 06:00:00    48.800 0.315 0.415         5 0.138    44.925     -0.098       0.236
38  2026-08-03 06:15:00    48.575 0.321 0.421         5 0.141    45.150     -0.096       0.238
39  2026-08-03 06:30:00    48.350 0.327 0.427         5 0.143    45.375     -0.095       0.237
40  2026-08-03 06:45:00    48.125 0.334 0.434         5 0.143    45.600     -0.093       0.236
41  2026-08-03 07:00:00    47.900 0.340 0.440         5 0.145    45.825     -0.091       0.236
42  2026-08-03 07:15:00    47.675 0.346 0.446         5 0.146    46.050     -0.089       0.235
43  2026-08-03 07:30:00    47.450 0.353 0.453         5 0.146    46.275     -0.087       0.234
44  2026-08-03 07:45:00    47.225 0.359 0.459         5 0.145    46.500     -0.086       0.231
45  2026-08-03 08:00:00    47.000 0.365 0.465         5 0.146    46.725     -0.084       0.230
46  2026-08-03 08:15:00    46.775 0.372 0.472         5 0.146    46.950     -0.082       0.227
47  2026-08-03 08:30:00    46.550 0.378 0.478         5 0.144    47.175     -0.080       0.224
48  2026-08-03 08:45:00    46.325 0.384 0.484         5 0.142    47.400     -0.078       0.220
49  2026-08-03 09:00:00    46.100 0.391 0.491         5 0.144    47.625     -0.077       0.221
50  2026-08-03 09:15:00    45.875 0.397 0.497         5 0.141    47.850     -0.075       0.215
51  2026-08-03 09:30:00    45.650 0.403 0.503         6 0.139    48.300     -0.071       0.210
52  2026-08-03 09:45:00    45.425 0.410 0.510         6 0.136    48.525     -0.069       0.205
53  2026-08-03 10:00:00    45.200 0.416 0.516         6 0.131    48.750     -0.067       0.199
54  2026-08-03 10:15:00    44.975 0.422 0.522         6 0.120    48.975     -0.066       0.186
55  2026-08-03 10:30:00    44.750 0.429 0.529         6 0.108    49.200     -0.064       0.172
56  2026-08-03 10:45:00    44.525 0.435 0.535         6 0.097    49.425     -0.062       0.159
57  2026-08-03 11:00:00    44.300 0.441 0.541         6 0.090    49.650     -0.060       0.150
58  2026-08-03 11:15:00    44.075 0.448 0.548         6 0.082    49.875     -0.058       0.140
59  2026-08-03 11:30:00    43.850 0.454 0.554         6 0.078    50.100     -0.057       0.135
60  2026-08-03 11:45:00    43.625 0.460 0.560         6 0.078    50.325     -0.055       0.133
61  2026-08-03 12:00:00    43.400 0.467 0.567         6 0.079    50.550     -0.053       0.132
62  2026-08-03 12:15:00    43.175 0.473 0.573         6 0.076    50.775     -0.051       0.127
63  2026-08-03 12:30:00    42.950 0.479 0.579         6 0.076    51.000     -0.049       0.125
64  2026-08-03 12:45:00    42.725 0.486 0.586         6 0.076    51.225     -0.048       0.124
65  2026-08-03 13:00:00    42.500 0.492 0.592         6 0.077    51.450     -0.046       0.123
66  2026-08-03 13:15:00    42.275 0.498 0.598         6 0.078    51.675     -0.044       0.122
67  2026-08-03 13:30:00    42.050 0.505 0.605         7 0.080    52.125     -0.040       0.121
68  2026-08-03 13:45:00    41.825 0.511 0.611         7 0.082    52.350     -0.038       0.120
69  2026-08-03 14:00:00    41.600 0.517 0.617         7 0.088    52.575     -0.037       0.125
70  2026-08-03 14:15:00    41.375 0.524 0.624         7 0.097    52.800     -0.035       0.132
71  2026-08-03 14:30:00    41.150 0.530 0.630         7 0.107    53.025     -0.033       0.140
72  2026-08-03 14:45:00    40.925 0.536 0.636         7 0.120    53.250     -0.031       0.151
73  2026-08-03 15:00:00    40.700 0.543 0.643         7 0.132    53.475     -0.029       0.162
74  2026-08-03 15:15:00    40.475 0.549 0.649         7 0.148    53.700     -0.028       0.175
75  2026-08-03 15:30:00    40.250 0.555 0.655         7 0.159    53.925     -0.026       0.185
76  2026-08-03 15:45:00    40.025 0.562 0.662         7 0.169    54.150     -0.024       0.193
77  2026-08-03 16:00:00    39.800 0.568 0.668         7 0.179    54.375     -0.022       0.201
78  2026-08-03 16:15:00    39.575 0.574 0.674         7 0.190    54.600     -0.020       0.210
79  2026-08-03 16:30:00    39.350 0.580 0.680         7 0.199    54.825     -0.019       0.218
80  2026-08-03 16:45:00    39.125 0.587 0.687         7 0.207    55.050     -0.017       0.224
81  2026-08-03 17:00:00    38.900 0.593 0.693         7 0.215    55.275     -0.015       0.230
82  2026-08-03 17:15:00    38.675 0.599 0.699         7 0.226    55.500     -0.013       0.239
83  2026-08-03 17:30:00    38.450 0.606 0.706         8 0.234    55.950     -0.009       0.243
84  2026-08-03 17:45:00    38.225 0.612 0.712         8 0.241    56.175     -0.008       0.249
85  2026-08-03 18:00:00    38.000 0.618 0.718         8 0.248    56.400     -0.006       0.254
86  2026-08-03 18:15:00    37.775 0.625 0.725         8 0.261    56.625     -0.004       0.265
87  2026-08-03 18:30:00    37.550 0.631 0.731         8 0.267    56.850     -0.002       0.270
88  2026-08-03 18:45:00    37.325 0.637 0.737         8 0.273    57.075     -0.000       0.274
89  2026-08-03 19:00:00    37.100 0.644 0.744         8 0.277    57.300      0.001       0.275
90  2026-08-03 19:15:00    36.875 0.650 0.750         8 0.282    57.525      0.003       0.279
91  2026-08-03 19:30:00    36.650 0.656 0.756         8 0.285    57.750      0.005       0.280
92  2026-08-03 19:45:00    36.425 0.663 0.763         8 0.285    57.975      0.007       0.278
93  2026-08-03 20:00:00    36.200 0.669 0.769         8 0.280    58.200      0.009       0.272
94  2026-08-03 20:15:00    35.975 0.675 0.775         8 0.280    58.425      0.010       0.270
95  2026-08-03 20:30:00    35.750 0.682 0.782         8 0.280    58.650      0.012       0.268
96  2026-08-03 20:45:00    35.525 0.688 0.788         8 0.280    58.875      0.014       0.266
97  2026-08-03 21:00:00    35.300 0.694 0.794         8 0.278    59.100      0.016       0.262
98  2026-08-03 21:15:00    35.075 0.701 0.801         9 0.276    59.550      0.020       0.257
99  2026-08-03 21:30:00    34.850 0.707 0.807         9 0.275    59.775      0.021       0.253
100 2026-08-03 21:45:00    34.625 0.713 0.813         9 0.273    60.000      0.023       0.250
101 2026-08-03 22:00:00    34.400 0.000 0.000         0 0.000     0.000      0.000       0.000
102 2026-08-03 22:15:00    34.175 0.000 0.000         0 0.000     0.000      0.000       0.000
103 2026-08-03 22:30:00    33.950 0.000 0.000         0 0.000     0.000      0.000       0.000
104 2026-08-03 22:45:00    33.725 0.000 0.000         0 0.000     0.000      0.000       0.000
105 2026-08-03 23:00:00    33.500 0.000 0.000         0 0.000     0.000      0.000       0.000
106 2026-08-03 23:15:00    33.275 0.000 0.000         0 0.000     0.000      0.000       0.000
107 2026-08-03 23:30:00    33.050 0.000 0.000         0 0.000     0.000      0.000       0.000
108 2026-08-03 23:45:00    32.825 0.000 0.000         0 0.000     0.000      0.000       0.000

2026-08-02 20:57:54 info: Instellingen voor laden van EV: Skoda
2026-08-02 20:57:54 info: Direct laden is uit
2026-08-02 20:57:54 info:  Ampere  Effic. Grid kW Accu kW
2026-08-02 20:57:54 info:    0.00    0.00    0.00    0.00
2026-08-02 20:57:54 info:   16.00    1.00   11.04   11.04
2026-08-02 20:57:54 info: Capaciteit accu: 54.0 kWh
2026-08-02 20:57:54 info: Maximaal laadvermogen: 11.04 kW
2026-08-02 20:57:54 info: Klaar met laden op: 03-08-2026 17:00:00
2026-08-02 20:57:54 info: Huidig laadniveau: 93.0 %
2026-08-02 20:57:54 info: Gewenst laadniveau:85.0 %
2026-08-02 20:57:54 info: Marge voor het laden: 0 %
2026-08-02 20:57:54 info: Locatie: home
2026-08-02 20:57:54 info: Ingeplugged:False
2026-08-02 20:57:54 info: Benodigde netto energie: 0.000 kWh
2026-08-02 20:57:54 info: Tijd nodig om te laden: 0:0 uur
2026-08-02 20:57:54 info: Afgerond naar hele intervallen: 0 kwartier
2026-08-02 20:57:54 info: Stand laden schakelaar: off
2026-08-02 20:57:54 info: Stand aantal ampere laden: 0.0 A
2026-08-02 20:57:54 info: Opladen wordt niet ingepland, omdat werkelijk niveau (93.0%) hoger is of gelijk aan gewenst niveau (85.0% minus de marge 0%), auto is niet ingeplugd.
2026-08-02 20:57:54 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-08-02 20:57:54 info: Apparaat Wasmachine direct starten staat uit
2026-08-02 20:57:55 info: Machine Wasmachine wordt niet ingepland, want er is gekozen voor Uit
2026-08-02 20:57:55 info: Strategie: minimale kosten
2026-08-02 20:57:55 info: Maximale fout (maximal gap): 0.005000 euro
2026-08-02 20:57:55 info: Rekentijd: 0.04  sec
2026-08-02 20:57:55 waarschuwing: Geen oplossing voor: minimize cost
jeroenribbink schreef op zondag 2 augustus 2026 @ 21:04:
...
Settings:
"entity setpoint": "input_number.dao_boiler_keuken_setpoint", // 60
"entity hysterese": "input_number.dao_boiler_setpoint_afwijking", // 5, heb ook 10 gehad
...
"heating allowed below": 55,
...
Met deze settings geef je DAO geen speelruimte:
De boiler gaat sowieso opwarmen als hij 55°C (= 60°C - 5 K hysterese) aantikt, maar DAO mag de boiler pas gaan opwarmen als hij onder de 55°C (=heating allowed below) is. Dus je geeft DAO geen speelruimte.
Vandaar geen oplossing.
Als dit je echte settings zijn kun je de boiler beter buiten DAO houden (boiler_present=false).

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 21:45

wmc

wmc schreef op woensdag 29 juli 2026 @ 09:30:
Ik kom interessant gedrag tegen het instellen van een vermogenslimiet als functie van de SOC. Het gedrag dat ik wil instelllen is:

SOC <= 94% P = 7200W
SOC>95% P=1800W

Zoals in de wiki nu interpreteer wordt er geëxtrapoleerd voorbij de ingestelde SOC waarde, oftewel, de helling die ik nu instel is (7200-1800) = 5400 W / % SOC, wat betekent dat er effectief boven de 95% SOC niet geladen wordt. Ik heb daarom een extra punt toegevoegd op 100% SOC, dat hetzelfde vermogen geeft als SOC 95%. De instelling die ik daarvoor heb gezet is:
code:
1
2
3
4
5
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800},
        { "soc": 100, "power": 1800}],
Dit levert hetvolgende gedrag op:

[Afbeelding]

Als ik de 100% SOC weghaal en dus de volgende instelling gebruik
code:
1
2
3
4
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800}],
krijg ik hetvolgende gedrag.

[Afbeelding]


Waar zit mijn denkfout? Het lijkt er namelijk op dat met de eerste instelling het totale vermogen wordt beperkt op 1800W voor het hele SOC bereik.
Iemand een idee hoe het vermogenslimiet voor hoge SOC te implementeren?

  • The Source
  • Registratie: April 2000
  • Laatst online: 22:24
KC27 schreef op zondag 2 augustus 2026 @ 16:13:
[...]

Waarom heb je hysterese op 0 gezet?
Hysterese op 0 betekent dat er direct opgewarmd moet worden van 54.5 naar 55.0.
Wat staat er in de logging?
Top, dat was het probleem inderdaad.
Nu finetunen! Niet makkelijk om de cooling rate en het stroomverbruik te bepalen omdat deze onderdeel van een warmtepomp is.
The Source schreef op maandag 3 augustus 2026 @ 10:12:
[...]

Top, dat was het probleem inderdaad.
Nu finetunen! Niet makkelijk om de cooling rate en het stroomverbruik te bepalen omdat deze onderdeel van een warmtepomp is.
De cooling-rate kun je bepalen uit de HA-grafiek van de boiler-temperatuur:
Afbeeldingslocatie: https://tweakers.net/i/d4f9AlByTr8quGI5ZFsGmBYMNaU=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/KaMYuApEQTZATENThaO1q6rZ.png?f=user_large

Het stroomverbruik heb ik bepaald door het elektriciteitsverbruik van de warmtepomp uit te splitsen in het verbruik in de "statussen" ("heating", "hot water", "cooling", "no request") van de warmtepomp met behulp van een "utility meter" van HA en dan te kijken naar het verbruik tijdens de status "hot water".

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

wmc schreef op maandag 3 augustus 2026 @ 07:46:
[...]
code:
1
2
3
4
5
"reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800},
        { "soc": 100, "power": 1800}],
Je maakt in deze instelling twee fouten:
De regel bij "soc" = 0 hoort er niet, maar zou wel kunnen, maar de de regel "soc"=100 moet of weg of de power moet een stuk lager zijn.
Als je deze waarden in een grafiek zet zou je een "bolle" lijn moeten krijgen, maar nu krijg je een holle aan het einde afgeplatte lijn. Dat laatste stuk afgeplatte lijn domineert nu het hele plaatje en dus zal het vermogen nooit boven de 1800 W komen.

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 21:45

wmc

KC27 schreef op dinsdag 4 augustus 2026 @ 10:01:
[...]

Je maakt in deze instelling twee fouten:
De regel bij "soc" = 0 hoort er niet, maar zou wel kunnen, maar de de regel "soc"=100 moet of weg of de power moet een stuk lager zijn.
Als je deze waarden in een grafiek zet zou je een "bolle" lijn moeten krijgen, maar nu krijg je een holle aan het einde afgeplatte lijn. Dat laatste stuk afgeplatte lijn domineert nu het hele plaatje en dus zal het vermogen nooit boven de 1800 W komen.
De holle lijn zoals je hem beschrijft is wel het gedrag dat de batterij laat zien. Boven de 95% SOC accepteert hij minder vermogen (~1800W). Daaronder accepteert hij meer, ik heb die waarde op 7200W gecapt. Ik zit dus met een dilemma, of de SOC komt nooit boven de ~96%, omdat de lijn wordt geëxtrapoleerd, waardoor het laadvermogen boven de 95% zo goed als nul is, of hij wordt geinterpoleerd, waardoor het laadvermogen <95% SOC nooit hoger wordt dan de 1800W die ik opgeef tussen de 95 en 100% SOC.


De plot hieronder is van een van de drie batterijen in de stack:
Afbeeldingslocatie: https://tweakers.net/i/ZqEXaDDpThVAvvqLjnoYzOGTmfo=/800x/filters:strip_exif()/f/image/NJQScE5iqBP3oNJiPmps02fJ.png?f=fotoalbum_large
Vanaf de 80% is dit toch een bolle lijn.
Ik zou dus zeggen:
  • "soc": 80, "power": 1850
  • "soc": 90, "power": 1800
  • "soc": 93, "power": 1500
  • "soc": 95, "power": 500
De volgende hoef je niet meer in te vullen want als je de lijn van 93 naar 95 doortrekt is ie al bij 96 op 0 (daar zorgt DAO dan weer voor).
In grafiek:
Afbeeldingslocatie: https://tweakers.net/i/PZcNcxv-1vyJrR9WZuwsZCyxmdU=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/af8MApwEH57Pu3E0zOOYjl2n.png?f=user_large
Het mip-algoritme van DAO werkt in deze situatie met begrenzingen (constraints). Ieder lijnstuk is een begrenzing die niet alleen geldt tussen de twee opgegeven SoC's maar over het hele SoC-gebied (0 - 100%): voor iedere SoC geldt dat het vermogen altijd kleiner of gelijk moet zijn aan de overeenkomende waarde bij een gegeven SoC.
Maar omdat er buiten de opgegeven grenzen vaak andere begrenzingen gelden (vandaar die bolle lijn) is de opgegeven begrenzing daar niet limiterend.

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


  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 13-08 15:02
KC27 schreef op zondag 2 augustus 2026 @ 22:09:
[...]

Met deze settings geef je DAO geen speelruimte:
De boiler gaat sowieso opwarmen als hij 55°C (= 60°C - 5 K hysterese) aantikt, maar DAO mag de boiler pas gaan opwarmen als hij onder de 55°C (=heating allowed below) is. Dus je geeft DAO geen speelruimte.
Vandaar geen oplossing.
Als dit je echte settings zijn kun je de boiler beter buiten DAO houden (boiler_present=false).
Dank je wel, maar waar ik niet bij kan is dat hij dan helemaal geen oplossing kan vinden.In mijn ogen zou hij dan de boiler kunnen uitsluiten van plannen, maar wel de batterij inplannen.
jeroenribbink schreef op dinsdag 4 augustus 2026 @ 20:25:
[...]

Dank je wel, maar waar ik niet bij kan is dat hij dan helemaal geen oplossing kan vinden.In mijn ogen zou hij dan de boiler kunnen uitsluiten van plannen, maar wel de batterij inplannen.
Ik zal kijken of ik in dit soort situaties een warning en uitsluiting van inplanning kan genereren.

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

@jeroenribbink
Zo wordt dus een prive project, dat ik deel zodat anderen er gebruik van kunnen maken, steeds meer een (exusez les mots) monkey proof project.

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


  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 13-08 15:02
KC27 schreef op dinsdag 4 augustus 2026 @ 22:48:
@jeroenribbink
Zo wordt dus een prive project, dat ik deel zodat anderen er gebruik van kunnen maken, steeds meer een (exusez les mots) monkey proof project.
Vind je dat erg? je bent erg betrokken bij de casussen of ideeën die mensen posten. ;)
jeroenribbink schreef op dinsdag 4 augustus 2026 @ 22:50:
[...]

Vind je dat erg? je bent erg betrokken bij de casussen of ideeën die mensen posten. ;)
Nee dat vind ik juist leuk: eerst had ik de lol om met die software de processen in mijn eigen huis te kunnen besturen.
Dat heb ik nu al vier jaar onder controle en nu heb ik lol om die software verder te professionaliseren. Ik ben geen echte software professional, maar met de steun en feedback hier van andere tweakers maken we er een mooi product van.

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
BBuilds schreef op donderdag 16 oktober 2025 @ 22:00:
@Bravo Bedankt voor de hulp. Ik begrijp de logica achter de naamgeving * production/consumption nog steeds niet 100%, maar door jouw hulp staat het nu goed geconfigureerd, waarvoor dank.

Ik heb ondertussen ook de calc_baseload functie in orde gekregen door mijn solar productie bij entities solar production ac te plaatsen ipv bij entities solar production dc (trial and error), ookal heb ik een hybride solar omvormer met dc gekoppelde batterij.
Heb ik de config daarvan verkeerd begrepen? Welk soort solar moet er dan bij Solar DC geconfigureerd worden?

Als ik m'n solar bij entities solar production dc vermeld krijg ik overdag allemaal negatieve waarden:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2025-10-16 21:11:26 info: Day Ahead Optimalisering versie: 2025.10.4
2025-10-16 21:11:26 info: Day Ahead Optimalisering gestart op: 16-10-2025 21:11:26
2025-10-16 21:11:26 info: Day Ahead Optimalisatie gestart: 16-10-2025 21:11:26 taak: calc_baseloads
2025-10-16 21:11:26 waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt
2025-10-16 21:11:36 info: baseload voor weekdag 0 :
2025-10-16 21:11:36 info: 0.347 0.297 0.347 0.335 0.309 0.309 0.335 0.184 -0.202 -0.855 -0.999 -1.269 -1.756 -2.742 -2.449 -1.991 -2.022 -1.62 -0.166 0.976 0.697 0.771 0.641 0.635 
2025-10-16 21:11:46 info: baseload voor weekdag 1 :
2025-10-16 21:11:46 info: 0.646 0.609 0.585 0.61 0.621 0.592 0.334 0.083 -0.228 -0.616 -0.873 -1.376 -1.643 -1.975 -2.257 -1.966 -1.916 -1.179 -0.093 0.711 0.659 0.584 0.372 0.422 
2025-10-16 21:11:56 info: baseload voor weekdag 2 :
2025-10-16 21:11:56 info: 0.285 0.322 0.335 0.272 0.31 0.285 0.322 0.284 -0.017 -0.551 -0.997 -1.237 -1.558 -1.641 -1.908 -1.678 -1.556 -0.501 0.012 0.422 0.497 0.434 0.359 0.384 
2025-10-16 21:12:07 info: baseload voor weekdag 3 :
2025-10-16 21:12:07 info: 0.347 0.347 0.347 0.31 0.322 0.322 0.297 0.132 -0.255 -0.789 -1.161 -1.351 -1.482 -1.427 -2.04 -2.14 -2.518 -1.265 -0.404 0.358 0.485 0.572 0.447 0.335 
2025-10-16 21:12:17 info: baseload voor weekdag 4 :
2025-10-16 21:12:17 info: 0.31 0.31 0.322 0.297 0.322 0.334 0.372 0.158 -0.34 -0.688 -1.075 -1.348 -1.661 -2.18 -2.053 -1.39 -2.306 -1.48 0.083 0.572 0.572 0.584 0.497 0.697 
2025-10-16 21:12:27 info: baseload voor weekdag 5 :
2025-10-16 21:12:27 info: 0.809 0.634 0.547 0.634 0.447 0.322 0.347 0.434 -0.117 -0.473 -1.015 -1.704 -2.136 -2.499 -2.901 -2.215 -1.878 -1.672 -0.275 0.455 0.359 0.397 0.384 0.659 
2025-10-16 21:12:37 info: baseload voor weekdag 6 :
2025-10-16 21:12:37 info: 0.659 0.684 0.409 0.334 0.297 0.285 0.31 0.134 -0.235 -0.866 -1.248 -1.303 -1.823 -2.48 -2.677 -2.911 -2.603 -1.612 -0.304 0.492 0.584 0.872 0.622 0.471 
<sys>:0: ResourceWarning: unclosed database in <sqlite3.Connection object at 0x7ffee3cd6e30>
Als ik dezelfde entiteit bij entities solar production ac vermeld in de config komen er wel allemaal geloofwaardige positieve waardes
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2025-10-16 21:22:10 info: Day Ahead Optimalisering versie: 2025.10.4
2025-10-16 21:22:10 info: Day Ahead Optimalisering gestart op: 16-10-2025 21:22:10
2025-10-16 21:22:10 info: Day Ahead Optimalisatie gestart: 16-10-2025 21:22:10 taak: calc_baseloads
2025-10-16 21:22:10 waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt
2025-10-16 21:22:21 info: baseload voor weekdag 0 :
2025-10-16 21:22:21 info: 0.347 0.297 0.347 0.335 0.309 0.309 0.335 0.26 0.385 0.745 1.126 1.393 1.081 1.145 1.339 1.347 1.09 1.13 0.896 1.101 0.697 0.771 0.641 0.635 
2025-10-16 21:22:31 info: baseload voor weekdag 1 :
2025-10-16 21:22:31 info: 0.646 0.609 0.585 0.61 0.621 0.592 0.334 0.295 0.397 0.796 0.764 0.799 0.932 1.3 1.455 1.109 0.572 0.896 0.582 0.861 0.671 0.584 0.372 0.422 
2025-10-16 21:22:41 info: baseload voor weekdag 2 :
2025-10-16 21:22:41 info: 0.285 0.322 0.335 0.272 0.31 0.285 0.322 0.372 0.258 0.399 0.628 0.775 1.067 1.296 0.867 0.935 0.832 0.724 0.575 0.596 0.522 0.434 0.359 0.384 
2025-10-16 21:22:52 info: baseload voor weekdag 3 :
2025-10-16 21:22:52 info: 0.347 0.347 0.347 0.31 0.322 0.322 0.297 0.283 0.533 0.611 0.989 1.186 1.68 1.648 1.072 0.622 0.52 0.798 0.858 0.571 0.498 0.572 0.447 0.335 
2025-10-16 21:23:02 info: baseload voor weekdag 4 :
2025-10-16 21:23:02 info: 0.31 0.31 0.322 0.297 0.322 0.334 0.372 0.371 0.685 0.987 1.162 1.19 1.176 1.244 1.135 1.547 1.169 0.995 1.07 0.797 0.61 0.584 0.497 0.697 
2025-10-16 21:23:12 info: baseload voor weekdag 5 :
2025-10-16 21:23:12 info: 0.809 0.634 0.547 0.634 0.447 0.322 0.347 0.534 0.708 1.114 0.835 0.772 0.764 0.576 0.661 0.985 0.959 0.74 0.775 0.58 0.384 0.397 0.384 0.659 
2025-10-16 21:23:22 info: baseload voor weekdag 6 :
2025-10-16 21:23:22 info: 0.659 0.684 0.409 0.334 0.297 0.285 0.31 0.284 0.653 0.972 1.152 1.385 1.289 1.307 1.398 0.951 0.822 0.825 0.708 0.567 0.597 0.872 0.622 0.471 
<sys>:0: ResourceWarning: unclosed database in <sqlite3.Connection object at 0x7fff3c7f6e30>
Ziet er veel beter uit zo! d:)b
[Afbeelding]
Tenzij ik er overheen gelezen heb, heeft @BBuilds nooit een antwoord gekregen op deze post van 16 oktober. Ik loop tegen hetzelfde probleem aan. Mijn zonnepanelen zijn aangesloten op een hybride omvormer (AlphaESS Smile-G3-T10) met DC-gekoppelde accu. Ik heb dus (lijkt me) alleen maar "entities_solar_production_dc" en géén "entities_solar_production_ac", en dat heb ik ook als zodanig ingevuld in mijn DAO options bestand. Maar dit zorgt ervoor dat mijn baseload calculation voor geen meter klopt, daar komen negatieve waarden uit. De workaround hiervoor is, net zoals bij @BBuilds, om de sensor voor PV productie dan maar onder "entities_solar_production_ac" te zetten. Maar eigenlijk is dit toch niet correct? En ik zal toch niet de enige persoon hier zijn met een hybride omvormer?

Dus, mis ik iets, of is dit een bugje dat wel eens gefikst mag worden? :)

Hoe dan ook, hartelijk dank voor deze software, ook al heeft ie me tot nu toe meer hoofdpijn gebracht dan me lief is |:( :+

Only connect...


  • wmc
  • Registratie: November 2012
  • Laatst online: 21:45

wmc

KC27 schreef op dinsdag 4 augustus 2026 @ 15:42:
Vanaf de 80% is dit toch een bolle lijn.
Ik zou dus zeggen:
  • "soc": 80, "power": 1850
  • "soc": 90, "power": 1800
  • "soc": 93, "power": 1500
  • "soc": 95, "power": 500
De volgende hoef je niet meer in te vullen want als je de lijn van 93 naar 95 doortrekt is ie al bij 96 op 0 (daar zorgt DAO dan weer voor).
In grafiek:
[Afbeelding]
Het mip-algoritme van DAO werkt in deze situatie met begrenzingen (constraints). Ieder lijnstuk is een begrenzing die niet alleen geldt tussen de twee opgegeven SoC's maar over het hele SoC-gebied (0 - 100%): voor iedere SoC geldt dat het vermogen altijd kleiner of gelijk moet zijn aan de overeenkomende waarde bij een gegeven SoC.
Maar omdat er buiten de opgegeven grenzen vaak andere begrenzingen gelden (vandaar die bolle lijn) is de opgegeven begrenzing daar niet limiterend.
Dat komt deels overeen met het echte gedrag, hierbij een zoom op 90-100% SOC

Afbeeldingslocatie: https://tweakers.net/i/Ws4ql6UPMZ0uV3KcAECq1Mto9xQ=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/9rZHYBSY8YuKVY1wCryAljZw.png?f=user_large

De rode lijnen zijn grove benaderingen van de limieten die ik wil instellen. Dat hij bij 96% nul wordt is precies niet wat ik wil.

Opmerking bij deze data: De temperatuur van de omvormer heeft ook nog invloed op het maximale vermogen, vandaar dat er enigszins spreiding te zien is. Ook draait de batterij zo nu en dan op NOM modus in plaats van maximaal ontladen, dat heb ik er niet uitgefilterd.

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

Dogooder

dus...

@vlix Nee je bent niet de enige, ik heb ook een hybride omvormer met mijn zonnepanelen op dc en mijn baseload wordt ook meer negatief naarmate ik meer zon overschot heb.

Ik heb er eerder even vluchtig naar gekeken en kon de "bug" zo snel niet vinden.

Maar ik wil hier binnenkort wel even dieper naar kijken om te kijken of ik tot een oplossing kan komen.
@vlix en @Dogooder
Kunnen jullie hier je settings (m.n. van de batterij, je solar en je reports) hier delen, liefst tussen quote- en code=json tags?

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

wmc schreef op woensdag 5 augustus 2026 @ 09:19:
[...]


Dat komt deels overeen met het echte gedrag, hierbij een zoom op 90-100% SOC

[Afbeelding]

De rode lijnen zijn grove benaderingen van de limieten die ik wil instellen. Dat hij bij 96% nul wordt is precies niet wat ik wil.

Opmerking bij deze data: De temperatuur van de omvormer heeft ook nog invloed op het maximale vermogen, vandaar dat er enigszins spreiding te zien is. Ook draait de batterij zo nu en dan op NOM modus in plaats van maximaal ontladen, dat heb ik er niet uitgefilterd.
Met het mip-algoritme is het niet mogelijk om de vlakke lijn boven 97% SoC te implementeren.
Misschien moet je dat ook niet willen.
Weet je wat de cel-spanning is als de 97% wordt bereikt?
Als de cel-spanning boven de 3,45 V komt is eigenlijk de verzadiging bereikt en ben je alleen maar de cellen aan het opwarmen, de balancering aan het voeden (tenminste als er een top-balancering in je bms zit) en schade aan de cellen aan het toebrengen.

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
KC27 schreef op woensdag 5 augustus 2026 @ 10:49:
@vlix en @Dogooder
Kunnen jullie hier je settings (m.n. van de batterij, je solar en je reports) hier delen, liefst tussen quote- en code=json tags?
Bij deze:
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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "supervisor",
    "protocol_api": "http"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attempts": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "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
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-08-03": 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-08-03": 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
    },
    "last_invoice": "2026-08-03",
    "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.35,
  0.35,
  0.35,
  0.35,
  0.35,
  0.35,
  0.38,
  0.42,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.50,
  0.50,
  0.50,
  0.50,
  0.50,
  0.42,
  0.38
],
  "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": "input_select.dao_strategy",
  "max_gap": 0.005,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },


"battery": [
  {
    "name": "AlphaESS Smile-G3-T10",

    "entity actual level": "sensor.alphaess_soc_battery",

    "capacity": 9.3,
    "upper limit": "input_number.dao_upper_limit",
    "lower limit": "input_number.dao_lower_limit",
    "optimal lower level": "input_number.dao_optimal_lower_level",
    "entity min soc end opt": "input_number.dao_min_soc_einde",
    "entity max soc end opt": "input_number.dao_max_soc_einde",
    
    "charge stages": [
      { "power": 0,    "efficiency": 1.0 },
      { "power": 1000, "efficiency": 0.965 },
      { "power": 2500, "efficiency": 0.960 },
      { "power": 4000, "efficiency": 0.955 },
      { "power": 5000, "efficiency": 0.950 }
    ],

    "discharge stages": [
      { "power": 0,    "efficiency": 1.0 },
      { "power": 1000, "efficiency": 0.965 },
      { "power": 2500, "efficiency": 0.960 },
      { "power": 4000, "efficiency": 0.955 },
      { "power": 5000, "efficiency": 0.950 }
    ],

    "minimum power": 100,

    "dc_to_bat efficiency": 0.968,
    "dc_to_bat max power": 5000,

    "bat_to_dc efficiency": 0.968,
    "bat_to_dc max power": 5000,

    "cycle cost": 0.015,
    "entity set power feedin": "input_number.dao_set_power_feedin",
    "entity set operating mode": "input_select.dao_set_operating_mode",
    "entity stop inverter": "input_datetime.dao_stop_inverter",
    "entity balance switch": "input_boolean.dao_balance_switch",
    "entity from battery": "input_number.dao_from_battery",
    "entity from ac": "input_number.dao_from_ac",
    "entity from pv": "input_number.dao_from_pv",
    "entity calculated soc": "input_number.dao_calculated_soc",

   "solar": [
      {
        "name": "AlphaESS PV",

        "entity pv switch": "input_boolean.alphaess_helper_dispatch_pv_switch",

        "ml_prediction": false,

        "entities sensors": [
          "sensor.alphaess_total_energy_from_pv"
        ],

        "strings": [
          {
            "tilt": 28,
            "orientation": 60,
            "capacity": 3.6,
            "yield": 0.00765
          },
          {
            "tilt": 28,
            "orientation": -120,
            "capacity": 3.15,
            "yield": 0.00669
          }
        ],

        "max_power": 6.75
      }
    ]
  }
],


"solar": [],



  "electric_vehicle": [],
  "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.alphaess_total_energy_consumption_from_grid_meter"      
    ],
    "entities_grid_production": [
      "sensor.alphaess_total_energy_feed_to_grid_meter"      
    ],
    "entities_solar_production_dc": [
      "sensor.alphaess_total_energy_from_pv"
    ],
    "entities_solar_production_ac": [],
    "entities_ev_consumption": [
      "sensor.laadpunt_total_energy"
    ],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.alphaess_total_energy_charge_battery"
    ],
    "entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
    ],
    "entities_machine_consumption": []
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0235",
        "action": "calc_baseloads"
      },
      {
        "time": "0435",
        "action": "get_meteo_data"
      },
      {
        "time": "1035",
        "action": "get_meteo_data"
      },
      {
        "time": "1635",
        "action": "get_meteo_data"
      },
      {
        "time": "2235",
        "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": "1840",
        "action": "train_ml_predictions"
      },
      {
        "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"
      }
    ]
  }
}

Only connect...

Ik zie bij "report" o.a. staan:
JSON:
1
2
3
    "entities_solar_production_dc": [
      "sensor.alphaess_total_energy_from_pv"
    ],
Maar deze doen daar niks en worden ook niet gebruikt voor de berekening van de baseload.
Belangrijk is dat in
JSON:
1
2
"entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
Niet alleen de energie wordt gemeten die uit de cellen van je batterij komen maar alles wat vanuit je Alpa ESS-omvormer naar je meterkast gaat.
Als dat zo is: hoe ziet je balans-rapportage (report/balans) van gisteren eruit (liefst in tabelvorm)?
Ik bedoel deze:
Afbeeldingslocatie: https://tweakers.net/i/hzJPW2coX1BUS2eVQPt5DCbBRq0=/800x/filters:strip_exif()/f/image/zA6azLHpfHuxl0Kp6JOGenuJ.png?f=fotoalbum_large

[ Voor 26% gewijzigd door KC27 op 05-08-2026 11:53 ]

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 21:45

wmc

KC27 schreef op woensdag 5 augustus 2026 @ 11:13:
[...]

Met het mip-algoritme is het niet mogelijk om de vlakke lijn boven 97% SoC te implementeren.
Misschien moet je dat ook niet willen.
Weet je wat de cel-spanning is als de 97% wordt bereikt?
Als de cel-spanning boven de 3,45 V komt is eigenlijk de verzadiging bereikt en ben je alleen maar de cellen aan het opwarmen, de balancering aan het voeden (tenminste als er een top-balancering in je bms zit) en schade aan de cellen aan het toebrengen.
Die wordt inderdaad (volgens de Zendure integratie) hoger dan 3.45V. De beperking op het laden komt ook uit de Zendure omvormer zelf, misschien moet ik de maximale capaciteit dan ook maar op 95% of iets dergelijks zetten. Goede suggestie!

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

Dogooder

dus...

KC27 schreef op woensdag 5 augustus 2026 @ 11:49:
[...]
JSON:
1
2
"entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
Niet alleen de energie wordt gemeten die uit de cellen van je batterij komen maar alles wat vanuit je Alpa ESS-omvormer naar je meterkast gaat.
Als dat zo is: hoe ziet je balans-rapportage (report/balans) van gisteren eruit (liefst in tabelvorm)?
Dit had ik verkeerd gezet. Ik heb nu
entities_battery_production
en
_consumption
de entiteiten gegeven van mijn kWh meter die aan de AC zijde van het systeem zit. Deze meet dus alles wat in en uit het systeem gaat.

Helaas blijven mijn baseload waardes in de reports negatief, maar bij de baseload berekening zie ik geen negatieve waardes meer.

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
KC27 schreef op woensdag 5 augustus 2026 @ 11:49:
[...]

Ik zie bij "report" o.a. staan:
JSON:
1
2
3
    "entities_solar_production_dc": [
      "sensor.alphaess_total_energy_from_pv"
    ],
Maar deze doen daar niks en worden ook niet gebruikt voor de berekening van de baseload.
Belangrijk is dat in
JSON:
1
2
"entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
Niet alleen de energie wordt gemeten die uit de cellen van je batterij komen maar alles wat vanuit je Alpa ESS-omvormer naar je meterkast gaat.
Als dat zo is: hoe ziet je balans-rapportage (report/balans) van gisteren eruit (liefst in tabelvorm)?
Ik bedoel deze:
[Afbeelding]
Bij deze een screenshot van mijn balans-rapportage van gisteren:

Afbeeldingslocatie: https://tweakers.net/i/229ZOUgoVQB-0AE8QhkmphVk-CA=/800x/filters:strip_exif()/f/image/GOZOfGiTnx47oMU8pivQHaSB.png?f=fotoalbum_large

Ik gok dat "sensor.alphaess_total_energy_discharge_battery" precies weergeeft wat je van de naam zou verwachten: de totale energie geleverd door de accu en niks anders.

Ik weet niet of ik een sensor heb die precies doet wat jij vraagt. Overzicht van vergelijkbare sensors in mijn systeem:

Afbeeldingslocatie: https://tweakers.net/i/hBErQWxqNqaGmyxEW7neigB21no=/800x/filters:strip_exif()/f/image/dw9L7DBsjpPVTdm16QvXZAAc.png?f=fotoalbum_large

Moet ik voor entities_battery_production dan sensor.alphaess_total_energy_feed_to_grid_meter gebruiken? Dat is dan alle energie die uit mijn omvormer komt, exclusief eigen verbruik. Of moet ik twee waardes combineren? Of moet ik simpelweg hiervoor óók sensor.alphaess_total_energy_from_pv gebruiken? Dat is alle door de PV opgewekte energie, inclusief energie die in eerste instantie in de accu wordt geduwd en dus pas later geconsumeerd wordt via de meterkast.

Only connect...

Dogooder schreef op woensdag 5 augustus 2026 @ 16:44:
[...]


Dit had ik verkeerd gezet. Ik heb nu
entities_battery_production
en
_consumption
de entiteiten gegeven van mijn kWh meter die aan de AC zijde van het systeem zit. Deze meet dus alles wat in en uit het systeem gaat.

Helaas blijven mijn baseload waardes in de reports negatief, maar bij de baseload berekening zie ik geen negatieve waardes meer.
Kun je je report/balans van gisteren hier delen?

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

vlix schreef op woensdag 5 augustus 2026 @ 17:50:
[...]

Bij deze een screenshot van mijn balans-rapportage van gisteren:

~[Afbeelding]

Ik gok dat "sensor.alphaess_total_energy_discharge_battery" precies weergeeft wat je van de naam zou verwachten: de totale energie geleverd door de accu en niks anders.

Ik weet niet of ik een sensor heb die precies doet wat jij vraagt. Overzicht van vergelijkbare sensors in mijn systeem:

~[Afbeelding]

Moet ik voor entities_battery_production dan sensor.alphaess_total_energy_feed_to_grid_meter gebruiken? Dat is dan alle energie die uit mijn omvormer komt, exclusief eigen verbruik. Of moet ik twee waardes combineren? Of moet ik simpelweg hiervoor óók sensor.alphaess_total_energy_from_pv gebruiken? Dat is alle door de PV opgewekte energie, inclusief energie die in eerste instantie in de accu wordt geduwd en dus pas later geconsumeerd wordt via de meterkast.
Ik durf het niet met zekerheid te zeggen, maar ik vermoed dat je "sensor.alphaess_total_energy_feed_to_grid_meter" moet hebben.
Je kunt het eenvoudig uitproberen door deze sensor in te vullen en dan het balans-rapport van gisteren oproepen.
Je ziet nu dat er bijvoorbeeld om 13.00 door je P1-meter energie wordt teruggeleverd, maar waar komt die vandaan?

Oh misschien mijn fout:
Er staat
JSON:
1
2
3
4
5
6
7
 "report": {
    "entities_grid_consumption": [
      "sensor.alphaess_total_energy_consumption_from_grid_meter"      
    ],
    "entities_grid_production": [
      "sensor.alphaess_total_energy_feed_to_grid_meter"      
    ],
Zijn dat data van jouw slimme meter?

[ Voor 9% gewijzigd door KC27 op 05-08-2026 20:00 ]

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


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

Dogooder

dus...

KC27 schreef op woensdag 5 augustus 2026 @ 19:52:
[...]

Kun je je report/balans van gisteren hier delen?
Bij deze:
Afbeeldingslocatie: https://tweakers.net/i/mUaMG6acnq_xgXsdSqxtmwbJZOg=/800x/filters:strip_exif()/f/image/MSfPxunSquxsWYtgEe8siUl8.png?f=fotoalbum_large

en de baseload berekening die nu zonder negatieve waardes is:
2026-08-05 22:40:46 info: Day Ahead Optimalisatie gestart: 05-08-2026 22:40:46 taak: calc_baseloads
2026-08-05 22:40:48 info: baseload voor weekdag 0 :
2026-08-05 22:40:48 info: 0.627 0.182 0.701 0.183 0.189 0.177 0.321 0.739 1.287 0.205 0.18 0.13 0.192 0.19 0.174 0.202 0.169 0.173 0.175 0.22 0.245 0.172 0.217 0.18 
2026-08-05 22:40:50 info: baseload voor weekdag 1 :
2026-08-05 22:40:50 info: 0.172 0.163 0.17 0.169 0.167 0.245 0.231 0.184 0.187 0.18 0.165 0.299 0.784 0.84 0.301 0.302 0.288 0.266 0.169 0.235 0.229 0.235 0.186 0.164 
2026-08-05 22:40:53 info: baseload voor weekdag 2 :
2026-08-05 22:40:53 info: 0.638 0.249 0.743 0.229 0.192 0.222 0.212 0.282 0.313 0.256 0.228 0.223 1.076 1.534 0.218 0.208 0.197 0.395 1.29 0.476 0.452 0.431 0.358 0.329 
2026-08-05 22:40:55 info: baseload voor weekdag 3 :
2026-08-05 22:40:55 info: 0.622 0.215 0.699 0.194 0.202 0.196 0.198 0.231 0.431 0.284 1.705 0.2 0.193 0.26 0.199 0.226 0.275 0.239 0.665 0.446 0.418 0.51 0.376 0.295 
2026-08-05 22:40:58 info: baseload voor weekdag 4 :
2026-08-05 22:40:58 info: 0.21 0.205 0.246 0.209 0.191 0.188 0.22 0.249 0.347 0.224 0.214 0.184 0.624 1.702 0.191 0.207 0.196 0.271 0.445 0.414 0.314 0.616 0.41 0.279 
2026-08-05 22:41:01 info: baseload voor weekdag 5 :
2026-08-05 22:41:01 info: 0.337 0.68 0.19 0.725 0.181 0.187 0.263 0.184 0.255 0.283 0.472 0.831 0.864 1.02 0.356 0.362 2.011 0.284 0.295 0.223 0.263 0.403 0.301 0.264 
2026-08-05 22:41:03 info: baseload voor weekdag 6 :
2026-08-05 22:41:03 info: 0.772 0.83 0.204 0.192 0.197 0.191 0.208 0.175 0.215 0.857 0.257 6.57 12.337 7.053 0.721 2.241 0.474 4.938 1.721 0.735 0.411 0.377 0.288 0.223
en het stuk config wat ik nu heb:
  "report": {
    "entities_grid_consumption": [
      "sensor.electricity_delivered_1",
      "sensor.electricity_delivered_2"
    ],
    "entities_grid_production": [
      "sensor.electricity_returned_1",
      "sensor.electricity_returned_2"
    ],
    "entities_solar_production_ac": [],
    "entities_solar_production_dc": [
      "sensor.ss_total_pv_energy"
    ],
    "entities_ev_consumption": [],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.battery_kwh_meter_energy_import"
    ],
    "entities_battery_production": [
      "sensor.battery_kwh_meter_energy_export"
    ],
    "entities_machine_consumption": []
  },
Daarbij zijn sensor.battery_kwh_meter_energy_import/export de waardes van een homewizard meter direct aan de grid zijde van de omvormer.
Ik ben nog aan het puzzelen hoe dit mogelijk is cq ontstaat.
Haal jij toevallig consumptie- (inkoop) en productiedata (teruglevering) op bij Tibber?

Morgen ben ik weg, maar ik kom er op terug!

[ Voor 16% gewijzigd door KC27 op 06-08-2026 00:22 ]

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


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

Dogooder

dus...

KC27 schreef op donderdag 6 augustus 2026 @ 00:18:
[...]
Ik ben nog aan het puzzelen hoe dit mogelijk is cq ontstaat.
Haal jij toevallig consumptie- (inkoop) en productiedata (teruglevering) op bij Tibber?
Nee, ik haal prijzen op bij Nordpool en lees verder zelf mijn P1 meter uit met home assistant.

Ok oplossing is een restart van DAO 8)7

Ik heb:
  • De formule gecontroleerd: Ik heb de rapportformule controleerd om te kijken of deze overeenkomt met de weergegeven getallen, uur tot uur, voor zowel calc_base() (route: /reports → routes.py → get_energy_balance_data() → calc_balance_columns()) als calc_weekday_baseload(). Formule: cons − prod + bat_out − bat_in [+ pv_ac] − ev − wp − boil − mach. (Hoofdverdachte hier was het niet hebben van pc_dc)
  • Caching / verouderde data uitgesloten: Ik heb vastgesteld dat de values-tabel van dao database 0 rijen bevat voor bat_in/bat_out-codes. Elk rapport wordt dus rechtstreeks opgehaald via de live fallback (get_sensor_data() op de statistics-tabel van HA) en niet uit een cache.
  • Verkeerde database uitgesloten: Op een gegeven moment ga je aan jezelf twijfelen.
  • Directe aanroep van get_sensor_data(): Ik heb get_sensor_data() rechtstreeks aangeroepen voor sensor.battery_kwh_meter_energy_import. Dit leverde kleine, logische waarden op (~1,46 kWh/dag totaal), wat overeenkomt met de ruwe statistieken in HA. Dit kwam echter niet overeen met de opgeblazen getallen uit het rapport (16,6 kWh/dag).
  • Directe aanroep van get_energy_balance_data(): Toen ik get_energy_balance_data() direct aanriep met identieke datum, kon ik de opgeblazen getallen uit het rapport wél exact reproduceren.
  • Live-inspectie: Ik heb r.energy_balance_dict["bat_in"]["sensors"] / ["bat_out"]["sensors"] live geïnspecteerd. Dit verklaarde.

    Oorzaak:
    report.entities_battery_consumption / entities_battery_production zijn niet de sensoren die daadwerkelijk worden gebruikt:


    Volgens configuratie
    sensor.battery_kwh_meter_energy_import
    sensor.battery_kwh_meter_energy_export

    Daadwerkelijk geconfigureerd / gebruikt
    sensor.ss_total_battery_charge
    sensor.ss_total_battery_discharge
Oplossing:
restart dao

[ Voor 74% gewijzigd door Dogooder op 06-08-2026 12:19 ]


  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 22:54
@KC27

Vraagje, nu in de zomer hebben we met de dynamische tarieven 1 dalperiode, overdag.

Over een paar maanden worden er dat 2, ‘s nachts en overdag.
Gaat DOA dat ook met 2 laad en ontlaad periodes rekenen?

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


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 14-08 18:41
Ja zeker!. Er is vast mooier bewijs maar hierbij een oud screenshot van begin dit jaar waarbij dit redelijk te zien is: Twee keer batterij laden en twee keer ontladen binnen 24 uur.Afbeeldingslocatie: https://tweakers.net/i/T8szzBCOWuQPzbsMWXciE4SR2kM=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/2JeFI5g9dWPhdC34cP6PfoEa.png?f=user_large
Dogooder schreef op donderdag 6 augustus 2026 @ 09:44:
[...]

Nee, ik haal prijzen op bij Nordpool en lees verder zelf mijn P1 meter uit met home assistant.

Ok oplossing is een restart van DAO 8)7

Ik heb:
  • De formule gecontroleerd: Ik heb de rapportformule controleerd om te kijken of deze overeenkomt met de weergegeven getallen, uur tot uur, voor zowel calc_base() (route: /reports → routes.py → get_energy_balance_data() → calc_balance_columns()) als calc_weekday_baseload(). Formule: cons − prod + bat_out − bat_in [+ pv_ac] − ev − wp − boil − mach. (Hoofdverdachte hier was het niet hebben van pc_dc)
  • Caching / verouderde data uitgesloten: Ik heb vastgesteld dat de values-tabel van dao database 0 rijen bevat voor bat_in/bat_out-codes. Elk rapport wordt dus rechtstreeks opgehaald via de live fallback (get_sensor_data() op de statistics-tabel van HA) en niet uit een cache.
  • Verkeerde database uitgesloten: Op een gegeven moment ga je aan jezelf twijfelen.
  • Directe aanroep van get_sensor_data(): Ik heb get_sensor_data() rechtstreeks aangeroepen voor sensor.battery_kwh_meter_energy_import. Dit leverde kleine, logische waarden op (~1,46 kWh/dag totaal), wat overeenkomt met de ruwe statistieken in HA. Dit kwam echter niet overeen met de opgeblazen getallen uit het rapport (16,6 kWh/dag).
  • Directe aanroep van get_energy_balance_data(): Toen ik get_energy_balance_data() direct aanriep met identieke datum, kon ik de opgeblazen getallen uit het rapport wél exact reproduceren.
  • Live-inspectie: Ik heb r.energy_balance_dict["bat_in"]["sensors"] / ["bat_out"]["sensors"] live geïnspecteerd. Dit verklaarde.

    Oorzaak:
    report.entities_battery_consumption / entities_battery_production zijn niet de sensoren die daadwerkelijk worden gebruikt:


    Volgens configuratie
    sensor.battery_kwh_meter_energy_import
    sensor.battery_kwh_meter_energy_export

    Daadwerkelijk geconfigureerd / gebruikt
    sensor.ss_total_battery_charge
    sensor.ss_total_battery_discharge
Oplossing:
restart dao
Blijkbaar buffert DAO dus ergens data.
Gebruik jij sqlite engine voor de ha database?
Zou het een oplossing kunnen zijn om bij wijziging van de settings de database connectie af te sluiten en opnieuw op te starten?

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
KC27 schreef op woensdag 5 augustus 2026 @ 19:58:
[...]

Ik durf het niet met zekerheid te zeggen, maar ik vermoed dat je "sensor.alphaess_total_energy_feed_to_grid_meter" moet hebben.
Je kunt het eenvoudig uitproberen door deze sensor in te vullen en dan het balans-rapport van gisteren oproepen.
Geprobeerd maar dan krijg ik nog steeds negatieve waardes in het balans-rapport.
Je ziet nu dat er bijvoorbeeld om 13.00 door je P1-meter energie wordt teruggeleverd, maar waar komt die vandaan?
Nou ja het antwoord is natuurlijk: van de DC-gekoppelde PV panelen, maar in het rapport is er geen kolom voor "PV DC", alleen een voor "PV ac"?
Oh misschien mijn fout:
Er staat
JSON:
1
2
3
4
5
6
7
 "report": {
    "entities_grid_consumption": [
      "sensor.alphaess_total_energy_consumption_from_grid_meter"      
    ],
    "entities_grid_production": [
      "sensor.alphaess_total_energy_feed_to_grid_meter"      
    ],
Zijn dat data van jouw slimme meter?
Het zijn data van mijn AlphaESS omvormer, maar ik denk dat die overeenkomen met data van mijn slimme meter?

Only connect...

vlix schreef op donderdag 6 augustus 2026 @ 16:37:
[...]

Geprobeerd maar dan krijg ik nog steeds negatieve waardes in het balans-rapport.


[...]

Nou ja het antwoord is natuurlijk: van de DC-gekoppelde PV panelen, maar in het rapport is er geen kolom voor "PV DC", alleen een voor "PV ac"?


[...]

Het zijn data van mijn AlphaESS omvormer, maar ik denk dat die overeenkomen met data van mijn slimme meter?
Heb je deze analyse gelezen:
Dogooder in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Misschien ook DAO herstarten?

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


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

Dogooder

dus...

KC27 schreef op donderdag 6 augustus 2026 @ 14:52:
[...]

Blijkbaar buffert DAO dus ergens data.
Gebruik jij sqlite engine voor de ha database?
Zou het een oplossing kunnen zijn om bij wijziging van de settings de database connectie af te sluiten en opnieuw op te starten?
Ik gebruik sqlite engine voor de ha database ja. Maar hier zit het probleem niet.

gelukkig valt dit probleem te reproduceren. En heel wat testjes later.

run report() vanuit de container, gebruik private browsers, check de json editor save. Maar de hoofdverdachte nu is da_base.py.

Daar staat zelfs in comments:
# "Load config exactly once, even when multiple threads construct a # DaBase subclass concurrently (e.g. gunicorn workers sharing a process)."
Mijn test in de container: nieuw process; DaBase._config start; laad vers en is correct.
Gunicorn workers: Welke als eerste Report() aanroept locked-in de configuratie die gebruikt wordt.

  • memorynl
  • Registratie: Juni 2010
  • Laatst online: 21:32
Eindelijk zomervakantie deze week en begonnen met wat ik langer wilde doen: DAO instellen om mijn PV en accu’s (een Zendure Ac2400 en een HW PiB) te managen 💪.

Ik ben een heel eind gevorderd, alles draait. Maar waar ik mee worstel is de HW PiB. Voor zover ik weet kan ik die niet op een bepaald (ont)laadt vermogen instellen. Vaak bij NOM is dat wel prima te managen met load of unload only (bij de vertaling van HA entities naar HW-acties), maar het volle-bak-ontladen mis is ik toch wel.

Hoe zou ik daarmee om moeten gaan?

De PiB buiten de berekening laten en als baseload mee laten draaien? Iets in het MIP toevoegen zodat hij alleen NOM kan ontladen?

Wat zijn jullie ideeën om daarmee om te gaan (behalve de PiB verkopen 😇)?

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
Ja, wel gelezen, maar ik zal eerlijk bekennen dat ik het maar half snap. Het lijkt alsof Dogooder zelf de Python code in is gedoken, en daar heb ik mij niet aan gewaagd vooralsnog.

En ja, ik start DAO altijd opnieuw op nadat ik wat voor wijziging dan ook maak.

Mijn hersens kraken, dus ik ga een partij domme vragen stellen. Bij voorbaat excuses.
  1. DAO verwacht dus voor "entities_battery_production" niet de output van de accu, maar de output van de accu plus output van PV? Maar waarom heet "entities_battery_production" dan zoals hij heet? Mijn hoofd zegt "does not compute"...
  2. Welke waardes in de DAO config worden nou precies gebruikt voor calc_baseloads, en volgens welke formule?
  3. En zijn dat dezelfde waardes die óók voor de reports worden gebruikt of zijn dat weer andere?
  4. Check dubbelcheck: met "baseload" wordt binnen de context van DAO toch het verbruik van de apparaten in mijn huis bedoeld exclusief het laden van de accu? Ergo de baseload kan per definitie niet negatief zijn?
  5. Ik test momenteel maar gewoon door nadat ik iets verander, DAO opnieuw te starten en een handmatige calc_baseloads te doen via het "run" menu. Ik merk dat ik dus nog steeds wél (wat lijkt op) realistische baseloads krijg als ik "sensor.alphaess_total_energy_from_pv" onder "entities_solar_production_ac" plaats en niet onder "entities_solar_production_dc". Hoe zit dat nou? Moet ik het dan maar zo laten staan ook al klopt het strikt gezien niet?
  6. Wat zijn nou eigenlijk de definities van "entities_solar_production_dc" en "entities_solar_production_ac"? Ik dacht dat met "entities_solar_production_ac" de input van PV panelen wordt bedoeld die via een "gewone" omvormer direct aan het net (of aan je huis) leveren, dus zonder hybride omvormer ertussen, en dat ik daarom per definitie geen enkele "entities_solar_production_ac" heb. Heb ik dit verkeerd begrepen?
Hartelijk dank voor je hulp en geduld!

Only connect...


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

Dogooder

dus...

Hi @vlix, ik denk dat er meerdere zaken door elkaar lopen. Ik zal je proberen te helpen @KC27 correct me if i'm wrong.

1. Ik had mij in eerste instantie (de eerste 10 maanden van mijn DAO gebruik) hier ook in vergist. Maar het moet dus de energie zijn die in en uit je omvormer gaat aan de grid zijde. Als je je huis op de loadzijde hebt dan moet je die ook meenemen denk ik, maar dan heb je eigenlijk je baseload al. Wellicht dat de naamgeving beter kan, iets van entities_system_production?

2. baseload = grid consumption − grid production + battery_out − battery_in [+ pv_ac] − ev − wp − boil − machines.
entities_solar_production_dc wordt nergens voor gebruikt in de reports of baseload.
battery_out en battery_in zijn dus eigenlijk system_in en system_out.

3. baseload en reports gebruiken dezelfde waardes.

4. Correct

5. Hier gaan dingen door elkaar lopen. Ik heb mij klein beetje ingelezen in de alphaess en kom tot een snelle conclusie. Controleer dit zeker. Ik weet ook niet of jij je huis aan de grid zijde hebt of aan de load zijde. Maar je hebt dus de waarde nodig gemeten door de interne meters van de inverter aan de AC stekker. Volgens mijn korte research is dat:
sensor.alphaess_total_generation
voor alles wat je systeem verlaat. entities_battery_production / battery_out(in de baseload)
sensor.alphaess_grid_charge_total
voor alles wat je systeem in gaat. entities_battery_consumption / battery_in(in de baseload)

Na het bijwerken van entities in de config, restart DAO. Zie mijn eerder post ander blijven de oude entitiewaardes in gebruik en wordt je nog verder het bos in gestuurd.

6. Voor zover ik weet is het correct wat je zegt.

Ik hoop heel erg dat bovenstaande je verder helpt.
vlix schreef op donderdag 6 augustus 2026 @ 18:16:
[...]

• DAO verwacht dus voor "entities_battery_production" niet de output van de accu, maar de output van de accu plus output van PV? Maar waarom heet "entities_battery_production" dan zoals hij heet? Mijn hoofd zegt "does not compute"...
"entities_battery_production": de sensor(en) die de afgifte van de omvormer aan de meterkast meten (dus zonder de pv die richting de dc-bus gaat).
• Welke waardes in de DAO config worden nou precies gebruikt voor calc_baseloads, en volgens welke formule?
In pseudo-code dit is de formule:
baseload =
+ inkoop_grid
- teruglevering_grid
+ productie_batterij(en)
- verbruik_batterij(en)
+ productie_pv_ac
- verbruik ev('s)
- verbruik_wp
- verbruik_boiler
- verbruik_machine(s)
Zo staat het letterlijk ergens in de code:
base_load=
row.cons
- row.prod
+ row.bat_out
- row.bat_in
+ row.pv_ac
- row.ev
- row.wp
- row.boil
- row.mach
• En zijn dat dezelfde waardes die óók voor de reports worden gebruikt of zijn dat weer andere?
Dat zijn dezelfde.
• Check dubbelcheck: met "baseload" wordt binnen de context van DAO toch het verbruik van de apparaten in mijn huis bedoeld exclusief het laden van de accu? Ergo de baseload kan per definitie niet negatief zijn?
De baseload is het restant-verbruik van alles dat niet is opgenomen in bovenstaande apparaten,
• Ik test momenteel maar gewoon door nadat ik iets verander, DAO opnieuw te starten en een handmatige calc_baseloads te doen via het "run" menu. Ik merk dat ik dus nog steeds wél (wat lijkt op) realistische baseloads krijg als ik "sensor.alphaess_total_energy_from_pv" onder "entities_solar_production_ac" plaats en niet onder "entities_solar_production_dc". Hoe zit dat nou? Moet ik het dan maar zo laten staan ook al klopt het strikt gezien niet?
Het lijkt er op dat er nog een sensor moet zijn die de totale teruglevering van de omvormer van je batterij meet.
Welke HA integratie voor je batterij gebruik je?
Misschien kan ik meekijken in de documentatie?
• Wat zijn nou eigenlijk de definities van "entities_solar_production_dc" en "entities_solar_production_ac"? Ik dacht dat met "entities_solar_production_ac" de input van PV panelen wordt bedoeld die via een "gewone" omvormer direct aan het net (of aan je huis) leveren, dus zonder hybride omvormer ertussen, en dat ik daarom per definitie geen enkele "entities_solar_production_ac" heb. Heb ik dit verkeerd begrepen?
entities_solar_production_dc: de sensoren die de pv levering meten op dc-bus van je batterij
entities_solar_production_ac: de sensoren die de productie van je ac-gebonden pv (=pv die direct aan je huisnet leveren) meten, bij jou zijn er dus geen van dergelijke sensoren

Edit: sorry @Dogooder crosspost.

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


  • arro3038
  • Registratie: November 2023
  • Laatst online: 22:00
memorynl schreef op donderdag 6 augustus 2026 @ 18:07:
Maar waar ik mee worstel is de HW PiB. Voor zover ik weet kan ik die niet op een bepaald (ont)laadt vermogen instellen.

Wat zijn jullie ideeën om daarmee om te gaan (behalve de PiB verkopen 😇)?
Je kunt hem foppen met een slimme meter simulator. Ik doe dit met mijn Zinvolt. Je stuurt naar de simulator wat je als P1 bericht wilt laten "zien" aan je PIB. Op die manier kun je de PIB in NOM stand laten doen wat jij wil.

De p1 meter die met je HW PIB praat steek je dan in de simulator ipv in je meter in de meterkast. Nadeel is wel dat de data van die P1 meter volledig gemanipuleerd is. Je wil die eigenlijk niet in je HW app zien, want het zegt niets over wat er in je huis gebeurd

https://www.benefactus.nl/projecten-elektronica/project-slimme-meter/slimme-meter-simulator-met-wifi/

  • memorynl
  • Registratie: Juni 2010
  • Laatst online: 21:32
arro3038 schreef op vrijdag 7 augustus 2026 @ 08:26:
[...]

Je kunt hem foppen met een slimme meter simulator. Ik doe dit met mijn Zinvolt. Je stuurt naar de simulator wat je als P1 bericht wilt laten "zien" aan je PIB. Op die manier kun je de PIB in NOM stand laten doen wat jij wil.

De p1 meter die met je HW PIB praat steek je dan in de simulator ipv in je meter in de meterkast. Nadeel is wel dat de data van die P1 meter volledig gemanipuleerd is. Je wil die eigenlijk niet in je HW app zien, want het zegt niets over wat er in je huis gebeurd

https://www.benefactus.nl/projecten-elektronica/project-slimme-meter/slimme-meter-simulator-met-wifi/
Oh dat is nice! Dank voor deze tip.

  • rescla
  • Registratie: November 2012
  • Laatst online: 23:23
Was er trouwens al iets om de tax refund instelling automatisch uit te zetten per 1 januari?

  • Impossibl3
  • Registratie: November 2012
  • Laatst online: 21:42
rescla schreef op vrijdag 7 augustus 2026 @ 13:41:
Was er trouwens al iets om de tax refund instelling automatisch uit te zetten per 1 januari?
1-1-2027 taxrefund op 0 zetten in je config. Kan je nu al doen. Heb je er twee datums in staan die van nu en de toekomstige variant van 1-1-2027.

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


  • rescla
  • Registratie: November 2012
  • Laatst online: 23:23
Impossibl3 schreef op vrijdag 7 augustus 2026 @ 14:37:
[...]


1-1-2027 taxrefund op 0 zetten in je config. Kan je nu al doen. Heb je er twee datums in staan die van nu en de toekomstige variant van 1-1-2027.
Heb je een voorbeeldje misschien? Ik kan het in de docs niet terugvinden, en dit werkt niet:
code:
1
2
3
4
    "tax_refund": {
      "2000-01-01": true,
      "2027-01-01": false
    },
Ik zie in de implementatie ook niet hoe ik het met dit veld zou moeten doen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    multiplier_production: Optional[dict[str, float]] = Field(
        default={"2000-01-01": 1.0},
        alias="multiplier production",
        description="Multiplier for production by date (YYYY-MM-DD -> x.xx)",
        json_schema_extra={
            "x-help": "Multiplier on feed-in/production day-ahead price indexed by effective date. Format: {'2024-01-01': 0.94}.",
            "x-unit": "-",
            "x-ui-section": "Cost",
            "x-validation-hint": "Dict with YYYY-MM-DD keys, float -100.0 - +100.0 values",
        },
    )
....
    tax_refund: bool = Field(
        default=True,
        alias="tax refund",
        description="Whether tax refund applies",
        json_schema_extra={
            "x-help": "Enable tax refund calculation if eligible. Some regions/users get energy tax refunds for solar production.",
            "x-ui-section": "Taxes",
        },
    )
Die andere velden die je op datum kan instellen zijn dicts, tax_refund is boolean.

  • thomvh
  • Registratie: September 2013
  • Laatst online: 00:12
rescla schreef op vrijdag 7 augustus 2026 @ 15:27:
[...]

Heb je een voorbeeldje misschien? Ik kan het in de docs niet terugvinden, en dit werkt niet:
code:
1
2
3
4
    "tax_refund": {
      "2000-01-01": true,
      "2027-01-01": false
    },
Ik zie in de implementatie ook niet hoe ik het met dit veld zou moeten doen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    multiplier_production: Optional[dict[str, float]] = Field(
        default={"2000-01-01": 1.0},
        alias="multiplier production",
        description="Multiplier for production by date (YYYY-MM-DD -> x.xx)",
        json_schema_extra={
            "x-help": "Multiplier on feed-in/production day-ahead price indexed by effective date. Format: {'2024-01-01': 0.94}.",
            "x-unit": "-",
            "x-ui-section": "Cost",
            "x-validation-hint": "Dict with YYYY-MM-DD keys, float -100.0 - +100.0 values",
        },
    )
....
    tax_refund: bool = Field(
        default=True,
        alias="tax refund",
        description="Whether tax refund applies",
        json_schema_extra={
            "x-help": "Enable tax refund calculation if eligible. Some regions/users get energy tax refunds for solar production.",
            "x-ui-section": "Taxes",
        },
    )
Die andere velden die je op datum kan instellen zijn dicts, tax_refund is boolean.
Is het dit niet?
code:
1
2
3
4
    "energy_taxes_production": {
      "2026-04-01": 0.09161,
      "2027-01-01": 0.0
    },

  • TheMystery
  • Registratie: Februari 2004
  • Laatst online: 01:23
Dogooder schreef op donderdag 6 augustus 2026 @ 23:17:
Hi @vlix, ik denk dat er meerdere zaken door elkaar lopen. Ik zal je proberen te helpen @KC27 correct me if i'm wrong.

1. Ik had mij in eerste instantie (de eerste 10 maanden van mijn DAO gebruik) hier ook in vergist. Maar het moet dus de energie zijn die in en uit je omvormer gaat aan de grid zijde. Als je je huis op de loadzijde hebt dan moet je die ook meenemen denk ik, maar dan heb je eigenlijk je baseload al. Wellicht dat de naamgeving beter kan, iets van entities_system_production?

2. baseload = grid consumption − grid production + battery_out − battery_in [+ pv_ac] − ev − wp − boil − machines.
entities_solar_production_dc wordt nergens voor gebruikt in de reports of baseload.
battery_out en battery_in zijn dus eigenlijk system_in en system_out.

3. baseload en reports gebruiken dezelfde waardes.

4. Correct

5. Hier gaan dingen door elkaar lopen. Ik heb mij klein beetje ingelezen in de alphaess en kom tot een snelle conclusie. Controleer dit zeker. Ik weet ook niet of jij je huis aan de grid zijde hebt of aan de load zijde. Maar je hebt dus de waarde nodig gemeten door de interne meters van de inverter aan de AC stekker. Volgens mijn korte research is dat:
sensor.alphaess_total_generation
voor alles wat je systeem verlaat. entities_battery_production / battery_out(in de baseload)
sensor.alphaess_grid_charge_total
voor alles wat je systeem in gaat. entities_battery_consumption / battery_in(in de baseload)

Na het bijwerken van entities in de config, restart DAO. Zie mijn eerder post ander blijven de oude entitiewaardes in gebruik en wordt je nog verder het bos in gestuurd.

6. Voor zover ik weet is het correct wat je zegt.

Ik hoop heel erg dat bovenstaande je verder helpt.
Ik gebruik deze met mijn AlphaESS:
JSON:
1
2
3
4
5
6
"entities_battery_consumption": [
      "sensor.alphaess_total_energy_charge_battery"
    ],
    "entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
    ],

  • rescla
  • Registratie: November 2012
  • Laatst online: 23:23
thomvh schreef op vrijdag 7 augustus 2026 @ 15:33:
[...]

Is het dit niet?
code:
1
2
3
4
    "energy_taxes_production": {
      "2026-04-01": 0.09161,
      "2027-01-01": 0.0
    },
Hmm, dat zal wel werken denk ik. Ik zat met tax_refund in m'n hoofd, maar ja, eigenlijk is de situatie dat er gewoon geen energiebelasting zit op geproduceerde stroom.

  • Impossibl3
  • Registratie: November 2012
  • Laatst online: 21:42
rescla schreef op vrijdag 7 augustus 2026 @ 16:14:
[...]

Hmm, dat zal wel werken denk ik. Ik zat met tax_refund in m'n hoofd, maar ja, eigenlijk is de situatie dat er gewoon geen energiebelasting zit op geproduceerde stroom.
Zo heb ik het in mijn config staan.

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

rescla schreef op vrijdag 7 augustus 2026 @ 16:14:
[...]

Hmm, dat zal wel werken denk ik. Ik zat met tax_refund in m'n hoofd, maar ja, eigenlijk is de situatie dat er gewoon geen energiebelasting zit op geproduceerde stroom.
En dan zijn er nog twee onderdelen die je wellicht moet aanpassen afhankelijk van wat jouw leverancier gaat doen:
  1. vat_production: staat nu op 21 en gaat waarschijnlijk naar 0 op 2027-01-01.
  2. cost_supplier_production: afhankelijk van het antwoord op de vraag: gaat jouw leverancier j́ou nog kosten in rekening brengen voor het terugleveren van elektriciteit. Zoja dan moet je hier een negatief bedrag invullen.
Dus hou de berichten van je leverancier in de gaten.

[ Voor 4% gewijzigd door KC27 op 07-08-2026 17:18 ]

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


  • rescla
  • Registratie: November 2012
  • Laatst online: 23:23
KC27 schreef op vrijdag 7 augustus 2026 @ 17:16:
[...]

En dan zijn er nog twee onderdelen die je wellicht moet aanpassen afhankelijk van wat jouw leverancier gaat doen:
  1. vat_production: staat nu op 21 en gaat waarschijnlijk naar 0 op 2027-01-01.
  2. cost_supplier_production: afhankelijk van het antwoord op de vraag: gaat jouw leverancier j́ou nog kosten in rekening brengen voor het terugleveren van elektriciteit. Zoja dan moet je hier een negatief bedrag invullen.
Dus hou de berichten van je leverancier in de gaten.
Ik ben BTW plichtig dus ik vermoed dat het gewoon 21 procent blijft, al dan niet 0%/verlegd op het factuur. Maar dat zal hopelijk in de loop van het jaar nog duidelijk worden.

Ik zit nu bij budget energie, maar de propositie voor volgend jaar is wel behoorlijk anders qua handelen. Dus tegen die tijd maar weer even goed gaan vergelijken.

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
Hartelijk dank @Dogooder en @KC27 voor jullie verhelderende antwoorden.
Dogooder schreef op donderdag 6 augustus 2026 @ 23:17:
5. Hier gaan dingen door elkaar lopen. Ik heb mij klein beetje ingelezen in de alphaess en kom tot een snelle conclusie. Controleer dit zeker. Ik weet ook niet of jij je huis aan de grid zijde hebt of aan de load zijde. Maar je hebt dus de waarde nodig gemeten door de interne meters van de inverter aan de AC stekker. Volgens mijn korte research is dat:
sensor.alphaess_total_generation
voor alles wat je systeem verlaat. entities_battery_production / battery_out(in de baseload)
sensor.alphaess_grid_charge_total
voor alles wat je systeem in gaat. entities_battery_consumption / battery_in(in de baseload)
Deze twee sensors heb ik helaas niet. Waarschijnlijk is wat jij gevonden hebt een andere integration dan degene die ik gebruik. Ik gebruik de Hillview AlphaESS integration via Modbus (https://projects.hillviewlodge.ie/alphaess/). Evengoed weet ik nu iets beter waar ik naar moet zoeken.
KC27 schreef op vrijdag 7 augustus 2026 @ 00:26:


Het lijkt er op dat er nog een sensor moet zijn die de totale teruglevering van de omvormer van je batterij meet.
Welke HA integratie voor je batterij gebruik je?
Misschien kan ik meekijken in de documentatie?
Ik gebruik dus de Hillview integratie (https://projects.hillviewlodge.ie/alphaess/). Als je eens wil kijken: heel graag! Ik ga intussen zelf ook nog eens op zoek...
TheMystery schreef op vrijdag 7 augustus 2026 @ 15:55:
[...]


Ik gebruik deze met mijn AlphaESS:
JSON:
1
2
3
4
5
6
"entities_battery_consumption": [
      "sensor.alphaess_total_energy_charge_battery"
    ],
    "entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
    ],
@TheMystery ja ik weet dat jij die gebruikt, want ik heb in de basis jouw configuratie gestolen geleend :P _/-\o_ . Maar ik krijg dan dus hele gekke negatieve waardes in de baseload berekening, áls ik tenminste mijn pv input neerzet onder "entities_solar_production_dc" ipv "entities_solar_production_ac". Volgens mij schreef jij dat je zelf AC gebruikt, en je ouders DC. Dus misschien moet jij dit in de config van je ouders ook maar eens controleren, zou zomaar kunnen dat je daar ook negatieve waardes krijgt?

Only connect...


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
Ik deel met jullie ook even wat mijn AI hulpje ervan vindt:
I read the latest posts. They clarify the issue substantially, and I need to revise one part of our earlier diagnosis.

The key clarification from both Dogooder and KC27 is that DAO’s unfortunately named entities_battery_production and entities_battery_consumption are not supposed to be battery-cell charge/discharge counters for a hybrid inverter. They are supposed to represent the energy crossing the inverter’s AC/grid-side connection. KC27 describes entities_battery_production as the inverter’s delivery to the house/grid side, and confirms the baseload formula is: grid import − grid export + inverter output − inverter input + AC-coupled PV − separately modelled loads. entities_solar_production_dc deliberately does not participate in this calculation. (Tweakers Gathering)

That means our present configuration is wrong here:
JSON:
1
2
3
4
5
6
"entities_battery_consumption": [
  "sensor.alphaess_total_energy_charge_battery"
],
"entities_battery_production": [
  "sensor.alphaess_total_energy_discharge_battery"
]
Those really are battery charge/discharge counters. They do not represent all energy crossing the AlphaESS inverter's AC connection. That's exactly why the DC PV disappears from the baseload equation: when PV goes DC → inverter → house/grid, DAO expects that energy to already appear in battery_production—better thought of as system_production. (Tweakers Gathering)

So the intended topology is effectively:
code:
1
2
3
4
5
DC PV ──┐
        ├── AlphaESS hybrid inverter ── AC output ── house/grid
Battery ┘
                               ↑
                   entities_battery_production
and in the reverse direction:
code:
1
2
3
grid/house AC ──> AlphaESS inverter ──> battery
                        ↑
            entities_battery_consumption
This also explains why putting your PV sensor into entities_solar_production_ac made the baseload appear correct: you were manually adding back the missing DC-PV energy, but that was compensating for using the wrong inverter-flow sensor. Once the correct whole-inverter AC output is used, adding DC PV separately would double-count it. (Tweakers Gathering)
The particularly useful new discovery
I also checked the current Hillview integration and AlphaESS's Modbus register documentation.

The official AlphaESS Modbus register list contains exactly the two measurements DAO wants:
code:
1
2
0x0502–0x0503   Total energy INV output   kWh
0x0504–0x0505   Total energy INV input    kWh
They are distinct from:
code:
1
2
3
0x0506–0x0507   Total energy battery output
0x0508–0x0509   Total energy battery input
0x050A–0x050B   Total PV energy
(projects.hillviewlodge.ie)

That is an almost perfect match to KC27's explanation.

However, I downloaded and inspected the current Hillview integration_alpha_ess.yaml, and Hillview currently exposes things such as:
code:
1
2
3
4
5
sensor.alphaess_total_energy_charge_battery
sensor.alphaess_total_energy_discharge_battery
sensor.alphaess_total_energy_from_pv
sensor.alphaess_total_energy_feed_to_grid_meter
sensor.alphaess_total_energy_consumption_from_grid_meter
but it does not appear to expose the Total energy INV output and Total energy INV input registers from 0x0502 and 0x0504.

So I think we have finally identified the actual missing piece:
code:
1
2
3
4
DAO itself probably isn't missing DC PV from the baseload formula.

Our Hillview/DAO mapping is missing the
WHOLE-INVERTER AC input/output energy counters.
Your latest Tweakers post correctly asks KC27 to look at the Hillview integration. (Tweakers Gathering)
One caution before we simply add those registers
The AlphaESS register document labels that particular 0x0500 register block as “Household Inverter (Only for Byte Watt)”. (projects.hillviewlodge.ie) So I don't want to assume without testing that your SMILE-G3-T10 returns meaningful values from 0x0502/0x0504.

But this is now the test I would perform next.

If your inverter supports those two registers, we'd want Home Assistant entities equivalent to:
code:
1
2
sensor.alphaess_total_energy_inverter_output
sensor.alphaess_total_energy_inverter_input
and DAO would become:
JSON:
1
2
3
4
5
6
"entities_battery_consumption": [
  "sensor.alphaess_total_energy_inverter_input"
],
"entities_battery_production": [
  "sensor.alphaess_total_energy_inverter_output"
]
while keeping:
JSON:
1
2
3
4
"entities_solar_production_dc": [
  "sensor.alphaess_total_energy_from_pv"
],
"entities_solar_production_ac": []
The DC sensor would still be useful for reporting/topology, but it would not be part of the automatic baseload formula—as KC27 says is intended.

So the latest forum discussion has moved us from “DAO has a major DC-PV baseload bug” to a much more specific and plausible diagnosis: the labels battery_production/consumption are misleading for hybrid systems, and our Hillview integration currently doesn't expose the inverter-wide AC energy counters DAO expects. (Tweakers Gathering)

I would wait for KC27's response to your latest post, but in parallel we can safely investigate whether your G3-T10 actually responds to Modbus registers 0x0502 and 0x0504. If it does, this may be a very clean fix.
Als de AI het goed heeft gesnapt dan bestaan de benodigde sensors dus niet in de Hillview integratie. De maker van de Hillview integratie is volgens mij ook actief op Tweakers dus misschien dat ik die dan maar eens ga vragen of hij kan helpen...

Only connect...


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

Dogooder

dus...

vlix schreef op zaterdag 8 augustus 2026 @ 17:22:
Hartelijk dank @Dogooder en @KC27 voor jullie verhelderende antwoorden.


[...]

Deze twee sensors heb ik helaas niet. Waarschijnlijk is wat jij gevonden hebt een andere integration dan degene die ik gebruik. Ik gebruik de Hillview AlphaESS integration via Modbus (https://projects.hillviewlodge.ie/alphaess/). Evengoed weet ik nu iets beter waar ik naar moet zoeken.


[...]

Ik gebruik dus de Hillview integratie (https://projects.hillviewlodge.ie/alphaess/). Als je eens wil kijken: heel graag! Ik ga intussen zelf ook nog eens op zoek...


[...]

@TheMystery ja ik weet dat jij die gebruikt, want ik heb in de basis jouw configuratie gestolen geleend :P _/-\o_ . Maar ik krijg dan dus hele gekke negatieve waardes in de baseload berekening, áls ik tenminste mijn pv input neerzet onder "entities_solar_production_dc" ipv "entities_solar_production_ac". Volgens mij schreef jij dat je zelf AC gebruikt, en je ouders DC. Dus misschien moet jij dit in de config van je ouders ook maar eens controleren, zou zomaar kunnen dat je daar ook negatieve waardes krijgt?
Aangezien hillview 'gewoon' een yaml integratie is zou ik aan je AI hulp vragen of hij de twee gevraagde sensors kan toevoegen. Dat is voor AI een peulenschil.

  • TheMystery
  • Registratie: Februari 2004
  • Laatst online: 01:23
vlix schreef op zaterdag 8 augustus 2026 @ 17:22:
Hartelijk dank @Dogooder en @KC27 voor jullie verhelderende antwoorden.


[...]

Deze twee sensors heb ik helaas niet. Waarschijnlijk is wat jij gevonden hebt een andere integration dan degene die ik gebruik. Ik gebruik de Hillview AlphaESS integration via Modbus (https://projects.hillviewlodge.ie/alphaess/). Evengoed weet ik nu iets beter waar ik naar moet zoeken.


[...]

Ik gebruik dus de Hillview integratie (https://projects.hillviewlodge.ie/alphaess/). Als je eens wil kijken: heel graag! Ik ga intussen zelf ook nog eens op zoek...


[...]

@TheMystery ja ik weet dat jij die gebruikt, want ik heb in de basis jouw configuratie gestolen geleend :P _/-\o_ . Maar ik krijg dan dus hele gekke negatieve waardes in de baseload berekening, áls ik tenminste mijn pv input neerzet onder "entities_solar_production_dc" ipv "entities_solar_production_ac". Volgens mij schreef jij dat je zelf AC gebruikt, en je ouders DC. Dus misschien moet jij dit in de config van je ouders ook maar eens controleren, zou zomaar kunnen dat je daar ook negatieve waardes krijgt?
Staat hier al meer over geschreven dat dc niet meegenomen wordt in de baseload dus die heb ik bij mijn ouders bij ac gezet en dan werkt de baseload prima, anders idd negatieve waardes.
JSON:
1
2
3
    "entities_solar_production_ac": [
      "sensor.alphaess_total_energy_from_pv"
    ],
En heb jij verder al automatiseringen gemaakt binnen ha die de planning van dao volgt?
Ik heb het nu denk ik helemaal werkend.

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
Dogooder schreef op zaterdag 8 augustus 2026 @ 19:46:
[...]

Aangezien hillview 'gewoon' een yaml integratie is zou ik aan je AI hulp vragen of hij de twee gevraagde sensors kan toevoegen. Dat is voor AI een peulenschil.
Daar heb je natuurlijk een heel goed punt 8)7. Zo gezegd, zo gedaan, en nu heb ik inderdaad de juiste sensors in mijn DAO config staan. Helaas klopt er op dit moment nog steeds niets van de baseload berekening omdat er eerst weer opnieuw historische data moet worden opgebouwd. Maar da's een kwestie van een weekje of wat geduld hebben, en in de tussentijd heb ik met behulp van mijn oude data een nauwkeurige tabel gegenereerd voor handmatige baseload invoer. Dat voldoet wel totdat ik weer genoeg historische data heb opgebouwd.
TheMystery schreef op zaterdag 8 augustus 2026 @ 20:34:
[...]

En heb jij verder al automatiseringen gemaakt binnen ha die de planning van dao volgt?
Ik heb het nu denk ik helemaal werkend.
Ja ik maak dus dankbaar gebruik van licht aangepaste versies van jouw drie automatiseringen. Bovendien heb ik op advies van mijn AI overlord nog een vierde automatisering toegevoegd om een eventueel draaiende mode-2 dispatch af te breken wanneer DAO de "entity balance switch" aan zet.

Only connect...


  • TheMystery
  • Registratie: Februari 2004
  • Laatst online: 01:23
vlix schreef op zondag 9 augustus 2026 @ 11:04:
[...]

Daar heb je natuurlijk een heel goed punt 8)7. Zo gezegd, zo gedaan, en nu heb ik inderdaad de juiste sensors in mijn DAO config staan. Helaas klopt er op dit moment nog steeds niets van de baseload berekening omdat er eerst weer opnieuw historische data moet worden opgebouwd. Maar da's een kwestie van een weekje of wat geduld hebben, en in de tussentijd heb ik met behulp van mijn oude data een nauwkeurige tabel gegenereerd voor handmatige baseload invoer. Dat voldoet wel totdat ik weer genoeg historische data heb opgebouwd.


[...]

Ja ik maak dus dankbaar gebruik van licht aangepaste versies van jouw drie automatiseringen. Bovendien heb ik op advies van mijn AI overlord nog een vierde automatisering toegevoegd om een eventueel draaiende mode-2 dispatch af te breken wanneer DAO de "entity balance switch" aan zet.
Welke entiteit heb je nog aan de yaml config toegevoegd? Want volgens mij is er toch geen andere pv entiteit aan de ac kant?

Mijn automatisering vangt de balance switch toch gewoon af, op dat moment wordt de automatisering namelijk niet getriggered en gaat de standaard nom modus draaien.

Ik heb mijn automatiseringen nu aangepast naar 15 min prijzen aangezien Zonneplan over is gegaan, hierdoor ging er wat fout wat met uur prijzen niet zo opviel, maar met 15 min out of range ging. Hierdoor ben ik over gestapt van de ac + pv berekening naar from battery, had ik in begin ook eens gedaan maar liep toen niet zoals ik wilde maar toen miste ik de 2 andere automatiseringen nog.
Verder viel me op met 15 min elke keer dat dispatch uit en aangezet werdt er even nom getriggerd werdt dat de accu altijd met vol vermogen even een export doet, dat heb ik nu ook opgelost, viel me op als je tijd aanpast dat dispatch dan niet uit hoeft, de timer start dan namelijk opnieuw, dus zet nu eerst tijd op 1 min en daarna weer op 15 min. Hierbij mijn ge-update automatiseringen:
YAML:
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
alias: "DAO: AlphaESS Mode 2"
description: Elk kwartier DAO planning doorsturen naar Hillview dispatch mode 2
triggers:
  - minutes: /15
    seconds: "15"
    trigger: time_pattern
conditions:
  - condition: template
    value_template: |
      {{ states('input_select.dao_set_operating_mode') != 'Uit' }}
  - condition: template
    value_template: |
      {{ not (states('input_select.dao_set_operating_mode') == 'Aan' 
         and states('input_boolean.dao_balance_switch') == 'on') }}
actions:
  - variables:
      dao_power: "{{ states('input_number.dao_from_battery') | float(0) }}"
      stop_time: "{{ states('input_datetime.dao_stop_inverter') }}"
      duration: |-
        {% if stop_time == '2000-01-01 00:00:00' %}15 {% else %}
          {% set stop = strptime(stop_time, '%Y-%m-%d %H:%M:%S') | as_local %}
          {% set now_dt = now().replace(second=0, microsecond=0) %}
          {% set diff = (stop - now_dt).total_seconds() / 60 %}
          {% if diff < 1 or diff > 15 %}15
          {% else %}{{ diff | int }}
          {% endif %}
        {% endif %}
      hillview_power: |-
        {% set dur = duration | int(15) %} {% if dur < 15 %}
          {% set power = (dao_power / 1000 * 15 / dur) | round(1) %}
          {{ [[power, 10.0] | min, -10.0] | max }}
        {% else %}
          {{ (dao_power / 1000) | round(1) }}
        {% endif %}
      hillview_soc: >-
        {% set base_soc = states('input_number.dao_calculated_soc') | int(0) %}
        {% set p = hillview_power | float(0) %} {% if p > 0 %}
          {{ [base_soc - 2, 15] | max }}
        {% elif p < 0 %}
          {{ [base_soc + 2, 100] | min }}
        {% else %}
          {{ base_soc }}
        {% endif %}
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 1
    action: input_number.set_value
  - delay: "00:00:01"
  - target:
      entity_id: number.alphaess_template_dispatch_power
    data:
      value: "{{ hillview_power }}"
    action: number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_cutoff_soc
    data:
      value: "{{ hillview_soc }}"
    action: input_number.set_value
  - target:
      entity_id: input_select.alphaess_helper_dispatch_mode
    data:
      option: State of Charge Control (2)
    action: input_select.select_option
  - delay: "00:00:01"
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: "{{ duration }}"
    action: input_number.set_value
  - condition: state
    entity_id: input_boolean.alphaess_helper_dispatch
    state: "off"
  - target:
      entity_id: input_boolean.alphaess_helper_dispatch
    action: input_boolean.turn_on
mode: single
YAML:
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
alias: "Dao: DAO off"
description: Mode 2 met power 0 als DAO uitgeschakeld is
triggers:
  - minutes: /15
    seconds: "15"
    trigger: time_pattern
conditions:
  - condition: template
    value_template: |
      {{ states('input_select.dao_set_operating_mode') == 'Uit' }}
  - condition: template
    value_template: |
      {{ states('input_number.dao_from_pv') | float(0) < 50 }}
actions:
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 1
    action: input_number.set_value
  - delay: "00:00:01"
  - target:
      entity_id: number.alphaess_template_dispatch_power
    data:
      value: 0
    action: number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_cutoff_soc
    data:
      value: "{{ states('input_number.dao_calculated_soc') | int(0) }}"
    action: input_number.set_value
  - target:
      entity_id: input_select.alphaess_helper_dispatch_mode
    data:
      option: State of Charge Control (2)
    action: input_select.select_option
  - delay: "00:00:01"
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 15
    action: input_number.set_value
  - condition: state
    entity_id: input_boolean.alphaess_helper_dispatch
    state: "off"
  - target:
      entity_id: input_boolean.alphaess_helper_dispatch
    action: input_boolean.turn_on
mode: single
YAML:
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
alias: "Dao: Dispatch off"
description: Mode 2 met power 0 als DAO dispatch uit gaat
triggers:
  - trigger: state
    entity_id:
      - input_boolean.alphaess_helper_dispatch
    to:
      - "off"
conditions:
  - condition: template
    value_template: >-
      {% set trigger_id = trigger.to_state.context.id %} {% set veroorzaker =
      states.automation
         | selectattr('context.id', 'eq', trigger_id)
         | map(attribute='entity_id') | first %}
      {{ veroorzaker !=
      'automation.dao_alphaess_mode_2'
         and veroorzaker != 'automation.dao_dao_off' }}
  - condition: not
    conditions:
      - condition: state
        entity_id: input_select.dao_set_operating_mode
        state: Uit
  - condition: state
    entity_id: input_boolean.dao_balance_switch
    state: "off"
actions:
  - target:
      entity_id: number.alphaess_template_dispatch_power
    data:
      value: 0
    action: number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 15
    action: input_number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_cutoff_soc
    data:
      value: "{{ states('input_number.dao_calculated_soc') | int(0) }}"
    action: input_number.set_value
  - target:
      entity_id: input_select.alphaess_helper_dispatch_mode
    data:
      option: State of Charge Control (2)
    action: input_select.select_option
  - target:
      entity_id: input_boolean.alphaess_helper_dispatch
    action: input_boolean.turn_on
mode: single

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
TheMystery schreef op zondag 9 augustus 2026 @ 11:33:
[...]


Welke entiteit heb je nog aan de yaml config toegevoegd? Want volgens mij is er toch geen andere pv entiteit aan de ac kant?
Ik heb de volgende entiteiten aan de Hillview yaml toegevoegd:
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
      # TEST - Household Inverter register block 0x0500

      - name: AlphaESS Test Grid Rated Voltage 0500
        unique_id: AlphaESS_Test_Grid_Rated_Voltage_0500
        slave: !secret alphaess_modbus_slaveId
        address: 0x0500
        data_type: uint16
        unit_of_measurement: V
        device_class: voltage
        state_class: measurement
        scan_interval: 60
        scale: 0.1
        precision: 1

      - name: AlphaESS Test Grid Rated Frequency 0501
        unique_id: AlphaESS_Test_Grid_Rated_Frequency_0501
        slave: !secret alphaess_modbus_slaveId
        address: 0x0501
        data_type: uint16
        unit_of_measurement: Hz
        device_class: frequency
        state_class: measurement
        scan_interval: 60
        scale: 0.01
        precision: 2

      - name: AlphaESS Test Total Energy INV Output 0502
        unique_id: AlphaESS_Test_Total_Energy_INV_Output_0502
        slave: !secret alphaess_modbus_slaveId
        address: 0x0502
        data_type: uint32
        unit_of_measurement: kWh
        device_class: energy
        state_class: total_increasing
        scan_interval: 60
        scale: 0.1
        precision: 1

      - name: AlphaESS Test Total Energy INV Input 0504
        unique_id: AlphaESS_Test_Total_Energy_INV_Input_0504
        slave: !secret alphaess_modbus_slaveId
        address: 0x0504
        data_type: uint32
        unit_of_measurement: kWh
        device_class: energy
        state_class: total_increasing
        scan_interval: 60
        scale: 0.1
        precision: 1
Die eerste twee zijn niet belangrijk, maar die laatste twee zijn exact wat DAO wil hebben: totale output respectievelijk input aan de AC kant van de omvormer.

In mijn DAO config staat nu dus dit:
code:
1
2
3
4
5
6
"entities_battery_consumption": [
  "sensor.alphaess_test_total_energy_inv_input_0504"
],
"entities_battery_production": [
  "sensor.alphaess_test_total_energy_inv_output_0502"
]
Mijn automatisering vangt de balance switch toch gewoon af, op dat moment wordt de automatisering namelijk niet getriggered en gaat de standaard nom modus draaien.
Als ik het goed begrijp is die vierde automatisering voor een edge case waarin mode-2 dispatch al actief is op het moment dat de balance switch op "aan" wordt gezet. Op dat moment zal de automatisering per direct mode 5 forceren.

Dit is 'm:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
alias: DAO → AlphaESS Balance
description: >
  Returns AlphaESS to its normal self-consumption/load-following behaviour
  whenever DAO requests grid balancing.
triggers:
  - trigger: state
    entity_id: input_boolean.dao_balance_switch
    to: "on"
  - trigger: time_pattern
    minutes: /15
    seconds: "45"
conditions:
  - condition: state
    entity_id: input_select.dao_set_operating_mode
    state: Aan
  - condition: state
    entity_id: input_boolean.dao_balance_switch
    state: "on"
actions:
  - action: input_boolean.turn_off
    target:
      entity_id: input_boolean.alphaess_helper_dispatch
mode: restart
Ik heb mijn automatiseringen nu aangepast naar 15 min prijzen aangezien Zonneplan over is gegaan, hierdoor ging er wat fout wat met uur prijzen niet zo opviel, maar met 15 min out of range ging. Hierdoor ben ik over gestapt van de ac + pv berekening naar from battery, had ik in begin ook eens gedaan maar liep toen niet zoals ik wilde maar toen miste ik de 2 andere automatiseringen nog.
Ja ik heb de boel ook aangepast naar 15 minuten prijzen, dat is de voornaamste wijziging die ik heb gemaakt.
Verder viel me op met 15 min elke keer dat dispatch uit en aangezet werdt er even nom getriggerd werdt dat de accu altijd met vol vermogen even een export doet, dat heb ik nu ook opgelost, viel me op als je tijd aanpast dat dispatch dan niet uit hoeft, de timer start dan namelijk opnieuw, dus zet nu eerst tijd op 1 min en daarna weer op 15 min. Hierbij mijn ge-update automatiseringen:
Hmm, ik zal eens kijken of ik hetzelfde gedrag zie. Dank voor de updates!

Only connect...


  • Domba
  • Registratie: Januari 2005
  • Laatst online: 21:34
Waar stel je timezone voor DAO in?

Optimalisatie voor 1 uur interval gaat goed met Optimaliseringsberekening met debug op een of andere manier zowel manueel als schedule.

Maar optimalisatie run met kwartier interval geeft ontbrekende kwartierdata als fout
volgens debug log is het eerste kwartier die opgehaald wordt van HA zonder timezone +2 uur (Amsterdam)
([ { 'end': datetime.datetime(2026, 8, 9, 22, 15, tzinfo=tzutc()),
'start': datetime.datetime(2026, 8, 9, 22, 0, tzinfo=tzutc()),
'value': 154.45},

DAO 2026.6.0 / DA&HA DB sqlite / Nordpool / HA als VM op Proxmox

Edit: optimalisatie rapport zoals voor 1 uur interval geeft wel de correcte NL-tijd achter berekend op: xx:xx (en niet de UTC)

[ Voor 10% gewijzigd door Domba op 09-08-2026 14:18 ]

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

Domba schreef op zondag 9 augustus 2026 @ 14:08:
Waar stel je timezone voor DAO in?

Optimalisatie voor 1 uur interval gaat goed met Optimaliseringsberekening met debug op een of andere manier zowel manueel als schedule.

Maar optimalisatie run met kwartier interval geeft ontbrekende kwartierdata als fout
volgens debug log is het eerste kwartier die opgehaald wordt van HA zonder timezone +2 uur (Amsterdam)
([ { 'end': datetime.datetime(2026, 8, 9, 22, 15, tzinfo=tzutc()),
'start': datetime.datetime(2026, 8, 9, 22, 0, tzinfo=tzutc()),
'value': 154.45},

DAO 2026.6.0 / DA&HA DB sqlite / Nordpool / HA als VM op Proxmox

Edit: optimalisatie rapport zoals voor 1 uur interval geeft wel de correcte NL-tijd achter berekend op: xx:xx (en niet de UTC)
DAO haalt timezone op uit Home Assistant.

Als je prijzen gaat ophalen na 13:00 uur haalt hij automatisch de prijzen van morgen op
Voor de prijzen van vandaag moet je in het eerste veld de datum van vandaag invullen.

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


  • TheMystery
  • Registratie: Februari 2004
  • Laatst online: 01:23
vlix schreef op zondag 9 augustus 2026 @ 13:10:
[...]

Ik heb de volgende entiteiten aan de Hillview yaml toegevoegd:


[...]

Die eerste twee zijn niet belangrijk, maar die laatste twee zijn exact wat DAO wil hebben: totale output respectievelijk input aan de AC kant van de omvormer.

In mijn DAO config staat nu dus dit:


[...]


[...]

Als ik het goed begrijp is die vierde automatisering voor een edge case waarin mode-2 dispatch al actief is op het moment dat de balance switch op "aan" wordt gezet. Op dat moment zal de automatisering per direct mode 5 forceren.

Dit is 'm:

[...]


[...]

Ja ik heb de boel ook aangepast naar 15 minuten prijzen, dat is de voornaamste wijziging die ik heb gemaakt.


[...]

Hmm, ik zal eens kijken of ik hetzelfde gedrag zie. Dank voor de updates!
Maar als dao de balance switch op aan zet en de automatisering draait doet de automatisering niets, een paar sec later zal de timer van de dispatch aflopen en nom gaan draaien, dus mij lijkt de 4de automatisering niet nodig.

Wat betreft de entiteiten voor de battery consumption en production moet je volgens mij toch deze hebben
JSON:
1
2
3
4
5
6
"entities_battery_consumption": [
      "sensor.alphaess_total_energy_charge_battery"
    ],
    "entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
    ],
Met die van jou mis je toch wat er dc in de accu gaat en gaat je baseload in de min.

En als je deze zo invult wordt de baseload in de plus:
JSON:
1
2
3
4
    "entities_solar_production_ac": [
      "sensor.alphaess_total_energy_from_pv"
    ],
    "entities_solar_production_dc": [],

  • Domba
  • Registratie: Januari 2005
  • Laatst online: 21:34
KC27 schreef op zondag 9 augustus 2026 @ 14:26:
[...]

DAO haalt timezone op uit Home Assistant.

Als je prijzen gaat ophalen na 13:00 uur haalt hij automatisch de prijzen van morgen op
Voor de prijzen van vandaag moet je in het eerste veld de datum van vandaag invullen.
Dat wordt dan wachten tot morgen
eerste en laatste was automatisch om 12:55 zonder data (daarna melding data al aanwezig)
daarvan ziet de log er goed uit
code:
1
2
3
4
2026-08-09 12:55:00 info: Day Ahead Optimalisering versie: 2026.6.0
2026-08-09 12:55:00 info: Day Ahead Optimalisering gestart op: 09-08-2026 12:55:00
2026-08-09 12:55:00 info: Day Ahead Optimalisatie gestart: 09-08-2026 12:55:00 taak: get_day_ahead_prices
2026-08-09 12:55:00 fout: Geen data van Nordpool: tussen 2026-08-09 00:00:00+02:00 en 2026-08-11 00:00:00+02:00
De manuele om 13:13 niet, die mist de laatste twee uur van morgen, manueel haalt niet met +2 uur op. RC2026.6.0
code:
1
2
3
4
5
 2026-08-09 13:13:56 info: Day Ahead Optimalisering versie: 2026.6.0
2026-08-09 13:13:56 info: Day Ahead Optimalisering gestart op: 09-08-2026 13:13:56
2026-08-09 13:13:56 info: Day Ahead Optimalisatie gestart: 09-08-2026 13:13:56 taak: get_day_ahead_prices
2026-08-09 13:13:56 info: Day ahead prijzen van Nordpool:
 [ { 'end': datetime.datetime(2026, 8, 9, 22, 15, tzinfo=tzutc()),

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 12-08 17:06
TheMystery schreef op zondag 9 augustus 2026 @ 14:48:
[...]


Maar als dao de balance switch op aan zet en de automatisering draait doet de automatisering niets, een paar sec later zal de timer van de dispatch aflopen en nom gaan draaien, dus mij lijkt de 4de automatisering niet nodig.
Het zal ook niet veel uitmaken, maar voor een AI is een paar seconden natuurlijk erg lang ;) .
Wat betreft de entiteiten voor de battery consumption en production moet je volgens mij toch deze hebben
JSON:
1
2
3
4
5
6
"entities_battery_consumption": [
      "sensor.alphaess_total_energy_charge_battery"
    ],
    "entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
    ],
Met die van jou mis je toch wat er dc in de accu gaat en gaat je baseload in de min.
Zie de eerdere posts hierboven. "entities_battery_consumption" en "entities_battery_production" hebben verwarrende namen, ze staan voor iets anders dan wat je zou denken:
KC27 schreef op vrijdag 7 augustus 2026 @ 00:26:
[...]

"entities_battery_production": de sensor(en) die de afgifte van de omvormer aan de meterkast meten (dus zonder de pv die richting de dc-bus gaat).
Ze staan dus voor de totale input en output van je hybride omvormer aan de AC-kant.
En als je deze zo invult wordt de baseload in de plus:
JSON:
1
2
3
4
    "entities_solar_production_ac": [
      "sensor.alphaess_total_energy_from_pv"
    ],
    "entities_solar_production_dc": [],
Ja maar ik heb dus geen zonnepanelen op AC zitten, alleen op DC.
KC27 schreef op vrijdag 7 augustus 2026 @ 00:26:
[...]

entities_solar_production_dc: de sensoren die de pv levering meten op dc-bus van je batterij
entities_solar_production_ac: de sensoren die de productie van je ac-gebonden pv (=pv die direct aan je huisnet leveren) meten, bij jou zijn er dus geen van dergelijke sensoren

Only connect...

Pagina: 1 ... 46 47 Laatste