Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[hemertje]

@konehead

Ik heb de meldingen uit de wiki (08. Voorbeelden, Notificaties) aangezet en twee dingen opgemerkt:

1. De automation DAO_Last_activity_timer_ran_out draait elke 15 minuten zolang de timer idle is, dus bij een langere uitval krijg je steeds dezelfde melding. Ik gebruik nu timer.finished als trigger: één melding per uitval.

2. In DAO_Calculation_error staat input_text.dao_notification_automation, terwijl de rest van de wiki input_text.dao_notification_message gebruikt. Die moet volgens mij ook dao_notification_message zijn?

Mijn foutmelding-automation werkt met een state-trigger op de helper (alles zonder "calc afgerond" gaat naar mijn telefoon).

Beide meldingen heb ik getest en komen aan.

[konehead]

hemertje schreef op woensdag 21 oktober 2026 @ 12:13:
@konehead

Ik heb de meldingen uit de wiki (08. Voorbeelden, Notificaties) aangezet en twee dingen opgemerkt:

1. De automation DAO_Last_activity_timer_ran_out draait elke 15 minuten zolang de timer idle is, dus bij een langere uitval krijg je steeds dezelfde melding. Ik gebruik nu timer.finished als trigger: één melding per uitval.

2. In DAO_Calculation_error staat input_text.dao_notification_automation, terwijl de rest van de wiki input_text.dao_notification_message gebruikt. Die moet volgens mij ook dao_notification_message zijn?

Mijn foutmelding-automation werkt met een state-trigger op de helper (alles zonder "calc afgerond" gaat naar mijn telefoon).

Beide meldingen heb ik getest en komen aan.

Dat is top man! Weet je ook zeker dat bovenstaande voor mij is? 😉🫡

[anboni]

KC27 schreef op dinsdag 1 april 2025 @ 23:35:
[...]


DAO kan de energieprijzen uit verschillende (zelf te kiezen) bronnen ophalen:
Nordpool; heb ik hele goede ervaringen mee, gratis, ze zijn vanaf 12:50 uur voor de volgende dag beschikbaar
Entsoe: werkt ook goed (iets minder dan Nordpool), je moet er een api-key voor ophalen
twee energieleveranciers, die meestal pas later in de middag beschikbaar zijn; Tibber, EasyEnergy

