Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[simnet]

ErnstH schreef op donderdag 19 maart 2026 @ 09:41:
[...]

Je zou in principe het ontladen van de EV batterij dusdanig inefficient kunnen maken (bijv 1% efficiency) dat DAO dit nooit zal willen doen.

Ik heb geen EV, dus kan het niet testen; maar ik vind dit eigenlijk best slim bedacht.

[Bravo]

simnet schreef op donderdag 19 maart 2026 @ 11:49:
[...]


Ik heb geen EV, dus kan het niet testen; maar ik vind dit eigenlijk best slim bedacht.

Maar dan mis je alle voordelen die de EV-configuratie mist. Check of de auto thuis staat, check of de auto ingeplugd is. Je krijgt dan sturingen terwijl de EV niet aanwezig is, dus niet optimaal omdat DAO die stroom aan de EV had toebedeeld kan het niet aan een andere gebruiker worden toebedeeld en nutteloos wegvloeit in het net?

[simnet]

Bravo schreef op donderdag 19 maart 2026 @ 13:48:
[...]

Maar dan mis je alle voordelen die de EV-configuratie mist. Check of de auto thuis staat, check of de auto ingeplugd is. Je krijgt dan sturingen terwijl de EV niet aanwezig is, dus niet optimaal omdat DAO die stroom aan de EV had toebedeeld kan het niet aan een andere gebruiker worden toebedeeld en nutteloos wegvloeit in het net?

Ah, ja... daar dacht ik dan weer niet aan. Is vast omheen te werken met automations, maar verre van ideaal.

[KC27]

Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc3
Dit staat in de changelog:
This release looks as a small release at the front-end, but in the back-end we are moving to gui-interface to fill in our settings.
This release is the first step in that direction.
The first step is that all our current settings are compared and validates with a model that is build of all possible settings.
Until now this model is only tested by @simnet and myself.<br>
@simnet is the great force and hard worker behind all these changes, all credits to him!
So we ask the testers before you install this update:

1. make a backup of your "old" app (what in the "old times" was named "add-on")
2. make a backup/copy of your settings (options.json) if you forget that: DAO also makes a copy of your options.jon: options_unversioned.json

Watch at the logging of the new app and if you find any "irregularities" tell us via tweakers or Github.
After installation there are a few new files in the app which are possibly interesting to read:

• DEVELOPER_GUIDE.md (in dao/prof/config) for developers and collaborators who want make new settings.
• config_schema.json to validate the configurations
• SETTINGS.md a completely automatic generated summary of all possible settings

One thing what also changed in this test-release:
The mip-library is updated to a new version; now we don't need the self-compiled binaries.

@simnet en ik horen hier of via Github graag jullie bevindingen.

[KC27]

@Bravo @2xdehelft
Voor 2027 is het misschien een idee om de "voorraad" in de auto niet direct "af te schrijven", maar deze te waarderen tegen de "gemiddelde inkoopprijs" (net als bij de inhoud van de batterij en de boiler).
Dan kan deze op goedkope tijden (mits thuis en ingeplugged) opgeladen worden.

[Bravo]

KC27 schreef op donderdag 19 maart 2026 @ 17:17:
@Bravo @2xdehelft
Voor 2027 is het misschien een idee om de "voorraad" in de auto niet direct "af te schrijven", maar deze te waarderen tegen de "gemiddelde inkoopprijs" (net als bij de inhoud van de batterij en de boiler).
Dan kan deze op goedkope tijden (mits thuis en ingeplugged) opgeladen worden.

Begrijp ik het goed dat het idee is dat dan de EV gaat bijladen als de huidige inkoopprijs laag is?

Dat doe ik momenteel nog handmatig (in DAO), evcc gaat altijd laden als de inkooprijs <18 cent is. Afhankelijk van het aantal uren stel ik een x% hogere SOC doel voor de EV in om ze niet tegen elkaar in te laten werken. Als zo'n handigheidje (altijd laden bij lage prijzen) in DAO komt zou dat heel fijn zijn.

[rescla]

KC27 schreef op donderdag 19 maart 2026 @ 17:10:
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc3
Dit staat in de changelog:
This release looks as a small release at the front-end, but in the back-end we are moving to gui-interface to fill in our settings.
This release is the first step in that direction.
The first step is that all our current settings are compared and validates with a model that is build of all possible settings.
Until now this model is only tested by @simnet and myself.<br>
@simnet is the great force and hard worker behind all these changes, all credits to him!
So we ask the testers before you install this update:

1. make a backup of your "old" app (what in the "old times" was named "add-on")
2. make a backup/copy of your settings (options.json) if you forget that: DAO also makes a copy of your options.jon: options_unversioned.json

Watch at the logging of the new app and if you find any "irregularities" tell us via tweakers or Github.
After installation there are a few new files in the app which are possibly interesting to read:

• DEVELOPER_GUIDE.md (in dao/prof/config) for developers and collaborators who want make new settings.
• config_schema.json to validate the configurations
• SETTINGS.md a completely automatic generated summary of all possible settings

One thing what also changed in this test-release:
The mip-library is updated to a new version; now we don't need the self-compiled binaries.

@simnet en ik horen hier of via Github graag jullie bevindingen.

code:

