Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[DaBit]

Vraag: is het zinvol om de DAO optimalisatie vaker dan eens per uur te laten draaien? Misschien alvast 1x per kwartier; daar gaat het toch naartoe.

De prijzen wijzigen niet vaker dan eens per uur, maar de energie-situatie buiten DAO om wel. Op dit moment vraagt DAO bijvoorbeeld om 11kW naar de accu toe, maar er gaat maar 7kW naartoe (omdat anders een fase overbelast raakt). Als DAO vaker optimaliseert zou dat beter ingepast worden lijkt me?

[KC27]

Ik denk: als er in een uur iets aan de situatie verandert (bijv. de belasting van een gelimiteerde fase neemt toe/af, de auto is vol, de auto komt thuis en moet geladen worden enz.) is het gewenst dat de optimaliseringsberekening wordt gestart.
Dat kan door hem eens per kwartier te triggeren. Het kan ook met een automation in HA die getriggerd wordt door een gewijzigde situatie en die dan onderstaand commando aanroept:
Ik heb daarvoor een rest_command aangemaakt in configuration.yaml:

YAML:

rest_command:
  start_dao_calc:
    url: http://192.168.178.36:5000/api/run/calc_zonder_debug
    verify_ssl: false

[decramy]

Sluit me aan bij bovenstaande. Is een kleine gedachte-tutorial op z'n plaats?

Iets als:
- wees in staat loads te sturen
- heb inzicht in opwekt en stroomtarieven
- begin klein met 1 load
- ...

[Robje1244]

KC27 schreef op zondag 6 april 2025 @ 08:57:
[...]

Kun je je instelling delen zonder je geheimen te delen?

Zie onderstaande code.

code:

"homeassistant": {
   "protocol api": "https",
   "ip adress": "domein.duckdns.org",
   "ip port": 443,
   "token": "!secret ha_api_token"

Domein moet je dus vervangen voor je eigen adres.

[tonvanboven]

DaBit schreef op zondag 6 april 2025 @ 13:23:
Vraag: is het zinvol om de DAO optimalisatie vaker dan eens per uur te laten draaien? Misschien alvast 1x per kwartier; daar gaat het toch naartoe.

De prijzen wijzigen niet vaker dan eens per uur, maar de energie-situatie buiten DAO om wel. Op dit moment vraagt DAO bijvoorbeeld om 11kW naar de accu toe, maar er gaat maar 7kW naartoe (omdat anders een fase overbelast raakt). Als DAO vaker optimaliseert zou dat beter ingepast worden lijkt me?

Ik heb deze gedachte precies zo gehad en in de tijd dat DAO nog op een aparte Linux machine moest lopen ook gedaan. Conclusie was dat het niet handig bleek te zijn. Dao bepaald nu op basis van uurprijzen precies de hoeveel energie dat in of uit de batterij moet gaan per uur (straks per kwartier). Als je tijdens dat uur opnieuw gaat rekenen ga je eigenlijk precies hetzelfde berekenen.

Waar we in het verleden wel tegenaan liepen was het voorbeeld van de EV, stel dat je één minuut over het uur de stekker in de auto stopt dan zou DOA pas 58 minuten later gaan bepalen wanneer de auto kan gaan laden terwijl het wellicht al in dat uur al gunstig was. Vandaar dat @KC27 een rest API heeft gemaakt om vanuit HA DOA even wakker kunt schudden. In mijn geval heb ik een 'connected car', maar je kunt ook denken aan andere mogelijkheden om te detecteren dat je auto is aangesloten.

[DaBit]

tonvanboven schreef op zondag 6 april 2025 @ 16:36:
Als je tijdens dat uur opnieuw gaat rekenen ga je eigenlijk precies hetzelfde berekenen.

Niet helemaal lijkt me.
De accu vult bijvoorbeeld door extere oorzaken niet zo snel als DAO verwacht dus die zal bij de volgende optimalisatie proberen om dezelfde SoC-verandering te bewerkstelligen in een kortere tijd. Of dat dan in een uur moet of in 1u45min kan verschil maken in laadvermodig/efficiency.

Ik zal het gewoon eens proberen. In het ergste geval berekent het spul 4x hetzelfde en is er nog geen man overboord.

[KC27]

Voor mensen die een nieuwe versie van DAO willen testen voordat ze worden gepubliceerd:
Op github staat in de addon-branche een testversie gereed: 2025.4.0.rc1.

Dit staat er in de changelog:

BREAKING CHANGE

Fixed the error (two hours too late) in the timestamp in the result-records from api/report-calls (thank @DaBit )
The optional parameter "expected" isn't used anymore The records now have a different structure:

• the attributes "realised" and "expected" are now in the record as datatype
• the attribute "time" now has a string presenting the date and time of the startmoment of the record
• the new atribute "time_ts" present the date and time as a timestamp in milliseconds.
• for instance a record of the price-info:

code:

    {
    "message": "Success",
    "data": [
      {
        "time_ts": 1743890400000,
        "time": "2025-04-06 00:00",
        "da_ex": 0.07045,
        "da_cons": 0.23290806,
        "da_prod": 0.23290806,
        "datatype": "recorded"
      },
      {
        "time_ts": 1743894000000,
        "time": "2025-04-06 01:00",
        "da_ex": 0.061,
        "da_cons": 0.22147356,
        "da_prod": 0.22147356,
        "datatype": "recorded"
      },
      .....

for instance the data-structure for a consumption request:

code:

    {"message": "Success",
    "data": [
      {
        "time_ts": 1743890400000,
        "time": "2025-04-06 00:00",
        "value": 0.653,
        "datatype": "recorded"
      },
      {
        "time_ts": 1743894000000,
        "time": "2025-04-06 01:00",
        "value": 0,
        "datatype": "recorded"
      },
      ...

Other fixes:

• Fixed warning when getting prices from Nordpool for a day with changing to/from daylight saving
• Fixed warning when calculating optimization for a day with changing to/from daylight saving

Als je mee wil testen en je weet niet hoe dat werkt: stuur me een dm.

[soepah]

@KC27 gave plugin, ik ga mee testen.
Denk dat ik op basis van de repo wel uit kom hoe ik het installeer, evt bij een update handig om dat in de Readme te zetten (quick howto install & configure for HA)

[KC27]

soepah schreef op maandag 7 april 2025 @ 10:18:
@KC27 gave plugin, ik ga mee testen.
Denk dat ik op basis van de repo wel uit kom hoe ik het installeer, evt bij een update handig om dat in de Readme te zetten (quick howto install & configure for HA)

In DOCS.md staat beschreven hoe je de addon installeert.
Ik zal in de README.md een directe verwijzing opnemen naar de installatie-paragraaf in DOCS.md.

De installatieparagraaf vind je ook met deze link:
https://github.com/cornee...n/dao/DOCS.md#installatie

De test-versie installeer je door als repository

code:

https://github.com/corneel27/day-ahead#addon

op te geven (dus met #addon erachter).

Belangrijk om te weten:

1. Je installeert hiermee een tweede versie van DAO naast je "productie-versie"
2. Geef de testversie een ander poort-nummer (bijv 5001) mee, dat kun je doen via "Configureer" op de informatiepagina van de addon.
3. Na installatie kun je je instellingen en secrets kopiëren van je productie-versie naar je testversie, waarna je de testversie beter een keer herstart.
4. Laat NOOIT de productie-versie en test-versie tegelijk rekenen of meteodata cq prijsdata ophalen, omdat dat mogelijk database-problemen en/of ha-problemen kan opleveren doordat tegelijkertijd dezelfde data worden opgeslagen/weggeschreven.

[verguldebarman]

@KC27 nu is het alleen mogelijk om DAO als HA add-on te installeren, maar dan moet je wel HA OS draaien. Ik draai HA in een container op Ubuntu....

Is het mogelijk om DAO ook als een losse docker container te draaien?

[tonvanboven]

verguldebarman schreef op dinsdag 8 april 2025 @ 12:57:
Is het mogelijk om DAO ook als een losse docker container te draaien?

@bvw @Marcjeno1 zijn hiermee bezig, kijk even terug in dit topic.

[mgroen81]

Robje1244 schreef op zondag 6 april 2025 @ 16:23:
[...]


Zie onderstaande code.

code:

"homeassistant": {
   "protocol api": "https",
   "ip adress": "domein.duckdns.org",
   "ip port": 443,
   "token": "!secret ha_api_token"

Domein moet je dus vervangen voor je eigen adres.

Wat is het nut om het zo te doen ipv:

code:

"homeassistant": {
    "protocol api": "http",
    "ip adress": "192.168.178.36",
    "ip port": 8123,
    "token": "!secret ha_api_token"

Ik gebruik ook duckdns om in HomeAssistant te komen.
Ik ga toch al via https van duckdns?

[ Voor 7% gewijzigd door mgroen81 op 08-04-2025 15:53 ]

[RudolfR]

@mgroen81

Misschien heb jij er nog een reverse proxy tussenzitten?
Ik niet, mijn HA is alleen bereikbaar via https.

YAML:

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

[mgroen81]

Ah ja. Ik heb NGINX ook draaien. Dus dan werkt het wel.

[hemertje]

Ter informatie

https://transparency.ents...=67efb3a4a2a7b927aeb0e4ef

Energinet transition to 15-minute Market Time Unit (MTU) April 9,2025 07.04.2025 07:48
Dear Transparency Platform users,

Energinet Announces Change in Time Resolution for Data Articles Effective Date: April 9, 2025

Energinet is excited to inform users of the ENTSO-E Transparency Platform about an upcoming change in the time resolution for several data articles due to the transition to 15-minute Market Time Unit (MTU) in Single Intraday Coupling (SIDC)​.
Starting from April 9, 2025, the time resolution for the following data articles will be changed from 60-minute to 15-minute MTU for BZN|DK1 and BZN|DK2:

* Generation Forecasts for Wind and Solar [TR 14.1.D]
* Actual Generation per Generation Unit [TR 16.1.A]
* Actual Generation per Production Type [TR 16.1.B&C]
* Total Load - Day Ahead / Actual [TR 6.1.A]
* Cross-Border Physical Flow [TR 12.1.G]
For examples of the data in 15-minute MTU, please see IOP ENTSO-E Transparency Platform.
Important Notice:

* During the night and morning hours of April 9, 2025, the data will not be available. The missing data will be published during the day.
* Time resolution for the data under Total Load - Day Ahead / Actual [TR 6.1.A] will be 15 minutes, but ENTSO-E Transparency Platform will show it as 60 minutes using an average. It is due to the adjacent data item (Day-ahead Total Load Forecast [TR 6.1.B]).
We appreciate your understanding and patience. For any questions or further information, please contact TPC Support.

Sincerely, the Transparency Platform team on behalf of Energinet

[bvw]

@KC27 Zou je me wat aanwijzingen kunnen geven met betrekking tot de warmtepomp?

Ik heb data van de warmtepomp van de COP vs. de buitentemperatuur en/of elektrisch opgenomen vermogen vs. buitentemperatuur. Wat lastiger is, het elektrisch opgenomen vermogen vs. de COP, want dat is een factor waar ik niet mee kan sturen. En als ik dat laatste bepaal bij 1 bepaalde buitentemperatuur, hoe schaal ik dat dan vs. andere buitentemperaturen?

COP vs. buitentemperatuur is bij benadering een rechte lijn tussen 4.6 bij 7 graden, 3.5 bij 2 graden volgens de manual van de warmtepomp, op basis van meetdata kan dit natuurlijk veel preciezer.

Verder kan ik de stooklijn aanpassen van de warmtepomp of 'm aan/uit regelen.

In de manual zag ik staan dat je de COP vs. buitentemp in "entity hp cop" kunt aangeven. Maar hoe laadt ik dan de curve in deze entity? dezelfde vraag voor de "entity hp power"

alvast dank :-)

[ Voor 12% gewijzigd door bvw op 08-04-2025 20:40 ]

[hemertje]

en hoe wordt de warmtepomp aangestuurd?

is dat via de optionele SG contacten?
of via MQTT commando's?

[KC27]

hemertje schreef op dinsdag 8 april 2025 @ 17:29:
Ter informatie

https://transparency.ents...=67efb3a4a2a7b927aeb0e4ef

Energinet transition to 15-minute Market Time Unit (MTU) April 9,2025 07.04.2025 07:48
Dear Transparency Platform users,


[...]

Dit geldt nog niet voor de day-ahead prijzen en tarieven.
Daarvan gaat de transitie in op 12 juni a.s. (op 11 juni wordt de eerste kwartieprijzen vastgesteld voor 12 juni).
Zie o.a. https://www.epexspot.com/...e-day-ahead-coupling-sdac
Ik ben al een heel eind op weg met een aangepaste van versie van DAO, maar deze is nog niet klaar.
De bedoeling van mij is wel dat je in de nieuwe versie bij de instellingen de keuze hebt tussen interval 1hour (huidige situatie) en 15min. Ik verwacht rond 1 mei een eerste testversie klaar te hebben.
Ik zal een link naar de repo daarvan hier posten en wie wil kan dan gaan testen. Op basis van jullie repons kan ik dan nog een en ander bijschaven.
Ideeën en suggesties zijn altijd welkom.

[KC27]

bvw schreef op dinsdag 8 april 2025 @ 20:38:
@KC27 Zou je me wat aanwijzingen kunnen geven met betrekking tot de warmtepomp?

Ik heb data van de warmtepomp van de COP vs. de buitentemperatuur en/of elektrisch opgenomen vermogen vs. buitentemperatuur. Wat lastiger is, het elektrisch opgenomen vermogen vs. de COP, want dat is een factor waar ik niet mee kan sturen. En als ik dat laatste bepaal bij 1 bepaalde buitentemperatuur, hoe schaal ik dat dan vs. andere buitentemperaturen?

COP vs. buitentemperatuur is bij benadering een rechte lijn tussen 4.6 bij 7 graden, 3.5 bij 2 graden volgens de manual van de warmtepomp, op basis van meetdata kan dit natuurlijk veel preciezer.

Verder kan ik de stooklijn aanpassen van de warmtepomp of 'm aan/uit regelen.

In de manual zag ik staan dat je de COP vs. buitentemp in "entity hp cop" kunt aangeven. Maar hoe laadt ik dan de curve in deze entity? dezelfde vraag voor de "entity hp power"

alvast dank :-)

Vanuit DAO kun je de warmtepomp met drie methoden aansturen:

1. Door de aanvoer- of retourtemperatuur van de stooklijn bij te stellen.Het beïnvloeden van de instelling van de kamerthermostaat kan met dezelfde methode.
2. Een aan/uit schakelaar waarmee je de warmtepomp dus aan- of uitzet
3. Een vermogen schakelaar, hiermee berekent DAO het elektrische vermogen van de warmtepomp voor het komende uur.

Voor alle drie geldt: DAO maakt een berekening en geeft deze door aan een helper in Home Assistant.
Het is dan aan jullie om hieraan dmv een automation en/of template dit met behulp van modbus, mqtt of anderszins (bijv relais) door te zetten naar je warmtepomp.

Ik zal alle methoden een voor een bespreken.

Stooklijn of kamertemperatuur instelling verschuiven

Je kiest deze methode door bij "adjustment" : "heating curve" in te vullen.
Ikzelf kan bij mijn warmtepomp alleen de stooklijn verschuiven, dus ik pas methode 1 toe.
Hiervoor heb ik een "simpel" algoritme in DAO zitten. DAO kijkt naar de relatieve afwijking van de prijs in het lopende uur ten opzichte van het etmaalgemiddelde van de prijs en op basis daarvan wordt de "verschuiving" berekent. Je stel bij de instellingen de .adjustment factor. Bijvoorbeeld "adjustment factor": 0.05
De betekenis daarvan lees terug in de toegepaste formule:
adjustment = -adjustment_factor * (price_act - price_avg) * 100 / price_avg
Dus ieder procent verschil heeft bij deze instelling 0,05 graden aanpassing van de stooklijn tot gevolg.

Vermogen

Vul bij de settings in "adjustment" : "power"
DAO rekent bij deze methode uit hoeveel warmte je nog nodig hebt om te verwarmen tot aan het einde van de planningshorizon. Dat doet DAO door voor de hele periode uit te rekenen hoeveel warmte je nodig hebt m.b.v. de graaddagen methode.
Je geeft daarvoor bij je instellingen op: "degree days factor" : 4,
Dat betekent het aantal thermische kWh jouw huis nodig heeft bij 1 graaddag.
Bij "entity hp heat produced": "sensor.daily_heat_production_heating", geef je de HA-sensor op die bijhoudt hoeveel je wp aan warmte in kWh produceert.
Het verschil tussen wat er nodig is en wat er al is geproduceerd zal nog moeten worden geproduceerd.
Verder moet het programma weten wat de efficiency (cop) van je warmtepomp is bij verschillende elektrische vermogens. Dat geef je op bij stages:

"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}
],

DAO rekent dan uit in welke uren en met welk vermogen de warmtepomp moet draaien om zo gunstig mogelijk de nog benodigde warmte te produceren.
Het berekende vermogen voor de lopende periode wordt aan HA gecommuniceerd met via de helper die je invult bij de instelling "entity hp power": "input_number.heatpump_calculated_power",

Aan/uit

Vul bij de settings in "adjustment" : "on/off"
Deze methode gaat rekenen als er warmtevraag is in de woning.
Daarvoor moet een entity worden geconfigureerd in HA waarvan je de naam opgeeft in de instellingen bij "entity hp heat demand". Als deze op aan/on/true of "1" staat wordt er gerekend.

De COP en het vermogen waarop de warmtepomp draait hangen af van de voorspelde buitentemperatuur en dienen door HA te worden berekend en aan DAO te worden doorgegeven middels de "entitity hp cop" en "entity hp power" entiteiten.
Om hier mee te kunnen werken zul je voor je woning door middel van metingen de relatie moeten vaststellen tussen de etmaal gemiddelde buitentemperatuur en de COP van je warmtepomp. Zie onderstaande grafiek als voorbeeld:

Bij een berekening door DAO zal DAO de voorspelde etmaalgemiddelde buitentemperatuur in °C wegschrijven naar de de entity die je hebt opgegeven bij "entity avg outside temp".
In HA maak je dan een automation die mbv van de relatie (=formule) uit die buitentemperatuur de COP berekent en deze berekende COP wordt door die automation weggeschreven in de entity die je opgeeft bij "entity hp cop".
Bij iedere gemiddelde buitentemperatuur hoort ook een berekend vermogen. Zie onderstaande grafiek:

Ook dat wordt door diezelfde automation berekend en weggeschreven naar een entiteit die je opgeeft bij de instelling "entity hp power"
O.a.met behulp van deze waarden rekent DAO dan uit of de wp aan of uit moet in het komende uur.
Om te voorkomen dat de wp te vaak aan/uit gaat (verkort de levensduur) kun je via de instelling "min run length" een minimaal aantal uren opgeven dat de wp achter elkaar moet draaien.
De uitkomst van de berekening gaat naar een entity waarvan je de naam opgeeft bij "entity hp switch".
Je zet dan de wp aan/uit middels een automation in HA. DAO rekent de optimale inzet van de warmtepomp uit.

[ Voor 20% gewijzigd door KC27 op 10-04-2025 00:03 ]

[bvw]

KC27 schreef op woensdag 9 april 2025 @ 00:17:
[...]

Vanuit DAO kun je de warmtepomp met drie methoden aansturen:

1. Door de aanvoer- of retourtemperatuur van de stooklijn bij te stellen.Het beïnvloeden van de instelling van de kamerthermostaat kan met dezelfde methode.
2. Een aan/uit schakelaar waarmee je de warmtepomp dus aan- of uitzet
3. Een vermogen schakelaar, hiermee berekent DAO het elektrische vermogen van de warmtepomp voor het komende uur.

Voor alle drie geldt: DAO maakt een berekening en geeft deze door aan een helper in Home Assistant.
Het is dan aan jullie om hieraan dmv een automation en/of template dit met behulp van modbus, mqtt of anderszins (bijv relais) door te zetten naar je warmtepomp.

Ik zal alle methoden een voor een bespreken.

Stooklijn of kamertemperatuur instelling verschuiven

Je kiest deze methode door bij "adjustment" : "heating curve" in te vullen.
Ikzelf kan bij mijn warmtepomp alleen de stooklijn verschuiven, dus ik pas methode 1 toe.
Hiervoor heb ik een "simpel" algoritme in DAO zitten. DAO kijkt naar de relatieve afwijking van de prijs in het lopende uur ten opzichte van het etmaalgemiddelde van de prijs en op basis daarvan wordt de "verschuiving" berekent. Je stel bij de instellingen de .adjustment factor. Bijvoorbeeld "adjustment factor": 0.05
De betekenis daarvan lees terug in de toegepaste formule:
adjustment = -adjustment_factor * (price_act - price_avg) * 100 / price_avg
Dus ieder procent verschil heeft bij deze instelling 0,05 graden aanpassing van de stooklijn tot gevolg.

Vermogen

Vul bij de settings in "adjustment" : "power"
DAO rekent bij deze methode uit hoeveel warmte je nog nodig hebt om te verwarmen tot aan het einde van de planningshorizon. Dat doet DAO door voor de hele periode uit te rekenen hoeveel warmte je nodig hebt m.b.v. de graaddagen methode.
Je geeft daarvoor bij je instellingen op: "degree days factor" : 4,
Dat betekent het aantal thermische kWh jouw huis nodig heeft bij 1 graaddag.
Bij "entity hp heat produced": "sensor.daily_heat_production_heating", geef je de HA-sensor op die bijhoudt hoeveel je wp aan warmte in kWh produceert.
Het verschil tussen wat er nodig is en wat er al is geproduceerd zal nog moeten worden geproduceerd.
Verder moet het programma weten wat de efficiency (cop) van je warmtepomp is bij verschillende elektrische vermogens. Dat geef je op bij stages:

"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}
],

DAO rekent dan uit in welke uren en met welk vermogen de warmtepomp moet draaien om zo gunstig mogelijk de nog benodigde warmte te produceren.
Het berekende vermogen voor de lopende periode wordt aan HA gecommuniceerd met via de helper die je invult bij de instelling "entity hp power": "input_number.heatpump_calculated_power",

Aan/uit

Vul bij de settings in "adjustment" : "on/off"
In DOCS,md staat een korte beschrijving.
Ik zal een deze dagen hier een uitgebreide beschrijving van geven.

Daarna zal ik het geheel (eventueel gecorrigeerd met jullie opmerkingen en suggesties) overnemen in de TS.

Dank voor je uitleg.

Ik heb in mijn config nu de "heating curve" gezet. Als ik de optimalisatie run, dan gaat ie fout omdat ik geen 'stages' heb aangegeven. Met stages erin gaat de run wel goed, maar gebruikt ie nu toch deze waardes?

Stel dat ik nu voor vermogen zou kiezen, dan is de COP toch aanzienlijk afhankelijk van de buitentemperatuur? Zit daar nog een correctiefactor op ten opzichte van de 'stages'?

code:

"heating": {
    "heater present": "True",
    "degree days factor": 1.55,
    "adjustment" : "heating curve",
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04,
    "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
      }      
    ]
  },

[KC27]

bvw schreef op woensdag 9 april 2025 @ 08:15:
[...]


Dank voor je uitleg.

Ik heb in mijn config nu de "heating curve" gezet. Als ik de optimalisatie run, dan gaat ie fout omdat ik geen 'stages' heb aangegeven. Met stages erin gaat de run wel goed, maar gebruikt ie nu toch deze waardes?

Stel dat ik nu voor vermogen zou kiezen, dan is de COP toch aanzienlijk afhankelijk van de buitentemperatuur? Zit daar nog een correctiefactor op ten opzichte van de 'stages'?

code:

"heating": {
    "heater present": "True",
    "degree days factor": 1.55,
    "adjustment" : "heating curve",
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04,
    "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
      }      
    ]
  },