Even terugkomen op een discussie van anderhalf jaar geleden, de vraag was of je Epex-Spot zou kunnen ondersteunen. Hiermee krijg je een genormaliseerde sensor in HA, waarbij de gebruiker zelf kan kiezen tussen meerdere bronnen, en er is ook een fork (https://github.com/brambo123/ha_epex_spot) die de mogelijkheid heeft om fallback sensors te configureren, zodat je bij het niet beschikbaar zijn van je primaire sensor terug kunt vallen op een andere sensor en nog steeds dezelfde genormaliseerde informatie hebt.

Maakt de DAO code waarschijnlijk ook nog wat simpeler, omdat je zelf niet meer de APIs van die 4 verschillende bronnen hoeft te blijven volgen (en de meeste mensen zullen vast ook al een dergelijke sensor in HA hebben om een dashboard mee te voeden)

[hemertje]

konehead schreef op woensdag 21 oktober 2026 @ 18:05:
[...]

Dat is top man! Weet je ook zeker dat bovenstaande voor mij is? 😉🫡

nou...

in mijn eigen punthoofd zit dat jij de DAO wiki onderhoudt
maar blijkbaar is dat niet zo

[konehead]

hemertje schreef op woensdag 21 oktober 2026 @ 19:54:
[...]


nou...

in mijn eigen punthoofd zit dat jij de DAO wiki onderhoudt
maar blijkbaar is dat niet zo

Ahh np, ik heb een deelpagina. je moet @Torch1969 hebben

[hemertje]

KC27 schreef op woensdag 21 oktober 2026 @ 00:04:
Er is een nieuwe testversie gepubliceerd: 2026.10.0.rc2

Dit staat in de changelog:

Breaking change

The scheduler task for retrieving predicted prices is renamed to: get_predicted_prices
and works now
Hint:
If you have defined tasks with "predited prices": please remove these before install and place them back with the right key afterwards. This prevents starting errors.

Changes

• Fix error calculate distance to weather station (reported by @buiter)
• Fixed error in the graph "not optimized": consumption and production in the "not predicted part" where in kWh this is changed to kW.
• Make the degree-days base temperature (stookgrens) configurable (thanks @voogel)
• Validate and load the json before storing it: prevents DAO from crashing (thanks @storeman)
• Introducting of Ruff as linter (@thanks @Lasoul)
• Heat pump (power mode): size blocks from hours needed, not hours available (thanks @llevering)
• clean-up and centralication of task (with aliases) now rest-api works again (thanks @storeman, reported by @Dabit)
• added .devcontainer to help development on systems with VS (see DEVELOPMENT.md, thanks @Lasoul)
• added jeroen_nl (jeroen.nl) as source for predicted prices
• update several python modules

Korte toelichting:
Op verzoek is jeroen.nl als bron voor voorspelde prijzen toegevoegd.
Om dit goed te laten werken moet er ook een api-key gedefinieerd worden.
De definitie om deze gegevens bij jeroen.nl op te halen ziet er dan zo uit:

JSON:

  "prices": {
    ....
    "prediction": {
      "extension": 96,
      "source": "jeroen_nl",
      "api": "https://jeroen.nl/api/dynamische-energieprijzen/v2/?key=<key>&period=voorspelling&type=json",
      "api_key": "!secret key_jeroen_nl"
    },
    ....
  }

@KC27
Ik heb de afgelopen dagen DAO met mijn warmtepomp (Panasonic, stooklijnverschuiving) uitgeprobeerd, voorlopig alleen met debug-runs en zonder de pomp aan te sturen.

Onderstaande drie dingen vallen me op en zijn naar mijn handig in een volgende versie:

1. Afvlakking van de stooklijn-aanpassing in DAO zelf. Nu schrijft DAO elke run een nieuwe waarde. Als er een andere regeling op dezelfde ingang meeluistert, en dat doen er bij mij en bij anderen meerdere, geeft dat veel wijzigingen. Zelf doe ik dat in HA (gemiddelde over een halfuur, stappen van 0,5 K, begrenzing). Een optie in DAO voor stapgrootte, minimale tijd tussen wijzigingen en maximale stap per kwartier zou dat voor iedereen oplossen.

2. COP per vermogenstrap afhankelijk van de buitentemperatuur. In mijn debug-run rekende DAO bij 500 W met COP 6,0 (3,0 kWh warmte voor 0,51 kWh elektrisch), terwijl ik vandaag ongeveer 4,1 meet (thermisch volgens de pomp zelf, gedeeld door elektrisch via S0-meters). Voor de boiler geldt hetzelfde: één COP-getal voor het hele jaar. Een COP-curve of een lijst per temperatuurgebied zou de planning dichter bij de praktijk brengen.

3. Wiki: de eenheid van entity_heat_produced. DAO trekt die in kWh af van de warmtebehoefte en gebruikt dezelfde sensor ook voor het aantal draaiuren (get_heatpump_run_hours). Ik had er eerst een vermogenssensor (W) ingezet; de uitleg bij de optie zegt niet duidelijk dat het kWh per dag moet zijn.

Hoe kijk jij hier tegen aan?

[oscaarbasgitaar]

timenator schreef op woensdag 21 oktober 2026 @ 11:57:
[...]

De COP heeft niks te maken met temperaturen. De formule is heel simpel "Geleverde thermische energie" gedeeld door "afgenomen elektrische energie".

Dat zaken als genoemde temperaturen de COP indirect beïnvloeden ben ik met je eens.

Het klopt dat COP = geleverde thermische energie/ verbruikte elektrische energie.

Maar dat is geen indirect gevolg van temperaturen. Temperaturen liggen aan de basis van de COP, niet omgekeerd.

Een warmtepomp werkt op basis van de wetten van de thermodynamica: als de druk verhoogt stijgt de temperatuur van de faseovergang van vloeibaar naar gas. Je laat een koelvloeistof verdampen aan de lage bron temperatuur, compresseert dit gas en laat het terug condenseren bij een hogere afgifte temperatuur.
Hogere temperatuursverschillen vragen een grotere drukverhoging, meer toegevoegde elektrische energie en dus een lagere COP.

Is het buiten 10°, dan kan ik mijn woning met ca 30° aanvoer temperatuur verwarmen en haal ik bij die delta T een COP(10/30) van 7à8.
Is het buiten -5°, dan moet de aanvoer temperatuur stijgen naar ca 45° en heb ik dus een veel lagere COP(10/45): ca. 4 in mijn geval omdat mijn bron temperatuur door de geothermie ca. 10° blijft. Ga je naar lucht bronnen kijken, dan zakt de COP(-5/45) nog lager omdat die delta T nog groter is.

Draait de warmtepomp dus aan 500watt elektrisch vermogen bij 10° buiten of bij -5° dan kan die minder thermisch vermogen leveren.

Op basis van de degree days factor doe je een voorspelling van de benodigde thermische energie. Als de stages een vaste COP hebben die niet gelinkt is aan de temperaturen, dan gaat de DAO de invulling van die warmte vraag verkeerd inplannen.

COP via een sensor variabel maken lost dit (deels) op.

[Hippe Lip]

KC27 schreef op zaterdag 17 oktober 2026 @ 23:55:
@Hippe Lip @Dogooder
Als je de app/add-on opnieuw start en je krijgt geen verbinding dan zou er iets moeten staan in de logging van de add-on/app.
Ga in HA naar Instellingen/Apps/DAO en klik het tabblad "Logboek" aan.
Ik ben benieuwd wat daar staat.
Bij mij staat er dan zoiets (ik heb de test-versie draaien):
[Afbeelding]

Sorry, late reactie want ik was weg.

Die log kan een handig hulpmiddel zijn als die ook iets zinnigs kan en wil zeggen over wat er mis gaat. Maar als die log alleen maar gevuld is met tig regels waar alleen maar "Scheduler crashed with exit code 1" op elke regel staat, dan kom je niet ver.

Ik hoop toch vurig op een beetje inhoudelijke foutmelding zoals HA dat zelf ook doet. Dan staat er dat er op regel X, positie Y een fout staat. Nu klopt dat regelnummer niet altijd, maar je hebt dan veel meer een richting. Nu heb ik geen idee wat er mis gaat. Is er iets in de options.json mis of ligt het ergens anders aan?

DAO komt niet verder dan een popup met "The app seems to not be ready, it might still be starting. Do you want to try again?"

[Hippe Lip]

cctl01 schreef op zondag 18 oktober 2026 @ 08:50:
[...]

Hier kun je veel meer instellingen vinden

Dank, @cctl01 .
Dat is een heleboel text, maar op dit moment heb ik grote behoefte aan voorbeelden en die staat daar helaas niet bij. Ik probeer nu bijvoorbeeld mijn thuisbatterijen toe te voegen, maar ergens gaat iets mis, maar geen idee WAT.

[KC27]

Hippe Lip schreef op donderdag 22 oktober 2026 @ 00:16:
[...]

Dank, @cctl01 .
Dat is een heleboel text, maar op dit moment heb ik grote behoefte aan voorbeelden en die staat daar helaas niet bij. Ik probeer nu bijvoorbeeld mijn thuisbatterijen toe te voegen, maar ergens gaat iets mis, maar geen idee WAT.

Als je hier de inhoud van het bestand options.json deelt (tussen quote en code tags) krijg je geheid respons wat er fout is en tips om het te verbeteren.

[buiter]

KC27 schreef op woensdag 21 oktober 2026 @ 00:04:
Er is een nieuwe testversie gepubliceerd: 2026.10.0.rc2

Dit staat in de changelog:

Breaking change

The scheduler task for retrieving predicted prices is renamed to: get_predicted_prices
and works now
Hint:
If you have defined tasks with "predited prices": please remove these before install and place them back with the right key afterwards. This prevents starting errors.

Changes

• Fix error calculate distance to weather station (reported by @buiter)
• Fixed error in the graph "not optimized": consumption and production in the "not predicted part" where in kWh this is changed to kW.
• Make the degree-days base temperature (stookgrens) configurable (thanks @voogel)
• Validate and load the json before storing it: prevents DAO from crashing (thanks @storeman)
• Introducting of Ruff as linter (@thanks @Lasoul)
• Heat pump (power mode): size blocks from hours needed, not hours available (thanks @llevering)
• clean-up and centralication of task (with aliases) now rest-api works again (thanks @storeman, reported by @Dabit)
• added .devcontainer to help development on systems with VS (see DEVELOPMENT.md, thanks @Lasoul)
• added jeroen_nl (jeroen.nl) as source for predicted prices
• update several python modules

Korte toelichting:
Op verzoek is jeroen.nl als bron voor voorspelde prijzen toegevoegd.
Om dit goed te laten werken moet er ook een api-key gedefinieerd worden.
De definitie om deze gegevens bij jeroen.nl op te halen ziet er dan zo uit:

JSON:

  "prices": {
    ....
    "prediction": {
      "extension": 96,
      "source": "jeroen_nl",
      "api": "https://jeroen.nl/api/dynamische-energieprijzen/v2/?key=<key>&period=voorspelling&type=json",
      "api_key": "!secret key_jeroen_nl"
    },
    ....
  }

Mooie aanpassingen, goed werk.
Ook getest met de meerdaagse verwachting van Jeroen.
Hopelijk kan DAO in de toekomst ook nog rekening houden met een geplande laadsessie.
Want de auto is een grootverbruiker.
En de mate van flexibiliteit van een grootverbruiker bepaald aanzienlijk het resultaat.

[Probydoby]

Ik ben bezig geweest om mijn Lucht/lucht warmtepomp in DAO te krijgen. Om meerdere redenen:

1. In de baseload is minder accuraat terwijl warmtevraag goed voorspelbaar is op basis van weer
2. Om voor te verwarmen om zo dure periodes te overbruggen, mijn huis als het ware als een thermische batterij gebruiken

Om een voorbeeldje te noemen van dat tweede, per graad dat ik mijn woonkamer warmer maak, moet er 4.9kwh thermisch in (en omgekeerd, om het 1 graad kelvin te laten zakken, gaat er 4.9kwh uit). Door het huis dus eerder op te warmen met 1 graad, bufferen we 4.9kwh thermisch (laten we zeggen 1.5kwh met een cop van 3+), en zo heb je dus eigenlijk gratis een thuisbatterij van 1.5kwh wat betreft de warmte.



Op zich doet DAO precies wat ik zou verwachten, heb op basis van fabriek specs van de MHI AC wat power en COP waardes erin gezet en DAO op power modus gezet. Hij doet vol blazen op de goedkope periodes en minimaal verwarmen op de dure periodes. Maar dit is natuurlijk niet comfortabel, er moet een bovengrens komen naar hoeveel er thermisch gebufferd mag worden als additionele constraint. En 'straf' voor het benutten van een buffer op basis van warmteverlies per periode zodat er niet onnodig vroeg gebufferd wordt, wil je dit echt gaan gebruiken.

Ik weet niet hoe dit is voor mensen met een water/water wp maar ik kan me voorstellen dat ook daar de hoeveelheid buffer verschilt.

In beginsel zal DAO dan een vermogen dicteren die overeenkomt met de warmtebehoefte van die periode en kan ervoor kiezen om de buffer op te vullen tussen 0 en de max (in mijn geval 4.9kwh, als ik besluit dat de mijn grenzen zijn wat betreft comfort), of de warmtebehoefte van dat uur te verminderen door de buffer te benutten (tijdens dure uren).

Tot dusver in ieder geval mijn gedachtes, het is een tijd geleden dat ik een lineair probleem wiskundig heb geformuleerd dus dat kan ik niet doen, maar is het een logisch concept die zinvol zou zijn voor anderen? Of zijn er al andere plannen dit hetzelfde probleem adresseren?

[Knielen]

@Probydoby Je rekent jezelf veel te rijk. Je COP kakt helemaal in als je WP harder moet gaan werken. Je hebt meer thermisch verlies als de temperatuur in de kamer hoger is. Rond het vriespunt heb je veel meer defrosts. Het is al vaker besproken dat deze manier van bufferen niet efficiënt is.

Een WP is toch echt het goedkoopst als deze stabiel en constant op een zo laag mogelijke frequentie kan draaien.

[Probydoby]

Knielen schreef op donderdag 22 oktober 2026 @ 13:55:

Een WP is toch echt het goedkoopst als deze stabiel en constant op een zo laag mogelijke frequentie kan draaien.

Niet in alle omstandigheden, zoals dynamische tarieven die snel veranderen. COP kan je gewoon opgegeven per verschillende vermogensschijven in de config, zoals eerder vermeldt in dit topic is wellicht een temperatuur afhankelijke config nog beter.

Thermisch verlies is vrij lineair met de tdelta dus makkelijk te configureren eenmalig en dan kan het optimalisatiemodel daar gewoon rekening meehouden.

Dus al je argumenten kunnen gewoon meegenomen worden door DAO als het model warmteverlies en lagere cop meeneemt.

EDIT: En zelfs, als bufferen niet rendabel is, dan zorgt dit ervoor dat de voorspelde load accurater wordt omdat DAO dan idd een constante load zal dicteren ipv bufferen zoals nu het geval is, zie mijn eerdere screenshot.

[ Voor 14% gewijzigd door Probydoby op 22-10-2026 14:20 ]

[Frankvbr]

Warmtepomp aansturen is gewoon complex. En dan zit je ook nog met wat er mogelijk is.

Mijn warmtepomp kan ik in principe sturen op watertemperatuur maar dat is via modbus en met een beperkt aantal schrijfactie's qua levensduur, dus niet ideal. Via een relais kan je de temperatuur naar max zetten, meer niet. Gaat dus via DAO niet lukken denk ik. Weet niet hoe dat bij anderen zit.

Ik zou liever in DAO wat settings instellen qua graaddagen, en aantal sensoren koppelen (werkelijk verbruik, boilervat verwarmen ja/nee) zodat DAO puur het energieverbruik voorspelt maar geen aansturing doet of plant, maar wel rekening kan houden met verbruik voor de accu.

[dingo35]

@Probydoby Waarom zet je niet eens een test-experimentje op, waarbij je in diverse scenarios de kosten van het verwarmen van je huis test? Het enige dat je nodig hebt is een periode van ongeveer constant weer, en je kunt evt met graaddagen corrigeren.
Scenario 1: gebruik huis als thermische buffer zoals DAO nu werkt
Scenario 2: je huidige stookstrategie zonder DAO
Scenario 3: je warmtepomp constant op laag vermogen, zoals @Knielen suggereert.

Benieuwd naar de uitkomst!

[Probydoby]

Frankvbr schreef op donderdag 22 oktober 2026 @ 14:57:
Warmtepomp aansturen is gewoon complex. En dan zit je ook nog met wat er mogelijk is.

Mijn warmtepomp kan ik in principe sturen op watertemperatuur maar dat is via modbus en met een beperkt aantal schrijfactie's qua levensduur, dus niet ideal. Via een relais kan je de temperatuur naar max zetten, meer niet. Gaat dus via DAO niet lukken denk ik. Weet niet hoe dat bij anderen zit.

Ik zou liever in DAO wat settings instellen qua graaddagen, en aantal sensoren koppelen (werkelijk verbruik, boilervat verwarmen ja/nee) zodat DAO puur het energieverbruik voorspelt maar geen aansturing doet of plant, maar wel rekening kan houden met verbruik voor de accu.

Tjsa, ik ben gewoon van plan om het setpoint te verhogen. Het hoeft niet perfect DAO te volgen als het maar redelijk in de buurt komt voor bijvoorbeeld je batterij en inplannen overige apparatuur.

dingo35 schreef op donderdag 22 oktober 2026 @ 14:58:
@Probydoby Waarom zet je niet eens een test-experimentje op, waarbij je in diverse scenarios de kosten van het verwarmen van je huis test? Het enige dat je nodig hebt is een periode van ongeveer constant weer, en je kunt evt met graaddagen corrigeren.
Scenario 1: gebruik huis als thermische buffer zoals DAO nu werkt
Scenario 2: je huidige stookstrategie zonder DAO
Scenario 3: je warmtepomp constant op laag vermogen, zoals @Knielen suggereert.

Benieuwd naar de uitkomst!

Ik zal die scenario's eens uitwerken, ik denk alleen wel dat ik het ga berekenen ipv uitvoeren want scenario 1 krijg ik er niet doorheen thuis (dat zou waarschijnlijk de temperatuur met 2-3 graden verhogen in huis als ik kijk naar het plan wat DAO vandaag had).

Scenario 2 en 3 is op dit moment hetzelfde, maar ik zat te denken om zelf iets te bedenken op basis van dynamische prijzen en weersvoorspelling in HA. Zodanig bedacht ik me dat ik het liever in DAO heb zodat DAO een accurate load voorspelling heeft en zo kwam dus mijn post tot stand.

Maar of het nou wel of niet rendabel is, ik pleit er dus vooral voor DAO niet onbegrenst te laten bufferen zoals hij nu wel doet . Al is het maar zodat de heating load meer in de buurt komt van de realiteit met alle voordelen die dat met zich meebrengt. Dus als je van mening bent dat een constante load altijd beter is, dan zou je dit ook moeten willen.

[dingo35]

Probleem van berekenen is dat je discussie blijft houden, enerzijds of je alle variabelen wel correct hebt meegenomen, en anderzijds de significantie hiervan.

The proof of the pudding is in the eating!

[KC27]

anboni schreef op woensdag 21 oktober 2026 @ 19:11:
[...]


Even terugkomen op een discussie van anderhalf jaar geleden, de vraag was of je Epex-Spot zou kunnen ondersteunen. Hiermee krijg je een genormaliseerde sensor in HA, waarbij de gebruiker zelf kan kiezen tussen meerdere bronnen, en er is ook een fork (https://github.com/brambo123/ha_epex_spot) die de mogelijkheid heeft om fallback sensors te configureren, zodat je bij het niet beschikbaar zijn van je primaire sensor terug kunt vallen op een andere sensor en nog steeds dezelfde genormaliseerde informatie hebt.

Maakt de DAO code waarschijnlijk ook nog wat simpeler, omdat je zelf niet meer de APIs van die 4 verschillende bronnen hoeft te blijven volgen (en de meeste mensen zullen vast ook al een dergelijke sensor in HA hebben om een dashboard mee te voeden)

Ik heb er even naar gekeken.
Ik denk voor de spot prijzen dat het mogelijk moet zijn.
Ik ga niet de reeds gedefinieerde "sources" weggooien, maar dit zou een mooie aanvullende bron kunnen zijn voor epex_spot-prijzen.
Heet die sensor met de "kale" epex prijs altijd "sensor.market_price".
Als meer gebruikers dit willen gebruiken graag een "duim" bij dit commentaar.
Bij minimaal 5 duimen ga ik het maken.

[tomvandepoel3]

tomvandepoel3 schreef op vrijdag 16 oktober 2026 @ 15:51:
[...]


Ja, dat is mijn voorbeeld. Ik zal het binnenkort aanpassen zodat het weer up to date is met de laatste EVCC versies.

Het Electric Vehicle - EV mogelijke uitbreiding voorbeeld in de Wiki is nu aangepast aan de laatste EVCC (smart + always charge) solar charging mogelijkheden.


@TheMystery dank voor het melden.

[simnet]

Knielen schreef op donderdag 22 oktober 2026 @ 13:55:
@Probydoby Je rekent jezelf veel te rijk. Je COP kakt helemaal in als je WP harder moet gaan werken. Je hebt meer thermisch verlies als de temperatuur in de kamer hoger is. Rond het vriespunt heb je veel meer defrosts. Het is al vaker besproken dat deze manier van bufferen niet efficiënt is.

Een WP is toch echt het goedkoopst als deze stabiel en constant op een zo laag mogelijke frequentie kan draaien.

Ik kan dit wel beamen. Een lucht/lucht warmtepomp is een zeer slechte termische battery. De energie opslag capaciteit van lucht is extreem laag en daarnaast is de afgifte capaciteit van lucht (aan de rest van de omgeving) erg slecht.
Dat resultaat kun je meteen testen door je WP uit te zetten. Je zult merken dat de temperatuur heel snel zakt (overigens stijgt deze ook snel), maar sprake van buffer is er nauwelijks.

Dit itt een vloerverwarming waar de warmtecapacitiet een factor 1000 hoger ligt. Met lucht een huis voorverwarmen is eigenlijk weggooien van geld, tenzij je huis potdicht zit en je niet ventileert ben je heel veel kwijt aan verliezen.

[tomvandepoel3]

hemertje schreef op woensdag 21 oktober 2026 @ 12:13:
@konehead

Ik heb de meldingen uit de wiki (08. Voorbeelden, Notificaties) aangezet en twee dingen opgemerkt:

1. De automation DAO_Last_activity_timer_ran_out draait elke 15 minuten zolang de timer idle is, dus bij een langere uitval krijg je steeds dezelfde melding. Ik gebruik nu timer.finished als trigger: één melding per uitval.

2. In DAO_Calculation_error staat input_text.dao_notification_automation, terwijl de rest van de wiki input_text.dao_notification_message gebruikt. Die moet volgens mij ook dao_notification_message zijn?

Mijn foutmelding-automation werkt met een state-trigger op de helper (alles zonder "calc afgerond" gaat naar mijn telefoon).

Beide meldingen heb ik getest en komen aan.

@hemertje Dank voor het melden. Ik zal er even naar kijken en de Wiki waar nodig aanpassen.

[Hedzie]

konehead schreef op zondag 18 oktober 2026 @ 21:08:
Changelog DAO Planning-kaart

Weer een paar verbeteringen op basis van jullie feedback, dank aan @Doopy-X- en de andere testers!

Nieuw

• Voorspelling hele dag in het totaalvak: gemeten tot nu plus het huidige DAO-plan voor de rest van de dag. Zo zie je waar je om middernacht uitkomt voor zon, verbruik en kosten.
• Instelbare rijvolgorde met de nieuwe instelling rij_volgorde, bijvoorbeeld Thuisaccu bovenaan. Rijen die je niet noemt komen onderaan; weglaten geeft de standaardvolgorde.

Verbeterd

• Duidelijkere namen in het totaalvak:
  - Vandaag: Voorspelling tot nu toe · Werkelijk tot nu toe · Voorspelling hele dag
  - Gisteren: Voorspelling hele dag · Werkelijk hele dag
  - Morgen: Voorspelling hele dag
• Auto in de Verschil-weergave: laden telt nu als afwijking. De auto staat niet in het DAO-plan, dus het plan is 0. De paarse blokjes blijven zichtbaar en de details tonen "niet gepland (0 kWh)".

Updaten
Vervang de hele kaart door de nieuwe YAML en zet daarna je eigen variables terug. rij_volgorde is nieuw en optioneel.

Wiki bijgewerkt
De wiki is bijgewerkt met de nieuwe YAML, de nieuwe instelling rij_volgorde en de nieuwe namen in het totaalvak.

Feedback blijft welkom!

Hi @konehead,

Toffe kaart heb je gemaakt!

vraagje, om circa 00:00 wordt het plan vanuit DAO overgenomen. Echter gaat dit plan eerst tot circa 23.00u.

Zodra om 14:00u de nieuwe day-ahead prijzen in DAO zijn opgenomen, wordt het plan herzien tot de volgende dag 23.00u.

Zou je dit ook niet in je kaart moeten opnemen? Het plan tot 23:00u “vandaag” zal immers nooit gevolgd worden.

Of heb ik het mis?

[Beekforel]

Ik twijfelde of er iets stuk was maar het is gewoon heel saai qua prijzen dus er wordt niets gepland.

[tomvandepoel3]

Mijn RESTfull dao_pv_forecast sensor, die de afgelopen maanden prima heeft gewerkt, heeft opeens de waarde "Unknown". Hierbij de (ongewijzigde) definitie uit de HA configuration.yaml file:

code:

  - resource: http://192.168.178.17:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 60
    sensor:
      - name: DAO PV Forecast
        unique_id: dao_pv_forecast
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

Dit is de bijbehorende stackdump (2026.10.0.rc2):

code:

[2026-10-23 11:05:50,708] fout in app: Exception on /api/report/pv_ac/vandaag_en_morgen [GET]
Traceback (most recent call last):
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/tom/day-ahead/.venv/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 "/home/tom/day-ahead/dao/webserver/app/api/routes.py", line 43, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
  File "/home/tom/day-ahead/dao/prog/da_report.py", line 3363, in get_api_data
    df["time_ts"] = df["time"].dt.tz_localize(self.time_zone)
                    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/pandas/core/accessor.py", line 127, in f
    return self._delegate_method(name, *args, **kwargs)
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/pandas/core/indexes/accessors.py", line 126, in _delegate_method
    result = method(*args, **kwargs)
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/pandas/core/indexes/datetimes.py", line 543, in tz_localize
    arr = self._data.tz_localize(tz, ambiguous, nonexistent)
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/pandas/core/arrays/_mixins.py", line 83, in method
    return meth(self, *args, **kwargs)
  File "/home/tom/day-ahead/.venv/lib/python3.13/site-packages/pandas/core/arrays/datetimes.py", line 1107, in tz_localize
    new_dates = tzconversion.tz_localize_to_utc(
        self.asi8,
    ...<3 lines>...
        creso=self._creso,
    )
  File "pandas/_libs/tslibs/tzconversion.pyx", line 382, in pandas._libs.tslibs.tzconversion.tz_localize_to_utc
ValueError: Cannot infer dst time from 2026-10-25 02:00:00, try using the 'ambiguous' argument

.../api/report/pv_ac/vandaag werkt prima
.../api/report/pv_ac/vandaag_en_morgen faalt

Ik heb geen stackdump van mijn productiesysteem 2026.9.1 maar ook daar werkt de sensor niet. Ben ik de enige met dit probleempje?

De error lijkt te wijzen op problemen met de Daylight Saving Time:

The error "Cannot infer dst time" typically occurs when there are ambiguous times due to the end of Daylight Saving Time (DST) or when the timezone information is not correctly set. To resolve this issue, you can use the 'ambiguous' argument in the tz_localize() method to handle these cases.

[ Voor 7% gewijzigd door tomvandepoel3 op 23-10-2026 11:39 ]

[KC27]

tomvandepoel3 schreef op vrijdag 23 oktober 2026 @ 11:20:
Mijn RESTfull dao_pv_forecast sensor, die de afgelopen maanden prima heeft gewerkt, heeft opeens de waarde "Unknown". Hierbij de (ongewijzigde) definitie uit de HA configuration.yaml file:

code:

  - resource: http://192.168.178.17:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 60
    sensor:
      - name: DAO PV Forecast
        unique_id: dao_pv_forecast
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

Dit is de bijbehorende stackdump (2026.10.0.rc2):

[...]


.../api/report/pv_ac/vandaag werkt prima
.../api/report/pv_ac/vandaag_en_morgen faalt

Ik heb geen stackdump van mijn productiesysteem 2026.9.1 maar ook daar werkt de sensor niet. Ben ik de enige met dit probleempje?

De error lijkt te wijzen op problemen met de Daylight Saving Time:

[...]

Ja we gaan weer naar de wintertijd.
Ik dacht dat dit probleem vorig jaar was gefixed, maar niet dus ....
Dank voor het melden.
Ik ga ernaar kijken.

[wmc]

KC27 schreef op dinsdag 10 maart 2026 @ 22:04:

Change

Changed entity hp heat demand from input_boolean (values "on"/"off" to input_select values "off"/"eco"/"max"(="on")

Ik kwam er vandaag achter dat dit nooit in de wiki terecht is gekomen, kan ik dit updaten of is er beperkt schrijfrecht?

[KC27]

wmc schreef op vrijdag 23 oktober 2026 @ 14:55:
[...]


Ik kwam er vandaag achter dat dit nooit in de wiki terecht is gekomen, kan ik dit updaten of is er beperkt schrijfrecht?

Of levert een kant en klaar stukje tekst aan via een dm naar @Torch1969 ,
maar als je meer wilt bijdragen (graag!): kan ik je ook uitnodigen als "collaborator" en dan krijg je schrijfrechten in de wiki.
Laat het maar weten.

[Doopy-X-]

@konehead
Vraagje over het dashboard:

Ik heb zojuist een EV toegevoegd aan DAO om die ook de meest ideale laadmomenten te laten bepalen.

Ik zie die geplande laadmomenten voor de EV echter niet terug in de rij 'Auto', zou dat niet netjes zijn?

[wmc]

KC27 schreef op vrijdag 23 oktober 2026 @ 14:59:
[...]

Of levert een kant en klaar stukje tekst aan via een dm naar @Torch1969 ,
maar als je meer wilt bijdragen (graag!): kan ik je ook uitnodigen als "collaborator" en dan krijg je schrijfrechten in de wiki.
Laat het maar weten.

ik heb @Torch1969 een berichtje gestuurd, mocht ik meer dingen zien, dan meld ik me voor schrijfrechten.

[Hippe Lip]

Frankvbr schreef op donderdag 22 oktober 2026 @ 14:57:
Warmtepomp aansturen is gewoon complex. En dan zit je ook nog met wat er mogelijk is.

Mijn warmtepomp kan ik in principe sturen op watertemperatuur maar dat is via modbus en met een beperkt aantal schrijfactie's qua levensduur, dus niet ideal. Via een relais kan je de temperatuur naar max zetten, meer niet. Gaat dus via DAO niet lukken denk ik. Weet niet hoe dat bij anderen zit.

Ik zou liever in DAO wat settings instellen qua graaddagen, en aantal sensoren koppelen (werkelijk verbruik, boilervat verwarmen ja/nee) zodat DAO puur het energieverbruik voorspelt maar geen aansturing doet of plant, maar wel rekening kan houden met verbruik voor de accu.

Dat is precies het punt waar ik nu ook mee zit. Mijn W/W-WP werkt nu helemaal weersafhankelijk, dus zonder kamerthermostaat. Erg stabiel, dus daar wil ik geen DAO aan laten sleutelen.
Bovendien kan door de traagheid (uitsluitend vloerverwarming) er nagenoeg geen voordeel uit gehaald worden als de WP wel aangestuurd zou worden. En ik ben bang dat het ten koste van rendement en comfort gaat.

Maar om mijn batterijgebruik te optimaliseren moet DAO wel weten hoeveel die WP die dag gaat verbruiken. Ik weet hoeveel graaddagen er elektrisch nodig zijn en DAO weet het weer, dus kan die uitrekenen met hoeveel kWh’s die voor een specifieke dat met het dan geldende weer en buitentemperatuur er nodig zijn voor de WP.

@KC27 Zit een dergelijke functie erin?
En zo nee, is dit dan een goede suggestie voor ‘product improvement’, zoals dat zo mooi heet?

[Beekforel]

Wat jullie noemen @Frankvbr en @Hippe Lip kan toch prima met wat virtuele entities? Wat DAO doet hoeft niet daadwerkelijk aan je WP gekoppeld te zijn, als DAO maar wel lees wat je WP doet?

[KC27]

Hippe Lip schreef op vrijdag 23 oktober 2026 @ 22:11:
[...]

Dat is precies het punt waar ik nu ook mee zit. Mijn W/W-WP werkt nu helemaal weersafhankelijk, dus zonder kamerthermostaat. Erg stabiel, dus daar wil ik geen DAO aan laten sleutelen.
Bovendien kan door de traagheid (uitsluitend vloerverwarming) er nagenoeg geen voordeel uit gehaald worden als de WP wel aangestuurd zou worden. En ik ben bang dat het ten koste van rendement en comfort gaat.

Maar om mijn batterijgebruik te optimaliseren moet DAO wel weten hoeveel die WP die dag gaat verbruiken. Ik weet hoeveel graaddagen er elektrisch nodig zijn en DAO weet het weer, dus kan die uitrekenen met hoeveel kWh’s die voor een specifieke dat met het dan geldende weer en buitentemperatuur er nodig zijn voor de WP.

@KC27 Zit een dergelijke functie erin?
En zo nee, is dit dan een goede suggestie voor ‘product improvement’, zoals dat zo mooi heet?

Veel (zo niet alles) van wat jij wilt weten zit al in DAO.
Als je deze paragraaf uit de wiki eens doorleest ben je een stuk wijzer:
https://github.com/cornee...lingen#warmtepomp-heating
Ik stuur zelf mijn w/w wp aan met de "heating_curve" regeling. DAO rekent als schaduw bij deze regeling ook de "power mode" om een voorspelling te krijgen wanneer en hoeveel de wp verbruikt.

[ Voor 8% gewijzigd door KC27 op 24-10-2026 00:13 ]

[DaBit]

Is op dat warmtepomp-verbruik ook niet vrij eenvoudig zo'n gradient boosting ML-model op los te laten, net zoals PV-opbrengst en EPEX-prijzen? Velen van ons hebben een database gevuld met actuele waarden.

[KC27]

DaBit schreef op zaterdag 24 oktober 2026 @ 10:05:
Is op dat warmtepomp-verbruik ook niet vrij eenvoudig zo'n gradient boosting ML-model op los te laten, net zoals PV-opbrengst en EPEX-prijzen? Velen van ons hebben een database gevuld met actuele waarden.

Dat vind ik wel een interessante gedachte. Ga ik over nadenken.
Niet alleen kwa voorspelling van het verbruik, maar ook kwa voorspelling van de warmte behoefte (invloed van temperatuur, zoninstraling en wind) is het dan beter dan alleen de graaddagen methode.

[ Voor 20% gewijzigd door KC27 op 24-10-2026 10:50 ]

[oscaarbasgitaar]

KC27 schreef op zaterdag 24 oktober 2026 @ 00:10:
[...]

Veel (zo niet alles) van wat jij wilt weten zit al in DAO.
Als je deze paragraaf uit de wiki eens doorleest ben je een stuk wijzer:
https://github.com/cornee...lingen#warmtepomp-heating
Ik stuur zelf mijn w/w wp aan met de "heating_curve" regeling. DAO rekent als schaduw bij deze regeling ook de "power mode" om een voorspelling te krijgen wanneer en hoeveel de wp verbruikt.

de winst die je er misschien nog kan uithalen is marginaal als je vloerverwarming hebt. Omdat je hier naar lage watertemperaturen moet opwarmen met dus sowieso al een zeer goede COP.
je kan misschien nog 5% besparen op "2 x niets"...

De regelstrategie die @KC27 toepast is inderdaad juist: als de prijs laag is, of er is zonne-energie over: dan mag de temperatuur iets omhoog zodat je aan een betere prijs je warmte kan bufferen voor later op de dag wanneer het duurder is, zodat dan je warmtepomp niet, of minder hard moet werken.

Ook de geschatte warmtevraag is redelijk goed: ik heb wat moeten zoeken en ik geraak er nog steeds niet uit hoe exact de berekening loopt. Maar ik heb een standaard waarde en met de flex zetting kan ik een correctie toepassen voor heel zonnige dagen, want dan is er meer "gratis" warmte of voor winderige dagen, want dan heb ik meer warmte nodig.

Dus @Hippe Lip op zich hoef je DAO niet noodzakelijk je warmtepomp laten sturen want de winst is klein, maar het kan dus wel.

Trouwens vloerverwarming is ook een batterij: een thermische batterij. Als je goed warmte kan opslaan / bufferen is het bovendien een véél efficiëntere batterij dan een elektrische thuisbatterij:
Mijn pylontech heeft een rondomrendement van ca. 78%: 1kWh in is dus 0,78kWh uit.
Een warmtepomp maakt van 1kWh COP keer kWh thermische warmte, als je die warmte niet of slechts heel traag verlies is de winst dus een veelvoud van elektrisch opslaan.


Warmte bufferen gaat goed met vloerverwarming, of als je een (zeer) groot buffervat hebt.
Het gaat redelijk in systemen met radiatoren in matig tot goed geïsoleerde huizen.


Met ventilo-convectoren of lucht-luchtwarmtepompen lukt het nagenoeg niet:
Dan gaat het eigenlijk enkel als je woning goed geïsoleerd én goed luchtdicht is én je daarboven ook nog eens een ventilatiesysteem D hebt én je tot slot ook de discipline hebt om ramen en deuren goed dicht te houden (wat misschien logisch klinkt, maar zeg dat maar eens tegen gezinnen met tieners in huis )

Maar zoals ik al eerder aangaf:
met radiatoren is er een grotere variatie van de COP bij de power stages.
(grafiekjes uit de datasheet van mijn warmtepomp, maar je kan ook de datapunten van je sensoren eens aan claude geven -> zo krijg je gelijkaardige grafieken voor jou specifieke setup thuis)


Als het buiten 10 graden is moet ik maar ca. 30° door mijn radiatoren jagen om het in huis aangenaam warm te krijgen (bovenste rij grafiekjes) en liggen mijn powerstages dus ergens tussen de gele en de groene lijn in het bovenste grafiekje COP/compressorspeed.
Maar eens het buiten -5° is moet er bijna 50° naar mijn radiatoren en worden mijn COP's bij dezelfde powerstages dus lager.

Vandaar dat ik het een waardevolle toevoeging zou vinden aan de add-on als in die stages de COP ook via een flex-setting kan bepalen. Je zou bijvoorbeeld op basis van de gemiddelde voorspelde buitentemperatuur je COP's kunnen laten varieren.

Dan is niet alleen de inschatting van het elektrisch verbruik beter: ik kan ook beperkt sturen op het vermogen dat de warmtepomp moet draaien.

Ik kan de aanvoertemperatuur enkele graden verhogen of verlagen -> verhogen is meer vermogen met een iets lagere COP, verlagen is minder vermogen maar met een hogere COP

En zo is een warmtepomp sturen toch enigzins mogelijk.

Ik val in herhaling @KC27, en ik begrijp dat jullie dit allemaal vrijwillig doen en dat tijd een schaars goed is, maar ik ben ervan overtuigd dat dit een waardevolle toevoeging zou zijn aan de add-on.
Nu pas ik een keer per week mijn config manueel aan op basis van de weersvoorspellingen van een hele week, en dat kan niet de bedoeling van automatisatie zijn

[wmc]

Ik ben sinds een paar dagen aan het experimenteren met https://community.home-as...-heating-forecasts/989204. Dit is een integratie die een voorspelling doet van de warmtevraag van je huis. Vooralsnog is de integratie zichzelf aan het inleren, ik hoop over een paar weken een betere beeld te hebben of dit wat is.

[oscaarbasgitaar]

KC27 schreef op zaterdag 24 oktober 2026 @ 10:47:
[...]

Dat vind ik wel een interessante gedachte. Ga ik over nadenken.
Niet alleen kwa voorspelling van het verbruik, maar ook kwa voorspelling van de warmte behoefte (invloed van temperatuur, zoninstraling en wind) is het dan beter dan alleen de graaddagen methode.

klopt, maar daar moet je enigzins mee opletten: ik heb dit een tijdje willen doen met een integratie "heating analytics", maar dat werkt ook maar half...

Want dan moet je ook al rekening houden met rolluiken /screens open en dicht , eventuele bijverwarming (een kachel, maar ook een oven in de keuken,...) zelf het aantal mensen in een ruimte kan je trainingsdata al ruis geven: elke persoon is ongeveer 100 watt, ramen en deuren veel of weinig open, ventilatie,...

Op mijn werk werken we soms met regelaars van https://builtwins.com, ontwikkeld ism de KUL. Die zijn gebaseerd op fysische modellen en houden dus met heel veel parameters rekening (tot interne warmtewinsten van verlichting)

De 2 main drivers naast buitentemperatuur zijn windkracht en zoninstraling. Dus een correctiefactor voor die 2 bepalen is al een hele stap vooruit.

[oscaarbasgitaar]

En nu we toch aan het volspammen zijn:

gewoon nog even zeggen dat dit een geweldige add-on is.
Hulde aan de ontwikkelaars!

[DaBit]

oscaarbasgitaar schreef op zaterdag 24 oktober 2026 @ 11:51:
klopt, maar daar moet je enigzins mee opletten: ik heb dit een tijdje willen doen met een integratie "heating analytics", maar dat werkt ook maar half...

Ja maar persoonlijk gezien vind ik half al best prima.
Ik ga de warmtepomp niet sturen. Been there done that vorig jaar, geeft me niet wat ik ervan gehoopt had. Laat de thuisaccu het maar oplossen.

Waar ik wel in geinteresseerd ben: DAO de voorspelde elektraconsumptie van de warmtepomp laten verrekenen. Samen met de EPEX-voorspeller word de 32kWh capaciteit van de thuisaccu dan beter gebruikt om optimalere laadmomenten te kiezen, schat ik zo.

Of die voorspelling van de warmtepomp-electraconsumptie dan heel accuraat is of niet lijkt me niet zo spannend. Die onzekerheid word opgeteld bij de onzekerheid van de zonne-opbrengst, baseload, EPEX-voorspelling, etcetera. Als DAO regelmatig zijn plannetje herziet komt het wel goed.

Maar, ik zou eigenlijk eerst eens moeten kijken of die warmtepomp-consumptie simpelweg in de baseload laten verdwijnen niet al optimaal genoeg is.

[DaBit]

Grafiekje van januari 2026:



Kijk ik naar 1/8/15/22/29 januari dan heb ik 32, 32, 20, 25, 32kWh per dag waarbij de verdeling over de uren ook wel grotendeels gelijk is. Dan zit die baseloadplanning er grofweg 4kWh per dag naast en de energiebehoefte per dag is zo groot dat de thuisbatterij het toch niet dagenlang volhoud.

Tsja. Ik heb zo mijn twijfels of een accuratere WP-consumptie-voorspelling de planning van de thuisbatterij veel efficienter zou maken.

[ Voor 3% gewijzigd door DaBit op 24-10-2026 12:38 ]

[rescla]

@KC27 Er lijkt een DST bug te zijn met de overgang naar wintertijd. Krijg ik bij het aanroepen van vandaag_en_morgen.

code:

ValueError: Cannot infer dst time from 2026-10-25 02:00:00, try using the 'ambiguous' argument                                                                                                                                            
     File "/root/dao/prog/da_report.py", line 3356, in get_api_data                                                                                                                                                                          
       df["time_ts"] = df["time"].dt.tz_localize(self.time_zone)

[edit] Iemand anders had hem ook al gevonden: https://github.com/corneel27/day-ahead/pull/964/changes

[ Voor 11% gewijzigd door rescla op 24-10-2026 13:39 ]

[TheMystery]

Hier ook aan het denken of ik de warmtepomp via dao moet laten aansturen, voor nu op mijn Nibe Spa aangezet op modus comfort (opslaan geprobeerd maar toen werdt het erg warm en duur wat ie wou bufferen) zodat er een beetje rekening gehouden wordt met prijzen. Denk dat als dao dit zou kunnen berekenen dat de accu idd beter ingezet kan worden.

[TheMystery]

Ik heb sinds vandaag de volgende fout als ik via de rest data opvraag bij dao, ik heb home assistant en dao al herstart maar dit lost het niet op.
Wat zou dit kunnen zijn? een fout in de data ofzo

code:

Logger: homeassistant.components.rest.data
Bron: components/rest/data.py:217
Integratie: RESTful (documentatie, problemen)
Eerst voorgekomen: 15:22:21 (2 gebeurtenissen)
Laatst gelogd: 15:24:32

REST request to http://1f491d2b-day-ahead-opt:5000/api/report/da/vandaag_en_morgen returned status 500 with text/html; charset=utf-8 response: <!doctype html> <html lang=en> <title>500 Internal Server Error</title> <h1>Internal Server Error</h1> <p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p>

Als ik het via de browser benader krijg ik dit ook te zien:
Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

Hoe zou ik dit op kunnen lossen?

[Isdatzo]

oscaarbasgitaar schreef op zaterdag 24 oktober 2026 @ 11:38:
[...]

de winst die je er misschien nog kan uithalen is marginaal als je vloerverwarming hebt. Omdat je hier naar lage watertemperaturen moet opwarmen met dus sowieso al een zeer goede COP.
je kan misschien nog 5% besparen op "2 x niets"...

Hier ben ik het niet mee eens, zeker niet in het tussenseizoen of op de dagen die in de winter vallen maar eigenlijk een herfstdag zijn. Op die dagen is het minimumvermogen van de warmtepomp in veel gevallen hoger dan het warmteverlies van de woning. In die gevallen zal de warmtepomp slechts een (klein) deel van de dag hoeven draaien om het warmteverlies te compenseren.

Gister was dat bijvoorbeeld 14kWh (gemiddeld warmteverlies van 580W, geen enkele warmtepomp kan zo ver terugmoduleren), en op dagen met een grote gang in temperatuur en/of een grote spread in elektriciteitsprijs kan het wel degelijk uitmaken op welk moment je die 14 kWh warmte opwekt.

Ik heb nu zelf een logica opgezet die op basis van mijn historische data kijkt wanneer de (voorspelde) benodigde warmte het best kan worden opgewekt. Ik weet immers het verband tussen buitentemperatuur en het warmteverlies van de woning, het verband tussen buitentemperatuur en COP van de warmtepomp, de stroomprijs en de voorspelde buitentemperatuur.

De logica kijkt naar de huidige binnentemperatuur en probeert binnen een in te stellen boven- en onderwaarde te blijven, met een in te stellen maximum aantal uren tussen de runs in, en met een in te stellen minimum run-lengte. Tot op heden bevalt me dat best prima.

[oscaarbasgitaar]

Isdatzo schreef op zaterdag 24 oktober 2026 @ 16:29:
[...]


Hier ben ik het niet mee eens, zeker niet in het tussenseizoen of op de dagen die in de winter vallen maar eigenlijk een herfstdag zijn. Op die dagen is het minimumvermogen van de warmtepomp in veel gevallen hoger dan het warmteverlies van de woning. In die gevallen zal de warmtepomp slechts een (klein) deel van de dag hoeven draaien om het warmteverlies te compenseren.

Gister was dat bijvoorbeeld 14kWh (gemiddeld warmteverlies van 580W, geen enkele warmtepomp kan zo ver terugmoduleren), en op dagen met een grote gang in temperatuur en/of een grote spread in elektriciteitsprijs kan het wel degelijk uitmaken op welk moment je die 14 kWh warmte opwekt.

Ik heb nu zelf een logica opgezet die op basis van mijn historische data kijkt wanneer de (voorspelde) benodigde warmte het best kan worden opgewekt. Ik weet immers het verband tussen buitentemperatuur en het warmteverlies van de woning, het verband tussen buitentemperatuur en COP van de warmtepomp, de stroomprijs en de voorspelde buitentemperatuur.

De logica kijkt naar de huidige binnentemperatuur en probeert binnen een in te stellen boven- en onderwaarde te blijven, met een in te stellen maximum aantal uren tussen de runs in, en met een in te stellen minimum run-lengte. Tot op heden bevalt me dat best prima.

daar heb je natuurlijk helemaal gelijk in...
maar da's het gevolg van een andere discussie die ik al met veel studiebureau's technieken heb gevoerd: het standaard overdimensioneren van warmtepompen.

De warmteverliesberekening van mijn woning heb ik volgens de geldende norm zelf gedaan. Ik kwam iets van 10kW uit... de meeste installateurs wouden op basis daarvan en op basis van mijn historisch verbruik een warmtepomp van 12 kW plaatsen, met dan ook een minimum vermogen van 4kW.

Ik heb er een laten plaatsen van 6kW, die moduleert terug tot 1 kW. Scheelt me ca. 10.000€ installatiekost en bovendien pendelt ze minder -> dus een beter rendement, en ze gaat langer mee

Want het aantal uren dat ik iets tussen 1 en 4 nodig heb is 75% van het stookseizoen. En de uren dat ik werkelijk meer dan 8 kW nodig heb kan ik op één hand tellen. Door de woning op de koudste dagen van het jaar niet meer te laten afkoelen is die 6 kW voldoende: enkel als het dagen na elkaar vriest, zonder zoninstraling en met veel wind ga'k koud hebben...
Het is te zeggen: de woning staat op 21 graden en koelt dan met ca. 2kW/uur af.
Want ik kan wel nog steeds 6kW leveren.


En als het écht nodig zou zijn, dan steek ik wel onze kachel even aan.

[Isdatzo]

oscaarbasgitaar schreef op zaterdag 24 oktober 2026 @ 17:14:
[...]

daar heb je natuurlijk helemaal gelijk in...
maar da's het gevolg van een andere discussie die ik al met veel studiebureau's technieken heb gevoerd: het standaard overdimensioneren van warmtepompen.

De warmteverliesberekening van mijn woning heb ik volgens de geldende norm zelf gedaan. Ik kwam iets van 10kW uit... de meeste installateurs wouden op basis daarvan en op basis van mijn historisch verbruik een warmtepomp van 12 kW plaatsen, met dan ook een minimum vermogen van 4kW.

Ik heb er een laten plaatsen van 6kW, die moduleert terug tot 1 kW. Scheelt me ca. 10.000€ installatiekost en bovendien pendelt ze minder -> dus een beter rendement, en ze gaat langer mee

Want het aantal uren dat ik iets tussen 1 en 4 nodig heb is 75% van het stookseizoen. En de uren dat ik werkelijk meer dan 8 kW nodig heb kan ik op één hand tellen. Door de woning op de koudste dagen van het jaar niet meer te laten afkoelen is die 6 kW voldoende: enkel als het dagen na elkaar vriest, zonder zoninstraling en met veel wind ga'k koud hebben...
Het is te zeggen: de woning staat op 21 graden en koelt dan met ca. 2kW/uur af.
Want ik kan wel nog steeds 6kW leveren.


En als het écht nodig zou zijn, dan steek ik wel onze kachel even aan.

Het gesprek dwaalt zo wel een beetje af van DAO, maar geen enkele warmtepomp geeft zowel ruim onder nul genoeg vermogen af om de kiet warm te houden én moduleert ver genoeg terug om bij dubbel cijfers boven nul continu te kunnen draaien.

Moduleert jouw warmtepomp terug tot een afgifte van 1kW bij 10 graden? Ik heb hier een Vaillant 5kW, die erom bekend staat ver terug te kunnen moduleren, en bij een buitentemperatuur van 10 graden op minimum toerental (30 rps) geeft 'ie zo'n 2.7kW warmte af bij een stroomverbruik van ongeveer 410W (COP +- 6.5).

Ik zie dat overigens ook niet als een probleem. En logischerwijs daalt het minimum afgiftevermogen bij een lagere temperatuur.

[oscaarbasgitaar]

14 kWh met 2,7 als min is inderdaad iets wat je wil inplannen op de goedkoopste momenten

Maar 14kWh thermisch in vloerverwarming op 25 graden met bron 10 + graden aan een COP van 7 of zo geeft 2 kWh elektrisch

Met een spread van 0,2€/ kWh spreken we dus over misschien de volle 0,4€/ dag.

Met hogere temperaturen (ik verwarm met radiatoren) wordt het zinvoller om te sturen. Maar nu is de winst van DAO voor de WP bij mij ook beperkt.

[Isdatzo]

oscaarbasgitaar schreef op zaterdag 24 oktober 2026 @ 20:09:
14 kWh met 2,7 als min is inderdaad iets wat je wil inplannen op de goedkoopste momenten

Maar 14kWh thermisch in vloerverwarming op 25 graden met bron 10 + graden aan een COP van 7 of zo geeft 2 kWh elektrisch

Met een spread van 0,2€/ kWh spreken we dus over misschien de volle 0,4€/ dag.

Met hogere temperaturen (ik verwarm met radiatoren) wordt het zinvoller om te sturen. Maar nu is de winst van DAO voor de WP bij mij ook beperkt.

Niet alleen de spread is van belang, maar ook het verschil tussen de buitentemperatuur en de aanvoertemperatuur. Op een dag met een grote gang kan er zo 10 graden verschil in minimum- en maximumtemperatuur zijn (12 oktober bijvoorbeeld, met respectievelijk 3 en 16 graden), met een navenant verschil in COP.

Moet ik een nier verkopen als ik er niks mee doe? Absoluut niet, maar we zitten hier op Tweakers .

[KC27]

TheMystery schreef op zaterdag 24 oktober 2026 @ 15:28:
Ik heb sinds vandaag de volgende fout als ik via de rest data opvraag bij dao, ik heb home assistant en dao al herstart maar dit lost het niet op.
Wat zou dit kunnen zijn? een fout in de data ofzo

code:

Logger: homeassistant.components.rest.data
Bron: components/rest/data.py:217
Integratie: RESTful (documentatie, problemen)
Eerst voorgekomen: 15:22:21 (2 gebeurtenissen)
Laatst gelogd: 15:24:32

REST request to http://1f491d2b-day-ahead-opt:5000/api/report/da/vandaag_en_morgen returned status 500 with text/html; charset=utf-8 response: <!doctype html> <html lang=en> <title>500 Internal Server Error</title> <h1>Internal Server Error</h1> <p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p>

Als ik het via de browser benader krijg ik dit ook te zien:
Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

Hoe zou ik dit op kunnen lossen?

Deze fout is ook al eerder gemeld.
Het komt door de aanstaande wintertijd. De fix is klaar maar die krijg ik voor morgen niet gepubliceerd. Dus je zit een paar dagen met een probleempje.
Excuses voor het ongemak.

[tomahowk]

Ik heb nu sinds een tijdje DAO draaien en nu ook na de planningen goed in de gaten te houden ook daadwerkelijk een automatisering er aan gekoppeld voor het laden en ontladen van mijn Marstek batterij. Knap stukje software van de ontwikkelaars, dank!

Het is mij nu dus gelukt de batterij te ontladen en opladen via de prognose van DAO. Maar, ik begrijp dit stukje niet helemaal uit de handleiding.

entity balance switch: entiteit waarmee je Home Assistant in samenwerking met de omvormer op "balanceren" zet (overrult set power feedin)
Hiermee zorg je ervoor dat er geen levering c.q. teruglevering aan het net plaatsvindt. Deze optie wordt met name interessant en bruikbaar als er een verschil is in tarief tussen leveren en terugleveren. Bijvoorbeeld als je niet meer kunt salderen. Maar ook bij de strategie "nul op de meter", zal het programma vaker van deze mogelijkheid gebruik willen maken.

Ik zou graag willen dat ook bij onverwachts verbruik in huis dat DAO niet standaard plant (bijv. een keer koekjes bakken in de oven, om maar iets te noemen), ook die batterij even moet ontladen, als bijv. de tarieven hoger zijn op dat specifieke moment dan iets later, zodat later weer opgeladen kan worden.

Hoe koppel ik deze 'entity balance switch' aan een automatisering zodat ik die 'nul op de meter' draai? En wanneer pakt DAO het weer over op 'power feedin'?

[ Voor 3% gewijzigd door tomahowk op 24-10-2026 22:31 ]

[Hippe Lip]

konehead schreef op zondag 18 oktober 2026 @ 21:08:
Changelog DAO Planning-kaart

Weer een paar verbeteringen op basis van jullie feedback, dank aan @Doopy-X- en de andere testers!

Nieuw

• Voorspelling hele dag in het totaalvak: gemeten tot nu plus het huidige DAO-plan voor de rest van de dag. Zo zie je waar je om middernacht uitkomt voor zon, verbruik en kosten.
• Instelbare rijvolgorde met de nieuwe instelling rij_volgorde, bijvoorbeeld Thuisaccu bovenaan. Rijen die je niet noemt komen onderaan; weglaten geeft de standaardvolgorde.

Verbeterd

• Duidelijkere namen in het totaalvak:
  - Vandaag: Voorspelling tot nu toe · Werkelijk tot nu toe · Voorspelling hele dag
  - Gisteren: Voorspelling hele dag · Werkelijk hele dag
  - Morgen: Voorspelling hele dag
• Auto in de Verschil-weergave: laden telt nu als afwijking. De auto staat niet in het DAO-plan, dus het plan is 0. De paarse blokjes blijven zichtbaar en de details tonen "niet gepland (0 kWh)".

Updaten
Vervang de hele kaart door de nieuwe YAML en zet daarna je eigen variables terug. rij_volgorde is nieuw en optioneel.

Wiki bijgewerkt
De wiki is bijgewerkt met de nieuwe YAML, de nieuwe instelling rij_volgorde en de nieuwe namen in het totaalvak.

Feedback blijft welkom!

Waar vind ik het hele ding, @konehead?
Waarschijnlijk kijk ik er overheen, want kan ‘m niet vinden.

[tomvandepoel3]

Hippe Lip schreef op zondag 25 oktober 2026 @ 15:51:
[...]

Waar vind ik het hele ding, @konehead?
Waarschijnlijk kijk ik er overheen, want kan ‘m niet vinden.

https://github.com/cornee...kaart-voor-Home-Assistant

[Doopy-X-]

Hippe Lip schreef op zondag 25 oktober 2026 @ 15:51:
[...]

Waar vind ik het hele ding, @konehead?
Waarschijnlijk kijk ik er overheen, want kan ‘m niet vinden.

Edit: post hierboven was eerder

Let wel op, dashboard werkt momenteel even niet vanwege REST-wintertijd-bug in DAO

[ Voor 32% gewijzigd door Doopy-X- op 25-10-2026 16:30 ]

[Hippe Lip]

@konehead
Ideetje om dat githubadres in je signature te zetten?

[Knielen]

@Hippe Lip Het is gewoon hoofdstuk 10 in de DAO wiki pagina, prima plek toch?

[GigaTexel_BE]

Hallo!

Ik ben helemaal nieuw in dit topic :-)

Zijn er plannen om de uur/kwartierprijzen rechtstreeks uit HA te kunnen halen?

• De meeste gebruikers hebben al een nordpool/entso-e/benglian energy contract integratie draaien. Door dit parallel te organiseren in DAO moet elke contract- of belastingswijziging 2 keer gebeuren
• Belgische energiecontracten zijn legendarisch complex, met verschillen per gewest voor wat betreft de belastingen en per regio voor de netkosten. Niet altijd even eenvoudig om dat correct te implementeren met de variabelen die beschikbaar zijn
• Ik gebruik een integratie die de prijzen voor mijn contract ophaalt en omrekent (https://github.com/renaud...ant_be_electricity_prices) en de all-in prijzen per uur/kwartier beschikbaar maakt in HA. Het zou erg netjes zijn om DAO gewoon die zelfde data te laten hergebruiken, al dan niet via een helper om dit in een vast formaat te krijgen

[manusjevanalles]

Ik probeer mijn batterij in DAO toe te voegen, maar ik krijg de volgende foutmelding:

code:

ERROR while running Cbc. Signal SIGSEGV caught. Getting stack trace.

Met daaronder een hele lap tekst met foutmeldingen. Zodra ik het stukje config van de batterij weghaal, werkt de berekening in DAO weer.

Config batterij:

code:

  "battery": [{
   "name": "Batterij",
   "entity_actual_level": "input_number.helper_dao_batterij_soc_proxy",
   "capacity": 1.5,
   "upper_limit": 100, "lower_limit": 10,
   "charge_stages":    [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
   "discharge_stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
   "minimum_power": 50,
   "dc_to_bat_efficiency": 0.94,
   "bat_to_dc_efficiency": 0.94,
   "cycle_cost": 0.005,
   "entity_set_power_feedin": "input_number.helper_dao_batterij_set_vermogen_invoer",
   "entity_set_operating_mode": "input_select.helper_dao_batterij_modus",
   "entity_set_operating_mode_on": "Aan",
   "entity_set_operating_mode_off": "Uit",
   "entity_stop_inverter": "input_datetime.helper_dao_batterij_stop",
   "entity_from_battery": "input_number.helper_dao_batterij_uit_batterij",
   "entity_from_ac": "input_number.helper_dao_batterij_uit_ac",
   "entity_calculated_soc": "input_number.helper_dao_batterij_berekende_soc",
   "entity_min_soc_end_opt": "input_number.helper_dao_batterij_min_soc_einde_opt",
   "entity_max_soc_end_opt": "input_number.helper_dao_batterij_max_soc_einde_opt"
  }],

Ligt het aan de config of gaat het ergens anders fout?

[konehead]

Hippe Lip schreef op zondag 25 oktober 2026 @ 16:51:
@konehead
Ideetje om dat githubadres in je signature te zetten?

Goede, doe ik!!

[konehead]

Doopy-X- schreef op zondag 25 oktober 2026 @ 16:29:
[...]

Edit: post hierboven was eerder

Let wel op, dashboard werkt momenteel even niet vanwege REST-wintertijd-bug in DAO

Inderdaad! Na morgen ga ik naar de bugjes en change requests kijken!

[Dogooder]

@manusjevanalles draai DAO in een VM? Staat je processor op host?

En meestal helpt de hele rits aan foutmeldingen wel om te achterhalen waarom het fout gaat.

[manusjevanalles]

Dogooder schreef op zondag 25 oktober 2026 @ 22:11:
@manusjevanalles draai DAO in een VM? Staat je processor op host?

En meestal helpt de hele rits aan foutmeldingen wel om te achterhalen waarom het fout gaat.

Klopt, Ubuntu in een VM op proxmox en DAO draait weer in docker. Ik heb de binaries al zelf gecompiled toen ik eerder al tegen problemen aan liep. Ik had allen PV en de wasmachine zonder probleem, maar bij de batterij gaat het dus mis.

Ik kan nu niet bij de foutmeldingen, zal dolie morgen posten hier.

[HenkHA22]

@KC27 – DAO 2026.9.1: warmtepomp ontbreekt structureel in dagplanning (0 kWh), terwijl werkelijk verbruik 13–15 kWh/dag bedraagt

Ik ben bezig DAO te integreren in mijn Home Energy Management System (Home Assistant, Sessy-accu’s, zonnepanelen en een DeWarmte-warmtepomp).

Met een eigen Sankey-visualisatie vergelijk ik de DAO-dagplanning met de daadwerkelijke energiestromen. Daarbij is een ernstig probleem zichtbaar geworden.

De warmtepomp ontbreekt op meerdere opeenvolgende dagen volledig in de DAO-planning, terwijl deze in werkelijkheid een van de grootste elektriciteitsverbruikers is.

De cijfers:

Datum	DAO-plan WP	Werkelijk WP-verbruik
22 oktober	7,60 kWh	14,59 kWh
23 oktober	0,00 kWh	13,48 kWh
24 oktober	0,00 kWh	14,37 kWh

Ook voor 25 oktober wordt geen warmtepompverbruik gepland. De realisatie daarvan is nog niet definitief vastgesteld.

Dit heeft grote gevolgen voor de totale optimalisatie. DAO maakt immers beslissingen over netafname, accu’s, laden/ontladen en teruglevering op basis van een sterk onderschatte elektriciteitsvraag.

Wat hebben we onderzocht?

In het DAO-log van de run op 23 oktober om 23:45:25 staat:

• Gewogen graaddagen vandaag: 5,0 K·dag
• Gewogen graaddagen morgen: 4,8 K·dag
• Graaddagenfactor: 4,6 kWh/K·dag
• Totale berekende warmtebehoefte: 45,0 kWh
• Reeds geproduceerde warmte: 55,9 kWh
• Nog benodigde warmte: 0,0 kWh
• Conclusie DAO: warmtepomp wordt niet ingepland

De gebruikte entiteit voor reeds geproduceerde warmte is sensor.hems_dao_wp_heat_produced_today, een dagelijkse Home Assistant-utility_meter die om middernacht reset.

Die sensor lijkt correct te functioneren. Voor 24 oktober rapporteert hij 57,77 kWh thermische energie, tegenover 57,8 kWh in de DeWarmte-app.

Mijn vermoeden

DAO berekent de warmtebehoefte voor vandaag én morgen samen en trekt daar de reeds geproduceerde warmte van vandaag vanaf.

Wanneer de warmteproductie van vandaag hoger is dan de berekende behoefte voor beide dagen samen, wordt de resterende behoefte nul.

Maar de warmte die vandaag is geproduceerd, is grotendeels gebruikt om het huis vandaag te verwarmen. Die kan niet zonder meer als beschikbare warmtevoorraad voor morgen worden beschouwd.

Dit lijkt vooral bij een DAO-run laat op de avond tot onrealistische uitkomsten te leiden.

Daarnaast valt iets op aan de COP-configuratie.

De standaard vermogensstappen bevatten COP-waarden van 7,1 bij 225 W tot 4,0 bij 1.250 W.

Onze warmtepomp rapporteert over de betreffende dagen een gemiddelde COP van ongeveer 4,2. We hebben bij onze installatie nog nooit een dag-COP van 5 of hoger vastgesteld.

Ik vraag me daarom ook af hoe representatief de gebruikte COP-/vermogenscurve is voor de elektrische verbruiksprognose.

Mijn vragen:

1. Is de hierboven beschreven berekening van de tweedaagse warmtebehoefte en de aftrek van reeds geproduceerde warmte bedoeld gedrag?
2. Hoe voorkomt DAO dat reeds verbruikte warmte van vandaag ten onrechte wordt beschouwd als beschikbare warmte voor morgen?
3. Is er in de bestaande configuratie een mogelijkheid om dit te corrigeren?
4. Is er al een verbetering van het warmtevoorspellingsmodel voorzien of in ontwikkeling?
5. Hoe kunnen we de COP-/vermogensstappen het beste afstemmen op werkelijk gemeten prestaties van de warmtepomp?

Ik wil bij voorkeur binnen de officiële DAO-configuratiemogelijkheden blijven en de broncode niet aanpassen, zodat toekomstige updates probleemloos blijven verlopen.

Het belangrijkste punt: wanneer een warmtepomp die dagelijks circa 14 kWh elektriciteit gebruikt volledig ontbreekt in de voorspelling, zijn ook de daarop gebaseerde accu- en netoptimalisatie onvoldoende betrouwbaar.

Ik ben benieuwd naar je verklaring en eventuele oplossingsrichting. De relevante DAO-logs, configuratie en Sankey-vergelijkingen zijn beschikbaar.

[Hippe Lip]

Knielen schreef op zondag 25 oktober 2026 @ 16:53:
@Hippe Lip Het is gewoon hoofdstuk 10 in de DAO wiki pagina, prima plek toch?

Kijk, die had ik nog niet door
Thnx

[KC27]

HenkHA22 schreef op zondag 25 oktober 2026 @ 23:31:
@KC27 – DAO 2026.9.1: warmtepomp ontbreekt structureel in dagplanning (0 kWh), terwijl werkelijk verbruik 13–15 kWh/dag bedraagt

Ik ben bezig DAO te integreren in mijn Home Energy Management System (Home Assistant, Sessy-accu’s, zonnepanelen en een DeWarmte-warmtepomp).

Met een eigen Sankey-visualisatie vergelijk ik de DAO-dagplanning met de daadwerkelijke energiestromen. Daarbij is een ernstig probleem zichtbaar geworden.

De warmtepomp ontbreekt op meerdere opeenvolgende dagen volledig in de DAO-planning, terwijl deze in werkelijkheid een van de grootste elektriciteitsverbruikers is.

De cijfers:

Datum	DAO-plan WP	Werkelijk WP-verbruik
22 oktober	7,60 kWh	14,59 kWh
23 oktober	0,00 kWh	13,48 kWh
24 oktober	0,00 kWh	14,37 kWh

Ook voor 25 oktober wordt geen warmtepompverbruik gepland. De realisatie daarvan is nog niet definitief vastgesteld.

Dit heeft grote gevolgen voor de totale optimalisatie. DAO maakt immers beslissingen over netafname, accu’s, laden/ontladen en teruglevering op basis van een sterk onderschatte elektriciteitsvraag.

Wat hebben we onderzocht?

In het DAO-log van de run op 23 oktober om 23:45:25 staat:

[list]
• Gewogen graaddagen vandaag: 5,0 K·dag
• Gewogen graaddagen morgen: 4,8 K·dag
• Graaddagenfactor: 4,6 kWh/K·dag

Ik vermoed dat jouw graaddagen factor te laag staat.
Met 5 graaddagen en een factor van 4,5 kWh/K.dag kom je maar op 22,5 kWh per dag, terwijl je ruim het dubbele nodig hebt.
Dus ik adviseer om deze factor op 9 of 10 te zetten.

• Totale berekende warmtebehoefte: 45,0 kWh
• Reeds geproduceerde warmte: 55,9 kWh
• Nog benodigde warmte: 0,0 kWh
• Conclusie DAO: warmtepomp wordt niet ingepland
[/list]
De gebruikte entiteit voor reeds geproduceerde warmte is sensor.hems_dao_wp_heat_produced_today, een dagelijkse Home Assistant-utility_meter die om middernacht reset.

Die sensor lijkt correct te functioneren. Voor 24 oktober rapporteert hij 57,77 kWh thermische energie, tegenover 57,8 kWh in de DeWarmte-app.

Mijn vermoeden

DAO berekent de warmtebehoefte voor vandaag én morgen samen en trekt daar de reeds geproduceerde warmte van vandaag vanaf.

Wanneer de warmteproductie van vandaag hoger is dan de berekende behoefte voor beide dagen samen, wordt de resterende behoefte nul.

Maar de warmte die vandaag is geproduceerd, is grotendeels gebruikt om het huis vandaag te verwarmen. Die kan niet zonder meer als beschikbare warmtevoorraad voor morgen worden beschouwd.

Dit lijkt vooral bij een DAO-run laat op de avond tot onrealistische uitkomsten te leiden.

Daarnaast valt iets op aan de COP-configuratie.

De standaard vermogensstappen bevatten COP-waarden van 7,1 bij 225 W tot 4,0 bij 1.250 W.

Onze warmtepomp rapporteert over de betreffende dagen een gemiddelde COP van ongeveer 4,2. We hebben bij onze installatie nog nooit een dag-COP van 5 of hoger vastgesteld.

Ik vraag me daarom ook af hoe representatief de gebruikte COP-/vermogenscurve is voor de elektrische verbruiksprognose.

De hele options_example.json is een voorbeeld (grotendeels gebaseerd op mijn eigen opzet met een w/w wp), maar het is de bedoeling dat je die aanpast aan jouw situatie met jouw vermogens en cop.

Mijn vragen:
[list=1]
• Is de hierboven beschreven berekening van de tweedaagse warmtebehoefte en de aftrek van reeds geproduceerde warmte bedoeld gedrag?

Ja voorlopig wel, maar dat gaat binnenkort veranderen, dan kun je zelf je "verwarmingshorizon" instellen.

• Hoe voorkomt DAO dat reeds verbruikte warmte van vandaag ten onrechte wordt beschouwd als beschikbare warmte voor morgen?

DAO rekent de totale benodigde warmte uit voor vandaag (en na 13:00) en morgen.
De reeds geproduceerde warmte (door jou gemeten) wordt in mindering gebracht.
Het restant moet nog worden geproduceerd in de resterende periode.

• Is er in de bestaande configuratie een mogelijkheid om dit te corrigeren?
• Is er al een verbetering van het warmtevoorspellingsmodel voorzien of in ontwikkeling?

Ja, wordt waarschijnlijk een ml-model (zoals bij pv)

• Hoe kunnen we de COP-/vermogensstappen het beste afstemmen op werkelijk gemeten prestaties van de warmtepomp?

Door de waarden van je eigen wp in te vullen.

[/list]
Ik wil bij voorkeur binnen de officiële DAO-configuratiemogelijkheden blijven en de broncode niet aanpassen, zodat toekomstige updates probleemloos blijven verlopen.

Het belangrijkste punt: wanneer een warmtepomp die dagelijks circa 14 kWh elektriciteit gebruikt volledig ontbreekt in de voorspelling, zijn ook de daarop gebaseerde accu- en netoptimalisatie onvoldoende betrouwbaar.

Ik ben benieuwd naar je verklaring en eventuele oplossingsrichting. De relevante DAO-logs, configuratie en Sankey-vergelijkingen zijn beschikbaar.

[Knielen]

manusjevanalles schreef op zondag 25 oktober 2026 @ 21:59:
Ik probeer mijn batterij in DAO toe te voegen, maar ik krijg de volgende foutmelding:

code:

ERROR while running Cbc. Signal SIGSEGV caught. Getting stack trace.

Met daaronder een hele lap tekst met foutmeldingen. Zodra ik het stukje config van de batterij weghaal, werkt de berekening in DAO weer.

Config batterij:

code:

  "battery": [{
   "name": "Batterij",
   "entity_actual_level": "input_number.helper_dao_batterij_soc_proxy",
   "capacity": 1.5,
   "upper_limit": 100, "lower_limit": 10,
   "charge_stages":    [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
   "discharge_stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
   "minimum_power": 50,
   "dc_to_bat_efficiency": 0.94,
   "bat_to_dc_efficiency": 0.94,
   "cycle_cost": 0.005,
   "entity_set_power_feedin": "input_number.helper_dao_batterij_set_vermogen_invoer",
   "entity_set_operating_mode": "input_select.helper_dao_batterij_modus",
   "entity_set_operating_mode_on": "Aan",
   "entity_set_operating_mode_off": "Uit",
   "entity_stop_inverter": "input_datetime.helper_dao_batterij_stop",
   "entity_from_battery": "input_number.helper_dao_batterij_uit_batterij",
   "entity_from_ac": "input_number.helper_dao_batterij_uit_ac",
   "entity_calculated_soc": "input_number.helper_dao_batterij_berekende_soc",
   "entity_min_soc_end_opt": "input_number.helper_dao_batterij_min_soc_einde_opt",
   "entity_max_soc_end_opt": "input_number.helper_dao_batterij_max_soc_einde_opt"
  }],

Ligt het aan de config of gaat het ergens anders fout?

Ik mis helemaal aan het eind solar[ ], die heb ik er wel in staan (leeg), als ik de wiki lees is die verplicht.

[manusjevanalles]

Knielen schreef op maandag 26 oktober 2026 @ 07:11:
[...]

Ik mis helemaal aan het eind solar[ ], die heb ik er wel in staan (leeg), als ik de wiki lees is die verplicht.

Die heb ik er wel in staan hoor, alleen het stukje batterij heb ik gisteren toegevoegd waarna de errors kwamen.

Errors:

code:

ERROR while running Cbc. Signal SIGSEGV caught. Getting stack trace.
/root/dao/prog/miplib/lib/libCbc.so(_Z15CbcCrashHandleri+0xbd) [0x70b7839a7849]
/lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x70b7ac46fdf0]
/root/dao/prog/miplib/lib/libCbc.so(_ZN15CbcCutGeneratorD1Ev+0x19) [0x70b7838e8f8f]
/root/dao/prog/miplib/lib/libCbc.so(_ZN8CbcModel16gutsOfDestructorEv+0x96) [0x70b78396b3d2]
/root/dao/prog/miplib/lib/libCbc.so(_ZN8CbcModelD1Ev+0x93) [0x70b78396b6a1]
/root/dao/prog/miplib/lib/libCbc.so(_ZN8CbcModelD0Ev+0x9) [0x70b78396b7cf]
/root/dao/prog/miplib/lib/libCbc.so(_ZN9CbcSolver3runESt5dequeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS6_EEPFiP8CbcModeliEP9ampl_info+0x23c5) [0x70b7839d79df]
/root/dao/prog/miplib/lib/libCbc.so(Cbc_solve+0x2534) [0x70b783a51d61]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(+0x2d052) [0x70b7a1a53052]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(+0x2b978) [0x70b7a1a51978]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(cffistatic_ffi_call+0x178) [0x70b7a1a51af3]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(+0x135e7) [0x70b7a1a395e7]
python3(_PyObject_MakeTpCall+0x27b) [0x54513b]
python3(_PyEval_EvalFrameDefault+0x2685) [0x561695]
python3(PyEval_EvalCode+0xcc) [0x55ad6c]
python3() [0x6a45c1]
python3() [0x6a164c]
python3() [0x6b29b3]
python3() [0x6b23c3]
python3() [0x6b21fe]
python3(Py_RunMain+0x3c1) [0x6b14c1]
python3(Py_BytesMain+0x2b) [0x67c4eb]
/lib/x86_64-linux-gnu/libc.so.6(+0x29ca8) [0x70b7ac459ca8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x70b7ac459d65]
python3(_start+0x21) [0x67b891]




ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace.
/root/dao/prog/miplib/lib/libCbc.so(_Z15CbcCrashHandleri+0xbd) [0x70b7839a7849]
/lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x70b7ac46fdf0]
/lib/x86_64-linux-gnu/libc.so.6(+0x9495c) [0x70b7ac4c495c]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x12) [0x70b7ac46fcc2]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x22) [0x70b7ac4584ac]
/root/dao/prog/miplib/lib/libCbc.so(+0x7f66c) [0x70b7838c166c]
/lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x70b7ac46fdf0]
/root/dao/prog/miplib/lib/libCbc.so(_ZN15CbcCutGeneratorD1Ev+0x19) [0x70b7838e8f8f]
/root/dao/prog/miplib/lib/libCbc.so(_ZN8CbcModel16gutsOfDestructorEv+0x96) [0x70b78396b3d2]
/root/dao/prog/miplib/lib/libCbc.so(_ZN8CbcModelD1Ev+0x93) [0x70b78396b6a1]
/root/dao/prog/miplib/lib/libCbc.so(_ZN8CbcModelD0Ev+0x9) [0x70b78396b7cf]
/root/dao/prog/miplib/lib/libCbc.so(_ZN9CbcSolver3runESt5dequeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS6_EEPFiP8CbcModeliEP9ampl_info+0x23c5) [0x70b7839d79df]
/root/dao/prog/miplib/lib/libCbc.so(Cbc_solve+0x2534) [0x70b783a51d61]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(+0x2d052) [0x70b7a1a53052]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(+0x2b978) [0x70b7a1a51978]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(cffistatic_ffi_call+0x178) [0x70b7a1a51af3]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so(+0x135e7) [0x70b7a1a395e7]
python3(_PyObject_MakeTpCall+0x27b) [0x54513b]
python3(_PyEval_EvalFrameDefault+0x2685) [0x561695]
python3(PyEval_EvalCode+0xcc) [0x55ad6c]
python3() [0x6a45c1]
python3() [0x6a164c]
python3() [0x6b29b3]
python3() [0x6b23c3]
python3() [0x6b21fe]
python3(Py_RunMain+0x3c1) [0x6b14c1]
python3(Py_BytesMain+0x2b) [0x67c4eb]
/lib/x86_64-linux-gnu/libc.so.6(+0x29ca8) [0x70b7ac459ca8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x70b7ac459d65]
python3(_start+0x21) [0x67b891]