=> directory dao_data exist
=> /root/dao/data doesn't exist, made
=> /root/dao/webserver/app/static/data exist
2026-03-19 20:01:19 INFO: Configuration needs migration from unversioned to v0
2026-03-19 20:01:19 INFO: Saved backup configuration to ../data/options_unversioned.json
2026-03-19 20:01:19 INFO: Migrating unversioned configuration to v0
2026-03-19 20:01:19 INFO: Added config_version=0 to unversioned configuration
2026-03-19 20:01:19 INFO: Migrated scheduler: active=True, 12 schedule entries
2026-03-19 20:01:19 INFO: Migrated prices.vat: set vat consumption and vat production to {'2022-01-01': 21, '2022-07-01': 9, '2023-01-01': 21}
2026-03-19 20:01:19 INFO: Configuration at version 0
Error loading configuration: 5 validation errors for ConfigurationV0
battery.0.upper limit
  Field required [type=missing, input_value={'name': 'Victron', 'capa...ao_battery_min_soc_end'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
battery.0.lower limit
  Field required [type=missing, input_value={'name': 'Victron', 'capa...ao_battery_min_soc_end'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
electric vehicle.0.entity stop charging
  Field required [type=missing, input_value={'name': 'Tesla Model 3 H...est_ev_charging_ampere'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.activate service
  Field required [type=missing, input_value={'boiler present': 'true'...48, 'elec. power': 3750}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.activate entity
  Field required [type=missing, input_value={'boiler present': 'true'...48, 'elec. power': 3750}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
check_db.py failed, exiting

[KC27]

rescla schreef op donderdag 19 maart 2026 @ 20:03:
[...]


[...]

Fijn dat je hebt willen testen!
Kunnen we de fouten eruit halen.
Heb je voor mij een kopie van je originele options.json?

[BackupBaTTerY]

Is een meerdaagse voorspelling voor jullie als DAO-gebruikers interessant, of speelt dat eigenlijk niet echt omdat jullie verbruik meestal maar per dag geoptimaliseerd hoeft te worden?

[Bravo]

BackupBaTTerY schreef op vrijdag 20 maart 2026 @ 10:34:
Is een meerdaagse voorspelling voor jullie als DAO-gebruikers interessant, of speelt dat eigenlijk niet echt omdat jullie verbruik meestal maar per dag geoptimaliseerd hoeft te worden?

Meerdaagse prijsverwachting is zeker interessant en is al meerdere keren (kort) besproken. Zeker vanaf 2027 is het waardevoller om eigen stroom vast te houden in een batterij om later te verbruiken in plaats van in te kopen.
KC27 speelt al met een ML model op dit gebied, ik heb mijn eigen integratie op basis van ned.nl ook al eens genoemd als mogelijke bron.

[Darkwings]

Hier sinds kort ook met DAO aan de slag, mooi stuk software! Vooralsnog alleen PV en EV eraan hangen en voorzichtig spelen.

Nu plugde ik net de auto in (lekker zonnig) en zie ik dat er geen laden wordt ingepland met deze melding:

Opladen wordt niet ingepland, omdat opgegeven tijdstip (2026-03-21 08:00:00) ligt voorbij de planningshorizon (2026-03-20 23:00:00).

Ik heb als "target" voor de auto om de volgende ochtend vol te zijn, dat leek me logisch maar op deze manier werkt het blijkbaar niet. Waar zit mijn denkfout?

[Torch1969]

Darkwings schreef op vrijdag 20 maart 2026 @ 10:59:
Hier sinds kort ook met DAO aan de slag, mooi stuk software! Vooralsnog alleen PV en EV eraan hangen en voorzichtig spelen.

Nu plugde ik net de auto in (lekker zonnig) en zie ik dat er geen laden wordt ingepland met deze melding:

[...]


Ik heb als "target" voor de auto om de volgende ochtend vol te zijn, dat leek me logisch maar op deze manier werkt het blijkbaar niet. Waar zit mijn denkfout?

Om 13 u komen pas de prijzen voor morgen binnen, dan kan DAO pas bepalen wat het beste moment is (voor 8:00 morgenochtend) om te laden. Als je de zon en lage prijs van vandaag wilt benutten moet je die tijd eerder zetten, b.v. Voor 18:00.

[Darkwings]

Ah, dat is logisch, maar ook wel jammer natuurlijk. Idealiter wil ik dat als er overschot is gedurende de dag en er kan geladen worden, dat altijd gedaan wordt, maar dat kan dus niet zo maar als ik het goed begrijp.

Misschien dat ik met een automation de target soc + tijd bijvoorbeeld naar 23 uur en 60% zet, en dan om middernacht naar 8 uur 's ochtends en 80%.

[KC27]

Darkwings schreef op vrijdag 20 maart 2026 @ 11:11:
Ah, dat is logisch, maar ook wel jammer natuurlijk. Idealiter wil ik dat als er overschot is gedurende de dag en er kan geladen worden, dat altijd gedaan wordt, maar dat kan dus niet zo maar als ik het goed begrijp.

Misschien dat ik met een automation de target soc + tijd bijvoorbeeld naar 23 uur en 60% zet, en dan om middernacht naar 8 uur 's ochtends en 80%.

Dat kun je dan beter om 13:00 uur doen (als de prijzen voor morgen binnen zijn) ipv om middernacht.

[balk]

Hier ook een foutmelding (ik heb geen boiler...)

code:

Error loading configuration: 7 validation errors for ConfigurationV0
boiler.`entity actual temp.`
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.entity setpoint
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.entity hysterese
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.cooling rate
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.heating allowed below
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.activate service
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
boiler.activate entity
  Field required [type=missing, input_value={'boiler present': 'False'}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.10/v/missing
check_db.py failed, exiting

code:

"boiler": {
        "boiler present": "False"
    }

[rescla]

KC27 schreef op donderdag 19 maart 2026 @ 21:13:
[...]

Fijn dat je hebt willen testen!
Kunnen we de fouten eruit halen.
Heb je voor mij een kopie van je originele options.json?

Ik zie dat ik voor testing wat van de acterende entity settings heb weggehaald, mogelijk zorgt dat voor problemen?

code:

"battery": [
  {
    "name": "Victron",
    "capacity": 64.3,
    "entity actual level": "input_number.doa_battery_entity_actual_level_testing",
    "solar": [],
    "charge stages": [
    { "power": 600,   "efficiency": 0.85 },
    { "power": 1500,  "efficiency": 0.92 },
    { "power": 3000,  "efficiency": 0.93 },
    { "power": 10500, "efficiency": 0.90 },
    { "power": 11250, "efficiency": 0.89 }
  ],
  "discharge stages": [
    { "power": 600,   "efficiency": 0.90 },
    { "power": 1500,   "efficiency": 0.95 },
    { "power": 2400,  "efficiency": 0.96 },
    { "power": 12300, "efficiency": 0.92 }
  ],
    "cycle cost": 0.01,
    "dc_to_bat efficiency": 0.98,
    "bat_to_dc efficiency": 0.98,
    "minimum power": 600,
    "entity min soc end opt": "input_number.dao_battery_min_soc_end"
  }
 ],

code:

"boiler": {
    "boiler present": "true",
    "entity actual temp.": "sensor.hot_water_charging_bt6_30010",
    "entity setpoint": "input_number.dao_boiler_setpoint",
    "entity hysterese": "input_number.dao_boiler_hysteresis",
    "cop": 2.9,
    "cooling rate": 0.3,
    "volume": 500,
    "heating allowed below": 48,
    "elec. power": 3750
  },

code:

"electric vehicle": [
{
   "name": "Tesla Model 3",
   "capacity": 68.45,
   "entity position": "device_tracker.tesla_location",
   "entity actual level": "sensor.tesla_battery",
   "entity plugged in": "binary_sensor.tesla_charger_plug",
   "charge stages": [
      {"ampere": 6, "efficiency": 0.96},
      {"ampere": 16, "efficiency": 0.98}
   ],
   "charge three phase": "true",
   "charge scheduler": {
      "entity set level": "input_number....",
      "entity ready datetime": "input_datetime...."
   },
   "entity set charging ampere": "input_number....",
   "charge switch": "input_boolean....",
   "entity max amperage": "input_number.dao_max_tesla_charge_amperage",
}

],

[BackupBaTTerY]

Bravo schreef op vrijdag 20 maart 2026 @ 10:54:
[...]

Meerdaagse prijsverwachting is zeker interessant en is al meerdere keren (kort) besproken. Zeker vanaf 2027 is het waardevoller om eigen stroom vast te houden in een batterij om later te verbruiken in plaats van in te kopen.
KC27 speelt al met een ML model op dit gebied, ik heb mijn eigen integratie op basis van ned.nl ook al eens genoemd als mogelijke bron.

Leuk om te zien dat hier wel wat interesse voor is en dat een paar mensen dit al hebben genoemd.

Ik werk hier zelf al wat langer aan en ben er in de tussentijd best ver mee gekomen. Het begint inmiddels steeds meer op een marktrijp product te lijken, al is het natuurlijk nog niet helemaal af. Juist de laatste stap vind ik belangrijk: het beter laten aansluiten op wat gebruikers in de praktijk echt nodig hebben.

Daarom zou ik graag meer contact hebben met echte gebruikers. Alleen zo kan ik het verder verbeteren en echt goed afstemmen op hoe mensen het daadwerkelijk willen gebruiken.

Als iemand het interessant vindt om mee te denken, feedback te geven of eens te kijken naar mogelijke koppelingen, dan hoor ik dat heel graag.

Ik heb trouwens ook al een API die de voorspelde prijs teruggeeft, maar er is op dit moment nog geen echte praktische integratie met bijvoorbeeld Home Assistant.

(https://stroomprijsprognose.nl/
)

[simnet]

BackupBaTTerY schreef op vrijdag 20 maart 2026 @ 16:43:
[...]

https://stroomprijsprognose.nl/

Op die website staat dat de werkelijke day-ahead prijs al bekend is tot zondag. Dat klopt niet helemaal lijkt me?

[BackupBaTTerY]

simnet schreef op vrijdag 20 maart 2026 @ 17:17:
[...]


Op die website staat dat de werkelijke day-ahead prijs al bekend is tot zondag. Dat klopt niet helemaal lijkt me?

Dank voor je feedback! Ik wil dit graag goed corrigeren, maar ik begrijp je opmerking nog niet helemaal.

Kun je iets concreter aangeven welke tekst/sectie je bedoelt?
Als het kan: welk tabblad, welke zin (liefst even citeren) en voor welke datum/situatie het volgens jou niet klopt.

Dan kan ik precies checken waar het misgaat en het direct aanpassen.

[BackupBaTTerY]

.

[ Voor 99% gewijzigd door BackupBaTTerY op 20-03-2026 19:27 ]

[simnet]

BackupBaTTerY schreef op vrijdag 20 maart 2026 @ 17:56:
[...]

Dank voor je feedback! Ik wil dit graag goed corrigeren, maar ik begrijp je opmerking nog niet helemaal.

Kun je iets concreter aangeven welke tekst/sectie je bedoelt?
Als het kan: welk tabblad, welke zin (liefst even citeren) en voor welke datum/situatie het volgens jou niet klopt.

Dan kan ik precies checken waar het misgaat en het direct aanpassen.

Als ik kijk naar de curves grafiek, dan staat daar werkelijke day ahead prijs ingeplot tot zondag.

[KC27]

balk schreef op vrijdag 20 maart 2026 @ 13:32:
Hier ook een foutmelding (ik heb geen boiler...)

[...]

code:

"boiler": {
        "boiler present": "False"
    }

Dank voor het testen.
Gaan we oppakken/aanpassen.

[BackupBaTTerY]

simnet schreef op vrijdag 20 maart 2026 @ 19:36:
[...]


Als ik kijk naar de curves grafiek, dan staat daar werkelijke day ahead prijs ingeplot tot zondag.

Het was een weergaveprobleem. Ik heb de weergave nu aangepast, zodat het duidelijker is dat de gegevens bij zaterdag horen.

[Mvdw]

f.welvering schreef op dinsdag 3 maart 2026 @ 17:58:
[...]


Ik heb de test versie draaien, ik zal je binnenkort laten weten wat de ervaring is.
Ik heb er een automatisering omheen gezet met wat helpers zodat dit gestuurd wordt.
Voor de geinteresseerde hierbij de automatisering welke ik nu gebruik:


[...]

Ik kom er niet helemaal uit of en hoe dit toe te passen op mijn setup, waarbij ik de stooklijn correctie vanuit DAO gebruik om de doeltemperatuur van een climate entiteit (HA thermostaat) te bepalen. De climate entiteit stuurt een switch entiteit aan die de warmtepomp activeert of stopt. Via separate automatiseringen stel ik de compressor frequentie en aanvoertemperatuur in (beide o.b.v. buitentemperatuur). Wat zou deze functie dan nog toevoegen aangezien ik de climate entiteit laat bepalen of er warmtevraag is?

[hemertje]

Heeft er iemand hier ook Zendure batterijen in gebruik met DAO??

[The Source]

hemertje schreef op vrijdag 20 maart 2026 @ 22:23:
Heeft er iemand hier ook Zendure batterijen in gebruik met DAO??

mtimmerm in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

Als je de batterij in HA kunt aansturen werkt DAO ook. Heb je specifieke vragen?

[ Voor 25% gewijzigd door The Source op 20-03-2026 23:55 ]

[hemertje]

The Source schreef op vrijdag 20 maart 2026 @ 23:38:
[...]

search:
mtimmerm in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

Als je de batterij in HA kunt aansturen werkt DAO ook. Heb je specifieke vragen?

Hoi,

Ik lees hier al maanden mee, de functionaliteit als duurzaamheids kapitein in huis staat me erg aan maar maar qua gebruiksgemak met de configs staat me toch tegen om de stap te wagen.

Daarbij komt dat je buiten DAO ook nog in HA aan de gang moet om daadwerkelijk te gaan sturen…

De vragen komen vanzelf

[The Source]

hemertje schreef op zaterdag 21 maart 2026 @ 00:02:
[...]


Hoi,

Ik lees hier al maanden mee, de functionaliteit als duurzaamheids kapitein in huis staat me erg aan maar maar qua gebruiksgemak met de configs staat me toch tegen om de stap te wagen.

Daarbij komt dat je buiten DAO ook nog in HA aan de gang moet om daadwerkelijk te gaan sturen…

De vragen komen vanzelf

Same hier hoor, maar het valt wel mee. Start met de installatie en configuratie, gewoon stap voor stap. Voeg je solar toe en zorg dat die goed gedefineerd zijn. Zodra het draait zonder fouten ben je al ver. De jason is een bitch met alle comma's en } tekens die juist moeten staan maar ik heb begrepen dat er binnenkort een gui komt voor de config (zit in de test versie), dus dan hoef je je hopelijk daar geen zorgen meer over te maken. Gewoon starten en mee spelen

[hemertje]

ik volg al een tijdje Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO
naar mijn idee een mooie kapitein om een plan te bepalen en triggers naar de diverse apparatuur te sturen dmv HomeAssistant

nu met de Zendure batterij sets erbij in afweging om Gielz met de Gast777 proxy in te zetten

• Zendure producten in Home Assistant integreren deel 2
• https://github.com/Gielz1986/Zendure-HA-zenSDK
• https://github.com/gast777/Zendure-zenSDK-proxy

of de officiele Zendure HA integratie en dan via HA de automatiseringen doen of toch via DAO en van daar uit automatiseren?

ideetje:
zou mooi zijn als we samen een soort database van devices kunnen vastleggen die als donordocument voor de config gebruikt kunnen worden? of soort van herkenning van devices uit HA en daarmee de DAO vullen?

[Levim]

Levim schreef op donderdag 19 maart 2026 @ 11:30:
[...]


Bedankt voor de reactie alvast!
Ik heb ondertussen opgemerkt dat het probleem blijkbaar ligt aan de "grid”: { “max_power”: 2.5  }"setting.
Als ik deze iets verhoog naar 3 of hoger, dan berekent hij wel. Had peak shaving wel op 2,5 willen hebben, maar dat gaat vanaf nu met de hoeveelheid zon waarschijnlijk toch irrelevant worden.

Je kan de logs hier vinden:


[...]

Ok, te vroeg gejuichd. Die verhoging naar 3 heeft het probleem toch niet structureel opgelost.

Als er iemand is die mij kan bijstaan, don't hesitate

[PcFer]

Levim schreef op zaterdag 21 maart 2026 @ 15:06:
[...]


Ok, te vroeg gejuichd. Die verhoging naar 3 heeft het probleem toch niet structureel opgelost.

Als er iemand is die mij kan bijstaan, don't hesitate

Is 2,5kW ook niet heel erg weinig voor een netaansluiting? In je config geef je wel aan dat de batterij 3,3kW kan laden en 7,5kW kan ontladen. Hoe had je dit bedacht?


In dezelfde categorie zie ik nog wel een verbetering hoe DAO omgaat met de netaansluiting en de belastingen. Met name enkelfase belastingen.

Ik heb nu regelmatig dat DAO de laadpaal vol aanzet, maar ook mijn enkelfase batterij vol laat laden. Dat kan de zekering op L1 niet aan dus gaat de batterij langzamer laden.

Het zou mooi zijn als we per belasting (maar beginnende met battery) kunnen aangeven op welke fase deze zit. Als DAO dan rekening houdt met de netaansluiting per fase voorkom je dat er te ambitieus wordt ingepland.

Is dit ingewikkeld om te implementeren?

[simnet]

PcFer schreef op zaterdag 21 maart 2026 @ 19:04:
[...]

Is 2,5kW ook niet heel erg weinig voor een netaansluiting? In je config geef je wel aan dat de batterij 3,3kW kan laden en 7,5kW kan ontladen. Hoe had je dit bedacht?


In dezelfde categorie zie ik nog wel een verbetering hoe DAO omgaat met de netaansluiting en de belastingen. Met name enkelfase belastingen.

Ik heb nu regelmatig dat DAO de laadpaal vol aanzet, maar ook mijn enkelfase batterij vol laat laden. Dat kan de zekering op L1 niet aan dus gaat de batterij langzamer laden.

Het zou mooi zijn als we per belasting (maar beginnende met battery) kunnen aangeven op welke fase deze zit. Als DAO dan rekening houdt met de netaansluiting per fase voorkom je dat er te ambitieus wordt ingepland.

Is dit ingewikkeld om te implementeren?

Dao heeft een grid max_power setting. Die staat default op 17 kW (3x25A).

[PcFer]

simnet schreef op zaterdag 21 maart 2026 @ 22:54:
[...]

Dao heeft een grid max_power setting. Die staat default op 17 kW (3x25A).

Ja klopt, die staat bij mij ook op 17kW, dus 25A per fase. Maar mijn laadpaal wordt met 16A aangestuurd vanuit DAO en de enkelfase batterij met 20A dus totaal van 36A.

Er is wel een beveiliging die gaat loadbalancen / peakshaven, maar ik denk dat DAO slimmere keuzes maakt als er in de optimalisatie rekening met deze situatie wordt gehouden.

[diamanten]

Goedemorgen,
Kan iemand uitleggen, waarom DAO na optimalisatie de produktie van mijn zonnepanelen niet meer meeneemt? En dus mijn thuisaccu gaat ontladen?
Volgens de Solar grafiek zijn er wel verwachten zonne-opbrensten.

En de log:

code:

2026-03-22 09:06:12 info: Day Ahead Optimalisering versie: 2026.03.2
2026-03-22 09:06:12 info: Day Ahead Optimalisering gestart op: 22-03-2026 09:06:12
2026-03-22 09:06:12 info: Day Ahead Optimalisatie gestart: 22-03-2026 09:06:12 taak: calc_optimum
2026-03-22 09:06:12 info: Debug = False
2026-03-22 09:06:12 info: Baseload uit instellingen
2026-03-22 09:06:12 info: ML prediction Enphase
                   date_time  prediction
0  2026-03-22 09:00:00+01:00       1.577
1  2026-03-22 10:00:00+01:00       2.779
2  2026-03-22 11:00:00+01:00       4.518
3  2026-03-22 12:00:00+01:00       5.304
4  2026-03-22 13:00:00+01:00       6.371
5  2026-03-22 14:00:00+01:00       6.522
6  2026-03-22 15:00:00+01:00       5.260
7  2026-03-22 16:00:00+01:00       3.367
8  2026-03-22 17:00:00+01:00       1.793
9  2026-03-22 18:00:00+01:00       0.332
10 2026-03-22 19:00:00+01:00       0.000
11 2026-03-22 20:00:00+01:00       0.000
12 2026-03-22 21:00:00+01:00       0.000
13 2026-03-22 22:00:00+01:00       0.000
14 2026-03-22 23:00:00+01:00       0.000
2026-03-22 09:06:13 info: Start waarden: 
      uur                tijd   spot   p_l    p_t  base  pv_ac  pv_dc
0   09:00 2026-03-22 09:00:00  0.020 0.135  0.024 0.062  0.165      0
1   09:15 2026-03-22 09:15:00  0.007 0.119  0.008 0.064  0.357      0
2   09:30 2026-03-22 09:30:00  0.001 0.111  0.001 0.066  0.432      0
3   09:45 2026-03-22 09:45:00 -0.000 0.111 -0.000 0.069  0.507      0
4   10:00 2026-03-22 10:00:00  0.000 0.111  0.000 0.073  0.574      0
5   10:15 2026-03-22 10:15:00 -0.000 0.111 -0.000 0.077  0.649      0
6   10:30 2026-03-22 10:30:00 -0.001 0.110 -0.001 0.080  0.724      0
7   10:45 2026-03-22 10:45:00 -0.001 0.110 -0.001 0.080  0.833      0
8   11:00 2026-03-22 11:00:00 -0.002 0.108 -0.003 0.079  0.981      0
9   11:15 2026-03-22 11:15:00 -0.003 0.107 -0.004 0.080  1.090      0
10  11:30 2026-03-22 11:30:00 -0.004 0.106 -0.005 0.081  1.199      0
11  11:45 2026-03-22 11:45:00 -0.007 0.102 -0.008 0.080  1.248      0
12  12:00 2026-03-22 12:00:00 -0.012 0.096 -0.014 0.080  1.248      0
13  12:15 2026-03-22 12:15:00 -0.018 0.089 -0.021 0.079  1.297      0
14  12:30 2026-03-22 12:30:00 -0.016 0.092 -0.019 0.078  1.346      0
15  12:45 2026-03-22 12:45:00 -0.018 0.089 -0.022 0.073  1.413      0
16  13:00 2026-03-22 13:00:00 -0.011 0.097 -0.013 0.063  1.507      0
17  13:15 2026-03-22 13:15:00 -0.010 0.099 -0.012 0.058  1.574      0
18  13:30 2026-03-22 13:30:00 -0.009 0.100 -0.011 0.053  1.640      0
19  13:45 2026-03-22 13:45:00 -0.007 0.103 -0.008 0.055  1.650      0
20  14:00 2026-03-22 14:00:00 -0.004 0.107 -0.004 0.063  1.638      0
21  14:15 2026-03-22 14:15:00 -0.002 0.108 -0.002 0.065  1.648      0
22  14:30 2026-03-22 14:30:00 -0.001 0.109 -0.001 0.067  1.657      0
23  14:45 2026-03-22 14:45:00  0.000 0.111  0.001 0.064  1.578      0
24  15:00 2026-03-22 15:00:00 -0.000 0.111 -0.000 0.056  1.443      0
25  15:15 2026-03-22 15:15:00  0.001 0.112  0.001 0.053  1.364      0
26  15:30 2026-03-22 15:30:00  0.012 0.126  0.015 0.050  1.286      0
27  15:45 2026-03-22 15:45:00  0.031 0.148  0.037 0.050  1.167      0
28  16:00 2026-03-22 16:00:00  0.029 0.145  0.035 0.047  1.014      0
29  16:15 2026-03-22 16:15:00  0.071 0.196  0.085 0.047  0.896      0
30  16:30 2026-03-22 16:30:00  0.095 0.226  0.115 0.047  0.778      0
31  16:45 2026-03-22 16:45:00  0.132 0.271  0.160 0.068  0.679      0
32  17:00 2026-03-22 17:00:00  0.090 0.219  0.109 0.114  0.594      0
33  17:15 2026-03-22 17:15:00  0.124 0.261  0.151 0.134  0.496      0
34  17:30 2026-03-22 17:30:00  0.139 0.279  0.168 0.155  0.397      0
35  17:45 2026-03-22 17:45:00  0.168 0.314  0.204 0.137  0.306      0
36  18:00 2026-03-22 18:00:00  0.144 0.286  0.175 0.087  0.202      0
37  18:15 2026-03-22 18:15:00  0.174 0.322  0.211 0.069  0.111      0
38  18:30 2026-03-22 18:30:00  0.160 0.304  0.193 0.052  0.020      0
39  18:45 2026-03-22 18:45:00  0.173 0.321  0.210 0.052  0.000      0
40  19:00 2026-03-22 19:00:00  0.178 0.326  0.215 0.066  0.026      0
41  19:15 2026-03-22 19:15:00  0.176 0.324  0.214 0.066  0.005      0
42  19:30 2026-03-22 19:30:00  0.166 0.312  0.201 0.066  0.000      0
43  19:45 2026-03-22 19:45:00  0.156 0.299  0.188 0.063  0.000      0
44  20:00 2026-03-22 20:00:00  0.177 0.325  0.215 0.059  0.000      0
45  20:15 2026-03-22 20:15:00  0.160 0.304  0.193 0.056  0.000      0
46  20:30 2026-03-22 20:30:00  0.153 0.296  0.185 0.054  0.000      0
47  20:45 2026-03-22 20:45:00  0.137 0.277  0.166 0.052  0.000      0
48  21:00 2026-03-22 21:00:00  0.153 0.296  0.185 0.050  0.000      0
49  21:15 2026-03-22 21:15:00  0.146 0.288  0.177 0.048  0.000      0
50  21:30 2026-03-22 21:30:00  0.140 0.280  0.169 0.046  0.000      0
51  21:45 2026-03-22 21:45:00  0.135 0.274  0.163 0.046  0.000      0
52  22:00 2026-03-22 22:00:00  0.146 0.287  0.177 0.046  0.000      0
53  22:15 2026-03-22 22:15:00  0.139 0.279  0.169 0.045  0.000      0
54  22:30 2026-03-22 22:30:00  0.135 0.275  0.164 0.045  0.000      0
55  22:45 2026-03-22 22:45:00  0.128 0.266  0.155 0.044  0.000      0
56  23:00 2026-03-22 23:00:00  0.146 0.287  0.177 0.042  0.000      0
57  23:15 2026-03-22 23:15:00  0.134 0.273  0.162 0.041  0.000      0
58  23:30 2026-03-22 23:30:00  0.130 0.268  0.157 0.039  0.000      0
59  23:45 2026-03-22 23:45:00  0.120 0.255  0.145 0.038  0.000      0
2026-03-22 09:06:13 info: No reduced hours applied for Zinvolt
2026-03-22 09:06:13 info: No reduced power applied during discharging at low soc
2026-03-22 09:06:13 info: No reduced power applied during charging at high soc
2026-03-22 09:06:13 info: Startwaarde SoC Zinvolt: 18.4%

2026-03-22 09:06:13 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2026-03-22 09:06:13 info: Instellingen voor laden van EV: Kia Niro EV
2026-03-22 09:06:13 info: Direct laden is uit
2026-03-22 09:06:13 info:  Ampere  Effic. Grid kW Accu kW
2026-03-22 09:06:13 info:    0.00    0.00    0.00    0.00
2026-03-22 09:06:13 info:   16.00    0.90   11.04    9.94
2026-03-22 09:06:13 info: Capaciteit accu: 55 kWh
2026-03-22 09:06:13 info: Maximaal laadvermogen: 11.04 kW
2026-03-22 09:06:13 info: Klaar met laden op: 18-02-2026 23:00:00
2026-03-22 09:06:13 info: Huidig laadniveau: 81.0 %
2026-03-22 09:06:13 info: Gewenst laadniveau:90.0 %
2026-03-22 09:06:13 info: Marge voor het laden: 2 %
2026-03-22 09:06:13 info: Locatie: home
2026-03-22 09:06:13 info: Ingeplugged:False
2026-03-22 09:06:13 info: Benodigde netto energie: 4.950 kWh
2026-03-22 09:06:13 info: Tijd nodig om te laden: 0:30 uur
2026-03-22 09:06:13 info: Afgerond naar hele intervallen: 2 kwartier
2026-03-22 09:06:13 info: Stand laden schakelaar: off
2026-03-22 09:06:13 info: Stand aantal ampere laden: 0.0 A
2026-03-22 09:06:13 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd, opgegeven tijdstip (2026-02-18 23:00:00) is verouderd.
2026-03-22 09:06:13 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-03-22 09:06:13 info: Apparaat Airco direct starten staat uit
2026-03-22 09:06:13 info: Machine Airco wordt niet ingepland, want er is gekozen voor Uit
2026-03-22 09:06:14 info: Apparaat Afwasmachine direct starten staat uit
2026-03-22 09:06:14 info: Machine Afwasmachine wordt niet ingepland, want het planning-window ligt voorbij einde optimalisering
2026-03-22 09:06:14 info: Machine Afwasmachine wordt niet ingepland, want er is gekozen voor Uit
2026-03-22 09:06:14 info: Strategie: minimale kosten
2026-03-22 09:06:14 info: Maximale fout (maximal gap): 0.005000 euro
2026-03-22 09:06:14 info: Rekentijd: 0.33  sec
2026-03-22 09:06:14 info: Het programma heeft een optimale oplossing gevonden.
2026-03-22 09:06:14 info: Laad volume in uur 3 09:45 0.0 kWh
2026-03-22 09:06:14 info: 3 1.0 0.3
2026-03-22 09:06:14 info: Laad volume in uur 6 10:30 0.0 kWh
2026-03-22 09:06:14 info: 6 0.3279651952669966 1.8
2026-03-22 09:06:14 info: 7 0.6720348047330035 2.0
2026-03-22 09:06:14 info: Laad volume in uur 7 10:45 0.0 kWh
2026-03-22 09:06:14 info: 7 1.0 2.0
2026-03-22 09:06:14 info: Laad volume in uur 8 11:00 0.0 kWh
2026-03-22 09:06:14 info: 7 1.0 2.0
2026-03-22 09:06:14 info: Laad volume in uur 9 11:15 0.0 kWh
2026-03-22 09:06:14 info: 7 1.0 2.0
2026-03-22 09:06:14 info: Laad volume in uur 10 11:30 0.0 kWh
2026-03-22 09:06:14 info: 7 1.0 2.0
2026-03-22 09:06:14 info: Ontlaad volume in uur 11 11:45 0.08 kWh
2026-03-22 09:06:14 info: 6 0.35555555555555546 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 12 12:00 0.07953125 kWh
2026-03-22 09:06:14 info: 7 0.2651041666666667 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 13 12:15 0.07890625 kWh
2026-03-22 09:06:14 info: 7 0.2630208333333333 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 14 12:30 0.07828125 kWh
2026-03-22 09:06:14 info: 6 0.34791666666666654 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 15 12:45 0.07328124999999999 kWh
2026-03-22 09:06:14 info: 6 0.3256944444444444 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 16 13:00 0.06328125000000001 kWh
2026-03-22 09:06:14 info: 7 0.21093750000000003 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 17 13:15 0.05828125 kWh
2026-03-22 09:06:14 info: 6 0.25902777777777775 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 18 13:30 0.053281249999999995 kWh
2026-03-22 09:06:14 info: 7 0.17760416666666667 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 19 13:45 0.055156250000000004 kWh
2026-03-22 09:06:14 info: 6 0.24513888888888885 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 20 14:00 0.0634375 kWh
2026-03-22 09:06:14 info: 5 0.36249999999999993 0.7
2026-03-22 09:06:14 info: Laad volume in uur 21 14:15 0.0 kWh
2026-03-22 09:06:14 info: 7 1.0 2.0
2026-03-22 09:06:14 info: Laad volume in uur 22 14:30 0.0 kWh
2026-03-22 09:06:14 info: 7 1.0 2.0
2026-03-22 09:06:14 info: Ontlaad volume in uur 37 18:15 0.2850000000000001 kWh
2026-03-22 09:06:14 info: 7 0.9500000000000003 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 38 18:30 0.032045702561736104 kWh
2026-03-22 09:06:14 info: 7 0.10681900853912034 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 39 18:45 0.22794804743826427 kWh
2026-03-22 09:06:14 info: 7 0.7598268247942142 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 40 19:00 0.2850000000000001 kWh
2026-03-22 09:06:14 info: 7 0.9500000000000003 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 41 19:15 0.2850000000000001 kWh
2026-03-22 09:06:14 info: 7 0.9500000000000003 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 42 19:30 0.065625 kWh
2026-03-22 09:06:14 info: 7 0.21874999999999997 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 43 19:45 0.063125 kWh
2026-03-22 09:06:14 info: 5 0.3607142857142857 0.7
2026-03-22 09:06:14 info: Ontlaad volume in uur 44 20:00 0.2850000000000001 kWh
2026-03-22 09:06:14 info: 7 0.9500000000000003 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 45 20:15 0.056093750000000005 kWh
2026-03-22 09:06:14 info: 5 0.3205357142857143 0.7
2026-03-22 09:06:14 info: Ontlaad volume in uur 46 20:30 0.05359375000000001 kWh
2026-03-22 09:06:14 info: 7 0.17864583333333336 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 47 20:45 0.051718749999999994 kWh
2026-03-22 09:06:14 info: 5 0.29553571428571423 0.7
2026-03-22 09:06:14 info: Ontlaad volume in uur 48 21:00 0.05 kWh
2026-03-22 09:06:14 info: 6 0.2222222222222222 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 49 21:15 0.04812500000000001 kWh
2026-03-22 09:06:14 info: 5 0.275 0.7
2026-03-22 09:06:14 info: Ontlaad volume in uur 50 21:30 0.04625 kWh
2026-03-22 09:06:14 info: 6 0.2055555555555555 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 51 21:45 0.04562499999999999 kWh
2026-03-22 09:06:14 info: 5 0.2607142857142857 0.7
2026-03-22 09:06:14 info: Ontlaad volume in uur 52 22:00 0.04609375000000001 kWh
2026-03-22 09:06:14 info: 6 0.2048611111111111 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 53 22:15 0.04546875 kWh
2026-03-22 09:06:14 info: 5 0.25982142857142854 0.7
2026-03-22 09:06:14 info: Ontlaad volume in uur 54 22:30 0.044843749999999995 kWh
2026-03-22 09:06:14 info: 7 0.14947916666666666 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 55 22:45 0.04359375 kWh
2026-03-22 09:06:14 info: 7 0.1453125 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 56 23:00 0.041874999999999996 kWh
2026-03-22 09:06:14 info: 7 0.1395833333333333 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 57 23:15 0.040624999999999994 kWh
2026-03-22 09:06:14 info: 6 0.18055555555555552 0.9
2026-03-22 09:06:14 info: Ontlaad volume in uur 58 23:30 0.039375 kWh
2026-03-22 09:06:14 info: 7 0.13125 1.2
2026-03-22 09:06:14 info: Ontlaad volume in uur 59 23:45 0.03812499999999999 kWh
2026-03-22 09:06:14 info: 6 0.1694444444444444 0.9
2026-03-22 09:06:14 info: In- en uitgaande energie per kwartier batterij Zinvolt
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --  18.40
 09:15   0.00     --   0.00   0.00   0.00     --   0.00     --  18.40
 09:30   0.00     --   0.00   0.00   0.00     --   0.00     --  18.40
 09:45   0.07  90.00   0.07   0.00   0.07  95.00   0.06  85.50  20.54
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.54
 10:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.54
 10:30   0.48  94.39   0.46   0.00   0.46  95.00   0.43  89.67  34.99
 10:45   0.50  95.00   0.48   0.00   0.47  95.00   0.45  90.25  50.03
 11:00   0.50  95.00   0.48   0.00   0.47  95.00   0.45  90.25  65.08
 11:15   0.50  95.00   0.48   0.00   0.47  95.00   0.45  90.25  80.12
 11:30   0.50  95.00   0.48   0.00   0.47  95.00   0.45  90.25  95.16
 11:45  -0.08  95.00  -0.08   0.00  -0.08  95.00  -0.09  90.25  92.20
 12:00  -0.08  95.00  -0.08   0.00  -0.08  95.00  -0.09  90.25  89.27
 12:15  -0.08  95.00  -0.08   0.00  -0.08  95.00  -0.09  90.25  86.35
 12:30  -0.08  95.00  -0.08   0.00  -0.08  95.00  -0.09  90.25  83.46
 12:45  -0.07  95.00  -0.08   0.00  -0.08  95.00  -0.08  90.25  80.75
 13:00  -0.06  95.00  -0.07   0.00  -0.07  95.00  -0.07  90.25  78.42
 13:15  -0.06  95.00  -0.06   0.00  -0.06  95.00  -0.06  90.25  76.26
 13:30  -0.05  95.00  -0.06   0.00  -0.06  95.00  -0.06  90.25  74.30
 13:45  -0.06  95.00  -0.06   0.00  -0.06  95.00  -0.06  90.25  72.26
 14:00  -0.06  95.00  -0.07   0.00  -0.07  95.00  -0.07  90.25  69.92
 14:15   0.50  95.00   0.48   0.00   0.47  95.00   0.45  90.25  84.96
 14:30   0.50  95.00   0.48   0.00   0.47  95.00   0.45  90.25 100.00
 14:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:15  -0.29  95.00  -0.30   0.00  -0.30  95.00  -0.32  90.25  89.47
 18:30  -0.03  95.00  -0.03   0.00  -0.03  95.00  -0.04  90.25  88.29
 18:45  -0.23  95.00  -0.24   0.00  -0.24  95.00  -0.25  90.25  79.87
 19:00  -0.29  95.00  -0.30   0.00  -0.30  95.00  -0.32  90.25  69.34
 19:15  -0.29  95.00  -0.30   0.00  -0.30  95.00  -0.32  90.25  58.82
 19:30  -0.07  95.00  -0.07   0.00  -0.07  95.00  -0.07  90.25  56.39
 19:45  -0.06  95.00  -0.07   0.00  -0.07  95.00  -0.07  90.25  54.06
 20:00  -0.29  95.00  -0.30   0.00  -0.30  95.00  -0.32  90.25  43.54
 20:15  -0.06  95.00  -0.06   0.00  -0.06  95.00  -0.06  90.25  41.46
 20:30  -0.05  95.00  -0.06   0.00  -0.06  95.00  -0.06  90.25  39.49
 20:45  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.06  90.25  37.58
 21:00  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.06  90.25  35.73
 21:15  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  33.95
 21:30  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  32.24
 21:45  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  30.56
 22:00  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  28.86
 22:15  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  27.18
 22:30  -0.04  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  25.52
 22:45  -0.04  95.00  -0.05   0.00  -0.05  95.00  -0.05  90.25  23.91
 23:00  -0.04  95.00  -0.04   0.00  -0.04  95.00  -0.05  90.25  22.36
 23:15  -0.04  95.00  -0.04   0.00  -0.04  95.00  -0.05  90.25  20.86
 23:30  -0.04  95.00  -0.04   0.00  -0.04  95.00  -0.04  90.25  19.41
 23:45  -0.04  95.00  -0.04   0.00  -0.04  95.00  -0.04  90.25  18.00
Totaal   0.66    NaN   0.32   0.00   0.32    NaN  -0.01    NaN    NaN
2026-03-22 09:06:18 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 09:00    0.00     0.00   0.00   0.13   0.06   0.00   0.00   0.00   0.17   0.00   -0.00  20.00   0.00
 09:15    0.00     0.00   0.00   0.29   0.06   0.00   0.00   0.00   0.36   0.00   -0.00  20.00   0.00
 09:30    0.00     0.00   0.00   0.37   0.07   0.00   0.00   0.00   0.43   0.00   -0.00  20.00   0.00
 09:45    0.07     0.00   0.00   0.36   0.07   0.00   0.00   0.00   0.51   0.00    0.00  20.00   0.00
 10:00    0.00     0.00   0.00   0.50   0.07   0.00   0.00   0.00   0.57   0.00   -0.00  20.00   0.00
 10:15    0.00     0.00   0.00   0.57   0.08   0.00   0.00   0.00   0.65   0.00    0.00  20.00   0.00
 10:30    0.48     0.00   0.00   0.16   0.08   0.00   0.00   0.00   0.72   0.00    0.00  20.00   0.00
 10:45    0.50     0.00   0.00   0.25   0.08   0.00   0.00   0.00   0.83   0.00    0.00  20.00   0.00
 11:00    0.50     0.00   0.00   0.40   0.08   0.00   0.00   0.00   0.98   0.00    0.00  20.00   0.00
 11:15    0.50     0.00   0.00   0.51   0.08   0.00   0.00   0.00   1.09   0.00    0.00  20.00   0.00
 11:30    0.50     0.00   0.00   0.62   0.08   0.00   0.00   0.00   1.20   0.00    0.00  20.00   0.00
 11:45    0.00     0.08   0.00   0.00   0.08   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 12:00    0.00     0.08   0.00   0.00   0.08   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 12:15    0.00     0.08   0.00   0.00   0.08   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 12:30    0.00     0.08   0.00   0.00   0.08   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 12:45    0.00     0.07   0.00   0.00   0.07   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 13:00    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 13:15    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 13:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 13:45    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 14:00    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 14:15    0.50     0.00   0.00   1.08   0.07   0.00   0.00   0.00   1.65   0.00    0.00  20.00   0.00
 14:30    0.50     0.00   0.00   1.09   0.07   0.00   0.00   0.00   1.66   0.00    0.00  20.00   0.00
 14:45    0.00     0.00   0.00   1.51   0.06   0.00   0.00   0.00   1.58   0.00   -0.00  20.00   0.00
 15:00    0.00     0.00   0.00   1.39   0.06   0.00   0.00   0.00   1.44   0.00    0.00  20.00   0.00
 15:15    0.00     0.00   0.00   1.31   0.05   0.00   0.00   0.00   1.36   0.00   -0.00  20.00   0.00
 15:30    0.00     0.00   0.00   1.24   0.05   0.00   0.00   0.00   1.29   0.00   -0.02  20.00   0.00
 15:45    0.00     0.00   0.00   1.12   0.05   0.00   0.00   0.00   1.17   0.00   -0.04  20.00   0.00
 16:00    0.00     0.00   0.00   0.97   0.05   0.00   0.00   0.00   1.01   0.00   -0.03  20.00   0.00
 16:15    0.00     0.00   0.00   0.85   0.05   0.00   0.00   0.00   0.90   0.00   -0.07  20.00   0.00
 16:30    0.00     0.00   0.00   0.73   0.05   0.00   0.00   0.00   0.78   0.00   -0.08  20.00   0.00
 16:45    0.00     0.00   0.00   0.61   0.07   0.00   0.00   0.00   0.68   0.00   -0.10  20.00   0.00
 17:00    0.00     0.00   0.00   0.48   0.11   0.00   0.00   0.00   0.59   0.00   -0.05  20.00   0.00
 17:15    0.00     0.00   0.00   0.36   0.13   0.00   0.00   0.00   0.50   0.00   -0.05  20.00   0.00
 17:30    0.00     0.00   0.00   0.24   0.15   0.00   0.00   0.00   0.40   0.00   -0.04  20.00   0.00
 17:45    0.00     0.00   0.00   0.17   0.14   0.00   0.00   0.00   0.31   0.00   -0.03  20.00   0.00
 18:00    0.00     0.00   0.00   0.12   0.09   0.00   0.00   0.00   0.20   0.00   -0.02  20.00   0.00
 18:15    0.00     0.29   0.00   0.33   0.07   0.00   0.00   0.00   0.11   0.00   -0.07  20.00   0.00
 18:30    0.00     0.03   0.00   0.00   0.05   0.00   0.00   0.00   0.02   0.00   -0.00  20.00   0.00
 18:45    0.00     0.23   0.00   0.18   0.05   0.00   0.00   0.00   0.00   0.00   -0.04  20.00   0.00
 19:00    0.00     0.29   0.00   0.25   0.07   0.00   0.00   0.00   0.03   0.00   -0.05  20.00   0.00
 19:15    0.00     0.29   0.00   0.22   0.07   0.00   0.00   0.00   0.01   0.00   -0.05  20.00   0.00
 19:30    0.00     0.07   0.00   0.00   0.07   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 19:45    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:00    0.00     0.29   0.00   0.23   0.06   0.00   0.00   0.00   0.00   0.00   -0.05  20.00   0.00
 20:15    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:45    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:00    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:15    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:45    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:00    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:15    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:30    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:45    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:00    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:15    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:30    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:45    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
Totaal    3.56     2.90   0.00  18.63   3.92   0.00   0.00   0.00  23.18   0.00   -0.80    NaN   0.00

2026-03-22 09:06:18 info: Consumption               0.00 (kWh)
2026-03-22 09:06:18 info: Cost consumption          0.00 (€)
2026-03-22 09:06:18 info: Tariff consumption        0.000 (€/kWh)
2026-03-22 09:06:18 info: Production               18.63 (kWh)
2026-03-22 09:06:18 info: Profit production        -0.80 (€)
2026-03-22 09:06:18 info: Tariff production         0.043 (€/kWh)

2026-03-22 09:06:18 info: 
Calculation profit after optimize in €
Cost before optimize             -0.06
Cost consumption      0.00
Cycle cost            0.19
Penalty cost          0.00
Battery storage       0.00
Boiler storage        0.00
Profit production    -0.80
Total                -0.61
Cost after optimize              -0.61
Profit:                           0.55
2026-03-22 09:06:18 info: Doorzetten van alle settings naar HA
2026-03-22 09:06:18 info: Laden van Kia Niro EV is niet ingepland
2026-03-22 09:06:18 info: Berekeningsuitkomst voor opladen van Kia Niro EV:
2026-03-22 09:06:18 info: - aantal ampere 0A (was 0.0A)
2026-03-22 09:06:18 info: - stand schakelaar 'off' (was 'off')
2026-03-22 09:06:18 info: - positie: home
2026-03-22 09:06:18 info: - ingeplugd: False
2026-03-22 09:06:18 info: Kia Niro EV is niet thuis of niet ingeplugd
2026-03-22 09:06:18 info: Evaluatie status laden Kia Niro EV op 2026-03-22 09:06
2026-03-22 09:06:18 info: - schakelaar laden: off
2026-03-22 09:06:18 info: - aantal ampere: 0.0
2026-03-22 09:06:18 info: Grid set point: -879.0 W
2026-03-22 09:06:18 info: Cycle cost Zinvolt: 0.19 euro
2026-03-22 09:06:18 info: Netto vermogen naar(+)/uit(-) omvormer Zinvolt: 0 W
2026-03-22 09:06:18 info: Balanceren: False
2026-03-22 09:06:18 info: Vermogen uit batterij: 0W
2026-03-22 09:06:18 info: Vermogen dat binnenkomt van pv: 0W
2026-03-22 09:06:18 info: Vermogen dat binnenkomt van ac: 0W
2026-03-22 09:06:18 info: Waarde SoC na eerste uur: 18.4%
2026-03-22 09:06:18 info: Apparaat: Airco
2026-03-22 09:06:18 info: Programma: Uit
2026-03-22 09:06:18 info: Apparaat: Afwasmachine
2026-03-22 09:06:18 info: Programma: Uit

[StarWing]

Ik zet m'n eerste stapjes met DAO, maar ik krijg onderstaande fout.
Het maakt geen verschil of ik al dan niet een datum invul:

code:

2026-03-22 11:05:40 info: Day Ahead Optimalisering versie: 2026.03.2
2026-03-22 11:05:40 info: Day Ahead Optimalisering gestart op: 22-03-2026 11:05:40
2026-03-22 11:05:40 info: Day Ahead Optimalisatie gestart: 22-03-2026 11:05:40 taak: get_day_ahead_prices
2026-03-22 11:05:40 fout: Geen data van Nordpool: tussen 2026-03-22 00:00:00+01:00 en 2026-03-23 00:00:00+01:00

Doe ik iets fout?

[Karpertje]

Ben er eens mee bezig geweest om dao op te zetten. Het enige wat ik mis is de voorspelling van de opbrengst van onze windmolen. Is dit op één of andere manier mogelijk?

[simnet]

Karpertje schreef op zondag 22 maart 2026 @ 11:31:
Ben er eens mee bezig geweest om dao op te zetten. Het enige wat ik mis is de voorspelling van de opbrengst van onze windmolen. Is dit op één of andere manier mogelijk?

Je zou deze eens kunnen proberen om hem op te voeren als solar en trainen met de ML modellen. Daar zit ook wind in verwerkt (als ik het goed heb). Dus zou dat voor jouw situatie moeten kunnen.

[simnet]

diamanten schreef op zondag 22 maart 2026 @ 09:10:
Goedemorgen,
Kan iemand uitleggen, waarom DAO na optimalisatie de produktie van mijn zonnepanelen niet meer meeneemt? En dus mijn thuisaccu gaat ontladen?
Volgens de Solar grafiek zijn er wel verwachten zonne-opbrensten.[Afbeelding]
[Afbeelding] [Afbeelding]
En de log:

[...]

Ik zie hetzelfde. Volgens mij komt dat omdat in die periode de kwh prijs negatief wordt als je niet (meer) kunt salderen.

[simnet]

simnet schreef op zondag 22 maart 2026 @ 12:11:
[...]

Ik zie hetzelfde. Volgens mij komt dat omdat in die periode de kwh prijs negatief wordt als je niet (meer) kunt salderen.

Yup, mijn zonnepanelen zijn zojuist (12:15) uitgeschakeld vanwege negatieve tarieven.

[rescla]

simnet schreef op zondag 22 maart 2026 @ 12:15:
[...]

Yup, mijn zonnepanelen zijn zojuist (12:15) uitgeschakeld vanwege negatieve tarieven.

is het in die situaties dan niet alsnog logisch om het overschot in de batterij op te slaan, ook al is de prijs niet laag genoeg om de batterij te laten laden?

[simnet]

rescla schreef op zondag 22 maart 2026 @ 13:02:
[...]

is het in die situaties dan niet alsnog logisch om het overschot in de batterij op te slaan, ook al is de prijs niet laag genoeg om de batterij te laten laden?

Opzich wel, maar ik kan mn zonnepanelen alleen aan of uit zetten. En op vol vermogen is dat 4,5kW.
Mijn batterij kan maximaal 2,5kW laden.
Als ik het vermogen van de panelen zou kunnen sturen (ben ik wel al mee bezig) dan kan ik inderdaad wel aangeven dat de panelen max 2,5kW moeten genereren. Maar zover ben ik nog niet.

[simnet]

simnet schreef op zondag 22 maart 2026 @ 13:12:
[...]

Opzich wel, maar ik kan mn zonnepanelen alleen aan of uit zetten. En op vol vermogen is dat 4,5kW.
Mijn batterij kan maximaal 2,5kW laden.
Als ik het vermogen van de panelen zou kunnen sturen (ben ik wel al mee bezig) dan kan ik inderdaad wel aangeven dat de panelen max 2,5kW moeten genereren. Maar zover ben ik nog niet.

Feature request voor DAO:
solar stages, vergelijkbaar met batterystages of evstages om de opwek te kunnen sturen.

[rescla]

simnet schreef op zondag 22 maart 2026 @ 13:13:
[...]


Feature request voor DAO:
solar stages, vergelijkbaar met batterystages of evstages om de opwek te kunnen sturen.

Of een toggle, voor export beperking. Dan kan je zelf realtime sturen op batterij laden, ev laden, extra verbruikers aanzetten, etc.

[simnet]

Ja, vanaf 2027 heb je eigenlijk 3 financiele situaties:

- stroom exporteren levert geld op en stroom importeren kost geld
- stroom importeren kost geld en stroom exporteren kost ook geld (0.0 > prijs < 0.12 inclusief belasting)
- stroom exporteren kost geld en stroom importeren levert geld op

Die middelste situatie is best lastig te modelleren.

[mgroen81]

Sinds een week heb ik naast de 3 gecombineerde Sessy's een 2e accusysteem werkend gekregen.
(Zoe battery 22kWh -> Battery Emulator -> Fronius Symo GEN24 10.0 plus)
Dit heeft eigenlijk bijna de hele week goed gewerkt in minimize cost modus maar er was ineens geen oplossing meer mogelijk.

Edit: probleem opgelost. Door het toevoegen van de accu kreeg ik negatieve waardes in de base load omdat ik nog niet alle entities had toegevoegd.

[ Voor 111% gewijzigd door mgroen81 op 23-03-2026 09:30 . Reden: Probleem gevonden ]

[mgroen81]

...

[ Voor 99% gewijzigd door mgroen81 op 23-03-2026 09:28 ]

[Karpertje]

simnet schreef op zondag 22 maart 2026 @ 12:04:
[...]

Je zou deze eens kunnen proberen om hem op te voeren als solar en trainen met de ML modellen. Daar zit ook wind in verwerkt (als ik het goed heb). Dus zou dat voor jouw situatie moeten kunnen.

dat gaat niet goed zie ik net, hij houdt dan ook rekening met de zon, dan zou die windmolen morgen als de zon schijnt alleen maar draaien.
Het ML model zou in dit geval alleen rekening moeten houden met de wind, geen zon.
Heeft iemand een oplossing voor ML model met alleen wind?

[ Voor 5% gewijzigd door Karpertje op 23-03-2026 08:08 ]

[f.welvering]

Nadat ik vanmorgen de update heb gewaagd naar versie 2026.03.3.rc3
Kreeg ik ineens onderstaande melding, blijkbaar is de stages key nu verplicht ondanks dat ik met aan/uit werk?
Daarnaast moet er vervolgens zoals je in de 2e error ziet tenminste 1 stage in staan.
Ik neem aan dat de stages bij on/off niet gebruikt worden?

code:

2026-03-23 07:32:52 INFO: Configuration needs migration from unversioned to v0
dao  | 2026-03-23 07:32:52 INFO: Saved backup configuration to ../data/options_unversioned.json
dao  | 2026-03-23 07:32:52 INFO: Migrating unversioned configuration to v0
dao  | 2026-03-23 07:32:52 INFO: Added config_version=0 to unversioned configuration
dao  | 2026-03-23 07:32:52 INFO: Migrated scheduler: active=True, 16 schedule entries
dao  | 2026-03-23 07:32:52 INFO: Configuration at version 0
dao  | Error loading configuration: 1 validation error for ConfigurationV0
dao  | heating.stages
dao  |   Field required [type=missing, input_value={'heater present': 'True'...ut_number.dao_wp_power'}, input_type=dict]
dao  |     For further information visit https://errors.pydantic.dev/2.10/v/missing
dao  | check_db.py failed, exiting

code:

2026-03-23 07:55:43 INFO: Configuration needs migration from unversioned to v0
dao  | 2026-03-23 07:55:43 INFO: Saved backup configuration to ../data/options_unversioned.json
dao  | 2026-03-23 07:55:43 INFO: Migrating unversioned configuration to v0
dao  | 2026-03-23 07:55:43 INFO: Added config_version=0 to unversioned configuration
dao  | 2026-03-23 07:55:43 INFO: Migrated scheduler: active=True, 16 schedule entries
dao  | 2026-03-23 07:55:43 INFO: Configuration at version 0
dao  | Error loading configuration: 1 validation error for ConfigurationV0
dao  | heating.stages
dao  |   List should have at least 1 item after validation, not 0 [type=too_short, input_value=[], input_type=list]
dao  |     For further information visit https://errors.pydantic.dev/2.10/v/too_short
dao  | check_db.py failed, exiting

[simnet]

f.welvering schreef op maandag 23 maart 2026 @ 08:03:
Nadat ik vanmorgen de update heb gewaagd naar versie 2026.03.3.rc3
Kreeg ik ineens onderstaande melding, blijkbaar is de stages key nu verplicht ondanks dat ik met aan/uit werk?
Daarnaast moet er vervolgens zoals je in de 2e error ziet tenminste 1 stage in staan.
Ik neem aan dat de stages bij on/off niet gebruikt worden?


[...]


[...]

Dat is een mooie vondst. Gaan we meenemen. De 2e error is zeker correct. Maar stages zouden optioneel moeten zijn als on/off gebruikt wordt.

[simnet]

Karpertje schreef op zondag 22 maart 2026 @ 20:47:
[...]


dat gaat niet goed zie ik net, hij houdt dan ook rekening met de zon, dan zou die windmolen morgen als de zon schijnt alleen maar draaien.
Het ML model zou in dit geval alleen rekening moeten houden met de wind, geen zon.
Heeft iemand een oplossing voor ML model met alleen wind?

Dat is jammer. Ik geloof dat er recent inderdaad een wijziging in de dataverwerking is gedaan die alles negeert als er geen zon voorspeld id. Je zou eigenlijk eens een versie van daarvoor moeten proberen, want ik zie niet in waarom het model niet ook geschikt zou zijn voor wind.
Mogelijk een feature request voor @KC27 om die optie toe te voegen.

[diamanten]

simnet schreef op zondag 22 maart 2026 @ 12:11:
[...]

Ik zie hetzelfde. Volgens mij komt dat omdat in die periode de kwh prijs negatief wordt als je niet (meer) kunt salderen.

OK dank, weer wat geleerd .

[DaBit]

simnet schreef op zondag 22 maart 2026 @ 13:13:
Feature request voor DAO:
solar stages, vergelijkbaar met batterystages of evstages om de opwek te kunnen sturen.

Ik heb daar ook over zitten denken, maar het lijkt me handiger om dat buiten DAO om te regelen als DAO om 0-op-meter vraagt?

[simnet]

DaBit schreef op maandag 23 maart 2026 @ 09:55:
[...]


Ik heb daar ook over zitten denken, maar het lijkt me handiger om dat buiten DAO om te regelen als DAO om 0-op-meter vraagt?

Dat kan ook inderdaad. Maar op dit moment vraagt DAO voor NoM per batterij.
Eigenlijk moet dat verplaatst worden naar de grid aansluiting.
Want ik zie het gebeuren dat V2H ook tractie gaat krijgen en/of windmolens zoals een andere gebruiker. Dan moet je NoM aansturen per grid en de onderlinge devices (dmv charge/discharge stages) sturen vanuit DAO.

Overigens zie ik NoM per tijdseenheid (kwartier of uur) en niet persee realtime. Dat laatste vind ik de verantwoordelijkheid van de huis installatie en niet van DAO.

[Joos74]

Bij ons draait DAO ook mooi, maar ik zie wel regelmatig 'Internal Server Error's langskomen. Die zie ik altijd als ik op 'Reports' klik, en vaak (maar niet altijd) als ik in het menu op 'Solar' klik. Ook schiet ik nog wel eens terug naar een menu waar het item 'Solar' helemaal niet meer in aanwezig is. Iemand enig idee hoe dit komt?

Dit is wat ik (oa) zie in de logging:

code:

[2026-03-23 10:25:06,651] fout in app: Exception on / [POST]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 320, in menu
    return solar()
  File "/root/dao/webserver/app/routes.py", line 652, in solar
    menu_dict = web_menu["solar"]
                ~~~~~~~~^^^^^^^^^
KeyError: 'solar'

[Mirabis]

in theorie - zal ik er voordeel van hebben als ik DAO laat detecteren wanneer EVCC het laden van de auto start? In principe zijn ze beide al in staat om entiteiten uit te lezen dan wel naar te schrijven in Homeassistant. Ik gebruik namelijk EVCC voor het schedulen en load balancen van mijn laadpaal en laat dat buiten DAO doen. Ik heb de laadpaal entities wel meegenomen voor tracking maar schedule verder niks. De batterij heeft slechts ~5kWh terwijl de auto accu 98/103kWh is...

Heb de nieuwe beta's nog niet getest want 2026.03.3.rc1 draait uitermate stabiel voor mij momenteel .

[balk]

simnet schreef op zondag 22 maart 2026 @ 14:04:
Ja, vanaf 2027 heb je eigenlijk 3 financiele situaties:

- stroom exporteren levert geld op en stroom importeren kost geld
- stroom importeren kost geld en stroom exporteren kost ook geld (0.0 > prijs < 0.12 inclusief belasting)
- stroom exporteren kost geld en stroom importeren levert geld op

Die middelste situatie is best lastig te modelleren.

Ik heb dat even in een grafiekje gezet. Dit is voor Tibber, tarieven zoals vandaag. Onder de 2 cent kale prijs moet je dus gaan betalen voor terugleveren (immers: 0 icm de terugleverboete die Tibber sinds dit jaar heeft). Onder de -12 cent krijg je betaald voor inkoop. Beiden zijn toch goed te berekenen omdat het tarief vast staat per kwartier?

Dus onder de 16 cent consument-consumptie tarief ga je moeten betalen voor teruglevering.

[ Voor 12% gewijzigd door balk op 23-03-2026 13:28 . Reden: grafiek nog iets verbeterd ]

[simnet]

balk schreef op maandag 23 maart 2026 @ 13:16:
[...]
Beiden zijn toch goed te berekenen omdat het tarief vast staat per kwartier?

Berekenen, zeker. Maar DAO laten modelleren welk device hoeveel moet produceren / gebruiken is best lastig in deze situatie, aangezien je wil sturen op NoM voor je grid aansluiting.

Op dit moment rekent DAO er alleen op dat een batterij NoM kan houden, maar dat kun je ook doen door je productie te limiteren (Enphase kan bijvoorbeeld ook NoM draaien door de productie van de zonnepanelen te regelen a.d.h.v. CT klemmen op de hoofdaansluiting).

De moeilijkheid komt er bij welk apparaat moet laden en/of ontladen en welke moet nu NoM gaan houden.
Als ik nu de batterij op NoM zet en mijn enphase installatie ook, dan zullen ze onderling constant in gevecht zijn en dat wil je natuurlijk voorkomen.
Op dit moment is DAO zich niet bewust van devices anders dan een batterij die NoM kunnen. Maar dat kan best veranderen als V2H echt bruikbaar wordt of als je zonnepanelen opwek kan laten regelen (of wind opwek dmv een shunt load).

[balk]

simnet schreef op maandag 23 maart 2026 @ 13:27:
[...]


Berekenen, zeker. Maar DAO laten modelleren welk device hoeveel moet produceren / gebruiken is best lastig in deze situatie, aangezien je wil sturen op NoM voor je grid aansluiting.

Op dit moment rekent DAO er alleen op dat een batterij NoM kan houden, maar dat kun je ook doen door je productie te limiteren (Enphase kan bijvoorbeeld ook NoM draaien door de productie van de zonnepanelen te regelen a.d.h.v. CT klemmen op de hoofdaansluiting).

De moeilijkheid komt er bij welk apparaat moet laden en/of ontladen en welke moet nu NoM gaan houden.
Als ik nu de batterij op NoM zet en mijn enphase installatie ook, dan zullen ze onderling constant in gevecht zijn en dat wil je natuurlijk voorkomen.
Op dit moment is DAO zich niet bewust van devices anders dan een batterij die NoM kunnen. Maar dat kan best veranderen als V2H echt bruikbaar wordt of als je zonnepanelen opwek kan laten regelen (of wind opwek dmv een shunt load).

Dat kan best een ingewikkelde optimalisatie zijn. Hoe groot is de fout als DAO ipv de batterij op NoM zou draaien, het hele huis op NoM zou draaien? En dat de gebruiker dat zelf kan invullen? Ik zou bijvoorbeeld bij maximale efficiency laden en dan de panelen terugschroeven. Maar dat kan HA beter dan DAO.

[Mirabis]

simnet schreef op maandag 23 maart 2026 @ 13:27:
[...]


Berekenen, zeker. Maar DAO laten modelleren welk device hoeveel moet produceren / gebruiken is best lastig in deze situatie, aangezien je wil sturen op NoM voor je grid aansluiting.

Op dit moment rekent DAO er alleen op dat een batterij NoM kan houden, maar dat kun je ook doen door je productie te limiteren (Enphase kan bijvoorbeeld ook NoM draaien door de productie van de zonnepanelen te regelen a.d.h.v. CT klemmen op de hoofdaansluiting).

De moeilijkheid komt er bij welk apparaat moet laden en/of ontladen en welke moet nu NoM gaan houden.
Als ik nu de batterij op NoM zet en mijn enphase installatie ook, dan zullen ze onderling constant in gevecht zijn en dat wil je natuurlijk voorkomen.
Op dit moment is DAO zich niet bewust van devices anders dan een batterij die NoM kunnen. Maar dat kan best veranderen als V2H echt bruikbaar wordt of als je zonnepanelen opwek kan laten regelen (of wind opwek dmv een shunt load).

Hmm misschien dat er een switch kan toegevoegd worden? Als de PV-installatie ook NoM kan, o.b.v. de toch al binnengehaalde zonproductie prognose beslissen of NoM op batterij ook ingeschakeld moet worden?

Ik heb bijv. zo een Growatt installatie met een inline meter die ook 'zero export' kan draaien. Nu heeft die een eigen "AI schedule" o.b.v. de dynamische prijs en modifiers. Ze weten mmenteel niks van elkaar.

[rescla]

Mirabis schreef op maandag 23 maart 2026 @ 13:43:
[...]

Hmm misschien dat er een switch kan toegevoegd worden? Als de PV-installatie ook NoM kan, o.b.v. de toch al binnengehaalde zonproductie prognose beslissen of NoM op batterij ook ingeschakeld moet worden?

Ik heb bijv. zo een Growatt installatie met een inline meter die ook 'zero export' kan draaien. Nu heeft die een eigen "AI schedule" o.b.v. de dynamische prijs en modifiers. Ze weten mmenteel niks van elkaar.

In mijn situatie zou het bij overcapaciteit zoiets zijn denk ik:

• Auto verantwoordelijk voor balancering, als de auto laad, en de beschikbare overcapaciteit groter is dan 6A * 230V * 3 (fase) = 4140W (realtime)
• Batterij verantwoordelijk voor balancering, als die niet 100% vol zit
• Solar inverter verantwoordelijk voor balancering

Het probleem/nadeel van DAO is dat die niet kan werken met realtime data, dus die kan wel ongeveer bepalen wat de verantwoordelijkheden zijn, maar die zou niet kunnen bepalen dat de auto moet stoppen met laden omdat het overschot minder is dan het minimale laadvermogen. Dus dat moet ik dan toch realtime aan gaan sturen vanuit HA.

Bij de balance switch ON zet ik nu gewoon mijn batterij in NOM modus, maar dat betekent ook dat als er wolken voor de zon komen en niet kunnen voorzien in het eigen vermogen, de batterij gaat ontladen om te compenseren. Maar het is niet helemaal zo simpel als een "beperk levering/opname", omdat de verliezen naar 'waardevolle energie' per apparaat verschillend zijn.

[balk]

Ik denk dat het heel moeilijk is om een harde, universele planning te maken met behulp van DAO. Voor de een betekent een kWh laden in de accu het meest, want nu laden betekent straks potentieel tegen beter tarief ontladen. Voor de ander kan het juist zijn dat de auto prioriteit heeft, want de waarde zit hem in de vrijheid "kunnen wegrijden wanneer je wil".

Wellicht kan de gebruiker een soort prioriteit meegeven aan DAO? Iets als:
if nom == true
then prio1 gebruiker maximaal laden, leftovers naar prio2 en eventueel prio3 etc
if prio1 == vol
then prio2 max laden etc

Solar panels zijn naar mijn inzicht de laatste in de rij. Indien geen laadcapaciteit beschikbaar en teruglevertarief <0 then terugmoduleren (indien kan), of uit. Indien op dat moment een wolkje langs komt zou je de accu niet aan moeten spreken.

Ik weet alleen niet of dit iets is wat we in DAO moeten willen of dat dit ieder voor zich is. Ik neig naar dat laatste. Laat DAO mij het seintje nom ja/nee geven en ik regel de rest zelf wel

[f.welvering]

simnet schreef op maandag 23 maart 2026 @ 08:20:
[...]


Dat is een mooie vondst. Gaan we meenemen. De 2e error is zeker correct. Maar stages zouden optioneel moeten zijn als on/off gebruikt wordt.

Ik merk ook dat de sensor voor de avg outside temp niet meer gevonden wordt, is daar iets aan veranderd?

code:

heating": {
    "heater_present": true,
    "degree_days_factor": 4.791,
    "adjustment": "on/off",
    "stages": [
      {
        "max_power": 0.0,
        "cop": 8.0
      },
      {
        "max_power": 225.0,
        "cop": 7.1
      }
    ],
"min_run_length": 1,
    "entity_heat_produced": "sensor.dewarmte_ao_a_232_heat_output_energy_daily",
    "entity_hp_heat_demand": "input_select.dao_wp_heat_demand",
    "entity_hp_cop": "input_number.dao_wp_cop",
    "entity_hp_power": "input_number.dao_wp_power",
    "entity_hp_switch": "input_boolean.dao_wp_on_off",
    "entity avg outside temp": "input_number.dao_wp_avg_outside"
  }

Melding

code:

-03-23 18:58:31 info: On/off warmtepomp wordt ingepland
2026-03-23 18:58:31 info: Gem. buitentemperatuur vandaag: 5.2 °C
2026-03-23 18:58:31 waarschuwing: Geen entity om gem. temperatuur te exporteren
2026-03-23 18:58:31 info: Voorspelde gemiddelde buiten temperatuur: 5.2 °C

[ Voor 35% gewijzigd door f.welvering op 23-03-2026 19:03 ]

[itavero]

itavero schreef op donderdag 19 maart 2026 @ 09:18:

Daar zie ik geen negatieve getallen. Sowieso vroeg ik mij af, aangezien ik de baseload laat genereren, zou daar niet een begrenzing op kunnen zitten (als er wel negatieve getallen zijn dat deze gelimiteerd worden tot 0 of op z'n minst anders worden weergegeven).


[...]

Ik zie nog steeds negatieve baseloads berekend worden. Enig idee hoe ik dit verder kan "debuggen"?

Relevant stukje configuratie

JSON:

{
  "report": {
    "entities grid consumption": [
      "sensor.sessy_pfuv_tariff_1_consumed_energy",
      "sensor.sessy_pfuv_tariff_2_consumed_energy"
    ],
    "entities grid production": [
      "sensor.sessy_pfuv_tariff_1_produced_energy",
      "sensor.sessy_pfuv_tariff_2_produced_energy"
    ],
    "entities solar production ac": ["sensor.envoy_122251081559_lifetime_energy_production"],
    "entities solar production dc": [],
    "entities ev consumption": ["sensor.peblar_ev_charger_levenslange_energie"],
    "entities machine consumption": ["sensor.power_dishwasher_energy", "sensor.power_scullery_laundry_energy"],
    "entities wp consumption": [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.sessy_df4k_charged_energy"],
    "entities battery production": ["sensor.sessy_df4k_discharged_energy"]
  }
}

Baseload berekening log

code:

2026-03-23 20:34:00 info: Day Ahead Optimalisering versie: 2026.03.2
2026-03-23 20:34:00 info: Day Ahead Optimalisering gestart op: 23-03-2026 20:34:00
2026-03-23 20:34:00 info: Day Ahead Optimalisatie gestart: 23-03-2026 20:34:00 taak: calc_baseloads
2026-03-23 20:34:10 info: baseload voor weekdag 0 :
2026-03-23 20:34:10 info: 0.46 0.442 0.474 0.493 0.465 0.499 0.545 0.271 -1.219 -2.349 -2.442 -2.332 -2.902 -2.929 -2.41 -1.345 -0.159 1.182 0.576 0.638 0.538 0.506 0.439 0.419 
2026-03-23 20:34:20 info: baseload voor weekdag 1 :
2026-03-23 20:34:20 info: 0.445 0.419 0.435 0.429 0.428 0.445 0.474 0.489 0.335 0.111 -0.184 -0.372 -1.356 -2.815 -1.712 -1.155 -0.32 0.811 0.668 0.405 0.657 0.568 0.438 0.432 
2026-03-23 20:34:31 info: baseload voor weekdag 2 :
2026-03-23 20:34:31 info: 0.425 0.415 0.43 0.44 0.35 0.452 0.563 0.182 -1.599 -3.088 -3.562 -3.544 -3.559 -3.374 -2.566 -1.647 -0.55 0.857 0.688 0.466 0.538 0.516 0.446 0.445 
2026-03-23 20:34:44 info: baseload voor weekdag 3 :
2026-03-23 20:34:44 info: 0.45 0.446 0.375 0.43 0.392 0.425 0.5 0.15 -1.325 -2.697 -3.365 -3.535 -3.551 -3.301 -2.531 -1.616 -0.527 0.572 0.543 0.49 0.512 0.606 0.428 0.392 
2026-03-23 20:34:54 info: baseload voor weekdag 4 :
2026-03-23 20:34:54 info: 0.411 0.38 0.405 0.412 0.398 0.419 0.437 0.294 -0.835 -1.763 -2.853 -3.372 -3.501 -3.062 -2.456 -1.519 -0.567 0.958 0.504 0.469 0.502 0.464 0.406 0.4 
2026-03-23 20:35:04 info: baseload voor weekdag 5 :
2026-03-23 20:35:04 info: 0.407 0.4 0.396 0.415 0.401 0.423 0.535 0.983 0.618 0.327 -0.54 -2.222 -3.121 -3.143 -2.509 -1.466 -0.36 1.38 0.539 0.552 0.441 0.433 0.375 0.395 
2026-03-23 20:35:15 info: baseload voor weekdag 6 :
2026-03-23 20:35:15 info: 0.401 0.42 0.406 0.413 0.401 0.424 1.049 0.212 -1.363 -2.733 -3.462 -3.53 -3.538 -3.301 -2.427 -1.422 -0.545 0.277 0.75 0.374 0.633 0.408 0.356 0.39

[ Voor 16% gewijzigd door itavero op 23-03-2026 20:45 . Reden: Reports config toegevoegd ]

[itavero]

simnet schreef op maandag 23 maart 2026 @ 13:27:
[...]

Op dit moment rekent DAO er alleen op dat een batterij NoM kan houden, maar dat kun je ook doen door je productie te limiteren (Enphase kan bijvoorbeeld ook NoM draaien door de productie van de zonnepanelen te regelen a.d.h.v. CT klemmen op de hoofdaansluiting).

[...]

Daar mis ik ook nog een nuance in (batterij NoM), maar wellicht komt dat ook door gebrek aan kennis.
Is NoM altijd om teruglevering te voorkomen momenteel, of kan het ook zijn om afname te voorkomen?
Als het voor beide situatie geld, zou het handig zijn om dat afzonderlijk te rapporteren.

Anders zou je in de situatie kunnen komen dat stroom heel goedkoop is, maar je verbruik gaat compenseren als er plots toch een dip in je PV opbrengst zit.
Die energie zou ik dan liever voor een duurder moment bewaren.

Overigens, enig idee hoe ik dat op mijn Enphase Envoy Metered-S configureer en inschakel (de NoM stand)?

[KC27]

DaBit schreef op maandag 23 maart 2026 @ 09:55:
[...]


Ik heb daar ook over zitten denken, maar het lijkt me handiger om dat buiten DAO om te regelen als DAO om 0-op-meter vraagt?

Niet helemaal want DAO rekent met de aangeboden mogelijkheden. Ik heb zelf twee SolarEdge omvormers die ik beide door HA kan laten regelen tussen 0 en 100%. Ik neem aan dat dat bij meer pv- omvormers kan. Het lijkt me goed dat we dat als regel optie kunnen instellen zodat DAO daar mee kan rekenen. Dan kan HA met die uitkomst gaan regelen.

[Torch1969]

itavero schreef op maandag 23 maart 2026 @ 20:43:
[...]


Ik zie nog steeds negatieve baseloads berekend worden. Enig idee hoe ik dit verder kan "debuggen"?


[...]


[...]

Kijk of er (grote) verbruikers (of leveranciers) van energie zijn die niet niet heel periodiek rapporteren en dan net ná het uur rapporteren. Bijvoorbeeld een laadpaal die eens per 15 minuten rapporteert (en dat waarschijnlijk net steeds een paar seconden na dat kwartier doet). De p1 meter ziet het verbruik “meteen”, maar de bijbehorende verbruiker komt dan in het volgende uur. Dit levert een verbruik op dat out of sync is qua uur.

[!null]

Zijn er mensen die DAO gebruiken voor enkel inkoop en verkoop handelen?
Zal vanaf 1 Januari niet interessant meer zijn, en straks heb ik ook het huis verbruik op het systeem.
Maar tot die tijd, vraag ik me af of het nuttig is DAO voor alleen dit doel te gebruiken, of toch iets anders, eventueel eigen script. En dan later, met huisconsumptie erop, DAO gebruiken.
Gaat bij om 80kWh met 12 tot 14kW laden/ontladen

[KC27]

itavero schreef op maandag 23 maart 2026 @ 20:43:
[...]


Ik zie nog steeds negatieve baseloads berekend worden. Enig idee hoe ik dit verder kan "debuggen"?


[...]


[...]

Aangezien de negatieve getallen overdag plaatsvinden zou ik het probleem toch zoeken in de pv productie.
Als je nu kijkt met reports/balans naar de opwekking van gisteren. In hoeverre klopt die met de opwekking zoals gerapporteerd in het energie-dashboard van HA?
Ik zie zelfs dat als je sommeert per dag dat je nog negatief uitkomt.
In welke eenheden rapporteert "sensor.envoy_122251081559_lifetime_energy_production"?

[simnet]

KC27 schreef op maandag 23 maart 2026 @ 21:44:
[...]

Niet helemaal want DAO rekent met de aangeboden mogelijkheden. Ik heb zelf twee SolarEdge omvormers die ik beide door HA kan laten regelen tussen 0 en 100%. Ik neem aan dat dat bij meer pv- omvormers kan. Het lijkt me goed dat we dat als regel optie kunnen instellen zodat DAO daar mee kan rekenen. Dan kan HA met die uitkomst gaan regelen.

Ik weet dat enphase maximaal 16 verschillende teruglever percentages aankan (in het geval van production limiting, waarbij je er al 2 kwijt bent voor 0 en 100). Dus wellicht is het gebruik van stages dan beter?
Of DAO geeft het te leveren vermogen door en dan kan HA dat omrekenen naar het juiste percentage, afhankelijk van de mogelijkheden van je omvormer.

[simnet]

itavero schreef op maandag 23 maart 2026 @ 20:55:
[...]


Daar mis ik ook nog een nuance in (batterij NoM), maar wellicht komt dat ook door gebrek aan kennis.
Is NoM altijd om teruglevering te voorkomen momenteel, of kan het ook zijn om afname te voorkomen?
Als het voor beide situatie geld, zou het handig zijn om dat afzonderlijk te rapporteren.

Anders zou je in de situatie kunnen komen dat stroom heel goedkoop is, maar je verbruik gaat compenseren als er plots toch een dip in je PV opbrengst zit.
Die energie zou ik dan liever voor een duurder moment bewaren.

Overigens, enig idee hoe ik dat op mijn Enphase Envoy Metered-S configureer en inschakel (de NoM stand)?

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

[ Voor 9% gewijzigd door simnet op 24-03-2026 00:25 ]

[Karpertje]

simnet schreef op maandag 23 maart 2026 @ 08:33:
[...]

Dat is jammer. Ik geloof dat er recent inderdaad een wijziging in de dataverwerking is gedaan die alles negeert als er geen zon voorspeld id. Je zou eigenlijk eens een versie van daarvoor moeten proberen, want ik zie niet in waarom het model niet ook geschikt zou zijn voor wind.
Mogelijk een feature request voor @KC27 om die optie toe te voegen.

Dit zou inderdaad een mooie feature zijn in DAO om alleen een ML model te laten rekenen met wind. Zou in mijn optiek nog makkelijker zijn dan rekening houden met zon e.d., maar ik ben geen programmeur haha. Hoe sta je hier voor in @KC27 om deze feature toe te voegen? Zou voor mij in ieder geval een hele uitkomst zijn

[simnet]

simnet schreef op dinsdag 24 maart 2026 @ 00:03:
[...]

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

Aansluitschema: https://support.enphase.c...contentId=05TPs00000H7oIH

En een artikeltje: https://degroenenerds.nl/...-cloud-of-home-assistant/

[ Voor 7% gewijzigd door simnet op 24-03-2026 08:46 ]

[DaBit]

Niet helemaal want DAO rekent met de aangeboden mogelijkheden. Ik heb zelf twee SolarEdge omvormers die ik beide door HA kan laten regelen tussen 0 en 100%. Ik neem aan dat dat bij meer pv- omvormers kan.

Ja, ik kan die van mij (een Growatt MOD7000TL-X en een zestal Hoymiles micro-omvormers) ook tussen de 0-100% regelen. Momenteel gebruik ik alleen de 100% en 0% stand.

Kwa 'vechten' van apparaten: voordat ik DAO+dynamisch contract implementeerde regelde ik de vermogens van apparaten met simpele PI-regelaars waarvan ik de I-term verreweg de meeste bijdrage liet leveren.
In de basis 'boiler_power=boiler_power + boiler_I * P_netaansluiting' en idem voor de auto e.d.
De onderlinge belangrijkheid van apparaten word dan geregeld door de magnitude van boiler_P/boiler_I tov auto_P/auto_I.

Dat ging niet vechten en regelde heel mooi nul-op-meter.

Iets dergelijks zou met DAO ook wel kunnen. DAO kan per apparaat een basisvermogen opgeven plus een NoM-switch zoals dat nu voor de batterij ook al gebeurt. Als de NoM-switch aanstaat kan de achterliggende automatie/logica desgewenst het basisvermogen wat omhoog/omlaag regelen om die NoM te bereiken.

In feite kan ik dit al prima implementeren met de batt balance switch in de huidige DAO, maar per device geeft DAO onder andere de mogelijkheid om de accu niet te gaan ontladen als er een streepje wolk langs komt gedreven.

[rescla]

DaBit schreef op dinsdag 24 maart 2026 @ 08:30:
[...]


Ja, ik kan die van mij (een Growatt MOD7000TL-X en een zestal Hoymiles micro-omvormers) ook tussen de 0-100% regelen. Momenteel gebruik ik alleen de 100% en 0% stand.

Kwa 'vechten' van apparaten: voordat ik DAO+dynamisch contract implementeerde regelde ik de vermogens van apparaten met simpele PI-regelaars waarvan ik de I-term verreweg de meeste bijdrage liet leveren.
In de basis 'boiler_power=boiler_power + boiler_I * P_netaansluiting' en idem voor de auto e.d.
De onderlinge belangrijkheid van apparaten word dan geregeld door de magnitude van boiler_P/boiler_I tov auto_P/auto_I.

Dat ging niet vechten en regelde heel mooi nul-op-meter.

Iets dergelijks zou met DAO ook wel kunnen. DAO kan per apparaat een basisvermogen opgeven plus een NoM-switch zoals dat nu voor de batterij ook al gebeurt. Als de NoM-switch aanstaat kan de achterliggende automatie/logica desgewenst het basisvermogen wat omhoog/omlaag regelen om die NoM te bereiken.

In feite kan ik dit al prima implementeren met de batt balance switch in de huidige DAO, maar per device geeft DAO onder andere de mogelijkheid om de accu niet te gaan ontladen als er een streepje wolk langs komt gedreven.

Om nog even een duit in het zakje te doen mbt omvormers, ik kan die van mij (Huawei) regelen op maximaal output vermogen in W. Ik moet zelf daar nog een keer een NOM regeling voor maken.

[KC27]

Karpertje schreef op dinsdag 24 maart 2026 @ 07:43:
[...]


Dit zou inderdaad een mooie feature zijn in DAO om alleen een ML model te laten rekenen met wind. Zou in mijn optiek nog makkelijker zijn dan rekening houden met zon e.d., maar ik ben geen programmeur haha. Hoe sta je hier voor in @KC27 om deze feature toe te voegen? Zou voor mij in ieder geval een hele uitkomst zijn

In eerste instantie (toen @simnet de pv-predictor voor DAO bouwde) zat windsnelheid en neerslag er nog bij als verklarende feature, maar die bleken niet significant (minder dan 0,5 %) bij te dragen aan de verklaring van de pv-productie (wat je ook wel kan verwachten). En dus heb ik die twee "er uit gesloopt".
Helaas. Met de kennis van nu zou ik windsnelheid erin gelaten hebben.
Ik ga kijken of ik windsnelheid alsnog nog toevoegen.

[simnet]

KC27 schreef op dinsdag 24 maart 2026 @ 08:52:
Ik ga kijken of ik windsnelheid alsnog nog toevoegen.

Wellicht een goed moment om ook te kijken naar de outlier detectie. Als ik het me goed herinner zat daar ook een physics gebaseerde detectie van PV in.

En wind kan een koelend effect hebben op hete momenten, vandaar dat die er in eerste instantie in zat.

[ Voor 14% gewijzigd door simnet op 24-03-2026 09:00 ]

[Karpertje]

KC27 schreef op dinsdag 24 maart 2026 @ 08:52:
[...]

In eerste instantie (toen @simnet de pv-predictor voor DAO bouwde) zat windsnelheid en neerslag er nog bij als verklarende feature, maar die bleken niet significant (minder dan 0,5 %) bij te dragen aan de verklaring van de pv-productie (wat je ook wel kan verwachten). En dus heb ik die twee "er uit gesloopt".
Helaas. Met de kennis van nu zou ik windsnelheid erin gelaten hebben.
Ik ga kijken of ik windsnelheid alsnog nog toevoegen.

Dat zou top zijn als windsnelheid alsnog toegevoegd wordt. Ik zit alleen wel met het punt dat het model anders misschien ook windenergie gaat berekenen op momenten dat het gewoon windstil is en alleen de zon schijnt. Daarom zou het mooi zijn als je in het ML-model ook alleen wind apart kunt selecteren.

[simnet]

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


Dat zou top zijn als windsnelheid alsnog toegevoegd wordt. Ik zit alleen wel met het punt dat het model anders misschien ook windenergie gaat berekenen op momenten dat het gewoon windstil is en alleen de zon schijnt. Daarom zou het mooi zijn als je in het ML-model ook alleen wind apart kunt selecteren.

Dat zou niet mogen. In jouw geval heeft zonlicht geen invloed op de windopwek. Dus zou die als feature insignificant worden (nets als dat windsnelheid insignificant is voor PV).
Het enige wat ik vooraf niet kan beoordelen is of het model rekening houdt met een minimale windsnelheid. Ik vermoed van wel, xgboost is slim genoeg.

[BBuilds]

Sinds de prijzen van vanmiddag gepubliceerd zijn kan DAO geen oplossing vinden.
Geeft het na 0.01 sec rekentijd ook op met rekenen.

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

Config
Log berekening met debug

Iemand die hier nog tegenaan loopt?

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

[Karpertje]

simnet schreef op dinsdag 24 maart 2026 @ 13:33:
[...]

Dat zou niet mogen. In jouw geval heeft zonlicht geen invloed op de windopwek. Dus zou die als feature insignificant worden (nets als dat windsnelheid insignificant is voor PV).
Het enige wat ik vooraf niet kan beoordelen is of het model rekening houdt met een minimale windsnelheid. Ik vermoed van wel, xgboost is slim genoeg.

Helder. Dan ben ik wel benieuwd hoe dat in het model precies berekend wordt. Vooral of het model echt leert dat bij lage of vrijwel nul windsnelheid de windopwek ook naar nul gaat, en niet via historische samenhang met zonnige dagen toch nog iets blijft voorspellen.

[itavero]

simnet schreef op dinsdag 24 maart 2026 @ 00:03:
[...]

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

Die spoelen heb ik en heb ook al een relais om ze helemaal uit te zetten (via de DRM0 interface).
Binnenkort eens in duiken hoe ik dat verder kan inregelen.

[itavero]

Torch1969 schreef op maandag 23 maart 2026 @ 21:47:
[...]

Kijk of er (grote) verbruikers (of leveranciers) van energie zijn die niet niet heel periodiek rapporteren en dan net ná het uur rapporteren. Bijvoorbeeld een laadpaal die eens per 15 minuten rapporteert (en dat waarschijnlijk net steeds een paar seconden na dat kwartier doet). De p1 meter ziet het verbruik “meteen”, maar de bijbehorende verbruiker komt dan in het volgende uur. Dit levert een verbruik op dat out of sync is qua uur.

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

KC27 schreef op maandag 23 maart 2026 @ 23:27:
[...]

Aangezien de negatieve getallen overdag plaatsvinden zou ik het probleem toch zoeken in de pv productie.
Als je nu kijkt met reports/balans naar de opwekking van gisteren. In hoeverre klopt die met de opwekking zoals gerapporteerd in het energie-dashboard van HA?
Ik zie zelfs dat als je sommeert per dag dat je nog negatief uitkomt.
In welke eenheden rapporteert "sensor.envoy_122251081559_lifetime_energy_production"?

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

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

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

[Noshi]

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

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

Config
Log berekening met debug

Iemand die hier nog tegenaan loopt?

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

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

[KC27]

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


Dat zou top zijn als windsnelheid alsnog toegevoegd wordt. Ik zit alleen wel met het punt dat het model anders misschien ook windenergie gaat berekenen op momenten dat het gewoon windstil is en alleen de zon schijnt. Daarom zou het mooi zijn als je in het ML-model ook alleen wind apart kunt selecteren.

Daar hoef je niet bang voor te zijn. Tijdens de training van het model worden de variabelen die geen invloed hebben op de uitkomst vanzelf uitgerangeerd. Dat is juist het mooie van dit soort ml-technieken.

[BBuilds]

Noshi schreef op dinsdag 24 maart 2026 @ 14:55:
[...]

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

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

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

[rescla]

BBuilds schreef op dinsdag 24 maart 2026 @ 16:06:
[...]


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

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

Je zou kunnen proberen om je DC solar er even uit te halen? En anders de EVs tijdelijk even verwijderen, kijken of hij dan een oplossing kan maken. Dat geeft misschien wat inzicht.

[Voogel]

code:

2026-03-24 16:00:07 fout: Fout bij schrijven naar input_number.alg001124080565_instantaneous_battery_soc, waarde 100.0
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 64, in <module>
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 60, in main
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 48, in scheduler
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 739, in run_task_function
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 583, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/day_ahead.py, line 4170, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 485, in set_entity_value
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 235, in set_value
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/states.py, line 15, in get_state
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 54, in _get
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 90, in _process_response
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 95, in _raise_error
2026-03-24 16:00:07 fout: Onverwachte fout: 404 status code returned from http://supervisor/core/api/states/input_number.alg001124080565_instantaneous_battery_soc

DAO wil graag data scrijven naar het SOC percentage, maar die data komt van mn batterij integratie... alles werkt verder overigens prima.

[Torch1969]

itavero schreef op dinsdag 24 maart 2026 @ 14:23:
[...]


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


[...]


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

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

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

Met fijnmazig bedoel ik een p1 meter die per 5 of 10 seconden rapporteert, of ct-klemmen per seconde. 5 minuten levert geen grote afwijkingen, maar het verbruik van minuut 55 tot 00 komt binnen op of na 00 en dus in het volgende uur.

[KC27]

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

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

Config
Log berekening met debug

Iemand die hier nog tegenaan loopt?

Ik denk het probleem gevonden te hebben (maar ik weet het niet zeker):

• Je hebt je PV DC-gekoppeld aan je batterij dus alle opwekking gaat naar de DC-bar
• Je hebt geen schakelaar/regelaar in de MPPT-regelaar (of niet ingevuld) die de PV productie op de DC-bar beperkt
• Je kunt niet meer salderen (althans salderen staat uit)
• Er zijn vanmiddag, vannachr en morgen veel uren met lage negatieve tarieven (buiten de piek-uren) en in die uren gaat terugleveren geld kosten

Mogelijke consequentie: het systeem krijgt teveel energie binnen en kan het niet kwijt op het grid.
Ik weet het niet zeker maar je zou het kunnen oplossen door (voor de test) die "entity pv switch": wel in te vullen met een input_boolean en dan kijken of er wel een oplossing uit rolt.
Ik ben benieuwd.

[KC27]

Voogel schreef op dinsdag 24 maart 2026 @ 16:37:

code:

2026-03-24 16:00:07 fout: Fout bij schrijven naar input_number.alg001124080565_instantaneous_battery_soc, waarde 100.0
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 64, in <module>
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 60, in main
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_scheduler.py, line 48, in scheduler
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 739, in run_task_function
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 583, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/day_ahead.py, line 4170, in calc_optimum
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 485, in set_entity_value
2026-03-24 16:00:07 fout: File: /root/dao/prog/da_base.py, line 235, in set_value
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/states.py, line 15, in get_state
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 54, in _get
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 90, in _process_response
2026-03-24 16:00:07 fout: File: /root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py, line 95, in _raise_error
2026-03-24 16:00:07 fout: Onverwachte fout: 404 status code returned from http://supervisor/core/api/states/input_number.alg001124080565_instantaneous_battery_soc

DAO wil graag data scrijven naar het SOC percentage, maar die data komt van mn batterij integratie... alles werkt verder overigens prima.

Dan moet je de regel met "entity calculated soc" uit je configuratie verwijderen of daar een input_number in zetten die nergens anders voor wordt gebruikt. Dit is de berekende SoC aan het einde van het interval.

[KC27]

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

[Karpertje]

KC27 schreef op dinsdag 24 maart 2026 @ 15:01:
[...]

Daar hoef je niet bang voor te zijn. Tijdens de training van het model worden de variabelen die geen invloed hebben op de uitkomst vanzelf uitgerangeerd. Dat is juist het mooie van dit soort ml-technieken.

Ah dat is mooi dat dit blijkbaar zo goed ingeregeld kan worden. Dan ben ik zeker benieuwd naar de uitkomst.

[itavero]

Torch1969 schreef op dinsdag 24 maart 2026 @ 21:43:
[...]

Met fijnmazig bedoel ik een p1 meter die per 5 of 10 seconden rapporteert, of ct-klemmen per seconde. 5 minuten levert geen grote afwijkingen, maar het verbruik van minuut 55 tot 00 komt binnen op of na 00 en dus in het volgende uur.

Als ik bij geschiedenis kijk zie ik bij de Sessy apparaten (batterij + P1 meter) dat deze elke 5 seconden uitgelezen worden.
De Peblar laadpaal elke 10 seconden.
De Enphase Envoy sensor update elke minuut.
Dat lijkt mij allemaal redelijk dicht bij elkaar en op de 15 minuten niet zo'n grote verschillen op te leveren.

Helaas nog geen tijd gehad om alle rauwe data eens te analyseren. Daar kom ik nog op terug.

[KC27]

Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.

Breaking change

The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:

• Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
• Then install the new release (or when you allready have installed restart the addon/app)
• Look in the logging off the app/addon if you see errors during the conversion.

Most important changes in the config/options.json:<br>

• all booleans are now noted as true or false: no "True" or "False" anymore.
• changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
• removed "show_graph" from settings
• implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
• (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"

These errors are fixed:

• defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
• default for ev "entity stop charging" (none)
• boiler activate service must have a value if boiler activate entity is set
• removed the requirement off stages from heating when adjustement is on/off
• when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
• if scheduler active = true is not present it will be set to true

[balk]

KC27 schreef op woensdag 25 maart 2026 @ 19:06:
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.

Breaking change

The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:

• Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
• Then install the new release (or when you allready have installed restart the addon/app)
• Look in the logging off the app/addon if you see errors during the conversion.

Most important changes in the config/options.json:<br>

• all booleans are now noted as true or false: no "True" or "False" anymore.
• changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
• removed "show_graph" from settings
• implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
• (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"

These errors are fixed:

• defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
• default for ev "entity stop charging" (none)
• boiler activate service must have a value if boiler activate entity is set
• removed the requirement off stages from heating when adjustement is on/off
• when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
• if scheduler active = true is not present it will be set to true

Ik krijg deze fout:

code:

2026-03-25 19:49:52 debug: query get column data da:
 SELECT strftime(?, datetime(prognoses.time, ?, ?)) AS uur, prognoses.time AS time, prognoses.time AS utc, prognoses.value AS value 
FROM prognoses, variabel 
WHERE variabel.code = ? AND prognoses.variabel = variabel.id AND prognoses.time >= strftime(?, ?, ?) AND prognoses.time < strftime(?, ?, ?) ORDER BY time
2026-03-25 19:49:52 debug: query get column data da:
 SELECT strftime(?, datetime(prognoses.time, ?, ?)) AS uur, prognoses.time AS time, prognoses.time AS utc, prognoses.value AS value 
FROM prognoses, variabel 
WHERE variabel.code = ? AND prognoses.variabel = variabel.id AND prognoses.time >= strftime(?, ?, ?) AND prognoses.time < strftime(?, ?, ?) ORDER BY time
2026-03-25 19:49:52 debug: query get column data da:
 SELECT strftime(?, datetime(prognoses.time, ?, ?)) AS uur, prognoses.time AS time, prognoses.time AS utc, prognoses.value AS value 
FROM prognoses, variabel 
WHERE variabel.code = ? AND prognoses.variabel = variabel.id AND prognoses.time >= strftime(?, ?, ?) AND prognoses.time < strftime(?, ?, ?) ORDER BY time
2026-03-25 19:49:52 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 694, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 538, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 288, in calc_optimum
    solar_prog = self.calc_solar_predictions(
        self.solar[s], start_interval_dt, end, self.interval
    )
  File "/root/dao/prog/da_base.py", line 587, in calc_solar_predictions
    solar_prog = solar_predictor.predict_solar_device(
        solar_option, vanaf, tot
    )
  File "/root/dao/prog/solar_predictor.py", line 1024, in predict_solar_device
    prediction = self.predict(weather_data)
  File "/root/dao/prog/solar_predictor.py", line 702, in predict
    prediction = self.model.predict(featured_df)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/sklearn.py", line 1446, in predict
    predts = self.get_booster().inplace_predict(
        data=X,
    ...<4 lines>...
        validate_features=validate_features,
    )
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 2865, in inplace_predict
    raise ValueError(
    ...<2 lines>...
    )
ValueError: Feature shape mismatch, expected: 8, got 9
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "POST /api/services/input_text/set_value HTTP/1.1" 200 331
2026-03-25 19:49:52 INFO: Loaded 6 secrets from ../data/secrets.json
2026-03-25 19:49:52 INFO: Validating configuration with ConfigurationV0
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "GET /api/ HTTP/1.1" 200 34
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "GET /api/config HTTP/1.1" 200 2420
2026-03-25 19:49:52 debug: hass/api/config: {"allowlist_external_dirs":["/media","/config/www"],"allowlist_external_urls":[],"components":["light","nederlandse_spoorwegen.sensor","derivative","tuya.sensor","version.binary_sensor","filter.sensor","auto_backup.button","ical","proxmoxve.sensor","tuya.number","homeassistant","my","auto_backup","mqtt.select","sessy.button","alarm_control_panel","tuya.event","localtuya","input_boolean","tuya.light","samsungtv_smart.media_player","proxmoxve.binary_sensor","spook.time","sessy.select","panel_custom","wake_word","history","persistent_notification","lovelace","nodered.number","mqtt.binary_sensor","adguard","spotifyplus","browser_mod.light","buienradar.weather","trace","sql","history_stats.sensor","climate","generic_thermostat.climate","media_source","number","google_generative_ai_conversation.conversation","zwave_js.siren","tuya.climate","spook.sensor","google_generative_ai_conversation.tts","zwave_js.binary_sensor","solaredgeoptimizers.sensor","cloud.stt","smartthings.event","blueprint","ping.sensor","solaredge_modbus","zwave_js.number","github","tado_hijack.binary_sensor","systemmonitor","zwave_js.sensor","ping.binary_sensor","conversation","recorder","tuya","sessy.switch","fan","workday.binary_sensor","mqtt.sensor","samsungtv.remote","local_todo","smartthings","tuya.alarm_control_panel","afvalwijzer.sensor","nodered.sensor","tado_hijack.sensor","github.sensor","tado_hijack.climate","tado_hijack.switch","wake_on_lan.switch","smartthings.binary_sensor","mpd","text","web_rtc","solaredge_modbus.sensor","template.select","smartthings.light","smartthings.climate","http","twinkly","mqtt.switch","tado_local","smartthings.water_heater","smartthings.number","camera","local_calendar.calendar","schedule","min_max.sensor","cloud","auto_backup.binary_sensor","zwave_js.humidifier","afvalwijzer","auth","tuya.valve","hacs","co2signal.sensor","notify","hacs.switch","cover","labs","esphome","buienradar.sensor","spook.switch","dsmr_reader","template.switch","image_upload","watchman.sensor","nodered.text","smartthings.valve","utility_meter","weather","workday.calendar","spotifyplus.media_player","onboarding","mqtt.number","solaredge_modbus.number","systemmonitor.sensor","tado_hijack.button","cloud.binary_sensor","esphome_designer","local_todo.todo","mqtt.event","smartthings.scene","tuya.vacuum","tod","mqtt","ical.sensor","zone","input_number","esphome.event","utility_meter.select","tibber","bluetooth","switch_as_x.light","media_player","wake_on_lan","esphome.cover","hassio.switch","browser_mod.binary_sensor","scene","smartthings.sensor","sessy.number","mobile_app.notify","energy_meter.sensor","intent","hassio.sensor","esphome.media_player","forecast_solar.sensor","adguard.sensor","cast.media_player","openweathermap.weather","tado_hijack.water_heater","ai_task","assist_pipeline","smartthings.select","diagnostics","input_datetime","pvoutput.sensor","logbook","ping","solaredgeoptimizers","mpd.media_player","zwave_js","spook","input_text","lock","siren","sun.sensor","mobile_app.binary_sensor","openweathermap.sensor","tuya.select","zwave_js.button","adguard.switch","plant","search","spook.button","api","zwave_js.update","network","mqtt.text","localtuya.number","group","rest","localtuya.sensor","repairs","tado_hijack.select","unifi","device_automation","tuya.humidifier","threshold.binary_sensor","kleenex_pollenradar","mobile_app.device_tracker","homeassistant.scene","nodered","button","browser_mod.sensor","config","statistics","integration.sensor","counter","nodered.select","spotify","nodered.time","utility_meter.sensor","smartthings.fan","esphome.camera","google_generative_ai_conversation","samsungtv","input_button","adguard.update","systemmonitor.binary_sensor","watchman.button","samsungtv_smart","zwave_js.fan","cloud.tts","esphome.switch","integration","watchman.text","tuya.camera","usb","tibber.sensor","spook.event","sensor","ffmpeg","remote","smartthings.lock","utility_meter_next_gen","websocket_api","sessy","script","zeroconf","binary_sensor","statistics.sensor","version.sensor","nederlandse_spoorwegen","smartthings.vacuum","samsungtv.media_player","ical.calendar","hassio.binary_sensor","zwave_js.light","buienradar","utility_meter_next_gen.sensor","esphome.number","tuya.button","backup.sensor","tuya.cover","auto_backup.sensor","nederlandse_spoorwegen.binary_sensor","zwave_js.select","humidifier","ssdp","smartthings.media_player","scheduler.switch","frontend","template.binary_sensor","sun","forecast_solar","tuya.binary_sensor","smartthings.update","calendar","energy.sensor","esphome.sensor","watchman","smartthings.cover","backup.event","tado_local.sensor","switch","tag","pvoutput","browser_mod.camera","timer","energy","smartthings.switch","event","universal.media_player","spook.binary_sensor","sql.sensor","command_line","rest.sensor","system_log","backup","mobile_app","openweathermap","mobile_app.sensor","template.sensor","rest_command","tado_local.climate","stt","threshold","mqtt.climate","scheduler","sessy.update","smart_thermostat.climate","buienalarm","time","smartthings.button","spotify.media_player","esphome.light","samsungtv_smart.remote","analytics","input_select","file_upload","tado_hijack.number","dsmr_reader.sensor","command_line.sensor","zwave_js.switch","esphome.select","tuya.siren","todo","hardware","tuya.switch","esphome.button","sessy.sensor","buienalarm.sensor","mqtt.light","min_max","select","buienradar.camera","system_health","tuya.fan","kleenex_pollenradar.sensor","proxmoxve","automation","valve","browser_mod","tts","application_credentials","sun.binary_sensor","energy_meter","esphome.binary_sensor","device_tracker","tado_hijack","ping.device_tracker","hassio","zwave_js.event","water_heater","nodered.switch","group.notify","localtuya.switch","bluetooth_adapters","co2signal","tuya.scene","nodered.button","group.light","zwave_js.climate","switch_as_x","logger","solaredge_modbus.select","google_generative_ai_conversation.ai_task","zwave_js.lock","version","local_calendar","nodered.binary_sensor","time_date.sensor","spook.select","tibber.notify","workday","browser_mod.media_player","cast","sessy.binary_sensor","derivative.sensor","vacuum","proxmoxve.button","webhook","mqtt.fan","spook.number","update","hassio.update","person","tado_local.text","hacs.update","tibber.binary_sensor","zwave_js.cover","tod.binary_sensor","shell_command","brands","esphome.update","template","google_generative_ai_conversation.stt","sessy.time"],"config_dir":"/config","config_source":"storage","country":"NL","currency":"EUR","debug":false,"elevation":0,"external_url":null,"internal_url":null,"language":"en","latitude":52.01789586139738,"location_name":"Home","longitude":4.3583106994628915,"radius":100,"recovery_mode":false,"safe_mode":false,"state":"RUNNING","time_zone":"Europe/Amsterdam","unit_system":{"length":"km","accumulated_precipitation":"mm","area":"m²","mass":"g","pressure":"Pa","temperature":"°C","volume":"L","wind_speed":"m/s"},"version":"2026.3.4","whitelist_external_dirs":["/media","/config/www"]}
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "GET /api/states/input_select.dao_strategy HTTP/1.1" 200 429
2026-03-25 19:49:52 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 19:49:52 debug: http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 323
2026-03-25 19:49:52 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 198 in /root/dao/prog/da_base.py
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4707, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4678, in main
    da_calc.run_task_function("calc_optimum_met_debug")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 694, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 538, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 288, in calc_optimum
    solar_prog = self.calc_solar_predictions(
        self.solar[s], start_interval_dt, end, self.interval
    )
  File "/root/dao/prog/da_base.py", line 587, in calc_solar_predictions
    solar_prog = solar_predictor.predict_solar_device(
        solar_option, vanaf, tot
    )
  File "/root/dao/prog/solar_predictor.py", line 1024, in predict_solar_device
    prediction = self.predict(weather_data)
  File "/root/dao/prog/solar_predictor.py", line 702, in predict
    prediction = self.model.predict(featured_df)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/sklearn.py", line 1446, in predict
    predts = self.get_booster().inplace_predict(
        data=X,
    ...<4 lines>...
        validate_features=validate_features,
    )
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 751, in inner_f
    return func(**kwargs)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/xgboost/core.py", line 2865, in inplace_predict
    raise ValueError(
    ...<2 lines>...
    )
ValueError: Feature shape mismatch, expected: 8, got 9

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

code:

{
  "config_version": 0,
  
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "entsoe_api_key": "!secret entsoe-api-key",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.12286,
      "2025-09-01": 0.12286
    },
    "energy_taxes_production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.12286,
      "2025-09-01": 0.12286
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0182,
      "2025-09-01": 0.020496,
      "2026-01-01": 0.020496
    },
    "cost_supplier_production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0182,
      "2025-09-01": 0.020496,
      "2026-01-01": -0.020496
    },
    "vat_consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21,
      "2026-01-01": 21
    },
    "vat_production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21,
      "2026-01-01": 21
    },
    "last_invoice": "2026-01-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
  "logging_level": "debug",
  "use_calc_baseload": false,
  "baseload_calc_periode": 42,
  "baseload": [
    0.15,
    0.15,
    0.15,
    0.15,
    0.15,
    0.15,
    0.15,
    0.25,
    0.3,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.5,
    0.8,
    0.8,
    0.5,
    0.2,
    0.2,
    0.15
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": true,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "input_select.dao_strategy",
  "max_gap": 0.005,
  "notifications": {
    "notification_entity": "input_text.notification_dao",
    "opstarten": false,
    "berekening": true,
    "last_activity_entity": "input_datetime.dao_last_activity"
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Sessys",
      "entity_actual_level": "sensor.sessy_all_state_of_charge",
      "capacity": 10.0,
      "upper_limit": 100,
      "lower_limit": 0,
      "optimal_lower_level": 0,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 120.0,
          "efficiency": 0.7
        },
        {
          "power": 220.0,
          "efficiency": 0.758
        },
        {
          "power": 440.0,
          "efficiency": 0.85
        },
        {
          "power": 660.0,
          "efficiency": 0.892
        },
        {
          "power": 880.0,
          "efficiency": 0.912
        },
        {
          "power": 1320.0,
          "efficiency": 0.933
        },
        {
          "power": 1760.0,
          "efficiency": 0.942
        },
        {
          "power": 2200.0,
          "efficiency": 0.946
        },
        {
          "power": 2640.0,
          "efficiency": 0.942
        },
        {
          "power": 3080.0,
          "efficiency": 0.938
        },
        {
          "power": 3520.0,
          "efficiency": 0.929
        },
        {
          "power": 3960.0,
          "efficiency": 0.921
        },
        {
          "power": 4400.0,
          "efficiency": 0.908
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 120.0,
          "efficiency": 0.7
        },
        {
          "power": 170.0,
          "efficiency": 0.735
        },
        {
          "power": 340.0,
          "efficiency": 0.829
        },
        {
          "power": 510.0,
          "efficiency": 0.882
        },
        {
          "power": 680.0,
          "efficiency": 0.921
        },
        {
          "power": 1020.0,
          "efficiency": 0.943
        },
        {
          "power": 1360.0,
          "efficiency": 0.957
        },
        {
          "power": 1700.0,
          "efficiency": 0.957
        },
        {
          "power": 2040.0,
          "efficiency": 0.953
        },
        {
          "power": 2380.0,
          "efficiency": 0.943
        },
        {
          "power": 2720.0,
          "efficiency": 0.936
        },
        {
          "power": 3060.0,
          "efficiency": 0.929
        },
        {
          "power": 3400.0,
          "efficiency": 0.925
        }
      ],
      "reduced_hours": {
        "0": 1000,
        "1": 1000,
        "2": 1000,
        "3": 1000,
        "4": 1000,
        "5": 1000,
        "6": 1000,
        "20": 1000,
        "21": 1000,
        "22": 1000,
        "23": 1000
      },
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 100,
      "dc_to_bat_efficiency": 1.0,
      "dc_to_bat_max_power": 2200.0,
      "bat_to_dc_efficiency": 1.0,
      "cycle_cost": 0.03,
      "entity_set_power_feedin": "input_number.sessy_charge_setpoint_from_dao_dummy",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_balance_switch": "input_boolean.sessy_dao_controlled_nom_aan_dummy",
      "entity_from_battery": "input_number.sessy_calculated_power_next_hour_dummy",
      "entity_calculated_soc": "input_number.sessy_calculated_soc_from_dao_dummy",
      "solar": [],
      "bat_to_dc max power": 1700
    }
  ],
  "solar": [
    {
      "name": "Solaredge",
      "tilt": 10.0,
      "orientation": 146.0,
      "capacity": 0.405,
      "yield_factor": 0.000931658,
      "strings": [],
      "ml_prediction": true,
      "entities_sensors": [
        "sensor.solaredge_modbus_ac_energy_kwh"
      ],
      "max_power": 3.0
    }
  ],
  "electric_vehicle": [],
  "machines": [],
  "boiler": {
    "boiler_present": false
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": [
      "sensor.dsmr_reading_electricity_delivered_1",
      "sensor.dsmr_reading_electricity_delivered_2"
    ],
    "entities_grid_production": [
      "sensor.dsmr_reading_electricity_returned_1",
      "sensor.dsmr_reading_electricity_returned_2"
    ],
    "entities_solar_production_ac": [
      "sensor.solaredge_modbus_ac_energy_kwh"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": [],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.sessy_links_charged_energy",
      "sensor.sessy_rechts_charged_energy"
    ],
    "entities_battery_production": [
      "sensor.sessy_links_discharged_energy",
      "sensor.sessy_rechts_discharged_energy"
    ],
    "entities_machine_consumption": [],
    "entity co2-intensity": [
      "sensor.electricity_maps_co2_intensity"
    ]
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "1037",
        "action": "get_meteo_data"
      },
      {
        "time": "1250",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1350",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1450",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1550",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1634",
        "action": "get_meteo_data"
      },
      {
        "time": "1650",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "2222",
        "action": "get_meteo_data"
      },
      {
        "time": "2359",
        "action": "clean_data"
      },
      {
        "time": "0437",
        "action": "get_meteo_data"
      },
      {
        "time": "1948",
        "action": "train_ml_predictions"
      }
    ]
  },
  "heater": {
    "heater present": "false"
  }
}

[simnet]

balk schreef op woensdag 25 maart 2026 @ 19:55:
[...]

Ik krijg deze fout:

[...]

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

[...]

Heb je de ML modellen wel opnieuw getraind?

[balk]

simnet schreef op woensdag 25 maart 2026 @ 19:59:
[...]

Heb je de ML modellen wel opnieuw getraind?

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

code:

..knip
2026-03-25 20:06:01 debug: Save record: 2026-03-23 22:00 temp 1774299600 8.1
2026-03-25 20:06:01 debug: Save record: 2026-03-23 22:00 gr 1774299600 0.0
2026-03-25 20:06:01 debug: Save record: 2026-03-23 22:00 winds 1774299600 2.0
2026-03-25 20:06:01 debug: Save record: 2026-03-23 23:00 temp 1774303200 7.7
2026-03-25 20:06:01 debug: Save record: 2026-03-23 23:00 gr 1774303200 0.0
2026-03-25 20:06:01 debug: Save record: 2026-03-23 23:00 winds 1774303200 3.0
2026-03-25 20:06:01 debug: Save record: 2026-03-24 00:00 temp 1774306800 6.9
2026-03-25 20:06:01 debug: Save record: 2026-03-24 00:00 gr 1774306800 0.0
2026-03-25 20:06:01 debug: Save record: 2026-03-24 00:00 winds 1774306800 3.0
2026-03-25 20:06:01 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 312 in /root/dao/lib/db_manager.py
2026-03-25 20:06:01 debug: query get column data da:
 SELECT strftime(?, datetime("values".time, ?, ?)) AS uur, "values".time AS time, "values".time AS utc, "values".value AS value 
FROM "values", variabel 
WHERE variabel.code = ? AND "values".variabel = variabel.id AND "values".time >= strftime(?, ?, ?) AND "values".time < strftime(?, ?, ?) ORDER BY time
2026-03-25 20:06:01 debug: query get column data da:
 SELECT strftime(?, datetime("values".time, ?, ?)) AS uur, "values".time AS time, "values".time AS utc, "values".value AS value 
FROM "values", variabel 
WHERE variabel.code = ? AND "values".variabel = variabel.id AND "values".time >= strftime(?, ?, ?) AND "values".time < strftime(?, ?, ?) ORDER BY time
2026-03-25 20:06:01 debug: query get column data da:
 SELECT strftime(?, datetime("values".time, ?, ?)) AS uur, "values".time AS time, "values".time AS utc, "values".value AS value 
FROM "values", variabel 
WHERE variabel.code = ? AND "values".variabel = variabel.id AND "values".time >= strftime(?, ?, ?) AND "values".time < strftime(?, ?, ?) ORDER BY time
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "GET /api/ HTTP/1.1" 200 34
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "GET /api/config HTTP/1.1" 200 2420
<knip>
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "GET /api/states/input_select.dao_strategy HTTP/1.1" 200 429
2026-03-25 20:06:01 debug: Starting new HTTP connection (1): 192.168.1.7:8123
2026-03-25 20:06:01 debug: http://192.168.1.7:8123 "POST /api/services/input_datetime/set_datetime HTTP/1.1" 200 10
2026-03-25 20:06:01 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 198 in /root/dao/prog/da_base.py
2026-03-25 20:06:01 debug: query get sensor data:
 SELECT to_char(to_timestamp(t2.start_ts), %(to_char_1)s) AS uur, to_char(to_timestamp(t2.start_ts), %(to_char_2)s) AS tijd, to_char(to_timestamp(t2.start_ts), %(to_char_3)s) AS tot, t2.start_ts AS utc, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE %(param_1)s END AS solar_kwh, v1.unit_of_measurement AS dim 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + %(start_ts_1)s JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = %(statistic_id_1)s AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= EXTRACT(epoch FROM to_timestamp(%(to_timestamp_1)s, %(to_timestamp_2)s)) - %(param_2)s AND t1.start_ts < EXTRACT(epoch FROM to_timestamp(%(to_timestamp_3)s, %(to_timestamp_4)s)) - %(param_3)s

[KC27]

balk schreef op woensdag 25 maart 2026 @ 20:07:
[...]

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


[...]

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

[Mirabis]

KC27 schreef op woensdag 25 maart 2026 @ 19:06:
Er is een nieuwe testversie gepubliceerd: 2026.03.3.rc5

Dit staat in de changelog:
In this release all the errors the testers found during testing are fixed.
Many thanks to all of them: great job.

Breaking change

The ML model was extended to allow for windspeed in predictions. this means you have to retrain the ML models before running a calculation!

Before we go with this release to production/stable we will ask all the testers to run a new test.
We hope we have tackled all the errors.
How to test:

• Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json
• Then install the new release (or when you allready have installed restart the addon/app)
• Look in the logging off the app/addon if you see errors during the conversion.

Most important changes in the config/options.json:<br>

• all booleans are now noted as true or false: no "True" or "False" anymore.
• changed entity_avg_temp to entity_avg_outside_temp (reported by @f.welvering)
• removed "show_graph" from settings
• implemented windvelocity as feature variable for solar prediction (request from @Karpertje)
• (re)moved deprecated "entity stop victron" in favor of "entity stop inverter"

These errors are fixed:

• defaults for battery low- (20%) and upper-limit (100%) (reported by @rescla )
• default for ev "entity stop charging" (none)
• boiler activate service must have a value if boiler activate entity is set
• removed the requirement off stages from heating when adjustement is on/off
• when boiler_present = false or heating_present= false all the other settings are optional (reported by @balk)
• if scheduler active = true is not present it will be set to true

Hmm ik wil van 2026.03.1.rc3 upgraden en de stappen volgen maar het onderstaande is mij nog niet helemaal duidelijk.

code:

Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json

er is geen options_unversioned.json. Moet ik options.json kopieren naar options_unversioned.json of moet ik toch echt eerst upgrade en dan de kopie doen.

[simnet]

Mirabis schreef op woensdag 25 maart 2026 @ 23:23:
[...]

Hmm ik wil van 2026.03.1.rc3 upgraden en de stappen volgen maar het onderstaande is mij nog niet helemaal duidelijk.

code:

Before installing this release: copy your old options.json (saved in options_unversioned.json) to options.json

er is geen options_unversioned.json. Moet ik options.json kopieren naar options_unversioned.json of moet ik toch echt eerst upgrade en dan de kopie doen.

options_unversioned.json bestaat alleen als je al een keer een 2026.03.3.rcX hebt gedraait.
Die specifieke instructie is alleen voor mensen die hiervoor al een rc van deze versie draaiden.