Ik heb in mijn config nu de "heating curve" gezet. Als ik de optimalisatie run, dan gaat ie fout omdat ik geen 'stages' heb aangegeven. Met stages erin gaat de run wel goed, maar gebruikt ie nu toch deze waardes?

Dat blijkt dus nog een foutje te zijn.
Ik reken eigenlijk met de drie methoden zo veel mogelijk parallel.
Ik zal dat aanpassen zodat het programma daar niet de mist mee ingaat.

Stel dat ik nu voor vermogen zou kiezen, dan is de COP toch aanzienlijk afhankelijk van de buitentemperatuur? Zit daar nog een correctiefactor op ten opzichte van de 'stages'?

De COP is inderdaad veel beter bij een hogere buitentemperatuur. Methode drie (aan/uit) maakt daar bewust gebruik van. Maar de vermogen-methode indirect ook.
Doordat er bij een hogere buitentemperatuur er veel minder warmte nodig is en met "stages" die bij hogere vermogens een slechtere COP hebben zal het programma automatisch naar een oplossing zoeken met weinig verbruik (hoge cop) in de goedkope uren.

[Impossibl3]

Wat gebruikt DAO voor de PV verwachting? Is dat de helper uit HA of iets anders?

In mijn geval klopt die helper uit HA voor geen meter met mijn enphase installatie op het dak van het huis en de schaduw van omliggende bomen en een 9 tal panelen plat op de uitbouw/garage in een L waar het huis ook nog naast staat (er is meestal schaduw op een van de panelen).

Voor nu stuur ik alles aan op de goedkoopste 4 uur van de dag (auto, vaatwasser, WP (verwarming en tapwater). Maar dat zorgt er voor dat ik in die 4 uur soms van het net afneem en de uren er buiten terug lever terwijl ik naar NOM wil gaan, in ieder geval voor de maanden dat ik genoeg PV opwek heb. In 2027 komt er een accu dan kunnen we weer verder gaan optimaliseren.

Maar deze add-on valt en staat met een goede PV voorspelling volgens mij.

[KC27]

Impossibl3 schreef op woensdag 9 april 2025 @ 12:46:
Wat gebruikt DAO voor de PV verwachting? Is dat de helper uit HA of iets anders?

In mijn geval klopt die helper uit HA voor geen meter met mijn enphase installatie op het dak van het huis en de schaduw van omliggende bomen en een 9 tal panelen plat op de uitbouw/garage in een L waar het huis ook nog naast staat (er is meestal schaduw op een van de panelen).

Voor nu stuur ik alles aan op de goedkoopste 4 uur van de dag (auto, vaatwasser, WP (verwarming en tapwater). Maar dat zorgt er voor dat ik in die 4 uur soms van het net afneem en de uren er buiten terug lever terwijl ik naar NOM wil gaan, in ieder geval voor de maanden dat ik genoeg PV opwek heb. In 2027 komt er een accu dan kunnen we weer verder gaan optimaliseren.

Maar deze add-on valt en staat met een goede PV voorspelling volgens mij.

De pv-voorspelling is gebaseerd op meteodata van het KNMI (beschikbaar via Meteoserver), waarin de globale straling voor jouw locatie per uur wordt voorspeld. Deze voorspelling wordt iedere zes uur geactualiseerd.
Uitgaande van de helling en de oriëntatie van je panelen wordt dit gegeven omgerekend naar een straling per cm² loodrecht op je panelen. Dit wordt dan weer omgerekend naar een totale opbrengst met de zogenaamde yield-factor die je zelf bij je instellingen invult (zie DOCS.md).
Tot nu toe krijg ik weinig klachten van de gebruikers over deze methode.
Ik heb nog een kleine verbetering in het vat door per uur de voorspelde hoeveelheid over een aantal dagen te vergelijken met de gerealiseerde hoeveelheid en dit als correctiefactor te gebruiken, zodat bijvoorbeeld de invloed van schaduw wordt gecorrigeerd.

[Impossibl3]

@KC27 Dank voor het antwoord. Voor de enphase panelen moet ik dit dus wel kunnen inregelen voor mijn complete string op het platte dak wordt dat nog een uitdaging vanwege de hoeveelheid schaduw en dat het 1 string is.

Ter info de string op het platte dak zijn de oude panelen van het huis, deze had ik nog over. Iedere kW er bij is mooi mee genomen vandaar dat ze op het dak liggen. Misschien tzt een omvormer met 2 MPPT's scoren om de opwek (en de voorspelling) te verhogen.

[Knielen]

@KC27 Wil je eens met me meekijken, sinds deze maand werkt DAO niet meer. Ik heb de volgende logs:

DAO:

code:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3448, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3411, in main
    da_calc = DaCalc("../data/options.json")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 30, in __init__
    super().__init__(file_name=file_name)
  File "/root/dao/prog/da_base.py", line 94, in __init__
    super().__init__(hassurl=self.hassurl, token=self.hasstoken)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 36, in __init__
    self._assert_api_running()
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 40, in _assert_api_running
    if not self._api_is_running():
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 46, in _api_is_running
    return self._get("/")["message"] == "API running."  # type: ignore
           ^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 54, in _get
    return self._process_response(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(f"{status_code} status code returned from {url}",)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.InternalServerError: 500 status code returned from http://supervisor/core/api/

Supervisor:

code:

2025-04-09 16:20:19.208 ERROR (MainThread) [aiohttp.server] Error handling request from 172.30.33.4
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/aiohttp/web_protocol.py", line 480, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/web_app.py", line 569, in _handle
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 198, in block_bad_requests
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 212, in system_validation
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 229, in token_validation
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 293, in core_proxy
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/api/proxy.py", line 120, in api
    path = request.match_info["path"]
           ~~~~~~~~~~~~~~~~~~^^^^^^^^
KeyError: 'path'

[RudolfR]

@Knielen

Je moet toegang naar HA expliciet configureren, is hierboven al wel gepost.

Bijvoorbeeld hier:
Robje1244 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

[ Voor 41% gewijzigd door RudolfR op 09-04-2025 16:36 ]

[Knielen]

RudolfR schreef op woensdag 9 april 2025 @ 16:35:
@Knielen

Je moet toegang naar HA expliciet configureren, is hierboven al wel gepost.

Bijvoorbeeld hier:
Robje1244 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

Bedankt, dat was inderdaad de oplossing. Is dit nodig sinds een update? Heeft nog nooit in mijn config bestand gestaan.

[KC27]

Knielen schreef op woensdag 9 april 2025 @ 17:08:
[...]


Bedankt, dat was inderdaad de oplossing. Is dit nodig sinds een update? Heeft nog nooit in mijn config bestand gestaan.

Dit is een voorlopige oplossing.
De fout is "spontaan" ontstaan. Ik heb de oorzaak en dus ook de oplossing nog niet gevonden.
Het lijkt te komen door een wijziging in Home Assistant.

[bvw]

KC27 schreef op woensdag 9 april 2025 @ 08:40:
[...]


[...]

Dat blijkt dus nog een foutje te zijn.
Ik reken eigenlijk met de drie methoden zo veel mogelijk parallel.
Ik zal dat aanpassen zodat het programma daar niet de mist mee ingaat.


[...]

De COP is inderdaad veel beter bij een hogere buitentemperatuur. Methode drie (aan/uit) maakt daar bewust gebruik van. Maar de vermogen-methode indirect ook.
Doordat er bij een hogere buitentemperatuur er veel minder warmte nodig is en met "stages" die bij hogere vermogens een slechtere COP hebben zal het programma automatisch naar een oplossing zoeken met weinig verbruik (hoge cop) in de goedkope uren.

Nogmaals bedankt voor de hulp (en uberhaupt de tool maken, heeft veel potentie!)

Met de warmtepomp even volgens de eerste methode ingesteld werkt prima. Nu denk ik dat de theorie van zoveel kWh warmte per dag je huis in goed klopt voor een grijze dag in december, maar op deze dagen is de warmtevraag vrij selectief aan het einde van de nacht. Ik zit zelf te denken aan een afkoelingsfactor van het huis, waar je dan kunt optimaliseren op wanneer de warmtepomp aan moet gedurende de dag. iets in de trend van:

x -= verliesfactor in kWh per uur / buitentemperatuur
als x <= 0 dan warmtepomp aan.

Snijdt m'n idee hout?

[KC27]

bvw schreef op woensdag 9 april 2025 @ 18:31:
[...]


Nogmaals bedankt voor de hulp (en uberhaupt de tool maken, heeft veel potentie!)

Met de warmtepomp even volgens de eerste methode ingesteld werkt prima. Nu denk ik dat de theorie van zoveel kWh warmte per dag je huis in goed klopt voor een grijze dag in december, maar op deze dagen is de warmtevraag vrij selectief aan het einde van de nacht. Ik zit zelf te denken aan een afkoelingsfactor van het huis, waar je dan kunt optimaliseren op wanneer de warmtepomp aan moet gedurende de dag. iets in de trend van:

x -= verliesfactor in kWh per uur / buitentemperatuur
als x <= 0 dan warmtepomp aan.

Snijdt m'n idee hout?

Ik ben het niet helemaal met je eens:
De graaddagen methode die in DAO is toegepast is de de zogenaamde "gewogen" graaddagen methode met een verlaagde stookgrens van 16 °C (i.p.v. 18 °C):

• Gewogen wil zeggen: in de wintermaand (december, januari en februari) worden de berekende graaddagen met 1.1 vermenigvuldigd en in de zomermaanden (april t/m september) met 0.8
• De lagere stookgrens van 16 °C is gebaseerd op de gedachte dat de huizen steeds beter zijn geïsoleerd en door de interne warmteproductie (van mensen en apparaten) boven die daggemiddelde buitentemperatuur niet meer verwarmd worden.

Jouw idee van een verliesfactor is m.i. alleen toepasbaar bij luchtverwarming. Bij de meeste warmtepompen (en bij mij) komt de warmte met vloerverwarming in een dikke betonvloer in de woning. Die betonvloer werkt dan als een goede warmtebuffer. Als ik de wp uitzet koelt die vloer heel langzaam af (ca 1 K per 12 uur). Hetzelfde geldt voor de luchttemperatuur. Dus ik zou zeggen zet de wp aan/hoger als de prijzen laag zijn en vice versa en zorg dat er op dagbasis genoeg maar niet teveel warmte de woning ingaat.

Ik heb voor mezelf nog wel een correctie gemaakt op de door DAO berekende stooklijnverschuiving.
Wij hebben voor onszelf bepaald dat 20.7 °C een optimale binnentemperatuur is voor de woonkamer/woonkeuken.
Wanneer nu de gemeten temperatuur daaronder komt (bijvoorbeeld bij veel koude wind en weinig zon-instraling) dan wordt de stooklijn verhoogd en idem dito als de temperatuur boven die 20.7 °C komt (meestal door veel zon-instraling) dan wordt de stooklijn verlaagd. Dat heb ik buiten DAO in Home Assistant geïmplementeerd en dat werkt heel erg goed: comfortverhogend en energiebesparend.

[KC27]

@hemertje @bvw
Ik heb mijn bijdrage over de wp (KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO") nog aangevuld met de beschrijving van methode 3 van de aansturing.

Als jullie akkoord zijn gaat dit geheel binnenkort naar de TS.

[Impossibl3]

KC27 schreef op woensdag 9 april 2025 @ 23:03:
[...]
Jouw idee van een verliesfactor is m.i. alleen toepasbaar bij luchtverwarming. Bij de meeste warmtepompen (en bij mij) komt de warmte met vloerverwarming in een dikke betonvloer in de woning. Die betonvloer werkt dan als een goede warmtebuffer. Als ik de wp uitzet koelt die vloer heel langzaam af (ca 1 K per 12 uur). Hetzelfde geldt voor de luchttemperatuur. Dus ik zou zeggen zet de wp aan/hoger als de prijzen laag zijn en vice versa en zorg dat er op dagbasis genoeg maar niet teveel warmte de woning ingaat.

Dat is niet helemaal waar. Hier heb ik juist vloerverwarming net onder mijn laminaat liggen en dus niet in 10cm beton. Het systeem reageert als een trein maar je moet het zien als een grote radiator plaat. Er is geen sprake van een warmtebuffer. Iedere situatie is dus iets anders. Overigens vind ik het sturen op graaddagen wel slim als je het vermogen kan aanpassen. Dan verlaag je die in de dure uren maar is de verlaging variabel op basis van je graaddagen.

[bvw]

KC27 schreef op woensdag 9 april 2025 @ 23:03:
[...]

Ik ben het niet helemaal met je eens:
De graaddagen methode die in DAO is toegepast is de de zogenaamde "gewogen" graaddagen methode met een verlaagde stookgrens van 16 °C (i.p.v. 18 °C):

• Gewogen wil zeggen: in de wintermaand (december, januari en februari) worden de berekende graaddagen met 1.1 vermenigvuldigd en in de zomermaanden (april t/m september) met 0.8
• De lagere stookgrens van 16 °C is gebaseerd op de gedachte dat de huizen steeds beter zijn geïsoleerd en door de interne warmteproductie (van mensen en apparaten) boven die daggemiddelde buitentemperatuur niet meer verwarmd worden.

Jouw idee van een verliesfactor is m.i. alleen toepasbaar bij luchtverwarming. Bij de meeste warmtepompen (en bij mij) komt de warmte met vloerverwarming in een dikke betonvloer in de woning. Die betonvloer werkt dan als een goede warmtebuffer. Als ik de wp uitzet koelt die vloer heel langzaam af (ca 1 K per 12 uur). Hetzelfde geldt voor de luchttemperatuur. Dus ik zou zeggen zet de wp aan/hoger als de prijzen laag zijn en vice versa en zorg dat er op dagbasis genoeg maar niet teveel warmte de woning ingaat.

Ik heb voor mezelf nog wel een correctie gemaakt op de door DAO berekende stooklijnverschuiving.
Wij hebben voor onszelf bepaald dat 20.7 °C een optimale binnentemperatuur is voor de woonkamer/woonkeuken.
Wanneer nu de gemeten temperatuur daaronder komt (bijvoorbeeld bij veel koude wind en weinig zon-instraling) dan wordt de stooklijn verhoogd en idem dito als de temperatuur boven die 20.7 °C komt (meestal door veel zon-instraling) dan wordt de stooklijn verlaagd. Dat heb ik buiten DAO in Home Assistant geïmplementeerd en dat werkt heel erg goed: comfortverhogend en energiebesparend.

Ik bedacht me later nog een andere factor die in het voor en naseizoen eigenlijk veel belangrijker is in deze discussie, dat is de zoninstraling, dus niet eens het standaard verlies tov de buitentemperatuur.
Ik ben met je eens dat dat door DAO wel afgedekt wordt mits je een betonbuffer hebt die je temperatuur binnen het aangename weet te houden. Als je buffer het niet in het nodige tempo kan afgeven aan de kamerlucht, dan wordt het onaangenaam.

Als voorbeeld, dit is wat DAO nu voorstelt:



Maar qua comfort heb ik juist de warmte in de ochtend nodig:

[mgroen81]

@KC27 De berekening duurt bij mij ongeveer 45-55 seconden. (Odroid N2+) Zou het mogelijk zijn de berekening iets eerder te doen zodat de veranderingen op het hele uur/kwartier doorgevoerd kunnen worden?

Nu loop je altijd een klein deel van het uur/kwartier mis en dat is dus niet optimaal.

[Marcjeno1]

tonvanboven schreef op dinsdag 1 april 2025 @ 18:09:
[...]

Inderdaad, dit is mijn config en ik heb er met @KC27 regelmatig naar gekeken of er wat mis is. Maar ja met 60kWh kun je wel verzetten.

code:

{
  "homeassistant": {
    "protocol api": "http",
    "ip adress": "192.168.7.2",
    "ip port": 8123,
    "token": "!secret ha_api_token"},
  "database da": {
    "engine": "mysql",
    "database": "day_ahead",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "database ha": {
    "server": "192.168.7.2",
    "database": "homeassistant",
    "port": 3306,
    "username": "homeassistant",
    "password": "!secret db_ha_password"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.35,
    "regular low": 0.32,
    "switch to low": 23,
    "energy taxes delivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes redelivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2027-01-01": 0
    },
    "cost supplier delivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2027-01-01": 0 
    },
    "vat": {
      "2023-01-01": 21
    },
    "last invoice": "2022-11-30",
    "tax refund": "True"
  },
  "logging level" : "info",
  "baseload calc": "True",
  "baseload calc periode": 60,
  "baseload": [
    0.75,
    0.75,
    0.75,
    0.75,
    0.75,
    0.75,
    0.75,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1.7,
    1.8,
    1.5,
    1.25,
    1.25,
    1.25,
    1
  ],
  "graphical backend": "",
  "graphics": {
    "style": "dark_background",
    "show" : "true",
    "battery balance": "True",
    "prices delivery": "False",
    "prices redelivery": "True",
    "average delivery": "False"
  },
  "strategy": "minimize cost",
  "notifications": {
    "notification entity": "input_text.dao_notificatie",
    "opstarten": "True",
    "berekening": "True",
    "last activity entity": "input_datetime.dao_laatste_activiteit"
  },
  "grid": {
    "max_power": 18.5
  },
  "history": {
    "save days": 3
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.kelder_boiler_temperature",
    "entity setpoint": "input_number.dao_boiler_ingesteld",
    "entity hysterese": "input_number.dao_boiler_hysterese",
    "cop": 1,
    "cooling rate": 0.4,
    "volume": 120,
    "heating allowed below": 40,
    "elec. power": 2000,
    "activate service": "press",
    "activate entity": "input_button.dao_boiler_start_verwarmen"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
    {
      "name": "LFP304",
      "entity actual level": "sensor.victron_battery_state_of_charge_system",
      "capacity": 60,
      "upper limit": 100,
      "lower limit": 10,
      "optimal lower level": 10,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 1500,
          "efficiency": 0.785
        },
        {
          "power": 3000,
          "efficiency": 0.872
        },
        {
          "power": 4500,
          "efficiency": 0.897
        },
        {
          "power": 6000,
          "efficiency": 0.899
        },
        {
          "power": 7500,
          "efficiency": 0.898
        },
        {
          "power": 9000,
          "efficiency": 0.892
        },
        {
          "power": 10500,
          "efficiency": 0.882
        },
        {
          "power": 12000,
          "efficiency": 0.871
        }
      ],
      "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 600,
          "efficiency": 0.891
        },
        {
          "power": 1500,
          "efficiency": 0.935
        },
        {
          "power": 3000,
          "efficiency": 0.952
        },
        {
          "power": 4500,
          "efficiency": 0.952
        },
        {
          "power": 7500,
          "efficiency": 0.934
        },
        {
          "power": 9000,
          "efficiency": 0.925
        },
        {
          "power": 10500,
          "efficiency": 0.915
        },
        {
          "power": 12000,
          "efficiency": 0.9
        },
        {
          "power": 13050,
          "efficiency": 0.893
        },
        {
          "power": 15360,
          "efficiency": 0.886
        },
        {
          "power": 16500,
          "efficiency": 0.863
        }
      ],
      "minimum power": 1000,
      "dc_to_bat efficiency": 0.9838,
      "bat_to_dc efficiency": 0.9838,
      "cycle cost": 0,
      "entity set power feedin": "input_number.dao_set_power_feedin",
      "entity set operating mode": "input_select.dao_set_operation_mode",
      "entity stop inverter": "input_datetime.dao_stop_inverter",
      "entity balance switch": "input_boolean.dao_balance_switch",
      "entity from battery": "input_number.dao_from_battery",
      "entity from pv": "input_number.dao_from_pv",
      "entity from ac": "input_number.dao_from_ac",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "solar": []
    }
  ],
  "solar": [
    {
      "name": "woning",
      "tilt": 43,
      "orientation": 20,
      "capacity": 10.2,
      "yield": 0.02375,
      "entity pv switch": "input_boolean.dao_pv_switch",
      "sensor history": "sensor.solaredge_woning_ac_energy_kwh"
    },
    {
      "name": "garage",
      "tilt": 45,
      "orientation": 5,
      "capacity": 2,
      "yield": 0.00175,
      "entity pv switch": "input_boolean.dao_pv_switch",
      "sensor history": "sensor.solaredge_woning_ac_energy_kwh_2"
    }
  ],
  "electric vehicle": [
    {
      "name": "Tesla",
      "capacity": 70,
      "entity position": "device_tracker.redmist_location_tracker",
      "entity max amperage": "input_number.dao_max_amperage",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 16, "efficiency": 0.90}
      ],      
      "entity actual level": "sensor.redmist_battery",
      "entity plugged in": "binary_sensor.dao_ev_plugged_in",
      "entity stop charging": "input_datetime.dao_stop_laden_ev",
      "charge scheduler": {
        "entity set level": "input_number.tesla_gewenste_soc",
        "level margin": 4,
        "entity ready datetime": "input_datetime.dao_redmist_klaar_met_laden"
      },
      "charge switch": "input_boolean.dao_redmist_charger",
      "entity set charging ampere" : "input_number.dao_redmist_set_charge_ampere"
    }
  ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.energy_consumed_tariff_1",
      "sensor.energy_consumed_tariff_2"
    ],
    "entities grid production": [
      "sensor.energy_produced_tariff_1",
      "sensor.energy_produced_tariff_2"
    ],
    "entities solar production ac": [
      "sensor.zonnepanelen_channel_a_energy",
      "sensor.zonnepanelen_channel_b_energy",
      "sensor.zonnepanelen_channel_c_energy",
      "sensor.shellyem3_34945475f512_channel_a_energy",
      "sensor.shellyem3_34945475f512_channel_b_energy",
      "sensor.shellyem3_34945475f512_channel_c_energy"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.redmist_charged_energy_at_home"],
    "entities wp consumption" : [],
    "entities boiler consumption": [],    
    "entities battery consumption": ["sensor.energy_into_battery"],
    "entities battery production": ["sensor.energy_from_battery"]
  },
  "scheduler": {
    "0445": "get_meteo_data",
    "0930": "calc_baseloads",
    "1045": "get_meteo_data",
    "0952": "get_tibber_data",
    "1052": "get_tibber_data",
    "1152": "get_tibber_data",
    "1252": "get_tibber_data",
    "1258": "get_day_ahead_prices",
    "1313": "get_day_ahead_prices",
    "1315": "calc_optimum",
    "1328": "get_day_ahead_prices",
    "1330": "calc_optimum",
    "1350": "get_tibber_data",
    "1358": "get_day_ahead_prices",
    "1452": "get_tibber_data",
    "1458": "get_day_ahead_prices",
    "1445": "get_meteo_data",
    "1558": "get_day_ahead_prices",
    "2245": "get_meteo_data",
    "2355": "clean_data",
    "xx00": "calc_optimum"
  }
}