[Knielen]

@manusjevanalles maar binnen je batterij moet je ook nog solar definieren, die heb je nu niet. Weet niet zeker of dit de oplossing is, maar dat is het enige verschil dat ik zie met mijn batterij instellingen

[manusjevanalles]

Knielen schreef op maandag 26 oktober 2026 @ 07:34:
@manusjevanalles maar binnen je batterij moet je ook nog solar definieren, die heb je nu niet. Weet niet zeker of dit de oplossing is, maar dat is het enige verschil dat ik zie met mijn batterij instellingen

Ik heb nu “solar”: [] toegevoegd, maar helaas nog steeds dezelfde foutmelding.

[Doopy-X-]

Doopy-X- schreef op zondag 25 oktober 2026 @ 16:29:
[...]

Let wel op, dashboard werkt momenteel even niet vanwege REST-wintertijd-bug in DAO

Hij doet het weer

[Dogooder]

@manusjevanalles probeer eens namen zonder underscores zoals het ook staat in de settings.md.

code:

"battery": [{
  "name": "Batterij",
  "entity actual level": "input_number.helper_dao_batterij_soc_proxy",
  "capacity": 1.5,
  "upper limit": 100,
  "lower limit": 10,
  "charge stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
  "discharge stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
  "minimum power": 50,
  "dc_to_bat efficiency": 0.94,
  "bat_to_dc efficiency": 0.94,
  "cycle cost": 0.005,
  "entity set power feedin": "input_number.helper_dao_batterij_set_vermogen_invoer",
  "entity set operating mode": "input_select.helper_dao_batterij_modus",
  "entity set operating mode on": "Aan",
  "entity set operating mode off": "Uit",
  "entity stop inverter": "input_datetime.helper_dao_batterij_stop",
  "entity from battery": "input_number.helper_dao_batterij_uit_batterij",
  "entity from ac": "input_number.helper_dao_batterij_uit_ac",
  "entity calculated soc": "input_number.helper_dao_batterij_berekende_soc",
  "entity min soc end opt": "input_number.helper_dao_batterij_min_soc_einde_opt",
  "entity max soc end opt": "input_number.helper_dao_batterij_max_soc_einde_opt"
}]

[ErnstH]

KC27 schreef op maandag 26 oktober 2026 @ 00:23:
[...]

Ja, wordt waarschijnlijk een ml-model (zoals bij pv)

[...]

Dit zou heel mooi zijn, om dit zo te doen! Misschien kan dit dan meteen ook gebruikt worden om koel-vermogen in de zomer mee te schatten?

[manusjevanalles]

Dogooder schreef op maandag 26 oktober 2026 @ 10:00:
@manusjevanalles probeer eens namen zonder underscores zoals het ook staat in de settings.md.

code:

"battery": [{
  "name": "Batterij",
  "entity actual level": "input_number.helper_dao_batterij_soc_proxy",
  "capacity": 1.5,
  "upper limit": 100,
  "lower limit": 10,
  "charge stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
  "discharge stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
  "minimum power": 50,
  "dc_to_bat efficiency": 0.94,
  "bat_to_dc efficiency": 0.94,
  "cycle cost": 0.005,
  "entity set power feedin": "input_number.helper_dao_batterij_set_vermogen_invoer",
  "entity set operating mode": "input_select.helper_dao_batterij_modus",
  "entity set operating mode on": "Aan",
  "entity set operating mode off": "Uit",
  "entity stop inverter": "input_datetime.helper_dao_batterij_stop",
  "entity from battery": "input_number.helper_dao_batterij_uit_batterij",
  "entity from ac": "input_number.helper_dao_batterij_uit_ac",
  "entity calculated soc": "input_number.helper_dao_batterij_berekende_soc",
  "entity min soc end opt": "input_number.helper_dao_batterij_min_soc_einde_opt",
  "entity max soc end opt": "input_number.helper_dao_batterij_max_soc_einde_opt"
}]