O ja, mijn EV heb ik al negen jaar geleden gekocht voordat Elon gek werd.
Mochten er nog verbeterpunten zijn dan hoor ik het graag

Ik heb een vergelijkbare opstelling met 45kwh batterij. Vind dit dus een mooie template voor mijzelf om mee aan de gang te gaan. Volgens mij zijn jullie toch wat bekender met een stukje programmeerwerk en dergelijke want ik kom er niet helemaal uit. Bij de batterij wordt er steeds verwezen naar een input_number uit homeassistant. Maar wat doet deze input_number in homeassistant dan?

Ik krijg al mijn data van de victron GX binnen met mqtt. Volgens mij moet ik met mqtt ook het een en ander aan kunnen sturen op de gx. Heb je misschien een voorbeeld van zo'n input number die in homeassistant hebt? Als ik het goed begrijp gaat dao dan uiteindelijk mijn batterij aansturen toch?

[ErnstH]

DAO vult een aantal sensoren in Home Assistant. Op basis daarvan kun je dan, via een automation, jouw eigen apparatuur bedienen. DAO zal dus niet zélf zaken aansturen.

[hemertje]

KC27 schreef op woensdag 9 april 2025 @ 00:17:
[...]
Daarvoor moet een entity worden geconfigureerd in HA waarvan je de naam opgeeft in de instellingen bij "entity hp heat demand". Als deze op aan/on/true of "1" staat wordt er gerekend.

De COP en het vermogen waarop de warmtepomp draait hangen af van de voorspelde buitentemperatuur en dienen door HA te worden berekend en aan DAO te worden doorgegeven middels de "entitity hp cop" en "entity hp power" entiteiten.

ondanks mijn elektrotechnische achtergrond kan ik niet programmeren, ook heb ik HA mbt de programmeermogelijkheden nog niet doorgrond

coderen is blijkbaar niet aan mij besteed

dus heb je een voorbeeld beschikbaar van zo'n enity?
en hoe je de voorspelde buitentemperatuur door HA laat berekenen en aan DAO doorgeeft middels de "entitity hp cop" en "entity hp power" entiteiten?

KC27 schreef op woensdag 9 april 2025 @ 00:17:
[...]
Om hier mee te kunnen werken zul je voor je woning door middel van metingen de relatie moeten vaststellen tussen de etmaal gemiddelde buitentemperatuur en de COP van je warmtepomp.

Is het een idee dat DAO deze waarden uit de beschikbare sensoren haalt en je deze in een database opslaat?

KC27 schreef op woensdag 9 april 2025 @ 00:17:
[...]
Bij een berekening door DAO zal DAO de voorspelde etmaalgemiddelde buitentemperatuur in °C wegschrijven naar de de entity die je hebt opgegeven bij "entity avg outside temp".
In HA maak je dan een automation die mbv van de relatie (=formule) uit die buitentemperatuur de COP berekent en deze berekende COP wordt door die automation weggeschreven in de entity die je opgeeft bij "entity hp cop".

ook van deze automation is een voorbeeld bestand gewenst

[tonvanboven]

hemertje schreef op donderdag 10 april 2025 @ 22:22:
[...]
ook van deze automation is een voorbeeld bestand gewenst

Die gaan jullie van me krijgen maar door privé omstandigheden ben ik nu niet in staat hierop antwoorden te geven. Ik kom hier zeker op terug, maar geef me even (hoelang weet ik helaas niet) tijd.

[Marcjeno1]

ErnstH schreef op donderdag 10 april 2025 @ 21:30:
DAO vult een aantal sensoren in Home Assistant. Op basis daarvan kun je dan, via een automation, jouw eigen apparatuur bedienen. DAO zal dus niet zélf zaken aansturen.

Ah op die manier. Waar kan ik die terugvinden?

Het zou kunnen dat het bij mij nog niet werkt hoor. Ik kan niet zien of het nu allemaal goed gekoppeld is in docker omgeving van dao. Ik kan in ieder geval grafieken maken maar de koppeling met homeassistant weet ik eigenlijk niet of dat nu werkt.

[hemertje]

tonvanboven schreef op donderdag 10 april 2025 @ 22:30:
[...]

Die gaan jullie van me krijgen maar door privé omstandigheden ben ik nu niet in staat hierop antwoorden te geven. Ik kom hier zeker op terug, maar geef me even (hoelang weet ik helaas niet) tijd.

geen probleem, neem vooral de tijd, ik ben toch nog niet actief bezig met het systeem
ben vooral bezig me in te lezen en te kijken wat DAO voor me kan betekenen

prive heeft altijd de prioriteit!

[storeman]

@hemertje

Ten eerste, echt programmeren is het niet in mijn optiek. Het is allemaal tamelijk gebruiksvriendelijk in Home Assistant tegenwoordig. Ik zal het proberen uit te leggen hoe het zou moeten werken.


1. Je maakt helpers aan van bepaalde types en geeft ze een naam (via Instellingen > Apparaten & Diensten > Helpers)
2. Deze helper krijgt op basis van de naam een uniek ID. Als je de helper hebt opgeslagen, kun je erop klikken en het ID vinden. Iets als `input_boolean.dao_balancing`
3. Dit ID gebruik je in de DAO config. DAO leest en schrijft deze waardes. Als je iets wil automatiseren op basis van DAO, dat gaat op basis van entiteiten die door DAO worden gevuld/geschreven.
4. Maak een automatisering in Home Assistant. De trigger is dan de entiteit (input_boolean.dao_balancing) die wijzigt. Hier hang je dan acties aan die uitgevoerd moeten worden.

[KC27]

Ik heb zojuist versie 2025.4.0 gepubliceerd op github.
Diegenen die DAO hebben geïnstalleerd als addon krijgen een melding van Home Assistant bij de instellingen:

Diegenen die DAO in een eigen container hebben draaien moeten zelf actie ondernemen om te updaten.

Belangrijkste wijziging;
"Fixed the error (two hours too late) in the timestamp in the result-records from api/report-calls".
Deze fout is gevonden door @DaBit .
Ik heb deze gelegenheid aangegrepen om ook de structuur van de api-resultaten te verbeteren (zie changelog).
Dit is dus een breaking change!

[KC27]

bvw schreef op donderdag 10 april 2025 @ 08:26:
[...]


Ik bedacht me later nog een andere factor die in het voor en naseizoen eigenlijk veel belangrijker is in deze discussie, dat is de zoninstraling, dus niet eens het standaard verlies tov de buitentemperatuur.
Ik ben met je eens dat dat door DAO wel afgedekt wordt mits je een betonbuffer hebt die je temperatuur binnen het aangename weet te houden. Als je buffer het niet in het nodige tempo kan afgeven aan de kamerlucht, dan wordt het onaangenaam.

Als voorbeeld, dit is wat DAO nu voorstelt:

[Afbeelding]

Maar qua comfort heb ik juist de warmte in de ochtend nodig:

[Afbeelding]

Ik ben het met je eens.
Als ik er nu over nadenk zou de planningshorizon van de wp instelbaar moeten zijn. Woningen met een kleine warmtebuffering kunnen in de ochtend geen warmte produceren en deze opslaan in hun vloer of buffer en die 12 uur later benutten.
Een planningshorizon van 1 uur is tekort om zinvol te zijn met dynamische prijzen, maar een horizon instelbaar tussen minimaal 6 en maximaal 24 uur lijkt me zinvol.
Wat vinden jullie hiervan?

De zoninstraling is zeker ook een belangrijke factor die zorgt voor warmteproductie.
Voor een deel zit deze verwerkt in de "gewogen" graaddagen, maar we zouden het allemaal instelbaar kunnen maken. In de opgehaalde meteo-gegevens zit naast de buitentemperatuur ook een goede indicator van de zonnestraling in de vorm van Globale Straling (in J/cm²). Die gebruikt DAO ook al om de pv-productie te voorspellen. Die zou ook gebruikt kunnen worden om de warmteopbrengst van de zon-instraling te voorspellen met een instelbare factor bijv 0.01 kWh/J/cm² (dat betekent dat 100 J/cm² 1 kWh warmte oplevert).
Ook hier de vraag: wat vinden jullie hiervan?

Voor beide voorstellen geldt:
Als het wordt doorgevoerd dan is het allemaal optioneel: als je niets instelt blijft alles bij het oude. Alleen gebruikers die het "onderste uit de kan willen" kunnen gebruik maken van een of beide van deze extra opties.

[KC27]

mgroen81 schreef op donderdag 10 april 2025 @ 16:49:
@KC27 De berekening duurt bij mij ongeveer 45-55 seconden. (Odroid N2+) Zou het mogelijk zijn de berekening iets eerder te doen zodat de veranderingen op het hele uur/kwartier doorgevoerd kunnen worden?

Nu loop je altijd een klein deel van het uur/kwartier mis en dat is dus niet optimaal.

Ik snap je redenering.
Maar ik vraag me wel af: waarom duurt bij jou de berekening zo lang?
Bij mij (op een Raspberry 5) is ie in 2 seconden klaar en een Odriod N2+ is m.i. minstens net zo krachtig.
Heb je veel batterijen?
Kun je je instellingen delen, dan kan ik of iemand er eens naar kijken.

Ik kan eventueel een extra instellingsoptie maken dat ie een instelbaar seconden eerder gaat rekenen.

[ Voor 6% gewijzigd door KC27 op 10-04-2025 23:43 ]

[mgroen81]

@KC27 Heb 3x Sessy in de config.

code:

{
  "homeassistant": {
   "protocol api": "http",
   "ip adress": "192.168.178.156",
   "ip port": 8123,
   "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.30,
    "regular low": 0.30,
    "switch to low": 23,
    "energy taxes delivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes redelivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier delivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.03957
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.03957
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2024-10-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "dark_background",
    "show" : "true",
    "battery balance": "False",
    "prices delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
    "notification entity": "input_text.dao_notificatie",
    "opstarten": "False",
    "berekening": "False",
    "last activity entity": "input_datetime.dao_laatste_activiteit"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "True",
    "boiler heated by heatpump": "True",
    "entity actual temp.": "sensor.ecodan_heatpump_dhw_current_temp",
    "entity setpoint": "sensor.ecodan_heatpump_dhw_setpoint_value",
    "entity hysterese": "input_number.dao_hysterese_dhw",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 200,
    "heating allowed below": 43,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "switch.ecodan_heatpump_force_dhw"
  },
  "heating": {
    "heater present": "False",
    "entity hp enabled": "input_boolean.dao_heatpump_heating",
    "entity hp switch": "input_boolean.dao_heatpump_switch",
    "entity avg outside temp": "input_number.dao_avg_outside_temp",
    "degree days factor": 3.6,
    "adjustment" : "on/off",
    "//adjustment" : "on/off | power | heating curve",
    "stages": [
      {
        "max_power": 400,
        "cop": 7.78
      },
      {
        "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.dao_stooklijn_verschuiving_day_ahead2",
    "adjustment factor": 0.04
  },
  "battery": [
    {
      "name": "Sessy1",
      "entity actual level": "sensor.sessy_dvw9_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4400.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 3400.0,
      "cycle cost": 0.03,
      "entity set power feedin": "input_number.dao_sessy_dvw9_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_dvw9_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_dvw9",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_dvw9",
      "entity from battery": "input_number.dao_sessy_dvw9_from_battery",
      "entity from pv": "input_number.dao_sessy_dvw9_from_pv",
      "entity from ac": "input_number.dao_sessy_dvw9_from_ac",
      "entity calculated soc": "input_number.dao_sessy_dvw9_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy2",
      "entity actual level": "sensor.sessy_dtjg_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4400.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 3400.0,
      "cycle cost": 0.03,
      "entity set power feedin": "input_number.dao_sessy_dtjg_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_dtjg_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_dtjg",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_dtjg",
      "entity from battery": "input_number.dao_sessy_dtjg_from_battery",
      "entity from pv": "input_number.dao_sessy_dtjg_from_pv",
      "entity from ac": "input_number.dao_sessy_dtjg_from_ac",
      "entity calculated soc": "input_number.dao_sessy_dtjg_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy3",
      "entity actual level": "sensor.sessy_duny_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4400.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 3400.0,
      "cycle cost": 0.03,
      "entity set power feedin": "input_number.dao_sessy_duny_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_duny_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_duny",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_duny",
      "entity from battery": "input_number.dao_sessy_duny_from_battery",
      "entity from pv": "input_number.dao_sessy_duny_from_pv",
      "entity from ac": "input_number.dao_sessy_duny_from_ac",
      "entity calculated soc": "input_number.dao_sessy_duny_calculated_soc",
      "solar": []
    }
  ],
  "solar": [
    {
      "name": "pv woning1",
      "tilt": 40,
      "orientation": 98,
      "capacity": 4.0,
      "yield": 0.007,
      "entity pv switch": ""
    },
    {
      "name": "pv woning2",
      "tilt": 40,
      "orientation": -82,
      "capacity": 4.8,
      "yield": 0.008,
      "entity pv switch": ""
    },
    {
      "name": "pv tuinhuis",
      "tilt": 8,
      "orientation": 0,
      "capacity": 2.3,
      "yield": 0.005,
      "entity pv switch": ""
    }
  ],
  "electric vehicle": [
    {
      "name": "Zoe",
      "capacity": 40,
      "entity position": "device_tracker.smartevse_6697",
      "entity max amperage": "sensor.smartevse_current_max",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 15, "efficiency" :  1}
      ],
      "entity actual level": "input_number.zoe_accu",
      "entity plugged in": "input_boolean.dao_zoe_external_power_connected",
      "charge scheduler": {
        "entity set level": "input_number.dao_zoe_gewenst_laad_niveau",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_zoetijdstip_klaar_met_laden"
      },
      "charge switch": "input_boolean.dao_zoe_charging",
      "entity set charging ampere" : "input_number.dao_zoe_set_car_charging_ampere",
      "entity stop charging": "input_datetime.dao_zoe_stop_laden_ev"
    }
  ],
  "report": {
    "entities grid consumption": [
      "sensor.sessy_p6eh_tariff_1_consumed_energy",
      "sensor.sessy_p6eh_tariff_2_consumed_energy"
    ],
    "entities grid production": [
      "sensor.sessy_p6eh_tariff_1_produced_energy",
      "sensor.sessy_p6eh_tariff_2_produced_energy"
    ],
    "entities solar production ac": [
      "sensor.solaredge_i1_ac_energy_kwh",
      "sensor.kwh_meter_1_phase_pv2_total_power_export"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.kwh_meter_3_phase_ev_energy_import"],
    "entities wp consumption" : ["sensor.extra_total"],
    "entities boiler consumption": [],
    "entities battery consumption": [
      "sensor.sessy_fase1_dvw9_charged_energy",
      "sensor.sessy_fase2_dtjg_charged_energy",
      "sensor.sessy_fase3_duny_charged_energy"],
    "entities battery production": [
      "sensor.sessy_fase1_dvw9_discharged_energy",
      "sensor.sessy_fase2_dtjg_discharged_energy",
      "sensor.sessy_fase3_duny_discharged_energy"]
  },
  "scheduler": {
    "active": "true",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

Resultaat

code:

 2025-04-11 07:00:00 info: Day Ahead Optimalisering versie: 2025.3.1
2025-04-11 07:00:00 info: Day Ahead Optimalisering gestart op: 11-04-2025 07:00:00
2025-04-11 07:00:00 info: Day Ahead Optimalisatie gestart: 11-04-2025 07:00:00 taak: calc_optimum
2025-04-11 07:00:00 info: Debug = False
2025-04-11 07:00:00 info: Zelf berekende baseload
2025-04-11 07:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0     7 2025-04-11 07:00:00   0.31   0.31   0.42   1.09      0
1     8 2025-04-11 08:00:00   0.33   0.33   0.32   2.53      0
2     9 2025-04-11 09:00:00   0.31   0.31   0.26   3.78      0
3    10 2025-04-11 10:00:00   0.20   0.20  -0.17   4.71      0
4    11 2025-04-11 11:00:00   0.17   0.17  -0.25   4.58      0
5    12 2025-04-11 12:00:00   0.16   0.16  -0.28   4.63      0
6    13 2025-04-11 13:00:00   0.16   0.16  -0.38   4.47      0
7    14 2025-04-11 14:00:00   0.16   0.16  -0.16   4.23      0
8    15 2025-04-11 15:00:00   0.17   0.17   0.31   3.53      0
9    16 2025-04-11 16:00:00   0.17   0.17   0.57   2.69      0
10   17 2025-04-11 17:00:00   0.25   0.25   0.63   1.73      0
11   18 2025-04-11 18:00:00   0.30   0.30   0.71   0.70      0
12   19 2025-04-11 19:00:00   0.32   0.32   0.54   0.08      0
13   20 2025-04-11 20:00:00   0.35   0.35   0.56   0.00      0
14   21 2025-04-11 21:00:00   0.32   0.32   0.64   0.00      0
15   22 2025-04-11 22:00:00   0.31   0.31   0.60   0.00      0
16   23 2025-04-11 23:00:00   0.29   0.29   0.58   0.00      0
2025-04-11 07:00:43 info: Verbruik dit contractjaar: 6008.242 kWh
2025-04-11 07:00:43 info: Productie dit contractjaar: 2040.705 kWh
2025-04-11 07:00:43 info: All taxes refund (alles wordt gesaldeerd)
2025-04-11 07:00:43 info: Reduced hours applied for Sessy1
2025-04-11 07:00:43 info: Startwaarde SoC Sessy1: 46.0%
2025-04-11 07:00:43 info: Reduced hours applied for Sessy2
2025-04-11 07:00:43 info: Startwaarde SoC Sessy2: 47.0%
2025-04-11 07:00:43 info: Reduced hours applied for Sessy3
2025-04-11 07:00:43 info: Startwaarde SoC Sessy3: 47.0%
2025-04-11 07:00:43 info: Boiler opwarmen wordt ingepland tussen: 8 en 23 uur
2025-04-11 07:00:43 info: Instellingen voor laden van EV: Zoe
2025-04-11 07:00:43 info:  Ampere  Effic. Grid kW Accu kW
2025-04-11 07:00:43 info:    0.00    1.00    0.00    0.00
2025-04-11 07:00:43 info:   15.00    1.00   10.35   10.35
2025-04-11 07:00:43 info: Capaciteit accu: 40 kWh
2025-04-11 07:00:43 info: Maximaal laadvermogen: 10.35 kW
2025-04-11 07:00:43 info: Klaar met laden op: 12-04-2025 06:00:00
2025-04-11 07:00:43 info: Huidig laadniveau: 25.0 %
2025-04-11 07:00:43 info: Gewenst laadniveau:100.0 %
2025-04-11 07:00:43 info: Marge voor het laden: 1 %
2025-04-11 07:00:43 info: Locatie: home
2025-04-11 07:00:43 info: Ingeplugged:False
2025-04-11 07:00:43 info: Benodigde energie: 30.0 kWh
2025-04-11 07:00:43 info: Tijd nodig om te laden: 2.90 uur
2025-04-11 07:00:43 info: Afgerond naar hele uren: 3
2025-04-11 07:00:43 info: Stand laden schakelaar: off
2025-04-11 07:00:43 info: Stand aantal ampere laden: 0.0 A
2025-04-11 07:00:43 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd, opgegeven tijdstip (2025-04-12 06:00:00) ligt voorbij de planningshorizon (2025-04-11 23:00:00).
2025-04-11 07:01:17 info: Strategie: minimale kosten
2025-04-11 07:01:17 info: Het programma heeft een optimale oplossing gevonden.
2025-04-11 07:01:17 info: Geen saldeer correctie
2025-04-11 07:01:17 info: Niet geoptimaliseerd, kosten met reguliere tarieven: -15.81
2025-04-11 07:01:17 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -6.15 
2025-04-11 07:01:17 info: Geoptimaliseerd, kosten met day ahead tarieven: -7.68 
2025-04-11 07:01:17 info: Levering: 1.88   (kWh)
2025-04-11 07:01:17 info: Waarde boiler om 23 uur: 1.28 kWh
2025-04-11 07:01:17 info: In- en uitgaande energie per uur batterij Sessy1
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     7  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  29.85
     8  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  10.39
     9  -0.55  95.70  -0.57   0.00  -0.57 100.00  -0.57  95.70  -0.00
    10   0.00     --   0.00   0.00  -0.00     --  -0.00     --  -0.00
    11   1.24  94.34   1.17   0.00   1.17 100.00   1.17  94.34  21.21
    12   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  47.47
    13   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  73.74
    14   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18  -0.61  95.70  -0.64   0.00  -0.64 100.00  -0.64  95.70  88.32
    19  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  68.86
    20  -1.53  92.90  -1.65   0.00  -1.65 100.00  -1.65  92.90  38.92
    21  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  19.46
    22  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  -0.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --   0.00
Totaal  -1.76     --  -2.53   0.00  -2.53     --  -2.53     --       
2025-04-11 07:01:17 info: In- en uitgaande energie per uur batterij Sessy2
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     7  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  30.85
     8  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  11.39
     9  -0.60  95.70  -0.63   0.00  -0.63 100.00  -0.63  95.70  -0.00
    10   0.00     --   0.00   0.00  -0.00     --  -0.00     --  -0.00
    11   1.24  94.34   1.17   0.00   1.17 100.00   1.17  94.34  21.21
    12   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  47.47
    13   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  73.74
    14   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19  -1.36  93.60  -1.45   0.00  -1.45 100.00  -1.45  93.60  73.58
    20  -1.57  92.50  -1.70   0.00  -1.70 100.00  -1.70  92.50  42.67
    21  -1.19  94.30  -1.26   0.00  -1.26 100.00  -1.26  94.30  19.73
    22  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30   0.27
    23   0.00     --   0.00   0.00   0.00     --   0.00     --   0.27
Totaal  -1.76     --  -2.57   0.00  -2.57     --  -2.57     --       
2025-04-11 07:01:17 info: In- en uitgaande energie per uur batterij Sessy3
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     7  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  30.85
     8  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  11.39
     9  -0.60  95.70  -0.63   0.00  -0.63 100.00  -0.63  95.70  -0.00
    10   0.00     --   0.00   0.00  -0.00     --  -0.00     --  -0.00
    11   1.24  94.34   1.17   0.00   1.17 100.00   1.17  94.34  21.21
    12   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  47.47
    13   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  73.74
    14   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  90.31
    19  -1.36  93.60  -1.45   0.00  -1.45 100.00  -1.45  93.60  63.89
    20  -1.53  92.90  -1.65   0.00  -1.65 100.00  -1.65  92.90  33.95
    21  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  14.49
    22  -0.76  95.70  -0.80   0.00  -0.80 100.00  -0.80  95.70  -0.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --   0.00
Totaal  -1.80     --  -2.58   0.00  -2.58     --  -2.58     --       
2025-04-11 07:01:18 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
  7.00    0.00     2.55   0.00   3.22   0.42   0.00   0.00   0.00   1.09   0.00   -1.00  43.10
  8.00    0.00     3.06   0.00   5.27   0.32   0.00   0.00   0.00   2.53   0.00   -1.74  42.70
  9.00    0.00     1.75   0.00   5.27   0.26   0.00   0.00   0.00   3.78   0.00   -1.61  42.30
 10.00    0.00     0.00   0.00   4.88  -0.17   0.00   0.00   0.00   4.71   0.00   -0.95  41.90
 11.00    3.71     0.00   0.00   1.12  -0.25   0.00   0.00   0.00   4.58   0.00   -0.19  41.50
 12.00    4.62     0.00   0.00   0.28  -0.28   0.00   0.00   0.00   4.63   0.00   -0.05  41.10
 13.00    4.62     0.00   1.08   0.00  -0.38   1.31   0.00   0.00   4.47   0.17    0.00  55.20
 14.00    4.62     0.00   0.23   0.00  -0.16   0.00   0.00   0.00   4.23   0.04    0.00  54.80
 15.00    0.00     0.00   0.00   3.22   0.31   0.00   0.00   0.00   3.53   0.00   -0.55  54.40
 16.00    0.00     0.00   0.00   2.12   0.57   0.00   0.00   0.00   2.69   0.00   -0.36  54.00
 17.00    0.00     0.00   0.00   1.11   0.63   0.00   0.00   0.00   1.73   0.00   -0.27  53.60
 18.00    0.00     1.12   0.00   1.11   0.71   0.00   0.00   0.00   0.70   0.00   -0.33  53.20
 19.00    0.00     3.74   0.00   3.28   0.54   0.00   0.00   0.00   0.08   0.00   -1.07  52.80
 20.00    0.00     4.63   0.00   4.07   0.56   0.00   0.00   0.00   0.00   0.00   -1.42  52.40
 21.00    0.00     3.23   0.00   2.59   0.64   0.00   0.00   0.00   0.00   0.00   -0.83  52.00
 22.00    0.00     2.80   0.00   2.21   0.60   0.00   0.00   0.00   0.00   0.00   -0.68  51.60
 23.00    0.00     0.00   0.58   0.00   0.58   0.00   0.00   0.00   0.00   0.17   -0.00  51.20
Totaal   17.57    22.89   1.88  39.74   4.89   1.31   0.00   0.00  38.74   0.38  -11.05       
2025-04-11 07:01:18 info: Winst: € 1.53
2025-04-11 07:01:18 info: Doorzetten van alle settings naar HA
2025-04-11 07:01:18 info: Boiler opwarmen niet geactiveerd
2025-04-11 07:01:18 info: Berekeningsuitkomst voor opladen van Zoe:
2025-04-11 07:01:18 info: - aantal ampere 0A (was 0.0A)
2025-04-11 07:01:18 info: - stand schakelaar 'off' (was 'off')
2025-04-11 07:01:18 info: - positie: home
2025-04-11 07:01:18 info: - ingeplugd: False
2025-04-11 07:01:18 info: Zoe is niet thuis of niet ingeplugd
2025-04-11 07:01:18 info: Evaluatie status laden Zoe op 2025-04-11 07:01
2025-04-11 07:01:18 info: - schakelaar laden: off
2025-04-11 07:01:18 info: - aantal ampere: 0.0
2025-04-11 07:01:18 info: Grid set point: -3217.0 W
2025-04-11 07:01:18 info: Cycle cost Sessy1: 0.41 euro
2025-04-11 07:01:18 info: Netto vermogen naar(+)/uit(-) omvormer Sessy1: -850 W
2025-04-11 07:01:18 info: Balanceren: False
2025-04-11 07:01:18 info: Vermogen uit batterij: 888W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van pv: 0W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van ac: -888W
2025-04-11 07:01:18 info: Waarde SoC na eerste uur: 29.9%
2025-04-11 07:01:18 info: Grid set point: -3217.0 W
2025-04-11 07:01:18 info: Cycle cost Sessy2: 0.41 euro
2025-04-11 07:01:18 info: Netto vermogen naar(+)/uit(-) omvormer Sessy2: -850 W
2025-04-11 07:01:18 info: Balanceren: False
2025-04-11 07:01:18 info: Vermogen uit batterij: 888W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van pv: 0W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van ac: -888W
2025-04-11 07:01:18 info: Waarde SoC na eerste uur: 30.9%
2025-04-11 07:01:18 info: Grid set point: -3217.0 W
2025-04-11 07:01:18 info: Cycle cost Sessy3: 0.41 euro
2025-04-11 07:01:18 info: Netto vermogen naar(+)/uit(-) omvormer Sessy3: -850 W
2025-04-11 07:01:18 info: Balanceren: False
2025-04-11 07:01:18 info: Vermogen uit batterij: 888W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van pv: 0W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van ac: -888W
2025-04-11 07:01:18 info: Waarde SoC na eerste uur: 30.9%

[bvw]

KC27 schreef op donderdag 10 april 2025 @ 23:30:
[...]

Een planningshorizon van 1 uur is tekort om zinvol te zijn met dynamische prijzen, maar een horizon instelbaar tussen minimaal 6 en maximaal 24 uur lijkt me zinvol.

Kijkend naar mijn voor- en najaars gedrag van de w-pomp nu slaat ie zo'n 2x aan (ochtend en latere avond), dus tussen 6- en 24 is voor mijn situatie realistisch. Misschien dat de gebruiker met houten vloeren zonder aanzienlijke buffer 4 uur kunnen gebruiken. Korter lijkt me inderdaad zinloos.Lijkt me een mooie optie!

Edit: Ik heb de on/off methode in de config gezet, en zie nu dat ie geen berekening kan doen, omdat in mijn power formule ik onder 0 uitkom met de avg temp van vandaag. (-0.0792 * states('input_number.dao_avg_outside_temperature') | float() + 0.9792). Dat zou dan denk ik betekenen dat de avg temperatuur van de planningshorizon meegenomen moet worden in deze berekening? Voor nu heb ik er maar even een 2e orde functie van gemaakt, is het probleem weg

KC27 schreef op donderdag 10 april 2025 @ 23:30:
[...]

De zoninstraling is zeker ook een belangrijke factor die zorgt voor warmteproductie.
Voor een deel zit deze verwerkt in de "gewogen" graaddagen, maar we zouden het allemaal instelbaar kunnen maken. In de opgehaalde meteo-gegevens zit naast de buitentemperatuur ook een goede indicator van de zonnestraling in de vorm van Globale Straling (in J/cm²). Die gebruikt DAO ook al om de pv-productie te voorspellen. Die zou ook gebruikt kunnen worden om de warmteopbrengst van de zon-instraling te voorspellen met een instelbare factor bijv 0.01 kWh/J/cm² (dat betekent dat 100 J/cm² 1 kWh warmte oplevert).

Wellicht is de factor te koppelen aan het aantal m2 glas op de zonzijde? xxm2 aan glas levert xxkWh aan warmte (binnen die planningshorizon van hierboven?).

[ Voor 29% gewijzigd door bvw op 11-04-2025 09:22 ]

[arro3038]

KC27 schreef op donderdag 10 april 2025 @ 23:30:
[...]


Ik ben het met je eens.
Als ik er nu over nadenk zou de planningshorizon van de wp instelbaar moeten zijn. Woningen met een kleine warmtebuffering kunnen in de ochtend geen warmte produceren en deze opslaan in hun vloer of buffer en die 12 uur later benutten.
Een planningshorizon van 1 uur is tekort om zinvol te zijn met dynamische prijzen, maar een horizon instelbaar tussen minimaal 6 en maximaal 24 uur lijkt me zinvol.
Wat vinden jullie hiervan?

De zoninstraling is zeker ook een belangrijke factor die zorgt voor warmteproductie.
Voor een deel zit deze verwerkt in de "gewogen" graaddagen, maar we zouden het allemaal instelbaar kunnen maken. In de opgehaalde meteo-gegevens zit naast de buitentemperatuur ook een goede indicator van de zonnestraling in de vorm van Globale Straling (in J/cm²). Die gebruikt DAO ook al om de pv-productie te voorspellen. Die zou ook gebruikt kunnen worden om de warmteopbrengst van de zon-instraling te voorspellen met een instelbare factor bijv 0.01 kWh/J/cm² (dat betekent dat 100 J/cm² 1 kWh warmte oplevert).
Ook hier de vraag: wat vinden jullie hiervan?

Voor beide voorstellen geldt:
Als het wordt doorgevoerd dan is het allemaal optioneel: als je niets instelt blijft alles bij het oude. Alleen gebruikers die het "onderste uit de kan willen" kunnen gebruik maken van een of beide van deze extra opties.

Dat klinkt als hele mooie toevoegingen aan een al heel erg mooi addon. Ik gebruik DAO nu alleen nog maar voor de batterij. Eerst eens een poos zien hoe het werkt en kijken of ik de parameters wel juist heb ingevuld. Daarna komt de warmtepomp aan de beurt. We hebben en goed geïsoleerd huis maar verwarmen met radiatoren. We hebben geen vloerverwarming en dus een kleine warmtebuffer. Voeg daar een grote glazen pui op Oost en West aan toe en instraling van de zon is een behoorlijke factor in het stookseizoen De toevoegingen die je beschijft zouden in onze situatie wel eens heel goed kunnen werken.

[DaBit]

KC27 schreef op woensdag 9 april 2025 @ 13:43:
De pv-voorspelling is gebaseerd op meteodata van het KNMI
..
Tot nu toe krijg ik weinig klachten van de gebruikers over deze methode.

Bij mij klopt het ook niet erg best. En dat ga ik ook niet goed krijgen; ik heb een aantal panelen die structureel het grootste deel van de dag in de schaduw liggen en dat verandert naarmate de baan van de zon wijzigt met jaargetijde stevig. Pas ik de yield aan voor een zonnige dag begin april dan zit ik mis tijdens een bewolktere dag eind april.

Maar het is me ook niet helemaal duidelijk hoe DAO die data gebruikt bij 'optimaliseer voor kosten' en in hoeverre de accuraatheid van de voorspelling daar invloed op heeft. Volgens mij komt het niet op de laatste procent, en op de laatste 50% ook niet, maar dat kan ik mishebben.

Ik heb nog een kleine verbetering in het vat door per uur de voorspelde hoeveelheid over een aantal dagen te vergelijken met de gerealiseerde hoeveelheid en dit als correctiefactor te gebruiken, zodat bijvoorbeeld de invloed van schaduw wordt gecorrigeerd.

Dat zou in mijn geval een welkome aanvulling zijn!

KC27 schreef op donderdag 10 april 2025 @ 23:12:
Ik heb zojuist versie 2025.4.0 gepubliceerd op github.
..
"Fixed the error (two hours too late) in the timestamp in the result-records from api/report-calls".

Yesss, dank, ook voor de aanpassing van de datastructuur! Ik ga 'm ergens dit weekend installeren en mijn eigen toevoegingen aanpassen.

edit:

1 klein opmerkingje: de string in data[x].time volgt niet de gangbare YYYY-MM-DDTHH:mm:ss.sssZ notitie (ISO8601), en het is uit die string niet duidelijk welke tijdzone ervoor gebruikt wordt.
Geen drama als je time_ts als bron van de waarheid beschouwt.

Maar ik vraag me wel af: waarom duurt bij jou de berekening zo lang?
Bij mij (op een Raspberry 5) is ie in 2 seconden klaar en een Odriod N2+ is m.i. minstens net zo krachtig.
Heb je veel batterijen?

Bij mij duurt het ook 25-30 seconden. HomeAssistant draait bij mij als virtuele machine op Proxmox, de Proxmox host is een Core i3-9100 met nvme opslag en voldoende geheugen.
De HA VM heeft 4 CPU cores en 4GB RAM gekregen. Aan de hardware ligt het opzich niet lijkt me.

Misschien vanwege accu, EV en 8 gedefinieerde zonne-installaties? Een groter optimalisatieprobleem duurt ook langer lijkt me.
Overigens vind ik het niet problematisch. De winst van 30 seconden eerder beginnen is nog geen procent, en dat ook nog maar als DAO iets perse in dat uur moet doen. Op dagen zoals vandaag waar er verspreid kan worden over meerdere uren is de winst nog veel kleiner.

[ Voor 5% gewijzigd door DaBit op 11-04-2025 12:07 ]

[bvw]

Ben nu begonnen aan het uitbreiden met machines. Ik heb de wasmachine er in gezet, en hij lijkt keurig meegenomen te worden in de berekening. Echter, volledig buiten m'n gedefinieerde window...

code:

  "machines" : [ 
    {
    "name" : "Wasmachine",
    "programs" : [
      {
        "name": "Uit",
        "power": []
      },
      {
        "name": "Normaal",
        "power": [2000, 500, 500, 400, 200, 400]
      }

    ],
    "entity start window" : "input_datetime.dao_wasmachine_start_window",
    "entity end window" : "input_datetime.dao_wasmachine_end_window",
    "entity selected program" : "input_select.dao_wasmachine_programma",
    "entity calculated start" : "input_datetime.dao_wasmachine_calculated_start",
    "entity calculated end" : "input_datetime.dao_wasmachine_calculated_end"
    }
  ],

In de logging geen errors, onderstaande het relevante (denk ik) stukje logging:

code:

2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_select.dao_wasmachine_programma HTTP/1.1" 200 432
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_calculated_start HTTP/1.1" 200 553
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_calculated_end HTTP/1.1" 200 549
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_start_window HTTP/1.1" 200 495
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_end_window HTTP/1.1" 200 492
2025-04-11 09:57:14 info: Apparaat Wasmachine met programma 'Normaal' wordt ingepland tussen 2025-04-11 08:00 en 2025-04-11 13:00.
2025-04-11 09:57:14 debug: Per kwartier welke run en met welk vermogen
kw: 0 tijd: 10:00 range r: 0 <-> 1 r: 0 power: 2000 
kw: 1 tijd: 10:15 range r: 0 <-> 2 r: 0 power: 500 1 power: 2000 
kw: 2 tijd: 10:30 range r: 0 <-> 3 r: 0 power: 500 1 power: 500 2 power: 2000 
kw: 3 tijd: 10:45 range r: 0 <-> 4 r: 0 power: 400 1 power: 500 2 power: 500 3 power: 2000 
kw: 4 tijd: 11:00 range r: 0 <-> 5 r: 0 power: 200 1 power: 400 2 power: 500 3 power: 500 4 power: 2000 
kw: 5 tijd: 11:15 range r: 0 <-> 6 r: 0 power: 400 1 power: 200 2 power: 400 3 power: 500 4 power: 500 5 power: 2000 
kw: 6 tijd: 11:30 range r: 1 <-> 7 r: 1 power: 400 2 power: 200 3 power: 400 4 power: 500 5 power: 500 6 power: 2000 
kw: 7 tijd: 11:45 range r: 2 <-> 8 r: 2 power: 400 3 power: 200 4 power: 400 5 power: 500 6 power: 500 7 power: 2000 
kw: 8 tijd: 12:00 range r: 3 <-> 9 r: 3 power: 400 4 power: 200 5 power: 400 6 power: 500 7 power: 500 8 power: 2000 
kw: 9 tijd: 12:15 range r: 4 <-> 10 r: 4 power: 400 5 power: 200 6 power: 400 7 power: 500 8 power: 500 9 power: 2000 
kw: 10 tijd: 12:30 range r: 5 <-> 11 r: 5 power: 400 6 power: 200 7 power: 400 8 power: 500 9 power: 500 10 power: 2000 
kw: 11 tijd: 12:45 range r: 6 <-> 12 r: 6 power: 400 7 power: 200 8 power: 400 9 power: 500 10 power: 500 11 power: 2000 
kw: 12 tijd: 13:00 range r: 7 <-> 13 r: 7 power: 400 8 power: 200 9 power: 400 10 power: 500 11 power: 500 12 power: 2000 
kw: 13 tijd: 13:15 range r: 8 <-> 14 r: 8 power: 400 9 power: 200 10 power: 400 11 power: 500 12 power: 500 13 power: 2000 
kw: 14 tijd: 13:30 range r: 9 <-> 15 r: 9 power: 400 10 power: 200 11 power: 400 12 power: 500 13 power: 500 14 power: 2000 
kw: 15 tijd: 13:45 range r: 10 <-> 16 r: 10 power: 400 11 power: 200 12 power: 400 13 power: 500 14 power: 500 
kw: 16 tijd: 14:00 range r: 11 <-> 16 r: 11 power: 400 12 power: 200 13 power: 400 14 power: 500 
kw: 17 tijd: 14:15 range r: 12 <-> 16 r: 12 power: 400 13 power: 200 14 power: 400 
kw: 18 tijd: 14:30 range r: 13 <-> 16 r: 13 power: 400 14 power: 200 
kw: 19 tijd: 14:45 range r: 14 <-> 16 r: 14 power: 400 
Welcome to the CBC MILP Solver 
Version: Trunk
Build Date: Oct 24 2021 

Starting solution of the Linear programming relaxation problem using Dual Simplex

Clp0024I Matrix will be packed to eliminate 76 small elements
Coin0506I Presolve 395 (-286) rows, 495 (-362) columns and 1485 (-692) elements
Clp0014I Perturbing problem by 0.001% of 7.800135 - largest nonzero change 0.00017408059 ( 0.0033224951%) - largest zero change 0.0001724982
Clp0000I Optimal - objective value 0
Coin0511I After Postsolve, objective 0, infeasibilities - dual 0 (0), primal 0 (0)
Clp0032I Optimal objective 0 - 109 iterations time 0.002, Presolve 0.00

Starting MIP optimization
Cgl0002I 21 variables fixed
Cgl0003I 0 fixed, 0 tightened bounds, 6 strengthened rows, 0 substitutions
Cgl0003I 0 fixed, 0 tightened bounds, 6 strengthened rows, 0 substitutions
Cgl0004I processed model has 407 rows, 522 columns (194 integer (194 of which binary)) and 1514 elements
Coin3009W Conflict graph built in 0.000 seconds, density: 0.115%
Cgl0015I Clique Strengthening extended 0 cliques, 0 were dominated
Cbc0036I Heuristics switched off as 15 branching objects are of wrong type
Cbc0045I Nauty did not find any useful orbits in time 0.003215
Cbc0031I 35 added rows had average density of 14.228571
Cbc0013I At root node, 35 cuts changed objective from 0 to 0 in 8 passes
Cbc0014I Cut generator 0 (Probing) - 76 row cuts average 3.2 elements, 0 column cuts (0 active)  in 0.008 seconds - new frequency is -100
Cbc0014I Cut generator 1 (Gomory) - 56 row cuts average 30.8 elements, 0 column cuts (0 active)  in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 2 (Knapsack) - 15 row cuts average 5.9 elements, 0 column cuts (0 active)  in 0.004 seconds - new frequency is -100
Cbc0014I Cut generator 3 (Clique) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 4 (OddWheel) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 5 (MixedIntegerRounding2) - 45 row cuts average 12.4 elements, 0 column cuts (0 active)  in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 6 (FlowCover) - 5 row cuts average 3.8 elements, 0 column cuts (0 active)  in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 7 (TwoMirCuts) - 61 row cuts average 21.5 elements, 0 column cuts (0 active)  in 0.003 seconds - new frequency is -100
Cbc0004I Integer solution of 0 found after 304 iterations and 10 nodes (0.07 seconds)
Cbc0001I Search completed - best objective 0, took 304 iterations and 10 nodes (0.07 seconds)
Cbc0032I Strong branching done 72 times (275 iterations), fathomed 0 nodes and fixed 0 variables
Cbc0035I Maximum depth 9, 0 variables fixed on reduced cost
31 bounds tightened after postprocessing

Total time (CPU seconds):       0.07   (Wallclock seconds):       0.08

2025-04-11 09:57:14 info: Eerste berekening
2025-04-11 09:57:14 info: Kosten (euro): 0.21  
2025-04-11 09:57:14 info: Levering (kWh): 0.00  
Starting solution of the Linear programming relaxation problem using Dual Simplex

Clp0014I Perturbing problem by 0.001% of 0.68824731 - largest nonzero change 2.8782949e-05 ( 0.0026274117%) - largest zero change 2.9824787e-05
Clp0000I Optimal - objective value -0.62707827

Starting MIP optimization
Cgl0002I 21 variables fixed
Cgl0003I 7 fixed, 0 tightened bounds, 3 strengthened rows, 0 substitutions
Cgl0004I processed model has 336 rows, 440 columns (149 integer (149 of which binary)) and 1265 elements
Coin3009W Conflict graph built in 0.000 seconds, density: 0.141%
Cgl0015I Clique Strengthening extended 0 cliques, 0 were dominated
Cbc0045I MIPStart provided solution with cost 0.213886
Cbc0012I Integer solution of 0.15956498 found by Reduced search after 0 iterations and 0 nodes (0.02 seconds)
Cbc0036I Heuristics switched off as 15 branching objects are of wrong type
Cbc0045I Nauty: 1582 orbits (2 useful covering 24 variables), 22 generators, group size: 5.83896e+19 - sparse size 7712 - took 0.004097 seconds
Cbc0031I 40 added rows had average density of 10.85
Cbc0013I At root node, 40 cuts changed objective from -0.62707827 to -0.62644563 in 21 passes
Cbc0014I Cut generator 0 (Probing) - 263 row cuts average 2.5 elements, 0 column cuts (0 active)  in 0.015 seconds - new frequency is 1
Cbc0014I Cut generator 1 (Gomory) - 98 row cuts average 67.1 elements, 0 column cuts (0 active)  in 0.005 seconds - new frequency is 1
Cbc0014I Cut generator 2 (Knapsack) - 6 row cuts average 6.5 elements, 0 column cuts (0 active)  in 0.007 seconds - new frequency is 1
Cbc0014I Cut generator 3 (Clique) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 4 (OddWheel) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 5 (MixedIntegerRounding2) - 32 row cuts average 24.3 elements, 0 column cuts (0 active)  in 0.004 seconds - new frequency is 1
Cbc0014I Cut generator 6 (FlowCover) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.004 seconds - new frequency is -100
Cbc0014I Cut generator 7 (TwoMirCuts) - 78 row cuts average 37.7 elements, 0 column cuts (0 active)  in 0.003 seconds - new frequency is -100
Cbc0016I Integer solution of -0.41334741 found by strong branching after 604 iterations and 14 nodes (0.15 seconds)
Cbc0016I Integer solution of -0.62616689 found by strong branching after 607 iterations and 17 nodes (0.16 seconds)
Cbc3008W Strong branching is fixing too many variables, too expensively!
Cbc0016I Integer solution of -0.62635089 found by strong branching after 632 iterations and 24 nodes (0.18 seconds)
Cbc0001I Search completed - best objective -0.6263508891545493, took 665 iterations and 28 nodes (0.19 seconds)
Cbc0032I Strong branching done 234 times (981 iterations), fathomed 3 nodes and fixed 14 variables
Cbc0035I Maximum depth 12, 15 variables fixed on reduced cost
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
24 bounds tightened after postprocessing

Total time (CPU seconds):       0.21   (Wallclock seconds):       0.23

[Faceless]

Als iemand inspiratie zoekt voor een Home Assistant dashboard op basis van DAO, met 2 Sessy batterijen.

[vinom]

Faceless schreef op vrijdag 11 april 2025 @ 19:18:
Als iemand inspiratie zoekt voor een Home Assistant dashboard op basis van DAO, met 2 Sessy batterijen.

[Afbeelding]

Ziet er goed uit. Kun je iets van de code delen zodat we alleen nog de juiste entities eraan hoeven te knopen?

[hemertje]

storeman schreef op donderdag 10 april 2025 @ 23:02:
@hemertje

Ten eerste, echt programmeren is het niet in mijn optiek. Het is allemaal tamelijk gebruiksvriendelijk in Home Assistant tegenwoordig. Ik zal het proberen uit te leggen hoe het zou moeten werken.


1. Je maakt helpers aan van bepaalde types en geeft ze een naam (via Instellingen > Apparaten & Diensten > Helpers)
2. Deze helper krijgt op basis van de naam een uniek ID. Als je de helper hebt opgeslagen, kun je erop klikken en het ID vinden. Iets als `input_boolean.dao_balancing`
3. Dit ID gebruik je in de DAO config. DAO leest en schrijft deze waardes. Als je iets wil automatiseren op basis van DAO, dat gaat op basis van entiteiten die door DAO worden gevuld/geschreven.
4. Maak een automatisering in Home Assistant. De trigger is dan de entiteit (input_boolean.dao_balancing) die wijzigt. Hier hang je dan acties aan die uitgevoerd moeten worden.

sorry,maar voor mij allemaal abrcadabra ondanks al je goede bedoelingen
het ligt ook niet aan jou maar aan mij:P

wanneer iemand uit omgeving Eindhoven mij een keer op weg wil helpen in HA en kan toelichten, dan hou ik me aanbevolen!

[ErnstH]

Goed idee om de verwachte SoC erin op te nemen. Dat ga ik in de day ahead grafieken toevoegen!

[ Voor 12% gewijzigd door ErnstH op 11-04-2025 21:05 ]

[stoner1978]

Hallo,

Kan iemand mij in de juiste richting wijzen, ik krijg de volgende foutmelding maar heb geen idee welke entiteit het om gaat.
Alvast bedankt!

code:

2025-04-11 21:11:11 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3448, in <module>
2025-04-11 21:11:11 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3424, in main
2025-04-11 21:11:11 fout: File: /root/dao/prog/da_base.py, line 478, in run_task_function
2025-04-11 21:11:11 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2862, in calc_optimum
2025-04-11 21:11:11 fout: File: /root/dao/prog/da_base.py, line 370, in set_entity_option
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 49, in select_option
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 28, in call_service
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 68, in _post
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 90, in _process_response
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 95, in _raise_error
2025-04-11 21:11:11 fout: Onverwachte fout: 500 status code returned from http://192.168.1.207:8123...nput_select/select_option
Traceback (most recent call last):
File "/root/dao/webserver/../prog/day_ahead.py", line 2656, in calc_optimum
self.set_entity_option(
File "/root/dao/prog/da_base.py", line 370, in set_entity_option
self.select_option(entity_id, value)
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 49, in select_option
return self.call_service("select_option", entity_id=entity_id, option=option)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 28, in call_service
self._post(
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 68, in _post
return self._process_response(
^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
self._raise_error(response.status_code, response.url)
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
raise error(f"{status_code} status code returned from {url}",) # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.InternalServerError: 500 status code returned from http://192.168.1.207:8123...nput_select/select_option

[RudolfR]

@stoner1978

Heb je wel HA geconfigureerd in DAO met een long-lived-token? Zonder werkt sinds kort niet meer.

[KC27]

mgroen81 schreef op vrijdag 11 april 2025 @ 07:44:
@KC27 Heb 3x Sessy in de config.

code:

{
  "homeassistant": {
   "protocol api": "http",
   "ip adress": "192.168.178.156",
   "ip port": 8123,
   "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.30,
    "regular low": 0.30,
    "switch to low": 23,
    "energy taxes delivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes redelivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier delivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.03957
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.03957
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2024-10-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "dark_background",
    "show" : "true",
    "battery balance": "False",
    "prices delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
    "notification entity": "input_text.dao_notificatie",
    "opstarten": "False",
    "berekening": "False",
    "last activity entity": "input_datetime.dao_laatste_activiteit"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "True",
    "boiler heated by heatpump": "True",
    "entity actual temp.": "sensor.ecodan_heatpump_dhw_current_temp",
    "entity setpoint": "sensor.ecodan_heatpump_dhw_setpoint_value",
    "entity hysterese": "input_number.dao_hysterese_dhw",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 200,
    "heating allowed below": 43,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "switch.ecodan_heatpump_force_dhw"
  },
  "heating": {
    "heater present": "False",
    "entity hp enabled": "input_boolean.dao_heatpump_heating",
    "entity hp switch": "input_boolean.dao_heatpump_switch",
    "entity avg outside temp": "input_number.dao_avg_outside_temp",
    "degree days factor": 3.6,
    "adjustment" : "on/off",
    "//adjustment" : "on/off | power | heating curve",
    "stages": [
      {
        "max_power": 400,
        "cop": 7.78
      },
      {
        "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.dao_stooklijn_verschuiving_day_ahead2",
    "adjustment factor": 0.04
  },
  "battery": [
    {
      "name": "Sessy1",
      "entity actual level": "sensor.sessy_dvw9_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4400.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 3400.0,
      "cycle cost": 0.03,
      "entity set power feedin": "input_number.dao_sessy_dvw9_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_dvw9_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_dvw9",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_dvw9",
      "entity from battery": "input_number.dao_sessy_dvw9_from_battery",
      "entity from pv": "input_number.dao_sessy_dvw9_from_pv",
      "entity from ac": "input_number.dao_sessy_dvw9_from_ac",
      "entity calculated soc": "input_number.dao_sessy_dvw9_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy2",
      "entity actual level": "sensor.sessy_dtjg_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4400.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 3400.0,
      "cycle cost": 0.03,
      "entity set power feedin": "input_number.dao_sessy_dtjg_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_dtjg_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_dtjg",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_dtjg",
      "entity from battery": "input_number.dao_sessy_dtjg_from_battery",
      "entity from pv": "input_number.dao_sessy_dtjg_from_pv",
      "entity from ac": "input_number.dao_sessy_dtjg_from_ac",
      "entity calculated soc": "input_number.dao_sessy_dtjg_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy3",
      "entity actual level": "sensor.sessy_duny_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "dc_to_bat max power" : 4400.0,
      "bat_to_dc efficiency": 1,
      "bat_to_dc max power" : 3400.0,
      "cycle cost": 0.03,
      "entity set power feedin": "input_number.dao_sessy_duny_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_duny_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_duny",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_duny",
      "entity from battery": "input_number.dao_sessy_duny_from_battery",
      "entity from pv": "input_number.dao_sessy_duny_from_pv",
      "entity from ac": "input_number.dao_sessy_duny_from_ac",
      "entity calculated soc": "input_number.dao_sessy_duny_calculated_soc",
      "solar": []
    }
  ],
  "solar": [
    {
      "name": "pv woning1",
      "tilt": 40,
      "orientation": 98,
      "capacity": 4.0,
      "yield": 0.007,
      "entity pv switch": ""
    },
    {
      "name": "pv woning2",
      "tilt": 40,
      "orientation": -82,
      "capacity": 4.8,
      "yield": 0.008,
      "entity pv switch": ""
    },
    {
      "name": "pv tuinhuis",
      "tilt": 8,
      "orientation": 0,
      "capacity": 2.3,
      "yield": 0.005,
      "entity pv switch": ""
    }
  ],
  "electric vehicle": [
    {
      "name": "Zoe",
      "capacity": 40,
      "entity position": "device_tracker.smartevse_6697",
      "entity max amperage": "sensor.smartevse_current_max",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 15, "efficiency" :  1}
      ],
      "entity actual level": "input_number.zoe_accu",
      "entity plugged in": "input_boolean.dao_zoe_external_power_connected",
      "charge scheduler": {
        "entity set level": "input_number.dao_zoe_gewenst_laad_niveau",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_zoetijdstip_klaar_met_laden"
      },
      "charge switch": "input_boolean.dao_zoe_charging",
      "entity set charging ampere" : "input_number.dao_zoe_set_car_charging_ampere",
      "entity stop charging": "input_datetime.dao_zoe_stop_laden_ev"
    }
  ],
  "report": {
    "entities grid consumption": [
      "sensor.sessy_p6eh_tariff_1_consumed_energy",
      "sensor.sessy_p6eh_tariff_2_consumed_energy"
    ],
    "entities grid production": [
      "sensor.sessy_p6eh_tariff_1_produced_energy",
      "sensor.sessy_p6eh_tariff_2_produced_energy"
    ],
    "entities solar production ac": [
      "sensor.solaredge_i1_ac_energy_kwh",
      "sensor.kwh_meter_1_phase_pv2_total_power_export"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.kwh_meter_3_phase_ev_energy_import"],
    "entities wp consumption" : ["sensor.extra_total"],
    "entities boiler consumption": [],
    "entities battery consumption": [
      "sensor.sessy_fase1_dvw9_charged_energy",
      "sensor.sessy_fase2_dtjg_charged_energy",
      "sensor.sessy_fase3_duny_charged_energy"],
    "entities battery production": [
      "sensor.sessy_fase1_dvw9_discharged_energy",
      "sensor.sessy_fase2_dtjg_discharged_energy",
      "sensor.sessy_fase3_duny_discharged_energy"]
  },
  "scheduler": {
    "active": "true",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

Resultaat

code:

 2025-04-11 07:00:00 info: Day Ahead Optimalisering versie: 2025.3.1
2025-04-11 07:00:00 info: Day Ahead Optimalisering gestart op: 11-04-2025 07:00:00
2025-04-11 07:00:00 info: Day Ahead Optimalisatie gestart: 11-04-2025 07:00:00 taak: calc_optimum
2025-04-11 07:00:00 info: Debug = False
2025-04-11 07:00:00 info: Zelf berekende baseload
2025-04-11 07:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0     7 2025-04-11 07:00:00   0.31   0.31   0.42   1.09      0
1     8 2025-04-11 08:00:00   0.33   0.33   0.32   2.53      0
2     9 2025-04-11 09:00:00   0.31   0.31   0.26   3.78      0
3    10 2025-04-11 10:00:00   0.20   0.20  -0.17   4.71      0
4    11 2025-04-11 11:00:00   0.17   0.17  -0.25   4.58      0
5    12 2025-04-11 12:00:00   0.16   0.16  -0.28   4.63      0
6    13 2025-04-11 13:00:00   0.16   0.16  -0.38   4.47      0
7    14 2025-04-11 14:00:00   0.16   0.16  -0.16   4.23      0
8    15 2025-04-11 15:00:00   0.17   0.17   0.31   3.53      0
9    16 2025-04-11 16:00:00   0.17   0.17   0.57   2.69      0
10   17 2025-04-11 17:00:00   0.25   0.25   0.63   1.73      0
11   18 2025-04-11 18:00:00   0.30   0.30   0.71   0.70      0
12   19 2025-04-11 19:00:00   0.32   0.32   0.54   0.08      0
13   20 2025-04-11 20:00:00   0.35   0.35   0.56   0.00      0
14   21 2025-04-11 21:00:00   0.32   0.32   0.64   0.00      0
15   22 2025-04-11 22:00:00   0.31   0.31   0.60   0.00      0
16   23 2025-04-11 23:00:00   0.29   0.29   0.58   0.00      0
2025-04-11 07:00:43 info: Verbruik dit contractjaar: 6008.242 kWh
2025-04-11 07:00:43 info: Productie dit contractjaar: 2040.705 kWh
2025-04-11 07:00:43 info: All taxes refund (alles wordt gesaldeerd)
2025-04-11 07:00:43 info: Reduced hours applied for Sessy1
2025-04-11 07:00:43 info: Startwaarde SoC Sessy1: 46.0%
2025-04-11 07:00:43 info: Reduced hours applied for Sessy2
2025-04-11 07:00:43 info: Startwaarde SoC Sessy2: 47.0%
2025-04-11 07:00:43 info: Reduced hours applied for Sessy3
2025-04-11 07:00:43 info: Startwaarde SoC Sessy3: 47.0%
2025-04-11 07:00:43 info: Boiler opwarmen wordt ingepland tussen: 8 en 23 uur
2025-04-11 07:00:43 info: Instellingen voor laden van EV: Zoe
2025-04-11 07:00:43 info:  Ampere  Effic. Grid kW Accu kW
2025-04-11 07:00:43 info:    0.00    1.00    0.00    0.00
2025-04-11 07:00:43 info:   15.00    1.00   10.35   10.35
2025-04-11 07:00:43 info: Capaciteit accu: 40 kWh
2025-04-11 07:00:43 info: Maximaal laadvermogen: 10.35 kW
2025-04-11 07:00:43 info: Klaar met laden op: 12-04-2025 06:00:00
2025-04-11 07:00:43 info: Huidig laadniveau: 25.0 %
2025-04-11 07:00:43 info: Gewenst laadniveau:100.0 %
2025-04-11 07:00:43 info: Marge voor het laden: 1 %
2025-04-11 07:00:43 info: Locatie: home
2025-04-11 07:00:43 info: Ingeplugged:False
2025-04-11 07:00:43 info: Benodigde energie: 30.0 kWh
2025-04-11 07:00:43 info: Tijd nodig om te laden: 2.90 uur
2025-04-11 07:00:43 info: Afgerond naar hele uren: 3
2025-04-11 07:00:43 info: Stand laden schakelaar: off
2025-04-11 07:00:43 info: Stand aantal ampere laden: 0.0 A
2025-04-11 07:00:43 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd, opgegeven tijdstip (2025-04-12 06:00:00) ligt voorbij de planningshorizon (2025-04-11 23:00:00).
2025-04-11 07:01:17 info: Strategie: minimale kosten
2025-04-11 07:01:17 info: Het programma heeft een optimale oplossing gevonden.
2025-04-11 07:01:17 info: Geen saldeer correctie
2025-04-11 07:01:17 info: Niet geoptimaliseerd, kosten met reguliere tarieven: -15.81
2025-04-11 07:01:17 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -6.15 
2025-04-11 07:01:17 info: Geoptimaliseerd, kosten met day ahead tarieven: -7.68 
2025-04-11 07:01:17 info: Levering: 1.88   (kWh)
2025-04-11 07:01:17 info: Waarde boiler om 23 uur: 1.28 kWh
2025-04-11 07:01:17 info: In- en uitgaande energie per uur batterij Sessy1
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     7  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  29.85
     8  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  10.39
     9  -0.55  95.70  -0.57   0.00  -0.57 100.00  -0.57  95.70  -0.00
    10   0.00     --   0.00   0.00  -0.00     --  -0.00     --  -0.00
    11   1.24  94.34   1.17   0.00   1.17 100.00   1.17  94.34  21.21
    12   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  47.47
    13   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  73.74
    14   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18  -0.61  95.70  -0.64   0.00  -0.64 100.00  -0.64  95.70  88.32
    19  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  68.86
    20  -1.53  92.90  -1.65   0.00  -1.65 100.00  -1.65  92.90  38.92
    21  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  19.46
    22  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  -0.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --   0.00
Totaal  -1.76     --  -2.53   0.00  -2.53     --  -2.53     --       
2025-04-11 07:01:17 info: In- en uitgaande energie per uur batterij Sessy2
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     7  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  30.85
     8  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  11.39
     9  -0.60  95.70  -0.63   0.00  -0.63 100.00  -0.63  95.70  -0.00
    10   0.00     --   0.00   0.00  -0.00     --  -0.00     --  -0.00
    11   1.24  94.34   1.17   0.00   1.17 100.00   1.17  94.34  21.21
    12   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  47.47
    13   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  73.74
    14   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19  -1.36  93.60  -1.45   0.00  -1.45 100.00  -1.45  93.60  73.58
    20  -1.57  92.50  -1.70   0.00  -1.70 100.00  -1.70  92.50  42.67
    21  -1.19  94.30  -1.26   0.00  -1.26 100.00  -1.26  94.30  19.73
    22  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30   0.27
    23   0.00     --   0.00   0.00   0.00     --   0.00     --   0.27
Totaal  -1.76     --  -2.57   0.00  -2.57     --  -2.57     --       
2025-04-11 07:01:17 info: In- en uitgaande energie per uur batterij Sessy3
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     7  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  30.85
     8  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  11.39
     9  -0.60  95.70  -0.63   0.00  -0.63 100.00  -0.63  95.70  -0.00
    10   0.00     --   0.00   0.00  -0.00     --  -0.00     --  -0.00
    11   1.24  94.34   1.17   0.00   1.17 100.00   1.17  94.34  21.21
    12   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  47.47
    13   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80  73.74
    14   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  90.31
    19  -1.36  93.60  -1.45   0.00  -1.45 100.00  -1.45  93.60  63.89
    20  -1.53  92.90  -1.65   0.00  -1.65 100.00  -1.65  92.90  33.95
    21  -1.02  95.30  -1.07   0.00  -1.07 100.00  -1.07  95.30  14.49
    22  -0.76  95.70  -0.80   0.00  -0.80 100.00  -0.80  95.70  -0.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --   0.00
Totaal  -1.80     --  -2.58   0.00  -2.58     --  -2.58     --       
2025-04-11 07:01:18 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
  7.00    0.00     2.55   0.00   3.22   0.42   0.00   0.00   0.00   1.09   0.00   -1.00  43.10
  8.00    0.00     3.06   0.00   5.27   0.32   0.00   0.00   0.00   2.53   0.00   -1.74  42.70
  9.00    0.00     1.75   0.00   5.27   0.26   0.00   0.00   0.00   3.78   0.00   -1.61  42.30
 10.00    0.00     0.00   0.00   4.88  -0.17   0.00   0.00   0.00   4.71   0.00   -0.95  41.90
 11.00    3.71     0.00   0.00   1.12  -0.25   0.00   0.00   0.00   4.58   0.00   -0.19  41.50
 12.00    4.62     0.00   0.00   0.28  -0.28   0.00   0.00   0.00   4.63   0.00   -0.05  41.10
 13.00    4.62     0.00   1.08   0.00  -0.38   1.31   0.00   0.00   4.47   0.17    0.00  55.20
 14.00    4.62     0.00   0.23   0.00  -0.16   0.00   0.00   0.00   4.23   0.04    0.00  54.80
 15.00    0.00     0.00   0.00   3.22   0.31   0.00   0.00   0.00   3.53   0.00   -0.55  54.40
 16.00    0.00     0.00   0.00   2.12   0.57   0.00   0.00   0.00   2.69   0.00   -0.36  54.00
 17.00    0.00     0.00   0.00   1.11   0.63   0.00   0.00   0.00   1.73   0.00   -0.27  53.60
 18.00    0.00     1.12   0.00   1.11   0.71   0.00   0.00   0.00   0.70   0.00   -0.33  53.20
 19.00    0.00     3.74   0.00   3.28   0.54   0.00   0.00   0.00   0.08   0.00   -1.07  52.80
 20.00    0.00     4.63   0.00   4.07   0.56   0.00   0.00   0.00   0.00   0.00   -1.42  52.40
 21.00    0.00     3.23   0.00   2.59   0.64   0.00   0.00   0.00   0.00   0.00   -0.83  52.00
 22.00    0.00     2.80   0.00   2.21   0.60   0.00   0.00   0.00   0.00   0.00   -0.68  51.60
 23.00    0.00     0.00   0.58   0.00   0.58   0.00   0.00   0.00   0.00   0.17   -0.00  51.20
Totaal   17.57    22.89   1.88  39.74   4.89   1.31   0.00   0.00  38.74   0.38  -11.05       
2025-04-11 07:01:18 info: Winst: € 1.53
2025-04-11 07:01:18 info: Doorzetten van alle settings naar HA
2025-04-11 07:01:18 info: Boiler opwarmen niet geactiveerd
2025-04-11 07:01:18 info: Berekeningsuitkomst voor opladen van Zoe:
2025-04-11 07:01:18 info: - aantal ampere 0A (was 0.0A)
2025-04-11 07:01:18 info: - stand schakelaar 'off' (was 'off')
2025-04-11 07:01:18 info: - positie: home
2025-04-11 07:01:18 info: - ingeplugd: False
2025-04-11 07:01:18 info: Zoe is niet thuis of niet ingeplugd
2025-04-11 07:01:18 info: Evaluatie status laden Zoe op 2025-04-11 07:01
2025-04-11 07:01:18 info: - schakelaar laden: off
2025-04-11 07:01:18 info: - aantal ampere: 0.0
2025-04-11 07:01:18 info: Grid set point: -3217.0 W
2025-04-11 07:01:18 info: Cycle cost Sessy1: 0.41 euro
2025-04-11 07:01:18 info: Netto vermogen naar(+)/uit(-) omvormer Sessy1: -850 W
2025-04-11 07:01:18 info: Balanceren: False
2025-04-11 07:01:18 info: Vermogen uit batterij: 888W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van pv: 0W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van ac: -888W
2025-04-11 07:01:18 info: Waarde SoC na eerste uur: 29.9%
2025-04-11 07:01:18 info: Grid set point: -3217.0 W
2025-04-11 07:01:18 info: Cycle cost Sessy2: 0.41 euro
2025-04-11 07:01:18 info: Netto vermogen naar(+)/uit(-) omvormer Sessy2: -850 W
2025-04-11 07:01:18 info: Balanceren: False
2025-04-11 07:01:18 info: Vermogen uit batterij: 888W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van pv: 0W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van ac: -888W
2025-04-11 07:01:18 info: Waarde SoC na eerste uur: 30.9%
2025-04-11 07:01:18 info: Grid set point: -3217.0 W
2025-04-11 07:01:18 info: Cycle cost Sessy3: 0.41 euro
2025-04-11 07:01:18 info: Netto vermogen naar(+)/uit(-) omvormer Sessy3: -850 W
2025-04-11 07:01:18 info: Balanceren: False
2025-04-11 07:01:18 info: Vermogen uit batterij: 888W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van pv: 0W
2025-04-11 07:01:18 info: Vermogen dat binnenkomt van ac: -888W
2025-04-11 07:01:18 info: Waarde SoC na eerste uur: 30.9%

Er is in principe niks fout aan je settings.
Maar met drie batterijen maak je het DAO niet makkelijk.
In jouw situatie met drie batterijen en een ev zijn er heel veel variabelen.
De rekentijd neemt toe met het ongeveer het kwadraat van de variabelen.
In jouw situatie heb je drie identieke batterijen die je - als ik het goed zie - ook identiek inzet.
Je zou het DAO waarschijnlijk veel makkelijker kunnen maken door van die drie één virtuele batterij te maken.

Dat zou je eerst even kunnen testen door tijdelijk twee batterijen weg te halen en dan een "run met debug" doen.
Als dat veel scheelt kun je alsnog (als je dat wilt) een virtuele batterij maken:

• je definieert één batterij
• de capaciteit vermenigvuldig je met drie, evenals het vermogen in alle "stages" en de andere vermogens
• voor de start soc neem je een template sensor die het gemiddelde van de drie echte soc's berekend
• voor de door DAO berekende inzet/het vermogen maak je een input_number aan en daar hang je een automation aan die een derde doorzet naar de drie afzonderlijke sessy's.

Ik ben benieuwd naar je bevindingen.

[KC27]

bvw schreef op vrijdag 11 april 2025 @ 09:59:
Ben nu begonnen aan het uitbreiden met machines. Ik heb de wasmachine er in gezet, en hij lijkt keurig meegenomen te worden in de berekening. Echter, volledig buiten m'n gedefinieerde window...

[Afbeelding]

code:

  "machines" : [ 
    {
    "name" : "Wasmachine",
    "programs" : [
      {
        "name": "Uit",
        "power": []
      },
      {
        "name": "Normaal",
        "power": [2000, 500, 500, 400, 200, 400]
      }

    ],
    "entity start window" : "input_datetime.dao_wasmachine_start_window",
    "entity end window" : "input_datetime.dao_wasmachine_end_window",
    "entity selected program" : "input_select.dao_wasmachine_programma",
    "entity calculated start" : "input_datetime.dao_wasmachine_calculated_start",
    "entity calculated end" : "input_datetime.dao_wasmachine_calculated_end"
    }
  ],

In de logging geen errors, onderstaande het relevante (denk ik) stukje logging:

code:

2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_select.dao_wasmachine_programma HTTP/1.1" 200 432
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_calculated_start HTTP/1.1" 200 553
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_calculated_end HTTP/1.1" 200 549
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_start_window HTTP/1.1" 200 495
2025-04-11 09:57:14 debug: Starting new HTTP connection (1): 192.168.2.2:8123
2025-04-11 09:57:14 debug: http://192.168.2.2:8123 "GET /api/states/input_datetime.dao_wasmachine_end_window HTTP/1.1" 200 492
2025-04-11 09:57:14 info: Apparaat Wasmachine met programma 'Normaal' wordt ingepland tussen 2025-04-11 08:00 en 2025-04-11 13:00.
2025-04-11 09:57:14 debug: Per kwartier welke run en met welk vermogen
kw: 0 tijd: 10:00 range r: 0 <-> 1 r: 0 power: 2000 
kw: 1 tijd: 10:15 range r: 0 <-> 2 r: 0 power: 500 1 power: 2000 
kw: 2 tijd: 10:30 range r: 0 <-> 3 r: 0 power: 500 1 power: 500 2 power: 2000 
kw: 3 tijd: 10:45 range r: 0 <-> 4 r: 0 power: 400 1 power: 500 2 power: 500 3 power: 2000 
kw: 4 tijd: 11:00 range r: 0 <-> 5 r: 0 power: 200 1 power: 400 2 power: 500 3 power: 500 4 power: 2000 
kw: 5 tijd: 11:15 range r: 0 <-> 6 r: 0 power: 400 1 power: 200 2 power: 400 3 power: 500 4 power: 500 5 power: 2000 
kw: 6 tijd: 11:30 range r: 1 <-> 7 r: 1 power: 400 2 power: 200 3 power: 400 4 power: 500 5 power: 500 6 power: 2000 
kw: 7 tijd: 11:45 range r: 2 <-> 8 r: 2 power: 400 3 power: 200 4 power: 400 5 power: 500 6 power: 500 7 power: 2000 
kw: 8 tijd: 12:00 range r: 3 <-> 9 r: 3 power: 400 4 power: 200 5 power: 400 6 power: 500 7 power: 500 8 power: 2000 
kw: 9 tijd: 12:15 range r: 4 <-> 10 r: 4 power: 400 5 power: 200 6 power: 400 7 power: 500 8 power: 500 9 power: 2000 
kw: 10 tijd: 12:30 range r: 5 <-> 11 r: 5 power: 400 6 power: 200 7 power: 400 8 power: 500 9 power: 500 10 power: 2000 
kw: 11 tijd: 12:45 range r: 6 <-> 12 r: 6 power: 400 7 power: 200 8 power: 400 9 power: 500 10 power: 500 11 power: 2000 
kw: 12 tijd: 13:00 range r: 7 <-> 13 r: 7 power: 400 8 power: 200 9 power: 400 10 power: 500 11 power: 500 12 power: 2000 
kw: 13 tijd: 13:15 range r: 8 <-> 14 r: 8 power: 400 9 power: 200 10 power: 400 11 power: 500 12 power: 500 13 power: 2000 
kw: 14 tijd: 13:30 range r: 9 <-> 15 r: 9 power: 400 10 power: 200 11 power: 400 12 power: 500 13 power: 500 14 power: 2000 
kw: 15 tijd: 13:45 range r: 10 <-> 16 r: 10 power: 400 11 power: 200 12 power: 400 13 power: 500 14 power: 500 
kw: 16 tijd: 14:00 range r: 11 <-> 16 r: 11 power: 400 12 power: 200 13 power: 400 14 power: 500 
kw: 17 tijd: 14:15 range r: 12 <-> 16 r: 12 power: 400 13 power: 200 14 power: 400 
kw: 18 tijd: 14:30 range r: 13 <-> 16 r: 13 power: 400 14 power: 200 
kw: 19 tijd: 14:45 range r: 14 <-> 16 r: 14 power: 400 
Welcome to the CBC MILP Solver 
Version: Trunk
Build Date: Oct 24 2021 

Starting solution of the Linear programming relaxation problem using Dual Simplex

Clp0024I Matrix will be packed to eliminate 76 small elements
Coin0506I Presolve 395 (-286) rows, 495 (-362) columns and 1485 (-692) elements
Clp0014I Perturbing problem by 0.001% of 7.800135 - largest nonzero change 0.00017408059 ( 0.0033224951%) - largest zero change 0.0001724982
Clp0000I Optimal - objective value 0
Coin0511I After Postsolve, objective 0, infeasibilities - dual 0 (0), primal 0 (0)
Clp0032I Optimal objective 0 - 109 iterations time 0.002, Presolve 0.00

Starting MIP optimization
Cgl0002I 21 variables fixed
Cgl0003I 0 fixed, 0 tightened bounds, 6 strengthened rows, 0 substitutions
Cgl0003I 0 fixed, 0 tightened bounds, 6 strengthened rows, 0 substitutions
Cgl0004I processed model has 407 rows, 522 columns (194 integer (194 of which binary)) and 1514 elements
Coin3009W Conflict graph built in 0.000 seconds, density: 0.115%
Cgl0015I Clique Strengthening extended 0 cliques, 0 were dominated
Cbc0036I Heuristics switched off as 15 branching objects are of wrong type
Cbc0045I Nauty did not find any useful orbits in time 0.003215
Cbc0031I 35 added rows had average density of 14.228571
Cbc0013I At root node, 35 cuts changed objective from 0 to 0 in 8 passes
Cbc0014I Cut generator 0 (Probing) - 76 row cuts average 3.2 elements, 0 column cuts (0 active)  in 0.008 seconds - new frequency is -100
Cbc0014I Cut generator 1 (Gomory) - 56 row cuts average 30.8 elements, 0 column cuts (0 active)  in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 2 (Knapsack) - 15 row cuts average 5.9 elements, 0 column cuts (0 active)  in 0.004 seconds - new frequency is -100
Cbc0014I Cut generator 3 (Clique) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 4 (OddWheel) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 5 (MixedIntegerRounding2) - 45 row cuts average 12.4 elements, 0 column cuts (0 active)  in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 6 (FlowCover) - 5 row cuts average 3.8 elements, 0 column cuts (0 active)  in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 7 (TwoMirCuts) - 61 row cuts average 21.5 elements, 0 column cuts (0 active)  in 0.003 seconds - new frequency is -100
Cbc0004I Integer solution of 0 found after 304 iterations and 10 nodes (0.07 seconds)
Cbc0001I Search completed - best objective 0, took 304 iterations and 10 nodes (0.07 seconds)
Cbc0032I Strong branching done 72 times (275 iterations), fathomed 0 nodes and fixed 0 variables
Cbc0035I Maximum depth 9, 0 variables fixed on reduced cost
31 bounds tightened after postprocessing

Total time (CPU seconds):       0.07   (Wallclock seconds):       0.08

2025-04-11 09:57:14 info: Eerste berekening
2025-04-11 09:57:14 info: Kosten (euro): 0.21  
2025-04-11 09:57:14 info: Levering (kWh): 0.00  
Starting solution of the Linear programming relaxation problem using Dual Simplex

Clp0014I Perturbing problem by 0.001% of 0.68824731 - largest nonzero change 2.8782949e-05 ( 0.0026274117%) - largest zero change 2.9824787e-05
Clp0000I Optimal - objective value -0.62707827

Starting MIP optimization
Cgl0002I 21 variables fixed
Cgl0003I 7 fixed, 0 tightened bounds, 3 strengthened rows, 0 substitutions
Cgl0004I processed model has 336 rows, 440 columns (149 integer (149 of which binary)) and 1265 elements
Coin3009W Conflict graph built in 0.000 seconds, density: 0.141%
Cgl0015I Clique Strengthening extended 0 cliques, 0 were dominated
Cbc0045I MIPStart provided solution with cost 0.213886
Cbc0012I Integer solution of 0.15956498 found by Reduced search after 0 iterations and 0 nodes (0.02 seconds)
Cbc0036I Heuristics switched off as 15 branching objects are of wrong type
Cbc0045I Nauty: 1582 orbits (2 useful covering 24 variables), 22 generators, group size: 5.83896e+19 - sparse size 7712 - took 0.004097 seconds
Cbc0031I 40 added rows had average density of 10.85
Cbc0013I At root node, 40 cuts changed objective from -0.62707827 to -0.62644563 in 21 passes
Cbc0014I Cut generator 0 (Probing) - 263 row cuts average 2.5 elements, 0 column cuts (0 active)  in 0.015 seconds - new frequency is 1
Cbc0014I Cut generator 1 (Gomory) - 98 row cuts average 67.1 elements, 0 column cuts (0 active)  in 0.005 seconds - new frequency is 1
Cbc0014I Cut generator 2 (Knapsack) - 6 row cuts average 6.5 elements, 0 column cuts (0 active)  in 0.007 seconds - new frequency is 1
Cbc0014I Cut generator 3 (Clique) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 4 (OddWheel) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.000 seconds - new frequency is -100
Cbc0014I Cut generator 5 (MixedIntegerRounding2) - 32 row cuts average 24.3 elements, 0 column cuts (0 active)  in 0.004 seconds - new frequency is 1
Cbc0014I Cut generator 6 (FlowCover) - 0 row cuts average 0.0 elements, 0 column cuts (0 active)  in 0.004 seconds - new frequency is -100
Cbc0014I Cut generator 7 (TwoMirCuts) - 78 row cuts average 37.7 elements, 0 column cuts (0 active)  in 0.003 seconds - new frequency is -100
Cbc0016I Integer solution of -0.41334741 found by strong branching after 604 iterations and 14 nodes (0.15 seconds)
Cbc0016I Integer solution of -0.62616689 found by strong branching after 607 iterations and 17 nodes (0.16 seconds)
Cbc3008W Strong branching is fixing too many variables, too expensively!
Cbc0016I Integer solution of -0.62635089 found by strong branching after 632 iterations and 24 nodes (0.18 seconds)
Cbc0001I Search completed - best objective -0.6263508891545493, took 665 iterations and 28 nodes (0.19 seconds)
Cbc0032I Strong branching done 234 times (981 iterations), fathomed 3 nodes and fixed 14 variables
Cbc0035I Maximum depth 12, 15 variables fixed on reduced cost
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Coin0505I Presolved problem not optimal, resolve after postsolve
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
24 bounds tightened after postprocessing

Total time (CPU seconds):       0.21   (Wallclock seconds):       0.23

Dit zou eigenlijk niet mogen en dat wil ik graag oplossen.

Ik heb jouw instellingen gekopieerd en als ik hem nu (23:00 uur) draai dan plant DAO de wasmachine wel in de window.

Nu zie ik dat je de berekening uitvoert op een tijdstip binnen het window en ik kan natuurlijk niet meer zien of en welke berekende datum/tijd er stonden in de "calculated" datum/tijden.

Mijn vraag aan jou is: wil je de berekening nog een keer doen, maar voordat je hem doet wil je dan de datum/tijden opschrijven (of screenshot) van de calculated tijdstippen.
Misschien is ook jouw gekozen strategie (minimize consumption ofminimize cost) nog van invloed.
Ik hoor het allemaal graag.

[KC27]

stoner1978 schreef op vrijdag 11 april 2025 @ 21:24:
Hallo,

Kan iemand mij in de juiste richting wijzen, ik krijg de volgende foutmelding maar heb geen idee welke entiteit het om gaat.
Alvast bedankt!

code:

2025-04-11 21:11:11 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3448, in <module>
2025-04-11 21:11:11 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3424, in main
2025-04-11 21:11:11 fout: File: /root/dao/prog/da_base.py, line 478, in run_task_function
2025-04-11 21:11:11 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2862, in calc_optimum
2025-04-11 21:11:11 fout: File: /root/dao/prog/da_base.py, line 370, in set_entity_option
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 49, in select_option
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 28, in call_service
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 68, in _post
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 90, in _process_response
2025-04-11 21:11:11 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 95, in _raise_error
2025-04-11 21:11:11 fout: Onverwachte fout: 500 status code returned from http://192.168.1.207:8123...nput_select/select_option
Traceback (most recent call last):
File "/root/dao/webserver/../prog/day_ahead.py", line 2656, in calc_optimum
self.set_entity_option(
File "/root/dao/prog/da_base.py", line 370, in set_entity_option
self.select_option(entity_id, value)
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 49, in select_option
return self.call_service("select_option", entity_id=entity_id, option=option)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 28, in call_service
self._post(
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 68, in _post
return self._process_response(
^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
self._raise_error(response.status_code, response.url)
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
raise error(f"{status_code} status code returned from {url}",) # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.InternalServerError: 500 status code returned from http://192.168.1.207:8123...nput_select/select_option

Ergens in je instellingen heb je een input_select staan als entity waar DAO een berekende instelling naar wil wegschrijven (waarschijnlijk een Aan/Uit input_select voor je batterij).
Check in Home Assistant of de naam van de input_select exact overeenkomt en of je de opties bij deze input_select ook Aan en Uit hebt genoemd (let op de hoofdletters).

[bvw]

KC27 schreef op zaterdag 12 april 2025 @ 00:00:
[...]


Dit zou eigenlijk niet mogen en dat wil ik graag oplossen.

Ik heb jouw instellingen gekopieerd en als ik hem nu (23:00 uur) draai dan plant DAO de wasmachine wel in de window.

Nu zie ik dat je de berekening uitvoert op een tijdstip binnen het window en ik kan natuurlijk niet meer zien of en welke berekende datum/tijd er stonden in de "calculated" datum/tijden.

Mijn vraag aan jou is: wil je de berekening nog een keer doen, maar voordat je hem doet wil je dan de datum/tijden opschrijven (of screenshot) van de calculated tijdstippen.
Misschien is ook jouw gekozen strategie (minimize consumption ofminimize cost) nog van invloed.
Ik hoor het allemaal graag.

Heb de instelling op minimize consumption staan.

Verder heb ik niets aan de instellingen veranderd, en inderdaad als ie binnen het window komt, herberekend ie telkens de tijd, ook buiten het window:

[RudolfR]

Is er ook een manier om DAO te gebruiken zonder dynamische tarieven?
Zou graag het op/ontladen van de batterij sturen voor zelfconsumptie en voorkomen van teruglevering.

[mgroen81]

KC27 schreef op vrijdag 11 april 2025 @ 23:24:
[...]


Er is in principe niks fout aan je settings.
Maar met drie batterijen maak je het DAO niet makkelijk.
In jouw situatie met drie batterijen en een ev zijn er heel veel variabelen.
De rekentijd neemt toe met het ongeveer het kwadraat van de variabelen.
In jouw situatie heb je drie identieke batterijen die je - als ik het goed zie - ook identiek inzet.
Je zou het DAO waarschijnlijk veel makkelijker kunnen maken door van die drie één virtuele batterij te maken.

Dat zou je eerst even kunnen testen door tijdelijk twee batterijen weg te halen en dan een "run met debug" doen.
Als dat veel scheelt kun je alsnog (als je dat wilt) een virtuele batterij maken:

• je definieert één batterij
• de capaciteit vermenigvuldig je met drie, evenals het vermogen in alle "stages" en de andere vermogens
• voor de start soc neem je een template sensor die het gemiddelde van de drie echte soc's berekend
• voor de door DAO berekende inzet/het vermogen maak je een input_number aan en daar hang je een automation aan die een derde doorzet naar de drie afzonderlijke sessy's.

Ik ben benieuwd naar je bevindingen.

Bedankt, Ik ga het als 1 accu configureren. Het was ook al iets wat ik overwogen had.

[ Voor 13% gewijzigd door mgroen81 op 12-04-2025 16:58 ]

[hemertje]

ErnstH schreef op vrijdag 11 april 2025 @ 21:04:
[Afbeelding]
Goed idee om de verwachte SoC erin op te nemen. Dat ga ik in de day ahead grafieken toevoegen!

Mooie kleurtjes in de dynamische tarieven grafieken

Hoe krijg je dat voor elkaar?

[stoner1978]

@RudolfR ja heb ik, dat werkt ook. probleem was wat @KC27 aangaf. Ik heb de input.select entities opnieuw ingevuld en HA een herstart gegeven. nu werkt het weer. Bedankt!

[stoner1978]

Heb ik eigenlijk nog een vraag over de boiler.

ik heb een warmtepomp boiler en die heb ik in de config gezet maar hij wordt eigenlijk maar 1x per dag een kort moment aangestuurd. Lijkt erg op een elektrische boiler met cop1.
als ik de normale grafieken van het vermogen van de boiler bekijk dan zie je een langzaam oplopende grafiek, begint met 200W en loopt zo op tot 500-600W verdeeld over een uurtje of 4. Ik heb al even gespeeld met het vermogen maar dat veranderd niets.
Is dit zoals bedoeld of moet ik de boiler onder het warmtepomp gedeelte plaatsen en vul ik hier het elektrische element in?

code:

  "boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.valliant_switch_temp_water",
    "entity setpoint": "input_number.dao_boiler_setpoint",
    "entity hysterese": "input_number.dao_boiler_hysterese",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 200,
    "heating allowed below": 43,
    "elec. power": 300,
    "activate service": "turn_on",
    "activate entity": "input_boolean.dao_boiler_aan_uit

[KC27]

bvw schreef op zaterdag 12 april 2025 @ 11:24:
[...]


Heb de instelling op minimize consumption staan.

Verder heb ik niets aan de instellingen veranderd, en inderdaad als ie binnen het window komt, herberekend ie telkens de tijd, ook buiten het window:

[Afbeelding]

Ik ben er nog eens goed ingedoken en heb jouw situatie nagebouwd.
Gelukkig kon ik de fout reproduceren én oplossen!
Binnenkort komt er een update met de fix!
Dank voor het melden en meedenken!

[KC27]

stoner1978 schreef op zaterdag 12 april 2025 @ 19:20:
Heb ik eigenlijk nog een vraag over de boiler.

ik heb een warmtepomp boiler en die heb ik in de config gezet maar hij wordt eigenlijk maar 1x per dag een kort moment aangestuurd. Lijkt erg op een elektrische boiler met cop1.
als ik de normale grafieken van het vermogen van de boiler bekijk dan zie je een langzaam oplopende grafiek, begint met 200W en loopt zo op tot 500-600W verdeeld over een uurtje of 4. Ik heb al even gespeeld met het vermogen maar dat veranderd niets.
Is dit zoals bedoeld of moet ik de boiler onder het warmtepomp gedeelte plaatsen en vul ik hier het elektrische element in?

[Afbeelding]

code:

  "boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.valliant_switch_temp_water",
    "entity setpoint": "input_number.dao_boiler_setpoint",
    "entity hysterese": "input_number.dao_boiler_hysterese",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 200,
    "heating allowed below": 43,
    "elec. power": 300,
    "activate service": "turn_on",
    "activate entity": "input_boolean.dao_boiler_aan_uit

Ik wil graag meedenken en zorgen dat het goed werkt.
Maar om dat goed te kunnen doen heb ik graag wat meer details van je boiler.
Heb je voor mij merk en type of een link naar een site waar de technische details van dat ding staan?
Heb je uit HA toevallig een grafiek die het verloop van het verbruik/vermogen weergeeft?

[KC27]

RudolfR schreef op zaterdag 12 april 2025 @ 12:32:
Is er ook een manier om DAO te gebruiken zonder dynamische tarieven?
Zou graag het op/ontladen van de batterij sturen voor zelfconsumptie en voorkomen van teruglevering.

Die is er momenteel niet, maar zou wel een mooie toevoeging zijn.
Wat voor contract heb je nu:
- opslag leverancier op kWh of zitten die in het leveringstarief?
- hoogtarief 7 - 23 (of 21?) uur?
- laagtarief 23 - 7 uur en in het weekend?
- of een vast tarief 0 - 24 uur?
- terugleverkosten?

Ik hoor het graag.

[Sebazzz]

Hoe verhoudt DAO zich tot EMHASS?

[stoner1978]

@KC27 bedankt voor je hulp!

De warmtepomp boiler is een Vaillant AroSTOR vwl bm 200/5 en hier staat de handleiding https://www.vaillant.nl/c...2FproductsLabel&q=Arostor
Vanaf pagina 188 staan de technische specificaties.

Onderstaan 2 grafieken van het vermogen tijdens het normale verwarmen en de tweede is inc legionella run (hier komt het element erbij)

KC27 schreef op zaterdag 12 april 2025 @ 22:26:
[...]


Ik wil graag meedenken en zorgen dat het goed werkt.
Maar om dat goed te kunnen doen heb ik graag wat meer details van je boiler.
Heb je voor mij merk en type of een link naar een site waar de technische details van dat ding staan?
Heb je uit HA toevallig een grafiek die het verloop van het verbruik/vermogen weergeeft?

[KC27]

stoner1978 schreef op zondag 13 april 2025 @ 07:46:
@KC27 bedankt voor je hulp!

De warmtepomp boiler is een Vaillant AroSTOR vwl bm 200/5 en hier staat de handleiding https://www.vaillant.nl/c...2FproductsLabel&q=Arostor
Vanaf pagina 188 staan de technische specificaties.

Onderstaan 2 grafieken van het vermogen tijdens het normale verwarmen en de tweede is inc legionella run (hier komt het element erbij)
[Afbeelding]
[Afbeelding]


[...]

Dank je wel, heel bruikbare info!
Heb je ove dezelfde opwarm periodes ook het verloop van de watertemperatuur?
Hoe vaak die je de legionella run?
O ja: hoe vaak per dag of per week is er een normale opwarm run?

[Impossibl3]

@KC27 een normale run doe je vaak 1x per dag. Dan stook je het vat op tot 50-55 graden afhankelijk van je gewenste temperatuur. Eens per week moet je een legionellarun doen als je kleine kinderen hebt, zieke etc (eigenlijk de "kwetsbare" mensen). Dan stook je het vat op naar 60+ graden. Zeker bij een legionellarun zonder kwetsbare mensen in je huis kan je nog veel mee spelen maar dat is voor een ander topic.

Edit: Vaak plan je een legionellarun in als je daarna veel warmwater nodig hebt. Bijvoorbeeld als iedereen van de sport af komt. Dan doe je die run in de ochtend en kan iedereen in de middag als ze terug zijn van sporten douchen.

[ Voor 22% gewijzigd door Impossibl3 op 13-04-2025 09:20 ]

[KC27]

stoner1978 schreef op zondag 13 april 2025 @ 07:46:
@KC27 bedankt voor je hulp!

De warmtepomp boiler is een Vaillant AroSTOR vwl bm 200/5 en hier staat de handleiding https://www.vaillant.nl/c...2FproductsLabel&q=Arostor
Vanaf pagina 188 staan de technische specificaties.

Onderstaan 2 grafieken van het vermogen tijdens het normale verwarmen en de tweede is inc legionella run (hier komt het element erbij)
[Afbeelding]
[Afbeelding]


[...]

Dank je wel, heel bruikbare info!
Heb je over dezelfde opwarm periodes ook het verloop van de watertemperatuur?
Hoe vaak doe je de legionella run?

[stoner1978]

Zie onderstaande grafieken voor het temperatuurverloop tijdens verwarmen.
Voor de rest komt het aardig overeen met wat @Impossibl3 geschreven heeft. Dus dagelijks 1x verwarmen. Liefst overdag als iedereen weg is, geen lawaai in de nacht en warm water in de avond met een beetje voor de ochtend.
De warmtepomp is goed te sturen via een extern contact, dit ben ik van plan te doen middels een esp bordje en een automatisering die naar de stroomprijs kijkt, goedkoop dan gewoon verwarmen en negatief dan de panelen uit en legionella run.
Als dit dus via DAO zou kunnen dan krijg je dus mooi alles in één!
Esp bordje ligt er al, draden liggen klaar maar voor nu meet ik alleen de temperatuur en houdt de rest bij om te kijken hoe het schakelt. De WAF neemt hard af als er koud gedoucht moet worden 😏

KC27 schreef op zondag 13 april 2025 @ 08:55:
[...]

Dank je wel, heel bruikbare info!
Heb je ove dezelfde opwarm periodes ook het verloop van de watertemperatuur?
Hoe vaak die je de legionella run?
O ja: hoe vaak per dag of per week is er een normale opwarm run?

[ Voor 4% gewijzigd door stoner1978 op 13-04-2025 11:04 ]

[Marcjeno1]

@KC27 Hoe kan ik nu testen of mijn docker dao omgeving gekoppeld zit aan mijn home assistant? Er zijn geen helpers aangemaakt door dao in mijn home assistant. Ik kan grafieken maken met prijzen uit meteo en nordpool. Maar ik weet niet of de koppeling er nu is tussen mijn home assistant.

[KC27]

In de addon-branche op github staat een testversie klaar met versienummer 2025.4.1.rc1.
Met de volgende fixes in de changelog:

• Fixed error with postgresql during reporting of savings (reported by @balk77)
• Fixed planning error when calculating the planning of a machine during the planning window (reported by @bvw)

Graag testen (met name voor @bvw).
In de TS staat een paragraaf hoe je kunt testen.

[ Voor 5% gewijzigd door KC27 op 13-04-2025 11:16 ]

[KC27]

Marcjeno1 schreef op zondag 13 april 2025 @ 11:06:
@KC27 Hoe kan ik nu testen of mijn docker dao omgeving gekoppeld zit aan mijn home assistant? Er zijn geen helpers aangemaakt door dao in mijn home assistant. Ik kan grafieken maken met prijzen uit meteo en nordpool. Maar ik weet niet of de koppeling er nu is tussen mijn home assistant.

DAO maakt zelf geen helpers aan.
In je settings geef je de namen van entities op. vaak helpers die je zelf met de hand hebt aangemaakt, maar het kunnen ook sensoren zijn met belangrijke informatie die DAO nodig heeft voor berekeningen en rapportages.
Ook de berekeningsresulaten worden weggeschreven naar de betreffende opgegeven entities.

Voorbeeld:

In de settings staat:

code:

      { "name": "vaatwasser",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "eco",
           "power": [2000, 2000, 1500, 1000, 500, 500, 1000, 1000]
           }
        ],
        "entity start window": "input_datetime.start_window_vaatwasser",
        "entity end window": "input_datetime.end_window_vaatwasser",
        "entity selected program": "input_select.program_vaatwasser",
        "entity calculated start": "input_datetime.calculated_start_vaatwasser",
        "entity calculated end": "input_datetime.calculated_stop_vaatwasser"
        }

De entities start window en end window staan op 2 en 7 uur
Mijn vaatwasser moet dus gaan draaien tussen 2 en 7 uur met het programma eco, dat 8 kwartieren loopt.
DAO heeft berekend dat ie vannacht om 3 uur moest beginnen en om 5 uur klaar is en zet dat in de calculated entities. Het is aan jou en jouw HA om dat op te pikken en die vaatwasser om drie uur aan te zetten.

Zo werkt het met alles.

[tonvanboven]

Sebazzz schreef op zaterdag 12 april 2025 @ 22:33:
Hoe verhoudt DAO zich tot EMHASS?

Heb je de twee oplossingen met elkaar vergeleken en heb je daar een specifieke vraag over? Zelf ben ik met DAO begonnen toen @KC27 lang geleden zijn plaatje van DOA op Tweakers poste en ben altijd bij deze mooie oplossing gebleven en heb daardoor geen ervaring met EMHASS. Ik kan het mis hebben, maar doet EMHASS iets met dynamische prijzen?

[KC27]

stoner1978 schreef op zondag 13 april 2025 @ 11:02:
Zie onderstaande grafieken voor het temperatuurverloop tijdens verwarmen.
Voor de rest komt het aardig overeen met wat @Impossibl3 geschreven heeft. Dus dagelijks 1x verwarmen. Liefst overdag als iedereen weg is, geen lawaai in de nacht en warm water in de avond met een beetje voor de ochtend.
De warmtepomp is goed te sturen via een extern contact, dit ben ik van plan te doen middels een esp bordje en een automatisering die naar de stroomprijs kijkt, goedkoop dan gewoon verwarmen en negatief dan de panelen uit en legionella run.
Als dit dus via DAO zou kunnen dan krijg je dus mooi alles in één!
Esp bordje ligt er al, draden liggen klaar maar voor nu meet ik alleen de temperatuur en houdt de rest bij om te kijken hoe het schakelt. De WAF neemt hard af als er koud gedoucht moet worden 😏
[Afbeelding]

[Afbeelding]

[...]

Wederom dank voor de info.
Ik denk dat ik een oplossing heb bedacht, maar ik heb geen tijd om het te testen, maar wellicht kun je dat zelf wel.
Je zou je boiler kunnen definiëren als een "machine" met drie programma's:

1. uit: hij doet niks
2. normaal: 16 kwartieren met een oplopend vermogen (dat haal je uit je vermogensgrafiek)
3. legionella: 20 kwartieren met extra vermogensstappen aan het eind.

Je maakt drie helpers aan voor de planning: programma, window start, window end en twee helpers voor het resultaat.
Je maakt in HA een automation aan die een minuut voor ieder uur runt met de volgende logica (of bij wijzging van de actuele temperatuur):

• als ie aan het opwarmen is niks doen
• je berekent de gemiddelde afkoeling van je boiler per uur in K/uur: afkoeling
• je meet de actule boilertemperatuur: act_temp
• je weet vanaf welke temperatuur het zinvol is te gaan opwarmen: opwarmen_vanat
• je stelt de minimale temperatuur van je boiler vast (hou rekening met de waf )
• je berekent wanneer opwarmen_vanaf wordt bereikt: start_window
• je berekent wanneer opwarmen uiterlijk moet beginnen, tel daar de duur van het programma bij op: end_window

Je houdt zelf in de gaten of je een normale of een legionalla run wil draaien.
Tijdens vakantie zet je het ding "uit".
Je maakt een tweede auomation die wordt getriggerd door de calculated start en die start de boiler.

Denk je dat dat gaat werken?

[Sebazzz]

tonvanboven schreef op zondag 13 april 2025 @ 11:47:
[...]

Heb je de twee oplossingen met elkaar vergeleken en heb je daar een specifieke vraag over? Ik kan het mis hebben, maar doet EMHASS iets met dynamische prijzen?

Nee, ik vraag of iemand anders dat heeft gedaan.

quote: https://github.com/davidusb-geek/emhass

EMHASS is a powerful energy management tool that generates an optimization plan based on variables such as solar power production, energy usage, and energy costs. The plan provides valuable insights into how energy can be better managed and utilized in the household. Even if households do not have all the necessary equipment, such as solar panels or batteries, EMHASS can still provide a minimal use case solution to optimize energy usage for controllable/deferrable loads.

De reden dat ik het vraag, is omdat EMHASS conceptueel vrij lastig te begrijpen is maar ook lastig te configureren is.

[Knielen]

Marcjeno1 schreef op zondag 13 april 2025 @ 11:06:
@KC27 Hoe kan ik nu testen of mijn docker dao omgeving gekoppeld zit aan mijn home assistant? Er zijn geen helpers aangemaakt door dao in mijn home assistant. Ik kan grafieken maken met prijzen uit meteo en nordpool. Maar ik weet niet of de koppeling er nu is tussen mijn home assistant.

Je moet die helpers zelf aanmaken en dan in de config van DAO koppelen.

[KC27]

Sebazzz schreef op zondag 13 april 2025 @ 12:00:
[...]

Nee, ik vraag of iemand anders dat heeft gedaan.


[...]

De reden dat ik het vraag, is omdat EMHASS conceptueel vrij lastig te begrijpen is maar ook lastig te configureren is.

Ik ben drie jaar geleden met DAO begonnen omdat ik toen niks anders kon vinden en overtuigd was dat mip (multiple integer programming) de basis moest zijn van een oplossing met dynamische prijzen.
Wiskunde in combinatie met software heeft altijd mijn bovengemiddelde interesse gehad.
Emhass gebruikt ook de python mip-bibliotheek, maar verder is het heel anders uitgewerkt.
Het is generieker van opzet en wordt ook in andere landen veel gebruikt.

Er zijn nog meer conculega's: GBBoptimizer bijvoorbeeld.

[ Voor 4% gewijzigd door KC27 op 13-04-2025 13:03 ]

[stoner1978]

Bedankt voor de richting!
Ik ga er mee aan de slag en zal mij hier weer melden met resultaten of vragen

KC27 schreef op zondag 13 april 2025 @ 11:52:
[...]


Wederom dank voor de info.
Ik denk dat ik een oplossing heb bedacht, maar ik heb geen tijd om het te testen, maar wellicht kun je dat zelf wel.
Je zou je boiler kunnen definiëren als een "machine" met drie programma's:

1. uit: hij doet niks
2. normaal: 16 kwartieren met een oplopend vermogen (dat haal je uit je vermogensgrafiek)
3. legionella: 20 kwartieren met extra vermogensstappen aan het eind.

Je maakt drie helpers aan voor de planning: programma, window start, window end en twee helpers voor het resultaat.
Je maakt in HA een automation aan die een minuut voor ieder uur runt met de volgende logica (of bij wijzging van de actuele temperatuur):

• als ie aan het opwarmen is niks doen
• je berekent de gemiddelde afkoeling van je boiler per uur in K/uur: afkoeling
• je meet de actule boilertemperatuur: act_temp
• je weet vanaf welke temperatuur het zinvol is te gaan opwarmen: opwarmen_vanat
• je stelt de minimale temperatuur van je boiler vast (hou rekening met de waf )
• je berekent wanneer opwarmen_vanaf wordt bereikt: start_window
• je berekent wanneer opwarmen uiterlijk moet beginnen, tel daar de duur van het programma bij op: end_window

Je houdt zelf in de gaten of je een normale of een legionalla run wil draaien.
Tijdens vakantie zet je het ding "uit".
Je maakt een tweede auomation die wordt getriggerd door de calculated start en die start de boiler.

Denk je dat dat gaat werken?

[bvw]

Ik probeer te simuleren wat het doet met een dynamisch tarief zonder salderen (vanaf 2027), dus (inkooptarief + opslag + belasting) * btw voor afname, en -inkooptarief voor teruggave.

Ik heb "tax refund: False". Is dat voldoende? of rekent DAO dan wel met salderen tot verbruik gelijk is aan opwek?

[hemertje]

KC27 schreef op zondag 13 april 2025 @ 12:21:
[...]


Ik ben drie jaar geleden met DAO begonnen omdat ik toen niks anders kon vinden en overtuigd was dat mip (multiple integer programming) de basis moest zijn van een oplossing met dynamische prijzen.
Wiskunde in combinatie met software heeft altijd mijn bovengemiddelde interesse gehad.
Emhass gebruikt ook de python mip-bibliotheek, maar verder is het heel anders uitgewerkt.
Het is generieker van opzet en wordt ook in andere landen veel gebruikt.

Er zijn nog meer conculega's: GBBoptimizer bijvoorbeeld.

Nog een groot voordeel


De Nederlandstalige ondersteuning hiero door de ontwikkelaar/ programmamaker

[RudolfR]

Ik draai zelf EMHASS, die werkt zeker met dynamische tarieven, maar die moet je zelf meegeven voor de berekening.

Helaas zit er ook geen eigen database in, dus je bent afhankelijk van de recorder in HA.

EMHASS is nog wat meer bare-bones, kan vziw bijv. niet overweg met complexe verbruikspatronen van apparatuur.

Ook het thermisch model is geen first-class-citizen.

[KC27]

bvw schreef op zondag 13 april 2025 @ 14:26:
Ik probeer te simuleren wat het doet met een dynamisch tarief zonder salderen (vanaf 2027), dus (inkooptarief + opslag + belasting) * btw voor afname, en -inkooptarief voor teruggave.

Ik heb "tax refund: False". Is dat voldoende? of rekent DAO dan wel met salderen tot verbruik gelijk is aan opwek?

In de DAO werkt het nu zo dat tax refund : False hetzelfde wordt behandeld als geen energiebelasting bij terugleveren.
Je kunt in de logging (logging level: info)van de berekening zien hoe dit uitpakt.
Daar staat vrij bovenaan een tabel met start waarden:

• de kolom met p_l zijn de levering tarieven
• de kolom met p_t zijn de teruglever tarieven

[RudolfR]

KC27 schreef op zaterdag 12 april 2025 @ 22:31:
[...]


Die is er momenteel niet, maar zou wel een mooie toevoeging zijn.
Wat voor contract heb je nu:
- opslag leverancier op kWh of zitten die in het leveringstarief?
- hoogtarief 7 - 23 (of 21?) uur?
- laagtarief 23 - 7 uur en in het weekend?
- of een vast tarief 0 - 24 uur?
- terugleverkosten?

Ik hoor het graag.

Dank voor je reactie.
- Vaste leveringskosten; 120,- per jaar
- Hoogtarief inderdaad van 7-23
- Laag van 23-7 en in het weekend/feestdagen, maar dat heb ik in EMHASS ook nog niet correct ingeregeld. Verschil is ook klein.
- Nu nog een modelcontract en dus geen terugleverkosten, maar daar komt een eind aan.

Details:

[Undertilted]

wat is het verschil tussen "energy taxes delivery" en "cost supplier delivery"? hoe worden beide bij de spotprijzen geteld? En BTW is toch enkel bij het aankopen?

[KC27]

Undertilted schreef op zondag 13 april 2025 @ 22:10:
wat is het verschil tussen "energy taxes delivery" en "cost supplier delivery"? hoe worden beide bij de spotprijzen geteld? En BTW is toch enkel bij het aankopen?

Onderstaand mijn antwoorden:

• energy taxes delivery: de energiebelasting op levering (=verbruik) die je betaalt over iedere kWh die je afneemt, ex btw. Momenteel 0.10154 eur/kWh
• cost supplier delivery: de toeslag op levering die je betaalt aan je leverancier over iedere kWh die je afneemt, ex BTW. Is per leverancier anders. Bij Tibber is nu 0.020496 eur/kWh
• Je betaalt BTW (21%) over levering, maar je krijgt ook 21% BTW terug bij teruglevering.

Als je alles kunt salderen (dus in een contractjaar is teruglevering kleiner of gelijk aan levering) is bij Tibber en Zonneplan het uiteindelijke tarief voor levering (kaal dynamisch uurtarief + energiebelasting +opslag leverancier) x 1,21 gelijk aan het tarief voor teruglevering.
Er zijn leveranciers (zoals Frank Energie), die voor teruglevering de leverancierstoeslag aftrekken van de vergoeding.
Is je teruglevering in een contractjaar hoger dan de levering dan krijg je over het meedere niet de energiebelasting en de btw daarover terug.

[ Voor 8% gewijzigd door KC27 op 14-04-2025 11:26 ]

[Undertilted]

BTW op teruglevering is niet logisch

Ik probeer dit in te voeren maar dat gaat dus niet...
Ik bespaar je de achterliggende berekening. Als je wilt kan je narekenen met https://files.boltenergie...r/online_res_el_nl_11.pdf

afname: TOTAAL exl btw	Belpex * 0,0011192 + 10,013714 + 0,2042 c€/kWh
afname TOTAAL incl 6% BTW	Belpex * 0,001186352 + 0,108187368€/kWh
teruglevering TOTAAL exl of incl BTW (er is geen BTW)	Belpex * 0,00094 - 0,01133 €/kWh

Maar zo te zien zal dit niet lukken.

[ Voor 31% gewijzigd door Undertilted op 14-04-2025 10:12 ]

[Torch1969]

Dankzij het voorwerk in dit topic van @KC27 en @bvw (filter dit topic op de zoekterm “docker” en het stappenplan ontvouwt zich als een spannend jongensboek, alle credits voor hen ) en een avondje uitproberen en debuggen, heb ik dao nu ook draaien in een docker container mbv docker compose. . Hieronder mijn HowTo voor wat ik tot nu toe heb gedaan (garantie tot de deur )

HowTo dao met docker compose

Voeg in je docker compose file het volgende toe (en pas dit aan naar je eigen situatie, zie toelichting):

code:

  dao:
    #bron: https://gathering.tweakers.net/forum/list_messages/2293338?data%5Bfilter_keywords%5D=docker
    container_name: dao
    build: 
      context: https://github.com/corneel27/day-ahead.git#main:dao
      dockerfile: Dockerfile
      args:
        - BUILD_ARCH=amd64
        - BUILD_FROM=ghcr.io/hassio-addons/debian-base/amd64:stable
        - BUILD_VERSION=2025.4.0
      tags:
        - "dao:latest"
    volumes:
      - /volume1/docker/homeassistant/config:/homeassistant
      - /volume1/docker/dao/data:/config
    ports:
      - 5009:5000
    restart: unless-stopped
    environment:
      - TZ=Europe/Amsterdam

Toelichting: het build deel bouwt een image op, op basis van de GitHub repository (je hoeft zelf dus niets te downloaden). Hiervoor moet je 3 argumenten instellen die de Dockerfile gebruikt:

• voor BUILD_ARCH moet je de processor invullen van je machine, momenteel worden alleen amd64 (=intel 64 bit), aarch64 (o.a. raspberry pi 4 en 5) en i386 (intel 32 bit)
• voor BUILD_FROM heb je ook weer de keuze uit:
  * ghcr.io/hassio-addons/debian-base/aarch64:stable
  * ghcr.io/hassio-addons/debian-base/amd64:stable
  * ghcr.io/hassio-addons/debian-base/i386:stable
• Voor BUILD_VERSION vul je de huidige versie van de GitHub repository van dao in.

Het resterende deel is nodig voor het opstarten van een container. Belangrijk daarin zijn de instellingen bij volumes en eventueel het poortnummer.

• Volumes: Maak de eerste keer een directory voor dao aan waar dao zijn data kan opslaan buiten de container (ik heb de subdirectory dao/data aangemaakt binnen mijn docker directory).
  Verwijs in het deel volumes naar het pad waar je home assistant database staat, en het pad waar je dao data directory staat. Doe dit in het deel voor de ":", het deel erna is de interne verwijzing binnen de container zelf
• Ports: ik draai docker op een synology Nas, dus poort 5000 (de standaardpoort van dao) is al bezet voor DSM. Daarom verander ik de poort waar ik dao op kan benaderen naar 5009.

Voor bouwen image doe je (dit duurt even):

code:

docker-compose build dao

Voor opstarten container:

code:

docker-compose up -d dao

of in één keer:

code:

docker-compose up -d --build --force-recreate dao

(Alles eventueel voorafgegaan door sudo afhankelijk van je rechten.)

Hierna kun je dao benaderen via <ip-adres docker>:<ingestelde poortnummer> (bijvoorbeeld 192.168.1.123:5009)
Volg verder de handleiding vanaf het kopje instellingen in DOCS.md op GitHub. Belangrijk hierbij is het instellen van de toegang tot homeassistant in de config:

code:

"homeassistant": {
    "ip adress": "<ip adres waar home assistant draait>",
    "ip port": <poort nummer van home asssitant, standaard 8123>,
    "token": "<je long lived access token>"
  },

Er wordt in de handleiding verder verwezen naar herstarten en logboek. Dat moet je uiteraard doen in je eigen docker omgeving (ik gebruik daarvoor nu portainer).

EDIT: environment TZ Amsterdam toegevoegd in docker compose
EDIT 2: privileged: true weggehaald in docker compose

[KC27]

Undertilted schreef op maandag 14 april 2025 @ 08:45:
BTW op teruglevering is niet logisch

Ik probeer dit in te voeren maar dat gaat dus niet...
Ik bespaar je de achterliggende berekening. Als je wilt kan je narekenen met https://files.boltenergie...r/online_res_el_nl_11.pdf

afname: TOTAAL exl btw	Belpex * 0,0011192 + 10,013714 + 0,2042 c€/kWh
afname TOTAAL incl 6% BTW	Belpex * 0,001186352 + 0,108187368€/kWh
teruglevering TOTAAL exl of incl BTW (er is geen BTW)	Belpex * 0,00094 - 0,01133 €/kWh

Maar zo te zien zal dit niet lukken.

Ah, nou begrijp ik je: je hebt het over een Belgische situatie en daar wordt - in tegenstelling tot Nederland - geen BTW teruggegeven bij teruglevering.
Op dit moment voorziet DAO daar nog niet in.
Ik zal in een volgende versie (helaas niet 2025.4.1, die is al te ver) hier een optie over opnemen en implementeren.

[KC27]

Torch1969 schreef op maandag 14 april 2025 @ 09:05:
Dankzij het voorwerk in dit topic van @KC27 en @bvw (filter dit topic op de zoekterm “docker” en het stappenplan ontvouwt zich als een spannend jongensboek, alle credits voor hen ) en een avondje uitproberen en debuggen, heb ik dao nu ook draaien in een docker container mbv docker compose. . Hieronder mijn HowTo voor wat ik tot nu toe heb gedaan (garantie tot de deur )

HowTo dao met docker compose

Voeg in je docker compose file het volgende toe (en pas dit aan naar je eigen situatie, zie toelichting):

code:

  dao:
    #bron: https://gathering.tweakers.net/forum/list_messages/2293338?data%5Bfilter_keywords%5D=docker
    container_name: dao
    build: 
      context: https://github.com/corneel27/day-ahead.git#main:dao
      dockerfile: Dockerfile
      args:
        - BUILD_ARCH=amd64
        - BUILD_FROM=ghcr.io/hassio-addons/debian-base/amd64:stable
        - BUILD_VERSION=2025.4.0
      tags:
        - "dao:latest"
    privileged: true
    volumes:
      - /volume1/docker/homeassistant/config:/homeassistant
      - /volume1/docker/dao/data:/config
    ports:
      - 5009:5000
    restart: unless-stopped

Toelichting: het build deel bouwt een image op, op basis van de GitHub repository (je hoeft zelf dus niets te downloaden). Hiervoor moet je 3 argumenten instellen die de Dockerfile gebruikt:

• voor BUILD_ARCH moet je de processor invullen van je machine, momenteel worden alleen amd64 (=intel 64 bit), aarch64 (o.a. raspberry pi 4 en 5) en i386 (intel 32 bit)
• voor BUILD_FROM heb je ook weer de keuze uit:
  * ghcr.io/hassio-addons/debian-base/aarch64:stable
  * ghcr.io/hassio-addons/debian-base/amd64:stable
  * ghcr.io/hassio-addons/debian-base/i386:stable
• Voor BUILD_VERSION vul je de huidige versie van de GitHub repository van dao in.

Het resterende deel is nodig voor het opstarten van een container. Belangrijk daarin zijn de instellingen bij volumes en eventueel het poortnummer.

• Volumes: Maak de eerste keer een directory voor dao aan waar dao zijn data kan opslaan buiten de container (ik heb de subdirectory dao/data aangemaakt binnen mijn docker directory).
  Verwijs in het deel volumes naar het pad waar je home assistant database staat, en het pad waar je dao data directory staat. Doe dit in het deel voor de ":", het deel erna is de interne verwijzing binnen de container zelf
• Ports: ik draai docker op een synology Nas, dus poort 5000 (de standaardpoort van dao) is al bezet voor DSM. Daarom verander ik de poort waar ik dao op kan benaderen naar 5009.

Voor bouwen image doe je (dit duurt even):

code:

docker-compose build dao

Voor opstarten container:

code:

docker-compose up -d dao

of in één keer:

code:

docker compose up -d --build --force-recreate dao

(Alles eventueel voorafgegaan door sudo afhankelijk van je rechten.)

Hierna kun je dao benaderen via <ip-adres docker>:<ingestelde poortnummer> (bijvoorbeeld 192.168.1.123:5009)
Volg verder de handleiding vanaf het kopje instellingen in DOCS.md op GitHub. Belangrijk hierbij is het instellen van de toegang tot homeassistant in de config:

code:

"homeassistant": {
    "ip adress": "<ip adres waar home assistant draait>",
    "ip port": <poort nummer van home asssitant, standaard 8123>,
    "token": "<je long lived access token>"
  },

Er wordt in de handleiding verder verwezen naar herstarten en logboek. Dat moet je uiteraard doen in je eigen docker omgeving (ik gebruik daarvoor nu portainer).

Perfect!
Ik zal dit - met jouw goedkeuring - samen met de docker-build oplossing opnemen in de TS.

[KC27]

KC27 schreef op zondag 13 april 2025 @ 11:11:
In de addon-branche op github staat een testversie klaar met versienummer 2025.4.1.rc1.
Met de volgende fixes in de changelog:

• Fixed error with postgresql during reporting of savings (reported by @balk77)
• Fixed planning error when calculating the planning of a machine during the planning window (reported by @bvw)

Graag testen (met name voor @bvw).
In de TS staat een paragraaf hoe je kunt testen.

Versie 2025.4.1 is nu gepubliceerd!

[bvw]

KC27 schreef op maandag 14 april 2025 @ 12:28:
[...]


Versie 2025.4.1 is nu gepubliceerd!

Afgelopen 24 uur heeft ie op de bèta release keurig gedraaid, dus das mooi! Dank!

[thys]

Faceless schreef op vrijdag 11 april 2025 @ 19:18:
Als iemand inspiratie zoekt voor een Home Assistant dashboard op basis van DAO, met 2 Sessy batterijen.

[Afbeelding]

Hoe haal je de verwachte SOC van DAO naar HA?

[Undertilted]

KC27 schreef op maandag 14 april 2025 @ 11:54:
[...]

Ah, nou begrijp ik je: je hebt het over een Belgische situatie en daar wordt - in tegenstelling tot Nederland - geen BTW teruggegeven bij teruglevering.
Op dit moment voorziet DAO daar nog niet in.
Ik zal in een volgende versie (helaas niet 2025.4.1, die is al te ver) hier een optie over opnemen en implementeren.

Super!

maar het gaat verder dan dat.

Het is [spotprijs * X + Y]
btw etc, maakt minder uit. Het is een kwestie van X en Y te berekenen.

in X en Y kan je al dan niet BTW steken, maar er moet een parameter zijn voor X en 1 voor Y.

[Torch1969]

KC27 schreef op maandag 14 april 2025 @ 11:55:
[...]


Perfect!
Ik zal dit - met jouw goedkeuring - samen met de docker-build oplossing opnemen in de TS.

Dat is uiteraard prima. 👍🏻
@KC27 heb net nog een edit gedaan, neem je die mee? (Tijd stond niet goed (2 uur te vroeg) in de container, daardoor klopte e.e.a. niet in reports, logging etc.)
@bvw heb jij dit probleem niet met jou docker run instructie?

[ Voor 31% gewijzigd door Torch1969 op 14-04-2025 15:14 ]

[stoner1978]

goedemiddag,

Kleine update van het "huiswerk" van @KC27
Dit werd voor mij als plantenkweker wel behoorlijk next level maar ben druk aan het stoeien geweest samen met chatGPT en we zijn tot de volgende automatisering gekomen:

code:

alias: dao vaillant starttijd berekenen met tijdvenster
triggers:
  - minutes: 59
    seconds: 0
    trigger: time_pattern
conditions:
  - condition: numeric_state
    entity_id: sensor.plug_warmtepomp_power
    below: 5
actions:
  - variables:
      huidige_temp: "{{ states('sensor.valliant_switch_temp_water') | float(0) }}"
      verschil: "{{ huidige_temp - 42 }}"
      uren_tot_ondergrens: "{{ verschil / 0.4 }}"
      gewenste_eindtijd: "{{ today_at('16:00:00') }}"
      berekende_starttijd_dt: "{{ (today_at('16:00:00') - timedelta(hours=4)) }}"
      starttijd_tijd: "{{ (today_at('16:00:00') - timedelta(hours=4)).strftime('%H:%M:%S') }}"
      eindtijd_tijd: "{{ today_at('16:00:00').strftime('%H:%M:%S') }}"
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {% set start = (today_at('06:00:00')) %} {% set eind =
              (today_at('12:00:00')) %} {% set berekend = (today_at('16:00:00')
              - timedelta(hours=4)) %} {{ start <= berekend <= eind }}
        sequence:
          - target:
              entity_id: input_datetime.dao_vaillant_begin_tijd
            data:
              time: "{{ starttijd_tijd }}"
            action: input_datetime.set_datetime
          - target:
              entity_id: input_datetime.dao_vaillant_eind_tijd
            data:
              time: "{{ eindtijd_tijd }}"
            action: input_datetime.set_datetime
    default:
      - target:
          entity_id: input_datetime.dao_vaillant_begin_tijd
        data:
          time: "00:00:00"
        action: input_datetime.set_datetime
      - target:
          entity_id: input_datetime.dao_vaillant_eind_tijd
        data:
          time: "00:00:00"
        action: input_datetime.set_datetime

Er komt een tijd naar de helpers voor DAO, ga dit eens volgen om te zien of het zo werkt. Ik ben bang dat het nog niet helemaal klopt. zit nog met de verschillen in "normaal" of "Legionella" die worden nu niet meegenomen / er wordt niet naar het programma gekeken. Ook zit er een afwijking in, oftewel DAO wil eerder starten dan het opgegeven start window. is geen probleem, hij zit nog in de tijd dat hij mag draaien.
als iemand nog tips of vragen heeft hoor ik het graag!
Misschien ook eerst een paar dagen volgen, heb nu zo vaak op berekenen gedrukt dat ik niet weet of hij het nog goed doet....

KC27 schreef op zondag 13 april 2025 @ 11:52:
[...]


Wederom dank voor de info.
Ik denk dat ik een oplossing heb bedacht, maar ik heb geen tijd om het te testen, maar wellicht kun je dat zelf wel.
Je zou je boiler kunnen definiëren als een "machine" met drie programma's:

1. uit: hij doet niks
2. normaal: 16 kwartieren met een oplopend vermogen (dat haal je uit je vermogensgrafiek)
3. legionella: 20 kwartieren met extra vermogensstappen aan het eind.

Je maakt drie helpers aan voor de planning: programma, window start, window end en twee helpers voor het resultaat.
Je maakt in HA een automation aan die een minuut voor ieder uur runt met de volgende logica (of bij wijzging van de actuele temperatuur):

• als ie aan het opwarmen is niks doen
• je berekent de gemiddelde afkoeling van je boiler per uur in K/uur: afkoeling
• je meet de actule boilertemperatuur: act_temp
• je weet vanaf welke temperatuur het zinvol is te gaan opwarmen: opwarmen_vanat
• je stelt de minimale temperatuur van je boiler vast (hou rekening met de waf )
• je berekent wanneer opwarmen_vanaf wordt bereikt: start_window
• je berekent wanneer opwarmen uiterlijk moet beginnen, tel daar de duur van het programma bij op: end_window

Je houdt zelf in de gaten of je een normale of een legionalla run wil draaien.
Tijdens vakantie zet je het ding "uit".
Je maakt een tweede auomation die wordt getriggerd door de calculated start en die start de boiler.

Denk je dat dat gaat werken?

[bvw]

Torch1969 schreef op maandag 14 april 2025 @ 14:36:
[...]


Dat is uiteraard prima. 👍🏻
@KC27 heb net nog een edit gedaan, neem je die mee? (Tijd stond niet goed (2 uur te vroeg) in de container, daardoor klopte e.e.a. niet in reports, logging etc.)
@bvw heb jij dit probleem niet met jou docker run instructie?

Nee, denk dat dat komt omdat ik dit al in de docker-compose-file had toegevoegd:

code:

environment:
     - TZ=Europe/Amsterdam

Trouwens, om chique te zijn, mag de "privileged" er niet uit? Volgens mij draait ie prima zonder.

[ Voor 8% gewijzigd door bvw op 14-04-2025 18:23 ]