Ik heb hem nu helemaal aangepast, maar de foutmelding blijft. Mijn huidige config-deel:

code:

  "battery": [{
   "name": "Batterij",
   "entity actual level": "input_number.helper_dao_batterij_soc_proxy",
   "capacity": 1.5,
   "upper limit": 100,
   "lower limit": 10,
   "optimal lower level": 15,
   "charge stages":    [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
   "discharge stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":800,"efficiency":0.93}],
   "minimum power": 50,
   "dc_to_bat efficiency": 1.0,
   "dc_to_bat max power": 800,
   "bat_to_dc efficiency": 1.0,
   "bat_to_dc max power": 800,
   "cycle cost": 0.005,
   "entity set power feedin": "input_number.helper_dao_batterij_set_vermogen_invoer",
   "entity set operating mode": "input_select.helper_dao_batterij_modus",
   "entity set operating mode on": "Aan",
   "entity set operating mode off": "Uit",
   "entity stop inverter": "input_datetime.helper_dao_batterij_stop",
   "entity from battery": "input_number.helper_dao_batterij_uit_batterij",
   "entity from ac": "input_number.helper_dao_batterij_uit_ac",
   "entity calculated soc": "input_number.helper_dao_batterij_berekende_soc",
   "entity min soc end opt": "input_number.helper_dao_batterij_min_soc_einde_opt",
   "entity max soc end opt": "input_number.helper_dao_batterij_max_soc_einde_opt",
   "solar": []
  }],

[tomvandepoel3]

manusjevanalles schreef op maandag 26 oktober 2026 @ 12:38:
[...]


Ik heb hem nu helemaal aangepast, maar de foutmelding blijft. Mijn huidige config-deel:

code:

  "battery": [{
   "name": "Batterij",
   "entity actual level": "input_number.helper_dao_batterij_soc_proxy",
   "capacity": 1.5,
   "upper limit": 100,
   "lower limit": 10,
   "optimal lower level": 15,
   "charge stages":    [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":1000,"efficiency":0.93}],
   "discharge stages": [{"power":0,"efficiency":1.0},{"power":500,"efficiency":0.88},{"power":800,"efficiency":0.93}],
   "minimum power": 50,
   "dc_to_bat efficiency": 1.0,
   "dc_to_bat max power": 800,
   "bat_to_dc efficiency": 1.0,
   "bat_to_dc max power": 800,
   "cycle cost": 0.005,
   "entity set power feedin": "input_number.helper_dao_batterij_set_vermogen_invoer",
   "entity set operating mode": "input_select.helper_dao_batterij_modus",
   "entity set operating mode on": "Aan",
   "entity set operating mode off": "Uit",
   "entity stop inverter": "input_datetime.helper_dao_batterij_stop",
   "entity from battery": "input_number.helper_dao_batterij_uit_batterij",
   "entity from ac": "input_number.helper_dao_batterij_uit_ac",
   "entity calculated soc": "input_number.helper_dao_batterij_berekende_soc",
   "entity min soc end opt": "input_number.helper_dao_batterij_min_soc_einde_opt",
   "entity max soc end opt": "input_number.helper_dao_batterij_max_soc_einde_opt",
   "solar": []
  }],

Je stackdump laat een botte crash zien in de MIP optimizer bibliotheek (miplib/lib/libCbc.so) die je blijkbaar zelf al hebt gecompileerd...

Je config is niet het probleem. Als ik je batterij in mijn test configuratie plak en de gebruikte HA helpers aanmaak en vul met voor mij redelijke input waarden werkt alles prima.

Als je de waarden van je input helpers deelt dan kan ik het daar ook nog een keer mee proberen al verwacht ik niet dat dat nieuwe info op gaat leveren.

Tenslotte kan je misschien ook nog een keer ALLEEN de batterij proberen (dus zonder PV en wasmachine). Het is idd een beetje zoeken naar een naald...

[Probydoby]

Eerder schreef ik over een potentiele verandering van de heating logica in DAO om het geschikt te maken voor een L/L warmtepomp. Ik heb hier over nagedacht en een issue geopend op de github pagina.

Wat ik voorstel is een generieke manier om een array vanuit HA toe te voegen aan de load forecast van DAO, zonder gebruik te maken van de heating config. Zo kan je het aan andere integraties/addons overlaten om zaken te voorspellen (in mijn geval heb ik zelf een python script gemaakt die op basis van buitentemperatuur mijn airco verbruik voorspelt), die daar ook gespecialiseerd in zijn, en scheelt dit weer bloat in DAO, maar kan DAO toch alles 'zien' waardoor het niet ten koste gaat van de optimalisatie uitkomsten en het aansturen van de batterij.

Zeker met verwarming heb je altijd een 'lag' in deze tijd van het jaar (en een omgekeerde lag in de lente). Maar er zullen nog meer use-cases zijn om iets buiten DAO aan te sturen, maar wat well voorspelbaar is en je DAO wilt laten meeberekenen in de load forecast.

[manusjevanalles]

tomvandepoel3 schreef op maandag 26 oktober 2026 @ 14:18:
[...]


Je stackdump laat een botte crash zien in de MIP optimizer bibliotheek (miplib/lib/libCbc.so) die je blijkbaar zelf al hebt gecompileerd...

Je config is niet het probleem. Als ik je batterij in mijn test configuratie plak en de gebruikte HA helpers aanmaak en vul met voor mij redelijke input waarden werkt alles prima.

Als je de waarden van je input helpers deelt dan kan ik het daar ook nog een keer mee proberen al verwacht ik niet dat dat nieuwe info op gaat leveren.

Tenslotte kan je misschien ook nog een keer ALLEEN de batterij proberen (dus zonder PV en wasmachine). Het is idd een beetje zoeken naar een naald...

Ik vermoed ook dat het met de libraries te maken heeft. Zou opnieuw compileren helpen?

input_number.helper_dao_batterij_berekende_soc: step 0.1, min 0 max 100, slider.
input_number.helper_dao_batterij_max_soc_einde_opt: step 1, min 0 max 100, slider.
input_number.helper_dao_batterij_min_soc_einde_opt: idem
input_select.helper_dao_batterij_modus: Aan, Uit
input_number.helper_dao_batterij_set_vermogen_invoer: -1000, 1000, step 1, slider, W.
input_number.helper_dao_batterij_soc_proxy: min 0, max 100, step 1, slider. %. (even aangemaakt omdat de batterij nog niet aan staat).
input_datetime.helper_dao_batterij_stop: datetime.
input_number.helper_dao_batterij_uit_ac: min -1000 max 1000 step 1. W.
input_number.helper_dao_batterij_uit_batterij: idem.

[tomvandepoel3]

manusjevanalles schreef op maandag 26 oktober 2026 @ 14:30:
[...]


Ik vermoed ook dat het met de libraries te maken heeft. Zou opnieuw compileren helpen?

input_number.helper_dao_batterij_berekende_soc: step 0.1, min 0 max 100, slider.
input_number.helper_dao_batterij_max_soc_einde_opt: step 1, min 0 max 100, slider.
input_number.helper_dao_batterij_min_soc_einde_opt: idem
input_select.helper_dao_batterij_modus: Aan, Uit
input_number.helper_dao_batterij_set_vermogen_invoer: -1000, 1000, step 1, slider, W.
input_number.helper_dao_batterij_soc_proxy: min 0, max 100, step 1, slider. %. (even aangemaakt omdat de batterij nog niet aan staat).
input_datetime.helper_dao_batterij_stop: datetime.
input_number.helper_dao_batterij_uit_ac: min -1000 max 1000 step 1. W.
input_number.helper_dao_batterij_uit_batterij: idem.

Zonder input helper helper_dao_batterij_soc_proxy krijg je een waarschuwing: 404 status code returned from http://HA_IP:HA_port/api/states/input_number.helper_dao_batterij_soc_proxy :No actual level info recieved from input_number.helper_dao_batterij_soc_proxy, but recieved '', assumed 50%. Prima waarschuwing; geen crash.

De definities van je helpers zijn OK, maar misschien wordt de crash veroorzaakt door een bijzondere combinatie van waarden van de input helpers. Dus ik zoek je actuele input waarden (niet de min/max grenzen uit de definitie) voor:
- input_number.helper_dao_batterij_min_soc_einde_opt
- input_number.helper_dao_batterij_max_soc_einde_opt
- helper_dao_batterij_soc_proxy

Ik heb zelf al wat zitten testen met rare input waarden (b.v. min > max, negatieve waarden, etc.) maar dan geeft DAO goede waarschuwingen dus is dit waarschijnlijk een dood spoor.

Alle overige helpers worden door DAO gebruikt om de output (de optimalisatie resultaten) in te schrijven (maar bij jouw crash in de berekening => dus geen output; dus die waarden zijn niet zo relevant)

Misschien toch nog maar een keer opnieuw compileren en/of testen zonder PV en Machine met alleen de Batterij

[Dogooder]

@manusjevanalles aangezien je zelf gecompileerd hebt, weet je ook welke versie? Momenteel is cbcbox gepinned op versie 2.929 vanwege een issue upstream. Dat issue veroorzaakt dit soort fouten. Gebruik je zelfgecompileerde binaries vanwege een afwijkende architectuur? Anders zou ik aanraden de meegeleverde versie uit de docker te gebruiken. Zorg er wel voor dat je docker niet alsnog naar de oude binaries verwijst.

[manusjevanalles]

Dogooder schreef op maandag 26 oktober 2026 @ 21:29:
@manusjevanalles aangezien je zelf gecompileerd hebt, weet je ook welke versie? Momenteel is cbcbox gepinned op versie 2.929 vanwege een issue upstream. Dat issue veroorzaakt dit soort fouten. Gebruik je zelfgecompileerde binaries vanwege een afwijkende architectuur? Anders zou ik aanraden de meegeleverde versie uit de docker te gebruiken. Zorg er wel voor dat je docker niet alsnog naar de oude binaries verwijst.

Daar moet ik echt even induiken, heb dat maanden geleden een keer gedaan. Waar kan ik zien welke versie ik gebruik?

[KC27]

Probydoby schreef op maandag 26 oktober 2026 @ 14:18:
Eerder schreef ik over een potentiele verandering van de heating logica in DAO om het geschikt te maken voor een L/L warmtepomp. Ik heb hier over nagedacht en een issue geopend op de github pagina.

Wat ik voorstel is een generieke manier om een array vanuit HA toe te voegen aan de load forecast van DAO, zonder gebruik te maken van de heating config. Zo kan je het aan andere integraties/addons overlaten om zaken te voorspellen (in mijn geval heb ik zelf een python script gemaakt die op basis van buitentemperatuur mijn airco verbruik voorspelt), die daar ook gespecialiseerd in zijn, en scheelt dit weer bloat in DAO, maar kan DAO toch alles 'zien' waardoor het niet ten koste gaat van de optimalisatie uitkomsten en het aansturen van de batterij.

Zeker met verwarming heb je altijd een 'lag' in deze tijd van het jaar (en een omgekeerde lag in de lente). Maar er zullen nog meer use-cases zijn om iets buiten DAO aan te sturen, maar wat well voorspelbaar is en je DAO wilt laten meeberekenen in de load forecast.

Nu zijn er twee mogelijkheden om de baseload te bepalen:
Je geeft 24 waarden op in de je config
Je laat het DAO berekenen per weekdag uit historische data in je HA-database met de formule
baseload = totaal_verbruik_grid - totaal_productie_grid + productie_pv +prod_accu - cons_accu - cons_app1 - cons_app2...

Jij wilt die laatste methode aanvullen met een HA-sensor die de baseload aanvult met de verwachte verbruikswaarden van je warmtepomp.
Dan zou ik het graag wat generieker maken:
Per apparaat waarvan het verbruik via een sensor in HA in de baseload moet komen geef je de naam (=entity_id) van die sensor op. De te gebruiken waarden van deze sensor staan in een attribute van die sensor.
Het werkelijk verbruik van dat apparaat staat in de sensor die je opgeeft bij "reports", zodat het gemeten verbruik in mindering blijft op de berekende baseload.

Heb ik het zo goed begrepen?

[ Voor 6% gewijzigd door KC27 op 27-10-2026 08:36 ]

[Knielen]

Voor de mensen die ook een Victron systeem hebben waarbij het lastig om op puur op discharge en charge van de accu te sturen heb ik een, naar mijn idee, goed werkende automation. Deze rekent je huidige levering/teruglevering om en past je ESS Setpoint zo aan dat de gewenste (ont)lading ontstaat. Ook is er een dropdown menu waarbij je DAO aan/uit kan zetten en handmatig kan (ont)laden. Daarnaast zit er een fallback scenario in dat als een entiteit niet beschikbaar is de Victron terugvalt naar 0-op-de-meter.

YAML: Victron ESS sturing voor DAO

# =====================================================================
# DAO -> Victron Multiplus II aansturing (ESS, via Home Assistant)
# =====================================================================
# PROBLEEM: Day Ahead Optimizer (DAO) vraagt een laad- of ontlaadvermogen
# van de accu, maar de Multiplus II kan niet direct op accuvermogen
# sturen. Het ESS-setpoint is een NETvermogen. Een setpoint van 600 W
# laadt de accu dus maar met 600 W min het huisverbruik.
#
# OPLOSSING: setpoint = gevraagd accuvermogen + netto huisverbruik,
# met terugkoppeling op het werkelijke accuvermogen.
#
# VEREISTEN (pas de entiteiten onderaan "variables" aan):
# - Home Assistant met Victron-entiteiten (setpoint, laadstroomlimiet,
#   omvormerlimiet, accuvermogen, SoC) en een netsensor.
# - DAO-entiteiten (zoals in je DAO-config):
#     input_boolean.dao_balance_switch  balansschakelaar van DAO
#     input_number.dao_feedin_grid      gevraagd ACCUvermogen in W
#                                       (+ = laden, - = ontladen)
#     input_datetime.dao_last_activity  tijdstip laatste DAO-activiteit
#                                       (moet datum EN tijd bevatten)
# - Zelf aan te maken helper: input_select.dao_mode met exact de opties
#     Automatisch, Laden, Ontladen, Uit
#
# AANNAMES:
# - Eén fase (alleen L1). Bij meerdere fases: tel de fases op.
# - Het accuvermogen is positief bij laden, negatief bij ontladen.
# - Het netvermogen is positief bij afname, negatief bij teruglevering.
# - PV zit NIET achter de Multiplus. Het netto huisverbruik wordt
#   afgeleid uit net en accu, dus zon zit er vanzelf in verwerkt.
# - De limieten staan op -1 = geen limiet (Victron MQTT).
# - Het laad-/ontlaadvermogen wordt door DAO zelf bewaakt, dus hier
#   zit geen vaste maximale begrenzing op.
#
# GEBRUIK OP EIGEN RISICO. Test eerst met een kleine laad-/ontlaadopdracht
# en controleer in de trace en in Victron of het accuvermogen overeenkomt
# met de DAO-vraag.
# =====================================================================
alias: DAO - Victron aansturing
description: |-
  Vertaalt DAO-opdrachten naar Victron ESS-aansturing (setpoint en limieten).

  NETTO VERBRUIK: netvermogen (negatief is teruglevering) min het accuvermogen. Zon zit er daardoor al in verwerkt. Zijn de netsensor of de accusensor niet beschikbaar, dan geldt de fail-safe.

  MODI (variabele "modus"), in volgorde van voorrang:
  - houd: input_select.dao_mode = Uit, DAO-vraag binnen de deadband, of accu vol (laden) / leeg (ontladen). Setpoint 0, laden en ontladen geblokkeerd (limieten 0).
  - laden / ontladen: input_select.dao_mode = Laden of Ontladen, of de DAO-vraag valt buiten de deadband. Setpoint = DAO-vraag + netto verbruik.
  - balance: balansschakelaar aan. Setpoint 0, limieten vrij (-1).
  - failsafe: DAO-activiteit te oud of sensoren niet beschikbaar. Zelfde actie als balance.

  NUL-BEGRENZING: het setpoint gaat nooit door 0. Bij laden is het setpoint minimaal 0 (geen teruglevering tijdens laden), bij ontladen maximaal 0 (geen afname tijdens ontladen).

  TERUGKOPPELING: op de timers (30 s en 5 min) wordt het setpoint bijgestuurd met huidig + demping x (DAO-vraag - werkelijk accuvermogen), begrensd op basis +/- max_corr. Alleen in laden en ontladen en alleen als de SoC bekend is. Vanaf soc_taper (laden) of tot soc_taper_laag (ontladen) mag de correctie het setpoint niet verder van 0 af brengen dan de basis.

  TIMERS: de timer van 30 s doet alleen iets in laden en ontladen. De timer van 5 min draait in alle modi (nodig voor de fail-safe). Wijzigingen van DAO of de input_select starten de automation direct.

  INSTELLINGEN (bovenaan de variabelen):
  - soc_max: vanaf dit % wordt laden houd. soc_min: tot dit % wordt ontladen houd.
  - soc_taper / soc_taper_laag: vanaf/tot dit % mag de terugkoppeling het setpoint niet meer verhogen.
  - force_laden / force_ontladen: vermogen in W bij handmatig Laden of Ontladen.
  - deadband: DAO-vragen kleiner dan dit aantal W tellen als houd.
  - drempel: minimale wijziging in W voordat het setpoint opnieuw geschreven wordt.
  - demping: 0-1, fractie van de afwijking die per stap wordt gecorrigeerd.
  - max_corr: maximale correctie in W ten opzichte van de basisberekening.
  - max_leeftijd: uren zonder DAO-activiteit voordat de fail-safe actief wordt.

  LET OP: de teksten van input_select.dao_mode moeten exact kloppen: Automatisch, Laden, Ontladen, Uit. Zet na handmatig gebruik terug op Automatisch.
mode: restart
triggers:
  - alias: Wijziging van DAO, balansschakelaar of override
    trigger: state
    entity_id:
      - input_boolean.dao_balance_switch
      - input_number.dao_feedin_grid
      - input_datetime.dao_last_activity
      - input_select.dao_mode
    id: wijziging
  - alias: Timer elke 30 seconden (bijsturen tijdens laden of ontladen)
    trigger: time_pattern
    seconds: "/30"
    id: timer
  - alias: Timer elke 5 minuten (alle modi, nodig voor de fail-safe)
    trigger: time_pattern
    minutes: "/5"
    id: timer_traag
  - alias: Start van Home Assistant
    trigger: homeassistant
    event: start
    id: start
actions:
  - alias: Instellingen en berekening van modus en doelwaarde
    variables:
      # ---- ENTITEITEN: pas aan op jouw installatie ----
      # ESS-gridsetpoint in W (+ = afname uit het net, - = teruglevering)
      e_setpoint: number.victron_mqtt_XXXXXXXXXXXX_system_0_system_ac_power_set_point
      # Maximale laadstroom van het systeem (-1 = geen limiet, 0 = niet laden)
      e_max_laad: number.victron_mqtt_XXXXXXXXXXXX_system_0_system_ess_max_charge_current
      # Maximaal omvormervermogen/ontladen (-1 = geen limiet, 0 = niet ontladen)
      e_max_inv: number.victron_mqtt_XXXXXXXXXXXX_system_0_system_ess_max_inverter_power_limit
      # Netvermogen in W op L1 (positief = afname, negatief = teruglevering)
      e_grid: sensor.venus_grid_power_l1
      # Accuvermogen DC in W (positief = laden, negatief = ontladen)
      e_bat: sensor.victron_mqtt_XXXXXXXXXXXX_system_0_system_dc_battery_power
      # Accu-SoC in %
      e_soc: sensor.victron_mqtt_XXXXXXXXXXXX_battery_XXX_battery_soc
      # Handmatige override (helper met opties: Automatisch, Laden, Ontladen, Uit)
      e_mode: input_select.dao_mode
      # ---- INSTELLINGEN ----
      soc_max: 98          # % : vanaf hier wordt een laadopdracht 'houd'
      soc_min: 10          # % : tot hier wordt een ontlaadopdracht 'houd' (zet op je minimum-SoC)
      soc_taper: 95        # % : vanaf hier mag de correctie het setpoint bij laden niet meer verhogen
      soc_taper_laag: 15   # % : tot hier mag de correctie het setpoint bij ontladen niet meer verlagen
      force_laden: 2000    # W : laadvermogen bij handmatig 'Laden'
      force_ontladen: 2000 # W : ontlaadvermogen bij handmatig 'Ontladen'
      deadband: 75         # W : DAO-vragen kleiner dan dit tellen als 'niets doen'
      drempel: 25          # W : minimale wijziging voordat het setpoint opnieuw geschreven wordt
      demping: 0.5         # 0-1 : fractie van de afwijking die per stap gecorrigeerd wordt
      max_corr: 300        # W : maximale correctie t.o.v. de basisberekening
      max_leeftijd: 2      # uur : zonder DAO-activiteit langer dan dit geldt de fail-safe
      # ---- BEREKENING (niet aanpassen) ----
      override: "{{ states(e_mode) }}"
      balans: "{{ is_state('input_boolean.dao_balance_switch', 'on') }}"
      bat_ok: "{{ states(e_bat) | is_number }}"
      bat: "{{ states(e_bat) | float(0) }}"
      grid_ok: "{{ states(e_grid) | is_number }}"
      grid: "{{ states(e_grid) | float(0) }}"
      verbruik_ok: "{{ grid_ok and bat_ok }}"
      # Netto huisverbruik (zon verrekend): net minus accu
      verbruik: "{{ grid - bat }}"
      soc_ok: "{{ states(e_soc) | is_number }}"
      soc: "{{ states(e_soc) | float(50) }}"
      huidig: "{{ states(e_setpoint) | float(0) }}"
      # Gevraagd accuvermogen: DAO, of vast bij handmatig Laden/Ontladen
      dao_w: >-
        {% if override == 'Laden' %}{{ force_laden }}
        {%- elif override == 'Ontladen' %}{{ -force_ontladen }}
        {%- else %}{{ states('input_number.dao_feedin_grid') | float(0) }}{% endif %}
      laatste: "{{ as_timestamp(states('input_datetime.dao_last_activity'), none) }}"
      verouderd: >-
        {{ laatste is not none and (now().timestamp() - laatste) > max_leeftijd * 3600 }}
      # Modus op basis van override, balans, fail-safe en DAO-vraag
      modus_ruw: >-
        {% if override == 'Uit' %}houd
        {%- elif override == 'Laden' and verbruik_ok %}laden
        {%- elif override == 'Ontladen' and verbruik_ok %}ontladen
        {%- elif balans %}balance
        {%- elif verouderd or not verbruik_ok %}failsafe
        {%- elif dao_w > deadband %}laden
        {%- elif dao_w < -deadband %}ontladen
        {%- else %}houd{% endif %}
      # Accu vol (laden) of leeg (ontladen): wordt 'houd'
      modus: >-
        {% if modus_ruw == 'laden' and soc_ok and soc >= soc_max %}houd
        {%- elif modus_ruw == 'ontladen' and soc_ok and soc <= soc_min %}houd
        {%- else %}{{ modus_ruw }}{% endif %}
      # Basisberekening: gevraagd accuvermogen + netto huisverbruik
      basis: "{{ dao_w + verbruik }}"
      # Terugkoppeling alleen op de timers, met bekende accu- en SoC-sensor
      feedback: >-
        {{ trigger.id in ['timer', 'timer_traag']
           and bat_ok and soc_ok
           and modus in ['laden', 'ontladen'] }}
      # Doel-setpoint: basis, bijgestuurd met terugkoppeling, nooit door 0
      doel: >-
        {% if modus in ['laden', 'ontladen'] %}
          {% if feedback %}
            {% set ruw = huidig + demping * (dao_w - bat) %}
            {% set boven = basis if (modus == 'laden' and soc >= soc_taper) else basis + max_corr %}
            {% set onder = basis if (modus == 'ontladen' and soc <= soc_taper_laag) else basis - max_corr %}
            {% set waarde = ([[ruw, onder] | max, boven] | min) | round(-1) | int %}
          {% else %}
            {% set waarde = basis | round(-1) | int %}
          {% endif %}
          {{ [waarde, 0] | max if modus == 'laden' else [waarde, 0] | min }}
        {% else %}0{% endif %}
      # Limieten: 0 bij 'houd' (laden en ontladen geblokkeerd), anders vrij (-1)
      lim: "{{ 0 if modus == 'houd' else -1 }}"
      marge: "{{ drempel if modus in ['laden', 'ontladen'] else 0 }}"
  - alias: Stop als de Victron niet bereikbaar is
    condition: template
    value_template: "{{ states(e_setpoint) | is_number }}"
  - alias: Timer van 30 seconden alleen bij laden of ontladen
    condition: template
    value_template: >
      {{ trigger.id != 'timer' or modus in ['laden', 'ontladen'] }}
  - alias: Schrijf setpoint en limieten, alleen bij een echte wijziging
    repeat:
      for_each:
        - entity: "{{ e_max_laad }}"
          waarde: "{{ lim }}"
          marge: 0.5
        - entity: "{{ e_max_inv }}"
          waarde: "{{ lim }}"
          marge: 0.5
        - entity: "{{ e_setpoint }}"
          waarde: "{{ doel }}"
          marge: "{{ marge }}"
      sequence:
        - alias: Alleen schrijven als de afwijking groter is dan de marge
          if:
            - condition: template
              value_template: >
                {{ (states(repeat.item.entity) | float(-99999)
                    - repeat.item.waarde | float(0)) | abs > repeat.item.marge | float(0) }}
          then:
            - alias: Waarde naar Victron schrijven
              action: number.set_value
              target:
                entity_id: "{{ repeat.item.entity }}"
              data:
                value: "{{ repeat.item.waarde }}"

[Probydoby]

KC27 schreef op dinsdag 27 oktober 2026 @ 00:07:
[...]

Nu zijn er twee mogelijkheden om de baseload te bepalen:
Je geeft 24 waarden op in de je config
Je laat het DAO berekenen per weekdag uit historische data in je HA-database met de formule
baseload = totaal_verbruik_grid - totaal_productie_grid + productie_pv +prod_accu - cons_accu - cons_app1 - cons_app2...

Jij wilt die laatste methode aanvullen met een HA-sensor die de baseload aanvult met de verwachte verbruikswaarden van je warmtepomp.
Dan zou ik het graag wat generieker maken:
Per apparaat waarvan het verbruik via een sensor in HA in de baseload moet komen geef je de naam (=entity_id) van die sensor op. De te gebruiken waarden van deze sensor staan in een attribute van die sensor.
Het werkelijk verbruik van dat apparaat staat in de sensor die je opgeeft bij "reports", zodat het gemeten verbruik in mindering blijft op de berekende baseload.

Heb ik het zo goed begrepen?

Dat is hem exact. En in die attribute staan dan 3 relevante waardes, zoals ik het zie, start datetime, end datetime, energy.


Ik heb al een voorbeeld draaien in HA van een sensor die dergelijke attributen bevat:

code:

entity_id: sensor.airco_vermogensforecast
state: '180'
last_changed: '2026-10-27T08:00:00.122Z'
last_updated: '2026-10-27T08:30:00.152Z'
attributes:
  friendly_name: Airco vermogensforecast
  unit_of_measurement: W
  device_class: power
  generated_at: '2026-10-27T09:30:00.128363+01:00'
  model: empirical_delta_t_v1
  target_temperature: 19
  current_outdoor_temperature: 14.4
  power_per_kelvin: 39.1
  base_power: 0
  forecast:
    - start: '2026-10-27T09:30:00.128363+01:00'
      end: '2026-10-27T09:45:00.128363+01:00'
      target: 19
      outdoor: 15.08
      delta_t: 3.92
      power: 153
      energy: 0.0384
    - start: '2026-10-27T09:45:00.128363+01:00'
      end: '2026-10-27T10:00:00.128363+01:00'
      target: 19
      outdoor: 15.23
      delta_t: 3.77
      power: 148
      energy: 0.0369

In principe is alleen start, end & energy relevant voor DAO.

Werkelijk verbruik gaat dan idd via reports via een andere sensor.

[ Voor 18% gewijzigd door Probydoby op 27-10-2026 10:21 ]

[simnet]

Probydoby schreef op dinsdag 27 oktober 2026 @ 09:25:
[...]


Dat is hem exact. En in die attribute staan dan 3 relevante waardes, zoals ik het zie, start datetime, end datetime, energy.


Ik heb al een voorbeeld draaien in HA van een sensor die dergelijke attributen bevat:

code:

entity_id: sensor.airco_vermogensforecast
state: '180'
last_changed: '2026-10-27T08:00:00.122Z'
last_updated: '2026-10-27T08:30:00.152Z'
attributes:
  friendly_name: Airco vermogensforecast
  unit_of_measurement: W
  device_class: power
  generated_at: '2026-10-27T09:30:00.128363+01:00'
  model: empirical_delta_t_v1
  target_temperature: 19
  current_outdoor_temperature: 14.4
  power_per_kelvin: 39.1
  base_power: 0
  forecast:
    - start: '2026-10-27T09:30:00.128363+01:00'
      end: '2026-10-27T09:45:00.128363+01:00'
      target: 19
      outdoor: 15.08
      delta_t: 3.92
      power: 153
      energy: 0.0384
    - start: '2026-10-27T09:45:00.128363+01:00'
      end: '2026-10-27T10:00:00.128363+01:00'
      target: 19
      outdoor: 15.23
      delta_t: 3.77
      power: 148
      energy: 0.0369

In principe is alleen start, end & energy relevant voor DAO.

Werkelijk verbruik gaat dan idd via reports via een andere sensor.

Hoe heb jij die sensor i HA aangemaakt? Ik ben (voor een ander project) op zoek naar exact dat wat jij hier doet...

[Probydoby]

simnet schreef op dinsdag 27 oktober 2026 @ 10:42:
[...]


Hoe heb jij die sensor i HA aangemaakt? Ik ben (voor een ander project) op zoek naar exact dat wat jij hier doet...

Ik stuur je wel een PB straks - beetje offtopic voor hier.

[KC27]

GigaTexel_BE schreef op zondag 25 oktober 2026 @ 19:30:
Hallo!

Ik ben helemaal nieuw in dit topic :-)

Zijn er plannen om de uur/kwartierprijzen rechtstreeks uit HA te kunnen halen?

• De meeste gebruikers hebben al een nordpool/entso-e/benglian energy contract integratie draaien. Door dit parallel te organiseren in DAO moet elke contract- of belastingswijziging 2 keer gebeuren
• Belgische energiecontracten zijn legendarisch complex, met verschillen per gewest voor wat betreft de belastingen en per regio voor de netkosten. Niet altijd even eenvoudig om dat correct te implementeren met de variabelen die beschikbaar zijn
• Ik gebruik een integratie die de prijzen voor mijn contract ophaalt en omrekent (https://github.com/renaud...ant_be_electricity_prices) en de all-in prijzen per uur/kwartier beschikbaar maakt in HA. Het zou erg netjes zijn om DAO gewoon die zelfde data te laten hergebruiken, al dan niet via een helper om dit in een vast formaat te krijgen

Ik zou dit wel ergens in november a.s. kunnen maken.
Mijn idee is dan dat je twee sensors (entity_id) opgeeft:

1. een sensor die in zijn attributen de complete berekende volledige (incl. belastingen en btw) inkoopprijs (euro/kWh) heeft staan
2. een tweede sensor idem voor de terugleveringprijs.

Bij iedere sensor geeft je op (naast de entity-id):

• naam van het attribute dat een lijst/array bevat met per interval minimaal een start-datum-tijd en een waarde
• naam (key) van de het start-datum-tijd veld
• naam (key) van het waarde veld

Kan zoiets werken?

[martin1982]

Hoi! Ik ben bezig met de Day Ahead Optimizer (DAO, versie 2026.9.1) in Home Assistant, maar loop vast op Meteoserver. Misschien herken jij dit?

Wat wel werkt:

• DAO start goed op, de config en secrets worden zonder fouten geladen
• Dynamische prijzen van Tibber komen binnen
• Batterij (Victron + 3x Dyness, 15 kWh) en zonnepanelen zijn ingesteld, voorlopig in adviesmodus

Het probleem:
“Meteoprognoses ophalen” geeft steeds “No harmonie-data received from meteoserver”. In de debuglog zie ik dat Meteoserver afwisselend api_key_invalid of een fout 502 (“Weergegevens konden tijdelijk niet worden geladen”) teruggeeft. Zonder weerdata breekt DAO de berekening af.

Wat ik al heb geprobeerd:

• Account aangemaakt en geactiveerd via de mail
• Sleutel in secrets.json gecontroleerd, die klopt
• Later een tweede account met een ander e-mailadres en een nieuwe sleutel: zelfde probleem
• Beide weermodellen geprobeerd (harmonie en gfs)
• Aantal pogingen in DAO verhoogd naar 10
• In de browser getest (incognito):
  • lat=53.03, long=5.66 → werkt
  • lat=53.04, long=5.67 → fout 502
  • lat=53.042, long=5.665 → fout 502
  • lat=53.0422592, long=5.6652914 (wat DAO gebruikt) → api_key_invalid
• Meteoserver gemaild, nog geen antwoord

Herken je dit? Werkt Meteoserver bij jou op dit moment wel? Of heb je iets speciaals ingesteld om het werkend te krijgen?

vriendelijke groet,

Martin


Update op mijn eerdere vraag over Meteoserver: ik heb de oorzaak gevonden, al is het nog geen echte oplossing.

Mijn API-key werkt wel, maar alleen voor bepaalde coördinaten. Getest in een incognitovenster met uurverwachting.php:

- lat=53.03&long=5.66 → werkt, steeds met actuele data

- lat=53.04&long=5.67 → fout 502 "Weergegevens konden tijdelijk niet worden geladen"

- lat=53.042&long=5.665 → fout 502

- lat=53.0422592&long=5.6652914 (mijn huis, wat DAO gebruikt) → afwisselend 502 en api_key_invalid

Als test heb ik de locatie in Home Assistant even op 53.03 / 5.66 gezet. Toen haalde DAO de meteodata direct zonder problemen op. Daarna heb ik de locatie weer teruggezet.

Het lijkt er dus op dat Meteoserver alleen vaste punten (zoals het centrum van een plaats) goed levert, en dat het ophalen voor andere coördinaten op dit moment niet lukt. Ik heb Meteoserver gemaild, nog geen reactie.

Herkent iemand dit? Werkt het bij jullie wel met de exacte coördinaten van je huis? En is er een manier om DAO andere coördinaten te laten gebruiken dan die van Home Assistant?

[ Voor 26% gewijzigd door martin1982 op 27-10-2026 20:34 ]

[oscaarbasgitaar]

is er een manier om een signaal te krijgen of de berekening geslaagd is?
Ik heb af en toe geen info via de API van mijn warmtepomp.
Daardoor lukt de hele berekening niet.
Als net dan de batterij staat op bijvoorbeeld laden van het net omdat dit kwartier goedkoop is, blijft hij laden ook al lopen plots de prijzen op.

Met een signaal dat de berekeningen niet lukken kan je wel automatiseren naar een fall-back mode

[piforce]

Dao geinstalleerd, tibber en openmeteo gekoppeld. Echter als ik vanuit de handleiding de zonnepanelen wil toevoegen. Ik heb geknipt,geplakt uit de wiki start dao niet meer op. Dan krijg ik in log scheduler crashed with exit code 1.

Dit is wat ik in de json heb geplakt

"solar": [

{"name": "pv oost",

"entity pv switch": "input_boolean.pv_oost_aan_uit"

"tilt": 13,

"orientation": 74,

"capacity": 3.2,

"yield": 0.07,

},

{"name": "pv garage",

"entity pv switch": "input_boolean.pv_west_aan_uit"

"tilt": 10,

"orientation": 254,

"capacity": 3.1,

"yield": 0.007,

}

],

Al verscheidene dingen geprobeerd al meer dan 6 uur aan klooien maar zie niet waar verkeerd. gaat. Telkens na aanpassen json loopt het vast en moet ik app herinstallen.
Kan nergens in ha de json vinden om die direct aan te passen.

Andere vraag als ik mijn deye hybrid toevoeg waar halen jullie de rendement vandaan tov gebruikt vermogen.

[anboni]

oscaarbasgitaar schreef op dinsdag 27 oktober 2026 @ 19:49:
is er een manier om een signaal te krijgen of de berekening geslaagd is?
Ik heb af en toe geen info via de API van mijn warmtepomp.
Daardoor lukt de hele berekening niet.
Als net dan de batterij staat op bijvoorbeeld laden van het net omdat dit kwartier goedkoop is, blijft hij laden ook al lopen plots de prijzen op.

Met een signaal dat de berekeningen niet lukken kan je wel automatiseren naar een fall-back mode

Ik denk dat je hier wat mee moet kunnen:

code:

  "notifications": {
    "notification_entity": "input_text.dao_notificatie",
    "opstarten": true,
    "berekening": true,
    "last_activity_entity": "input_datetime.dao_laatste_activiteit"
  },

[KC27]

piforce schreef op dinsdag 27 oktober 2026 @ 21:00:
Dao geinstalleerd, tibber en openmeteo gekoppeld. Echter als ik vanuit de handleiding de zonnepanelen wil toevoegen. Ik heb geknipt,geplakt uit de wiki start dao niet meer op. Dan krijg ik in log scheduler crashed with exit code 1.

Dit is wat ik in de json heb geplakt

"solar": [

{"name": "pv oost",

"entity pv switch": "input_boolean.pv_oost_aan_uit"

"tilt": 13,

"orientation": 74,

"capacity": 3.2,

"yield": 0.07,

},

{"name": "pv garage",

"entity pv switch": "input_boolean.pv_west_aan_uit"

"tilt": 10,

"orientation": 254,

"capacity": 3.1,

"yield": 0.007,

}

],

Al verscheidene dingen geprobeerd al meer dan 6 uur aan klooien maar zie niet waar verkeerd. gaat. Telkens na aanpassen json loopt het vast en moet ik app herinstallen.
Kan nergens in ha de json vinden om die direct aan te passen.

Je kunt via samba en dan app_configs naar de data map van DAO. In die map staat options.json die kun je editen.
In de volgende versie werkt dit allemaal soepeler.

Andere vraag als ik mijn deye hybrid toevoeg waar halen jullie de rendement vandaan tov gebruikt vermogen.

Zoek in dit topic op "deye". Er zijn een paar gebruikers die hun instellingen hebben gedeeld.

[Knielen]

@piforce Je gaat nat op de komma's, het laatste item sluit je niet meer af met een komma. In jouw geval dus na de yield waarde. Gebruik een yaml checker voor je de config opslaat, dat scheelt al veel ellende.

[tomvandepoel3]

anboni schreef op dinsdag 27 oktober 2026 @ 21:09:
[...]


Ik denk dat je hier wat mee moet kunnen:

code:

  "notifications": {
    "notification_entity": "input_text.dao_notificatie",
    "opstarten": true,
    "berekening": true,
    "last_activity_entity": "input_datetime.dao_laatste_activiteit"
  },

In de Wiki - hoofdstuk 8, staan ook nog een paar voorbeelden van dergelijke notificaties

[GigaTexel_BE]

KC27 schreef op dinsdag 27 oktober 2026 @ 13:50:
[...]

Ik zou dit wel ergens in november a.s. kunnen maken.
Mijn idee is dan dat je twee sensors (entity_id) opgeeft:

1. een sensor die in zijn attributen de complete berekende volledige (incl. belastingen en btw) inkoopprijs (euro/kWh) heeft staan
2. een tweede sensor idem voor de terugleveringprijs.

Bij iedere sensor geeft je op (naast de entity-id):

• naam van het attribute dat een lijst/array bevat met per interval minimaal een start-datum-tijd en een waarde
• naam (key) van de het start-datum-tijd veld
• naam (key) van het waarde veld

Kan zoiets werken?

Zou heel goed zijn.
Stuur ik anders even een DM met een sensor-voorbeeld?

[KC27]

Misschien een screenshot van de status van zo'n sensor incl de kolom attributen
Mag je hier ook delen.

[martin1982]

heb antwoord van meteoserver , het lag bij hun dus het is opgelost.

[dingo35]

TheMystery schreef op vrijdag 16 oktober 2026 @ 15:05:
[...]


ik heb de api entiteiten even aangepast met de add-on url zodat het copy paste wordt en ik heb er een availability sensor aan toegevoegd, dit scheelt fouten in het log als ze niet beschikbaar zijn.

YAML:

rest:
  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/da/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DA Price"
        unique_id: da_price
        unit_of_measurement: "euro/kWh"
        value_template: "{{ (value_json.data[now().hour].da_ex) | round(5) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/consumption/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO Grid consumption"
        unique_id: dao_grid_consumption
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/consumption/vandaag?cumulate=1
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO Grid consumption cumulatief"
        unique_id: dao_grid_consumption_cumulatief
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/production/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO Grid production"
        unique_id: dao_grid_production
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO Solar Production AC"
        unique_id: dao_solar_production_ac
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/bat_in/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO Bat In"
        unique_id: dao_bat_in
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/bat_out/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO Bat Out"
        unique_id: dao_bat_out
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

  - resource: http://1f491d2b-day-ahead-opt:5000/api/report/soc/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: "DAO SoC"
        unique_id: dao_soc
        unit_of_measurement: "%"
        value_template: "{{ (value_json.data[now().hour].value) | round(1) }}"
        availability: "{{ value_json is defined and value_json.data is defined and value_json.data[now().hour] is defined }}"
        json_attributes:
          - data

ik heb dan solar ac, in voorbeeld van @pimNH werdt dc gebruikt.

Verder vraag aan @KC27
bij dao soc en da price krijg ik deze melding:
State attributes for sensor.dao_soc exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored
Is hier wat aan te doen? voor nu heb ik ze uit de recorder gehaald zodat de fout niet komt maar dan draaid het alleen vanuit het geheugen.

Is het een idee om dit stukje configuration.yaml toe te voegen aan hfd 10 van de wiki? Als je deze thread niet volgt is het niet vanzelfsprekend dat je dat toe moet voegen om de dao-sensoren in HA te krijgen, óók niet als je hfd 6 van de wiki gelezen hebt....

[diamanten]

Een vraag over het laden van de EV. Na de draaien van de optimalisatie run staat deze info in de tabel:

code:

2026-10-28 20:46:15 info: Kia Niro EV wordt geladen tussen 2026-10-29 11:00:00 en 2026-10-29 14:15:00

Weet iemand een handige methode om deze tekst in een HA-sensor te krijgen?

[KC27]

diamanten schreef op woensdag 28 oktober 2026 @ 20:56:
Een vraag over het laden van de EV. Na de draaien van de optimalisatie run staat deze info in de tabel:

code:

2026-10-28 20:46:15 info: Kia Niro EV wordt geladen tussen 2026-10-29 11:00:00 en 2026-10-29 14:15:00

Weet iemand een handige methode om deze tekst in een HA-sensor te krijgen?

Dit zit in de huidige testversie (zie hierboven de changelog van 2026.10.0.rc1)
Ik hoop deze eind deze week over te zetten naar "productie"

[ Voor 4% gewijzigd door KC27 op 28-10-2026 22:45 ]

[Hippe Lip]

Langzaam begin ik DAO een beetje geconfigureerd te krijgen. Nu nog leren snappen wat ik zie. Want ik zie nu wat DOA wil doen met mijn TB, maar waarom gaat die vannacht maar op halve kracht die batterij laden en niet full speed? En tussendoor wel korte tijd op max vermogen en dan weer halve kracht?

[Beekforel]

@Hippe Lip tarief is bijna flat line vannacht dus hij neemt de tijd. Heb je verschillende vermogens + efficiënties geconfigureerd voor je batterij?