:strip_icc():strip_exif()/u/685142/crop66d0254153c6a_cropped.jpg?f=community)
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
:strip_icc():strip_exif()/u/40490/avatar23.jpg?f=community){kind=avatar}
Misschien wat minder ChatGPT gebruiken @hemertje, je eigen reacties beginnen ook aardig AI te lijken. 
Ik wil vandaag of morgen mijn setup met Marstek batterijen even beschrijven. Zal proberen ook de door jou gevraagde informatie erbij te zetten.
Ik wil vandaag of morgen mijn setup met Marstek batterijen even beschrijven. Zal proberen ook de door jou gevraagde informatie erbij te zetten.
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
@hemertje bij deze.
Ik heb een Home Assistant package gemaakt waarin ik al mijn (generieke) helpers, automations en scripts heb gemaakt.
https://gist.github.com/fbloemhof/ded1c1dcfd797d11e4b61e66c101e4f0
Denk er aan dat je op regel 19 je eigen notify target invult en op regel 1170 het IP adres van DAO invult.
Ik heb hiernaast nog een andere file waarin ik wat persoonlijkere config heb, specifieker voor mijn setup.
In de DAO configuratie heb ik dan mijn battery als volgt geconfigureerd:
Er zit, nu nog eens bekeken, toch wel wat specifieke dingen van mij in de package, ik houd bijvoorbeeld ook rekening met het laden van mijn EV. Ook heb ik momenteel wat gedonder met 1 van mijn 3 accu's, dus die is grotendeels uitgezonderd in de sensoren/automations.
Er zit ook allemaal voorbereiding in voor machines, die ik nog helemaal niet heb. De Ariston boiler boost werkt wel, rest niet.
Ik begon hieraan met de ambitie een zo generiek mogelijke file te maken die mogelijk opgenomen kan worden in de DAO wiki, maar ik denk dat ik bij nader inzien dit beter in losse packages ("modules") kan gaan gieten zodat je kunt kiezen wat je wel/niet wilt hebben.
Ik heb zoveel mogelijk generieke naamgeving aangehouden (alles begint altijd met DAO) en ook opmaak en comments zo overzichtelijk mogelijk gehouden, maar het is een hoop avonduurtjes pielerij dus er sluipt ook wel eens wat luiheid doorheen.
Ik heb een Home Assistant package gemaakt waarin ik al mijn (generieke) helpers, automations en scripts heb gemaakt.
https://gist.github.com/fbloemhof/ded1c1dcfd797d11e4b61e66c101e4f0
Denk er aan dat je op regel 19 je eigen notify target invult en op regel 1170 het IP adres van DAO invult.
Ik heb hiernaast nog een andere file waarin ik wat persoonlijkere config heb, specifieker voor mijn setup.
In de DAO configuratie heb ik dan mijn battery als volgt geconfigureerd:
De keten is dan: DAO run past input_boolean.dao_battery_balance_mode en/of input_number.dao_battery_power_feedin aan, wat vervolgens automation.dao_marstek_battery_bridge zal triggeren. Die automation roept vervolgens script.marstek_control aan die de daadwerkelijke batterijen aanstuurt. Mijn batterijen hebben zelf een PID meter (in dit topic geleerd) en die kunnen daarmee prima zelf NOM aanhouden.
Er zit, nu nog eens bekeken, toch wel wat specifieke dingen van mij in de package, ik houd bijvoorbeeld ook rekening met het laden van mijn EV. Ook heb ik momenteel wat gedonder met 1 van mijn 3 accu's, dus die is grotendeels uitgezonderd in de sensoren/automations.
Er zit ook allemaal voorbereiding in voor machines, die ik nog helemaal niet heb.
De Ariston boiler boost werkt wel, rest niet.Ik begon hieraan met de ambitie een zo generiek mogelijke file te maken die mogelijk opgenomen kan worden in de DAO wiki, maar ik denk dat ik bij nader inzien dit beter in losse packages ("modules") kan gaan gieten zodat je kunt kiezen wat je wel/niet wilt hebben.
Ik heb zoveel mogelijk generieke naamgeving aangehouden (alles begint altijd met DAO) en ook opmaak en comments zo overzichtelijk mogelijk gehouden, maar het is een hoop avonduurtjes pielerij dus er sluipt ook wel eens wat luiheid doorheen.
[ Voor 3% gewijzigd door Beekforel op 08-05-2026 08:06 ]
ja is herkenbaar he:
Misschien wat minder ChatGPT gebruiken @hemertje, je eigen reacties beginnen ook aardig AI te lijken.
Ik wil vandaag of morgen mijn setup met Marstek batterijen even beschrijven. Zal proberen ook de door jou gevraagde informatie erbij te zetten.
ik gebruik Claude Code voor men reis door Home Assistant...
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
Hoi, dankjewel voor deze informatie!
ik krijg een 404 foutmelding op je Github link
@Bravo ik lees in je handtekening dat ook jij in een prachtige EV mag rijden
hoe voorkom jij dat je wanneer je de EV laad je de kWh uit je thuisbatterijen haalt?
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
Oeps, heb delink gerepareerd.:
[...]
Hoi, dankjewel voor deze informatie!
ik krijg een 404 foutmelding op je Github link
@Bravo ik lees in je handtekening dat ook jij in een prachtige EV mag rijden
hoe voorkom jij dat je wanneer je de EV laad je de kWh uit je thuisbatterijen haalt?
Ik laad mijn EV overigens niet met DAO, dat laat ik over aan Tibber. Die knalt er dus wel doorheen maar DAO gaat daar goed mee om.
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Morgen tussen 10:00 en 16:00 (ongeveer) is de prijs een flatline op 0. Dat ziet er uit als een fout ergens...
Tibber laat hetzelfde zien.
Maar ik heb toch sterk het gevoel dat er ergens in een systeem iets stuk is gegaan er er 0.00 euro wordt geretourneerd
Tibber laat hetzelfde zien.
Maar ik heb toch sterk het gevoel dat er ergens in een systeem iets stuk is gegaan er er 0.00 euro wordt geretourneerd
@KC27 @simnet @Beekforel @Bravo de laatste week met vriend Claude (Code) verder inhoudelijk in DAO, thuisbatterijen en NOM gedoken.
Van daaruit een aantal Feature Requests welk naar mijn idee een toegevoegde waarde kan bieden aan DAO en hun eindgebruikers.
Een overzichtje met hulp van Claude... ik ben benieuwd naar jou en anderen hun visie en mening
DAO Feature Requests
Hieronder een aantal feature requests voor de Day Ahead Optimizer (DAO), opgesteld na vergelijkende analyse van een aantal vergelijkbare projecten: bvweerd/battery_controller (Dynamic Programming optimizer), Utini2000/Zendure-Solarflow-Local-HomeAssistant (productie-grade NoM controller) en b3nn0/EpexPredictor (LightGBM EPEX prijsvoorspelling). Aangevuld met eigen implementatie-ervaring op een Zendure 3× SolarFlow 2400 AC+ setup met SolarEdge 8kW omvormer.
---
FR-001 — entity pv switch in de solar-sectie (AC-omvormer) | Prioriteit: Hoog
DAO ondersteunt "entity pv switch" al in de battery/dc-sectie, maar niet in de solar (AC-omvormer) sectie. Bij negatieve EPEX-prijzen zetten AC-omvormers zoals SolarEdge, Fronius en SMA zichzelf automatisch uit via hun eigen app-logica. DAO weet dit niet en houdt rekening met PV-productie die er feitelijk niet is. Het gevolg: DAO verwacht PV-overschot en plant geen grid-import in, terwijl de werkelijkheid PV = 0W is. De accu laadt dan onnodig uit het grid tegen positieve prijs. De forecast-error loopt op tot 3-8 kWh per curtailment-dag.
Gewenste oplossing: voeg "entity pv switch" toe als optioneel veld in de solar (AC) sectie, identiek aan de bestaande implementatie in de dc/battery-sectie. Gedrag: als entity pv switch = off rekent DAO pv_forecast = 0 voor die installatie, en DAO mag de boolean zelf op off zetten bij negatieve terugleververgoeding.
---
FR-002 — Pre-13:00 prijsfallback vóór Nordpool-publicatie | Prioriteit: Hoog
Nordpool NL publiceert dag-vooruit prijzen rond 13:00 CET. DAO draait zijn optimalisatie op vaste tijdstippen en gebruikt vóór 13:00 statische fallback-waarden (regular high / regular low) voor de volgende dag. Het gevolg: de ochtend-optimalisatie (bijv. 07:00) plant de volgende dag verkeerd in. Bij verwachte piekprijzen (Dunkelflaute) wordt de accu te vroeg leeggemaakt; bij verwachte negatieve prijzen wordt de accu niet maximaal geladen vóór de goedkope periode.
Gewenste oplossing optie A: integratie met EpexPredictor (https://github.com/b3nn0/EpexPredictor) als optionele prijsfallback-bron. Dit project gebruikt LightGBM op weerdata + ENTSO-E load + gasprijs en ondersteunt de NL regio. Nauwkeurigheid: nacht <0,5 ct/kWh, pieken 1-1,5 ct/kWh fout. Publieke API is gratis beschikbaar.
---
FR-003 — Shadow price als horizon-eindconditie voor batterij | Prioriteit: Middel
DAO's batterij-optimalisatie gebruikt "entity min soc end opt" en "entity max soc end opt" als harde eindconditie. Deze waarden zijn statisch of handmatig ingesteld. De optimizer weet daardoor niet wat opgeslagen energie ná de planningshorizon waard is. Het gevolg: bij horizon-einde wordt de accu irrationeel leeg- of voorgepland, en gebruikers moeten dao_min_soc_einde_opt handmatig bijstellen op basis van verwachtingen voor de volgende dag.
Gewenste oplossing: een rolling shadow price als terminal condition. De shadow price is de marginale waarde van 1 kWh opgeslagen energie, afgeleid uit de vorige optimizer-run. Na ongeveer een week convergeert dit naar een stabiele waarde.
---
FR-004 — Oscillation filter (anti-micro-cyclus) | Prioriteit: Middel
DAO kan kwartieren plannen waarbij de accu afwisselend laadt en ontlaadt met een klein prijsverschil. Elke cyclus kost degradatie plus round-trip rendementsverlies. De minimaal winstgevende spread voor arbitrage is:
---
FR-005 — Write-throttling / dispatch cooldown voor battery setpoint | Prioriteit: Laag
DAO schrijft naar "entity set power feedin" bij elke optimizer-tick, ook als de waarde identiek is aan de vorige. Dit genereert onnodig HA state-changes, database-writes en downstream REST-calls naar omvormers. Gewenste oplossing: schrijf alleen naar entity set power feedin als de waarde ≥ X Watt afwijkt van de vorige (configureerbaar, bijv. 25W), of als meer dan Y seconden verstreken zijn zonder write (heartbeat, bijv. 60s). Inspiratie: Utini2000/zendure_control.yaml gebruikt een vergelijkbaar dispatch-cooldown patroon met een mismatch-check en force-flag.
---
FR-006 — EpexPredictor configuratievoorbeeld in DOCS.md | Prioriteit: Laag
Verzoek om in DAO DOCS.md een officieel configuratievoorbeeld toe te voegen voor EpexPredictor als pre-13:00 prijsfallback sensor. Dit betreft alleen documentatie, geen code-wijziging.
---
FR-007 — Native zero-export / balance controller met hysterese | Prioriteit: Hoog
DAO ondersteunt via "entity balance switch" al een balanceerstand, maar de daadwerkelijke regeling van het setpoint tijdens balanceren valt volledig buiten DAO. DAO schrijft dan geen waarden meer naar "entity set power feedin" en verwacht dat de omvormer zelf balanceert. Dit werkt goed voor hybride omvormers met ingebouwde zero-export logica (bijv. Victron ESS, SolarEdge StorEdge), maar niet voor AC-gekoppelde batterijsystemen zoals Zendure, SolarFlow, Enphase IQ Battery, of andere systemen die via een HA-helper worden aangestuurd. Voor die systemen moet de gebruiker zelf een volledige real-time regelaar bouwen.
Bewijs van de noodzaak: onze productie-implementatie
Testopstelling: Zendure 3x SolarFlow 2400 AC+ (24,48 kWh totaal, 3-fase, 1 unit per fase), SolarEdge 8kW AC-omvormer, Panasonic Aquarea 7kW warmtepomp, HomeWizard P1 meter (1s update), NL dynamische prijzen via Nordpool. Aansturing via @gielz en @gast777 proxy over zenSDK REST.
Omdat DAO tijdens balance-uren stopt met schrijven maar Zendure geen eigen zero-export logica heeft, was volledige import/export ongecontroleerd. Oplossing: een bang-bang controller met hysterese-timers gebouwd als HA-automatisering bovenop DAO. Gefaseerde implementatie:
Fase 1 — helpers (geen impact op bestaande DAO werking):
Native ondersteuning voor een zero-export regelaar als optionele module binnen DAO, actief tijdens balance-uren. Minimale vereisten: configureerbare import/export drempels, hysterese-timer (anti-flapping), SoC-aware vermogensbegrenzing, en EV-pause logica. De regelaar schrijft naar "entity set power feedin" tijdens balance-uren in plaats van te stoppen met schrijven.
Dit voorkomt dat elke gebruiker met een AC-gekoppeld batterijsysteem zelf een volledige real-time regelaar moet bouwen. De Tweakers DAO-thread toont meerdere vergelijkbare implementaties (@pimNH , @KC27 , @Bravo , @Xom , @Beekforel ) — allemaal varianten van dezelfde ontbrekende DAO-functionaliteit.
Referenties: Utini2000/Zendure-Solarflow-Local-HomeAssistant (bewezen 1-15W precisie op productie), @pimNH bang-bang implementatie (Tweakers DAO-topic), @KC27 dubbele-helper patroon (Tweakers DAO-topic).
---
Samenvatting
FR-001 entity pv switch AC-omvormer — Hoog — Bugfix/Feature
FR-002 Pre-13:00 prijsfallback / EpexPredictor — Hoog — Feature
FR-003 Shadow price terminal condition — Middel — Algoritme
FR-004 Oscillation filter — Middel — Algoritme
FR-005 Write-throttling setpoint — Laag — Optimalisatie
FR-006 EpexPredictor documentatie — Laag — Docs
FR-007 Native zero-export / balance controller — Hoog — Feature
FR-001 en FR-007 hebben de meeste directe impact. FR-007 in het bijzonder omdat meerdere gebruikers in de Tweakers DAO-thread onafhankelijk van elkaar dezelfde workaround hebben gebouwd — een duidelijk signaal dat dit een structureel ontbrekende maar veel gewenste feature is.
Alvast bedankt voor de reacties!
Van daaruit een aantal Feature Requests welk naar mijn idee een toegevoegde waarde kan bieden aan DAO en hun eindgebruikers.
Een overzichtje met hulp van Claude... ik ben benieuwd naar jou en anderen hun visie en mening
DAO Feature Requests
Hieronder een aantal feature requests voor de Day Ahead Optimizer (DAO), opgesteld na vergelijkende analyse van een aantal vergelijkbare projecten: bvweerd/battery_controller (Dynamic Programming optimizer), Utini2000/Zendure-Solarflow-Local-HomeAssistant (productie-grade NoM controller) en b3nn0/EpexPredictor (LightGBM EPEX prijsvoorspelling). Aangevuld met eigen implementatie-ervaring op een Zendure 3× SolarFlow 2400 AC+ setup met SolarEdge 8kW omvormer.
---
FR-001 — entity pv switch in de solar-sectie (AC-omvormer) | Prioriteit: Hoog
DAO ondersteunt "entity pv switch" al in de battery/dc-sectie, maar niet in de solar (AC-omvormer) sectie. Bij negatieve EPEX-prijzen zetten AC-omvormers zoals SolarEdge, Fronius en SMA zichzelf automatisch uit via hun eigen app-logica. DAO weet dit niet en houdt rekening met PV-productie die er feitelijk niet is. Het gevolg: DAO verwacht PV-overschot en plant geen grid-import in, terwijl de werkelijkheid PV = 0W is. De accu laadt dan onnodig uit het grid tegen positieve prijs. De forecast-error loopt op tot 3-8 kWh per curtailment-dag.
Gewenste oplossing: voeg "entity pv switch" toe als optioneel veld in de solar (AC) sectie, identiek aan de bestaande implementatie in de dc/battery-sectie. Gedrag: als entity pv switch = off rekent DAO pv_forecast = 0 voor die installatie, en DAO mag de boolean zelf op off zetten bij negatieve terugleververgoeding.
code:
Huidige workaround: input_boolean + automation die de curtailment-sensor synchroniseert. Werkt, maar is omslachtig en niet officieel ondersteund.1
2
3
4
5
6
7
8
9
| "solar": [
{
"name": "SolarEdge 8kW",
"entity pv switch": "input_boolean.dao_pv_solaredge_active",
"ml_prediction": "true",
"entities sensors": "sensor.solaredge_lifetime_energy",
"strings": [...]
}
] |
---
FR-002 — Pre-13:00 prijsfallback vóór Nordpool-publicatie | Prioriteit: Hoog
Nordpool NL publiceert dag-vooruit prijzen rond 13:00 CET. DAO draait zijn optimalisatie op vaste tijdstippen en gebruikt vóór 13:00 statische fallback-waarden (regular high / regular low) voor de volgende dag. Het gevolg: de ochtend-optimalisatie (bijv. 07:00) plant de volgende dag verkeerd in. Bij verwachte piekprijzen (Dunkelflaute) wordt de accu te vroeg leeggemaakt; bij verwachte negatieve prijzen wordt de accu niet maximaal geladen vóór de goedkope periode.
Gewenste oplossing optie A: integratie met EpexPredictor (https://github.com/b3nn0/EpexPredictor) als optionele prijsfallback-bron. Dit project gebruikt LightGBM op weerdata + ENTSO-E load + gasprijs en ondersteunt de NL regio. Nauwkeurigheid: nacht <0,5 ct/kWh, pieken 1-1,5 ct/kWh fout. Publieke API is gratis beschikbaar.
code:
Gewenste oplossing optie B: een "source_day_ahead_fallback" veld dat een HA-sensor accepteert met forecast-attributen, zodat gebruikers zelf een prijsmodel kunnen koppelen. Referentie: bvweerd/battery_controller ALGORITHM.md §9 en §14 voor een zelflerend historisch prijsmodel op basis van weerdata en recorder-data.1
2
3
4
5
6
| "prices": {
"source_day_ahead": "nordpool",
"source_forecast_fallback": "epexpredictor",
"epexpredictor_url": "https://epexpredictor.batzill.com/prices_short",
"epexpredictor_region": "NL"
} |
---
FR-003 — Shadow price als horizon-eindconditie voor batterij | Prioriteit: Middel
DAO's batterij-optimalisatie gebruikt "entity min soc end opt" en "entity max soc end opt" als harde eindconditie. Deze waarden zijn statisch of handmatig ingesteld. De optimizer weet daardoor niet wat opgeslagen energie ná de planningshorizon waard is. Het gevolg: bij horizon-einde wordt de accu irrationeel leeg- of voorgepland, en gebruikers moeten dao_min_soc_einde_opt handmatig bijstellen op basis van verwachtingen voor de volgende dag.
Gewenste oplossing: een rolling shadow price als terminal condition. De shadow price is de marginale waarde van 1 kWh opgeslagen energie, afgeleid uit de vorige optimizer-run. Na ongeveer een week convergeert dit naar een stabiele waarde.
code:
Praktisch effect: de optimizer stopt met irrationeel ontladen vlak voor het horizon-einde en dao_min_soc_einde_opt hoeft niet meer handmatig bijgesteld te worden. Volledige wiskundige uitwerking in bvweerd/battery_controller ALGORITHM.md §5 en §9.1
2
| terminal_value[s] = stored_kwh[s] x shadow_price shadow_price = afgeleid uit vorige optimizer-run (convergeert ~1 week) |
---
FR-004 — Oscillation filter (anti-micro-cyclus) | Prioriteit: Middel
DAO kan kwartieren plannen waarbij de accu afwisselend laadt en ontlaadt met een klein prijsverschil. Elke cyclus kost degradatie plus round-trip rendementsverlies. De minimaal winstgevende spread voor arbitrage is:
code:
Laden bij 0,10 €/kWh en ontladen bij 0,13 €/kWh geeft slechts 0,03 €/kWh spread, wat na degradatiekosten niet winstgevend is. Gewenste oplossing: een post-processing filter op de optimizer-output waarbij een laad→ontlaad of ontlaad→laad overgang die minder dan min_arbitrage_spread oplevert wordt vervangen door idle. Alternatief als config-parameter: "min_price_spread": 0.03 die de optimizer zelf meeneemt in de kostenfunctie. Referentie: bvweerd/battery_controller ALGORITHM.md §8.1 voor het iteratieve lookahead-algoritme.1
2
3
| min_spread = (2 x cycle_cost_per_kWh + min_price_spread) / sqrt(RTE)
= (2 x 0.015 + 0.005) / sqrt(0.93)
≈ 0.036 EUR/kWh |
---
FR-005 — Write-throttling / dispatch cooldown voor battery setpoint | Prioriteit: Laag
DAO schrijft naar "entity set power feedin" bij elke optimizer-tick, ook als de waarde identiek is aan de vorige. Dit genereert onnodig HA state-changes, database-writes en downstream REST-calls naar omvormers. Gewenste oplossing: schrijf alleen naar entity set power feedin als de waarde ≥ X Watt afwijkt van de vorige (configureerbaar, bijv. 25W), of als meer dan Y seconden verstreken zijn zonder write (heartbeat, bijv. 60s). Inspiratie: Utini2000/zendure_control.yaml gebruikt een vergelijkbaar dispatch-cooldown patroon met een mismatch-check en force-flag.
---
FR-006 — EpexPredictor configuratievoorbeeld in DOCS.md | Prioriteit: Laag
Verzoek om in DAO DOCS.md een officieel configuratievoorbeeld toe te voegen voor EpexPredictor als pre-13:00 prijsfallback sensor. Dit betreft alleen documentatie, geen code-wijziging.
code:
Bron: https://github.com/b3nn0/EpexPredictor — NL regio ondersteund, gratis publieke API, self-hosting mogelijk via Docker Compose, ENTSO-E API key verhoogt nauwkeurigheid significant voor NL.1
2
3
4
5
6
7
8
9
10
11
12
| sensor:
- platform: rest
resource: "https://epexpredictor.batzill.com/prices_short?region=NL&surcharge=10.154&taxPercent=21&unit=EUR_PER_KWH&hours=48"
method: GET
unique_id: epex_price_prediction_nl
name: "EPEX Price Prediction NL"
unit_of_measurement: "EUR/kWh"
scan_interval: 3600
value_template: "{{ value_json.t[0] }}"
json_attributes:
- s
- t |
---
FR-007 — Native zero-export / balance controller met hysterese | Prioriteit: Hoog
DAO ondersteunt via "entity balance switch" al een balanceerstand, maar de daadwerkelijke regeling van het setpoint tijdens balanceren valt volledig buiten DAO. DAO schrijft dan geen waarden meer naar "entity set power feedin" en verwacht dat de omvormer zelf balanceert. Dit werkt goed voor hybride omvormers met ingebouwde zero-export logica (bijv. Victron ESS, SolarEdge StorEdge), maar niet voor AC-gekoppelde batterijsystemen zoals Zendure, SolarFlow, Enphase IQ Battery, of andere systemen die via een HA-helper worden aangestuurd. Voor die systemen moet de gebruiker zelf een volledige real-time regelaar bouwen.
Bewijs van de noodzaak: onze productie-implementatie
Testopstelling: Zendure 3x SolarFlow 2400 AC+ (24,48 kWh totaal, 3-fase, 1 unit per fase), SolarEdge 8kW AC-omvormer, Panasonic Aquarea 7kW warmtepomp, HomeWizard P1 meter (1s update), NL dynamische prijzen via Nordpool. Aansturing via @gielz en @gast777 proxy over zenSDK REST.
Omdat DAO tijdens balance-uren stopt met schrijven maar Zendure geen eigen zero-export logica heeft, was volledige import/export ongecontroleerd. Oplossing: een bang-bang controller met hysterese-timers gebouwd als HA-automatisering bovenop DAO. Gefaseerde implementatie:
Fase 1 — helpers (geen impact op bestaande DAO werking):
code:
Fase 2 — bang-bang controller (elke 6s tijdens balance, SoC-aware power limits):1
2
3
4
5
6
7
8
9
10
11
12
13
| input_number: dao_zendure_target_power: # actuator tussen DAO en omvormer, bereik -3000..+3000 W dao_nom_import_threshold: # default 80 W — drempel voor laden dao_nom_export_threshold: # default 200 W — drempel voor ontladen dao_nom_bias: # default 7 W — kleine offset richting export dao_nom_timer_seconds: # default 10 s — hysterese-timer, tunable 5-60s input_select: dao_nom_active_mode: # charge / discharge / idle timer: dao_nom_import_arm: # hysterese-timer import dao_nom_export_arm: # hysterese-timer export |
code:
Fase 2.5 — uitbreidingen:1
2
3
4
5
6
7
8
9
10
11
12
13
| # Logica (vereenvoudigd): # grid = P1_meting - bias # als grid > import_threshold: arm import_timer → na 10s: mode = discharge # als grid < -export_threshold: arm export_timer → na 10s: mode = charge # anders: cancel beide timers (dode zone) # # target binnen huidige mode: # discharge: target = -clamp(grid, 0, max_discharge_voor_SoC) # charge: target = +clamp(-grid, 0, max_charge_voor_SoC) # # SoC-aware limieten (pimNH-tabel, aangepast aan 3000W Zendure max): # laden: SoC<88% → 3000W, SoC<93% → 2000W, SoC<95% → 800W, SoC<98% → 300W, SoC<99% → 150W, anders 60W # ontladen: SoC>30% → 3000W, SoC>20% → 2000W, SoC>15% → 1500W, anders 300W |
code:
Fase 2.6 — PV-curtailment workaround (zie ook FR-001):1
2
3
4
5
6
| # Grid-overbelastings-clamp (safety, normale werking raakt dit nooit): # grid > 6000W → forceer max discharge | grid < -5000W → forceer max charge # EV-aware force-stop: # bij EV charge-start → target = 0, mode = idle # bij EV charge-einde → herstart init |
code:
Gevraagde DAO-feature1
2
3
| # input_boolean.dao_pv_solaredge_active wordt gesynchroniseerd met # sensor.dao_pv_curtailment_active (all-in prijs < drempel). # Zolang FR-001 niet upstream beschikbaar is: handmatige sync via automation. |
Native ondersteuning voor een zero-export regelaar als optionele module binnen DAO, actief tijdens balance-uren. Minimale vereisten: configureerbare import/export drempels, hysterese-timer (anti-flapping), SoC-aware vermogensbegrenzing, en EV-pause logica. De regelaar schrijft naar "entity set power feedin" tijdens balance-uren in plaats van te stoppen met schrijven.
Dit voorkomt dat elke gebruiker met een AC-gekoppeld batterijsysteem zelf een volledige real-time regelaar moet bouwen. De Tweakers DAO-thread toont meerdere vergelijkbare implementaties (@pimNH , @KC27 , @Bravo , @Xom , @Beekforel ) — allemaal varianten van dezelfde ontbrekende DAO-functionaliteit.
Referenties: Utini2000/Zendure-Solarflow-Local-HomeAssistant (bewezen 1-15W precisie op productie), @pimNH bang-bang implementatie (Tweakers DAO-topic), @KC27 dubbele-helper patroon (Tweakers DAO-topic).
---
Samenvatting
FR-001 entity pv switch AC-omvormer — Hoog — Bugfix/Feature
FR-002 Pre-13:00 prijsfallback / EpexPredictor — Hoog — Feature
FR-003 Shadow price terminal condition — Middel — Algoritme
FR-004 Oscillation filter — Middel — Algoritme
FR-005 Write-throttling setpoint — Laag — Optimalisatie
FR-006 EpexPredictor documentatie — Laag — Docs
FR-007 Native zero-export / balance controller — Hoog — Feature
FR-001 en FR-007 hebben de meeste directe impact. FR-007 in het bijzonder omdat meerdere gebruikers in de Tweakers DAO-thread onafhankelijk van elkaar dezelfde workaround hebben gebouwd — een duidelijk signaal dat dit een structureel ontbrekende maar veel gewenste feature is.
Alvast bedankt voor de reacties!
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
FR-001 zit er gewoon in. FR-007 doen in 9 van de 10 gevallen de inverters zelf. Vandaar dat er waarschijnlijk de keus is gemaakt dat niet te integreren. E.g. de logica in Home Assistant te bakken.:
@KC27 @simnet @Beekforel @Bravo de laatste week met vriend Claude (Code) verder inhoudelijk in DAO, thuisbatterijen en NOM gedoken.
Van daaruit een aantal Feature Requests welk naar mijn idee een toegevoegde waarde kan bieden aan DAO en hun eindgebruikers.
Een overzichtje met hulp van Claude... ik ben benieuwd naar jou en anderen hun visie en mening
DAO Feature Requests
Hieronder een aantal feature requests voor de Day Ahead Optimizer (DAO), opgesteld na vergelijkende analyse van een aantal vergelijkbare projecten: bvweerd/battery_controller (Dynamic Programming optimizer), Utini2000/Zendure-Solarflow-Local-HomeAssistant (productie-grade NoM controller) en b3nn0/EpexPredictor (LightGBM EPEX prijsvoorspelling). Aangevuld met eigen implementatie-ervaring op een Zendure 3× SolarFlow 2400 AC+ setup met SolarEdge 8kW omvormer.
---
FR-001 — entity pv switch in de solar-sectie (AC-omvormer) | Prioriteit: Hoog
DAO ondersteunt "entity pv switch" al in de battery/dc-sectie, maar niet in de solar (AC-omvormer) sectie. Bij negatieve EPEX-prijzen zetten AC-omvormers zoals SolarEdge, Fronius en SMA zichzelf automatisch uit via hun eigen app-logica. DAO weet dit niet en houdt rekening met PV-productie die er feitelijk niet is. Het gevolg: DAO verwacht PV-overschot en plant geen grid-import in, terwijl de werkelijkheid PV = 0W is. De accu laadt dan onnodig uit het grid tegen positieve prijs. De forecast-error loopt op tot 3-8 kWh per curtailment-dag.
Gewenste oplossing: voeg "entity pv switch" toe als optioneel veld in de solar (AC) sectie, identiek aan de bestaande implementatie in de dc/battery-sectie. Gedrag: als entity pv switch = off rekent DAO pv_forecast = 0 voor die installatie, en DAO mag de boolean zelf op off zetten bij negatieve terugleververgoeding.code:Huidige workaround: input_boolean + automation die de curtailment-sensor synchroniseert. Werkt, maar is omslachtig en niet officieel ondersteund.
"solar": [ { "name": "SolarEdge 8kW", "entity pv switch": "input_boolean.dao_pv_solaredge_active", "ml_prediction": "true", "entities sensors": "sensor.solaredge_lifetime_energy", "strings": [...] } ]
---
FR-002 — Pre-13:00 prijsfallback vóór Nordpool-publicatie | Prioriteit: Hoog
Nordpool NL publiceert dag-vooruit prijzen rond 13:00 CET. DAO draait zijn optimalisatie op vaste tijdstippen en gebruikt vóór 13:00 statische fallback-waarden (regular high / regular low) voor de volgende dag. Het gevolg: de ochtend-optimalisatie (bijv. 07:00) plant de volgende dag verkeerd in. Bij verwachte piekprijzen (Dunkelflaute) wordt de accu te vroeg leeggemaakt; bij verwachte negatieve prijzen wordt de accu niet maximaal geladen vóór de goedkope periode.
Gewenste oplossing optie A: integratie met EpexPredictor (https://github.com/b3nn0/EpexPredictor) als optionele prijsfallback-bron. Dit project gebruikt LightGBM op weerdata + ENTSO-E load + gasprijs en ondersteunt de NL regio. Nauwkeurigheid: nacht <0,5 ct/kWh, pieken 1-1,5 ct/kWh fout. Publieke API is gratis beschikbaar.code:Gewenste oplossing optie B: een "source_day_ahead_fallback" veld dat een HA-sensor accepteert met forecast-attributen, zodat gebruikers zelf een prijsmodel kunnen koppelen. Referentie: bvweerd/battery_controller ALGORITHM.md §9 en §14 voor een zelflerend historisch prijsmodel op basis van weerdata en recorder-data.
"prices": { "source_day_ahead": "nordpool", "source_forecast_fallback": "epexpredictor", "epexpredictor_url": "https://epexpredictor.batzill.com/prices_short", "epexpredictor_region": "NL" }
---
FR-003 — Shadow price als horizon-eindconditie voor batterij | Prioriteit: Middel
DAO's batterij-optimalisatie gebruikt "entity min soc end opt" en "entity max soc end opt" als harde eindconditie. Deze waarden zijn statisch of handmatig ingesteld. De optimizer weet daardoor niet wat opgeslagen energie ná de planningshorizon waard is. Het gevolg: bij horizon-einde wordt de accu irrationeel leeg- of voorgepland, en gebruikers moeten dao_min_soc_einde_opt handmatig bijstellen op basis van verwachtingen voor de volgende dag.
Gewenste oplossing: een rolling shadow price als terminal condition. De shadow price is de marginale waarde van 1 kWh opgeslagen energie, afgeleid uit de vorige optimizer-run. Na ongeveer een week convergeert dit naar een stabiele waarde.code:Praktisch effect: de optimizer stopt met irrationeel ontladen vlak voor het horizon-einde en dao_min_soc_einde_opt hoeft niet meer handmatig bijgesteld te worden. Volledige wiskundige uitwerking in bvweerd/battery_controller ALGORITHM.md §5 en §9.
---
FR-004 — Oscillation filter (anti-micro-cyclus) | Prioriteit: Middel
DAO kan kwartieren plannen waarbij de accu afwisselend laadt en ontlaadt met een klein prijsverschil. Elke cyclus kost degradatie plus round-trip rendementsverlies. De minimaal winstgevende spread voor arbitrage is:code:Laden bij 0,10 €/kWh en ontladen bij 0,13 €/kWh geeft slechts 0,03 €/kWh spread, wat na degradatiekosten niet winstgevend is. Gewenste oplossing: een post-processing filter op de optimizer-output waarbij een laad→ontlaad of ontlaad→laad overgang die minder dan min_arbitrage_spread oplevert wordt vervangen door idle. Alternatief als config-parameter: "min_price_spread": 0.03 die de optimizer zelf meeneemt in de kostenfunctie. Referentie: bvweerd/battery_controller ALGORITHM.md §8.1 voor het iteratieve lookahead-algoritme.
min_spread = (2 x cycle_cost_per_kWh + min_price_spread) / sqrt(RTE) = (2 x 0.015 + 0.005) / sqrt(0.93) ≈ 0.036 EUR/kWh
---
FR-005 — Write-throttling / dispatch cooldown voor battery setpoint | Prioriteit: Laag
DAO schrijft naar "entity set power feedin" bij elke optimizer-tick, ook als de waarde identiek is aan de vorige. Dit genereert onnodig HA state-changes, database-writes en downstream REST-calls naar omvormers. Gewenste oplossing: schrijf alleen naar entity set power feedin als de waarde ≥ X Watt afwijkt van de vorige (configureerbaar, bijv. 25W), of als meer dan Y seconden verstreken zijn zonder write (heartbeat, bijv. 60s). Inspiratie: Utini2000/zendure_control.yaml gebruikt een vergelijkbaar dispatch-cooldown patroon met een mismatch-check en force-flag.
---
FR-006 — EpexPredictor configuratievoorbeeld in DOCS.md | Prioriteit: Laag
Verzoek om in DAO DOCS.md een officieel configuratievoorbeeld toe te voegen voor EpexPredictor als pre-13:00 prijsfallback sensor. Dit betreft alleen documentatie, geen code-wijziging.code:Bron: https://github.com/b3nn0/EpexPredictor — NL regio ondersteund, gratis publieke API, self-hosting mogelijk via Docker Compose, ENTSO-E API key verhoogt nauwkeurigheid significant voor NL.
sensor: - platform: rest resource: "https://epexpredictor.batzill.com/prices_short?region=NL&surcharge=10.154&taxPercent=21&unit=EUR_PER_KWH&hours=48" method: GET unique_id: epex_price_prediction_nl name: "EPEX Price Prediction NL" unit_of_measurement: "EUR/kWh" scan_interval: 3600 value_template: "{{ value_json.t[0] }}" json_attributes: - s - t
---
FR-007 — Native zero-export / balance controller met hysterese | Prioriteit: Hoog
DAO ondersteunt via "entity balance switch" al een balanceerstand, maar de daadwerkelijke regeling van het setpoint tijdens balanceren valt volledig buiten DAO. DAO schrijft dan geen waarden meer naar "entity set power feedin" en verwacht dat de omvormer zelf balanceert. Dit werkt goed voor hybride omvormers met ingebouwde zero-export logica (bijv. Victron ESS, SolarEdge StorEdge), maar niet voor AC-gekoppelde batterijsystemen zoals Zendure, SolarFlow, Enphase IQ Battery, of andere systemen die via een HA-helper worden aangestuurd. Voor die systemen moet de gebruiker zelf een volledige real-time regelaar bouwen.
Bewijs van de noodzaak: onze productie-implementatie
Testopstelling: Zendure 3x SolarFlow 2400 AC+ (24,48 kWh totaal, 3-fase, 1 unit per fase), SolarEdge 8kW AC-omvormer, Panasonic Aquarea 7kW warmtepomp, HomeWizard P1 meter (1s update), NL dynamische prijzen via Nordpool. Aansturing via @gielz en @gast777 proxy over zenSDK REST.
Omdat DAO tijdens balance-uren stopt met schrijven maar Zendure geen eigen zero-export logica heeft, was volledige import/export ongecontroleerd. Oplossing: een bang-bang controller met hysterese-timers gebouwd als HA-automatisering bovenop DAO. Gefaseerde implementatie:
Fase 1 — helpers (geen impact op bestaande DAO werking):code:Fase 2 — bang-bang controller (elke 6s tijdens balance, SoC-aware power limits):
Native ondersteuning voor een zero-export regelaar als optionele module binnen DAO, actief tijdens balance-uren. Minimale vereisten: configureerbare import/export drempels, hysterese-timer (anti-flapping), SoC-aware vermogensbegrenzing, en EV-pause logica. De regelaar schrijft naar "entity set power feedin" tijdens balance-uren in plaats van te stoppen met schrijven.
Dit voorkomt dat elke gebruiker met een AC-gekoppeld batterijsysteem zelf een volledige real-time regelaar moet bouwen. De Tweakers DAO-thread toont meerdere vergelijkbare implementaties (@pimNH , @KC27 , @Bravo , @Xom , @Beekforel ) — allemaal varianten van dezelfde ontbrekende DAO-functionaliteit.
Referenties: Utini2000/Zendure-Solarflow-Local-HomeAssistant (bewezen 1-15W precisie op productie), @pimNH bang-bang implementatie (Tweakers DAO-topic), @KC27 dubbele-helper patroon (Tweakers DAO-topic).
---
Samenvatting
FR-001 entity pv switch AC-omvormer — Hoog — Bugfix/Feature
FR-002 Pre-13:00 prijsfallback / EpexPredictor — Hoog — Feature
FR-003 Shadow price terminal condition — Middel — Algoritme
FR-004 Oscillation filter — Middel — Algoritme
FR-005 Write-throttling setpoint — Laag — Optimalisatie
FR-006 EpexPredictor documentatie — Laag — Docs
FR-007 Native zero-export / balance controller — Hoog — Feature
FR-001 en FR-007 hebben de meeste directe impact. FR-007 in het bijzonder omdat meerdere gebruikers in de Tweakers DAO-thread onafhankelijk van elkaar dezelfde workaround hebben gebouwd — een duidelijk signaal dat dit een structureel ontbrekende maar veel gewenste feature is.
Alvast bedankt voor de reacties!
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
Dit heeft alles te maken met de merit-order systematiek waarmee de day-ahead prijzen tot stand komen.:
Morgen tussen 10:00 en 16:00 (ongeveer) is de prijs een flatline op 0. Dat ziet er uit als een fout ergens...
Tibber laat hetzelfde zien.
Maar ik heb toch sterk het gevoel dat er ergens in een systeem iets stuk is gegaan er er 0.00 euro wordt geretourneerd
Veel producenten met zon- en windparken bieden hun (geplande) productie aan met een prijs van minimaal 0.00 euro (willen geen verlies maken). Zodra er meer dan de vraag wordt aangeboden tegen 0 euro wordt daarop de prijs bepaald.
De prijs zakt onder nul als er genoeg producenten zijn die ook bij negatieve prijzen gewoon blijven produceren en met die lagere prijzen aanbieden:
- energiebedrijven van consumenten met een vast contract moeten van hun overschot af
- producenten met een subsidie per geproduceerde kWh gaan door tot de subsidiegrens.
Als er dan ook nog genoeg vraag is (bij die negatieve prijs) zakt het evenwicht van vraag en aanbod alsnog "onder nul".
Hieronder een grafiek van een tool die de day-ahead prijs zes dagen vooruit voorspelt op basis van
- de verwachte consumptie in Nederland enerzijds en
- anderzijds geaccumuleerd: de productie van wind op land, wind op zee en zon.
Zondag wordt mogelijk weer een dag met day ahead prijzen onder nul (disclaimer: dit model heeft de neiging om pieken en dalen te overschatten).
:strip_exif()/f/image/OjGWv1YgeQUxJTfrokVNrWry.png?f=user_large)
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
:strip_icc():strip_exif()/u/12112/snake_av.jpg?f=community)
:strip_icc():strip_exif()/u/2026/DSC_2281.jpg?f=community)
Hier draait het, maar ik geloof niet dat ik gebruik maak van de delen die je verandert hebt. Wel blijft het lastig om te zien wanneer iets fout gaat. Ik heb de test versie normaal uit staan en test alleen wanneer je een nieuwe versie hebt. Dat betekent dat de meteo/epex/ml altijd achterlopen.
Na run met debug komt er een groen vinkje maar geen resultaat, en ook geen duidelijke foutmelding. Hierdoor is het moeilijk achterhalen wat je moet doen om het aan de praat te krijgen. Ik weet intussen wat ik moet doen, maar het zou duidelijker kunnen.
===
na ophalen van prijzen krijg ik dit bij run:
===
na ophalen meteo verdwijnt de foutmelding. Nu kan ik wel een debug run doen, met groen vinkje als resultaat. De eerste keer dat ik dan terug ga naar Home zag ik nog de niet geoptimaliseerde grafiek, na nog een run wel.
===
Uiteindelijk kon ik wel een ml training afstarten maar kwam ik op deze melding:
code:
en dit in de addon log in HA:1
2
3
4
5
| <!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> |
code:
Ik weet dat ik dan de ML training met een scheduler moet starten, maar dit verdient wel wat polijsting 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| [2026-05-09 07:50:05,126] ERROR in app: Exception on /log [GET]
Traceback (most recent call last):
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
response = self.full_dispatch_request()
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
rv = self.dispatch_request()
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/root/dao/webserver/app/routes.py", line 652, in show_log
logfile = task_state["logfile"]
~~~~~~~~~~^^^^^^^^^^^
KeyError: 'logfile' |
Ik ben wel heel erg blij met DAO overigens! Petje af voor al het werk dat er verzet wordt door jou en de andere programmeurs.
[ Voor 64% gewijzigd door balk op 09-05-2026 07:54 ]
De komende tijd wil ik het inplannen van de EV door DAO wat meer onderzoeken. Tot nu toe merk ik dat de strategie "minimale kosten" vaak uitkomt op een situatie waarbij er niet aan één stuk geladen wordt, maar dat er zelfs delen van kwartieren wordt geladen.
Voorbeeld (met name het stuk rond 15/16 uur):
:strip_exif()/f/image/IdyyvPp1UpOjBYRqArDzT0ZL.png?f=user_large)
Mijn voorkeur zou daarom uitgaan naar één laadblok waarbij de hoeveelheid kWh per kwartier door de laadstroom geregeld wordt. Is er een manier om dit te bereiken?
Voorbeeld (met name het stuk rond 15/16 uur):
code:
Ik begrijp dat het een resultaat is van een rekenkundige optimalisatie, maar dit pendelgedrag is in mijn ogen slechter voor de hardware en bovendien krijg je elk kwartier een melding van de auto app dat het laden gestart/gestopt is. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| 2026-05-09 08:50:08 info: Inzet-factor laden BMW IX1 per stap uur 0.0A 6.0A 8.0A 10.0A 12.0A 14.0A 16.0A cons power 08:45 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 09:00 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 09:15 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 09:30 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 09:45 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 10:00 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 10:15 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 10:30 1.00(1.0) 0.00(0.0) 0.00(1.0) 0.00(0.0) -0.00(0.0) 0.00(0.0) -0.00(0.0) 0.000 5.520 10:45 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) -0.00(0.0) -0.000 0.000 11:00 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 11:15 0.96(1.0) 0.04(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.039 4.140 11:30 0.00(0.0) 0.00(0.0) 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 1.380 5.520 11:45 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 11.040 12:00 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 11.040 12:15 0.00(0.0) 0.00(0.0) 0.00(0.0) -0.00(0.0) -0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 11.040 12:30 0.00(0.0) 0.00(0.0) 0.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 16.560 12:45 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 11.040 13:00 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) -0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 11.040 13:15 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(1.0) 0.00(1.0) 1.00(1.0) 2.760 28.980 13:30 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(1.0) 1.00(1.0) 2.760 20.700 13:45 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 1.00(1.0) 2.760 11.040 14:00 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(1.0) 1.00(1.0) 2.760 20.700 14:15 0.85(1.0) 0.00(0.0) 0.00(0.0) 0.15(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.267 6.900 14:30 0.43(1.0) 0.57(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) -0.00(0.0) 0.594 4.140 14:45 0.86(1.0) 0.00(0.0) 0.14(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.197 5.520 15:00 0.90(1.0) 0.00(0.0) 0.10(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.134 5.520 15:15 0.97(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.03(1.0) 0.086 11.040 15:30 0.98(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.02(1.0) 0.00(0.0) 0.00(0.0) 0.037 8.280 15:45 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) -0.00(0.0) -0.000 0.000 16:00 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 16:15 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 16:30 1.00(1.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.00(0.0) 0.000 0.000 |
Mijn voorkeur zou daarom uitgaan naar één laadblok waarbij de hoeveelheid kWh per kwartier door de laadstroom geregeld wordt. Is er een manier om dit te bereiken?
Super nuttige feedback! Wordt zeer gewaardeerd!:
[...]
Hier draait het, maar ik geloof niet dat ik gebruik maak van de delen die je verandert hebt. Wel blijft het lastig om te zien wanneer iets fout gaat. Ik heb de test versie normaal uit staan en test alleen wanneer je een nieuwe versie hebt. Dat betekent dat de meteo/epex/ml altijd achterlopen.
Na run met debug komt er een groen vinkje maar geen resultaat, en ook geen duidelijke foutmelding. Hierdoor is het moeilijk achterhalen wat je moet doen om het aan de praat te krijgen. Ik weet intussen wat ik moet doen, maar het zou duidelijker kunnen.
===
na ophalen van prijzen krijg ik dit bij run:
[...]
===
na ophalen meteo verdwijnt de foutmelding. Nu kan ik wel een debug run doen, met groen vinkje als resultaat. De eerste keer dat ik dan terug ga naar Home zag ik nog de niet geoptimaliseerde grafiek, na nog een run wel.
===
Uiteindelijk kon ik wel een ml training afstarten maar kwam ik op deze melding:code:en dit in de addon log in HA:
[2026-05-09 07:50:05,126] ERROR in app: Exception on /log [GET] Traceback (most recent call last): File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app response = self.full_dispatch_request() File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request rv = self.handle_user_exception(e) File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request rv = self.dispatch_request() File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ File "/root/dao/webserver/app/routes.py", line 652, in show_log logfile = task_state["logfile"] ~~~~~~~~~~^^^^^^^^^^^ KeyError: 'logfile'
Ik ben wel heel erg blij met DAO overigens! Petje af voor al het werk dat er verzet wordt door jou en de andere programmeurs.
:strip_icc():strip_exif()/u/94573/crop5fb4d88a54f8e_cropped.jpeg?f=community)
Ik begin mij steeds meer te irriteren aan die lappen AI poep.:
@KC27 @simnet @Beekforel @Bravo de laatste week met vriend Claude (Code) verder inhoudelijk in DAO, thuisbatterijen en NOM gedoken.
Van daaruit een aantal Feature Requests welk naar mijn idee een toegevoegde waarde kan bieden aan DAO en hun eindgebruikers.
Een overzichtje met hulp van Claude... ik ben benieuwd naar jou en anderen hun visie en mening
DAO Feature Requests
Hieronder een aantal feature requests voor de Day Ahead Optimizer (DAO), opgesteld na vergelijkende analyse van een aantal vergelijkbare projecten: bvweerd/battery_controller (Dynamic Programming optimizer), Utini2000/Zendure-Solarflow-Local-HomeAssistant (productie-grade NoM controller) en b3nn0/EpexPredictor (LightGBM EPEX prijsvoorspelling). Aangevuld met eigen implementatie-ervaring op een Zendure 3× SolarFlow 2400 AC+ setup met SolarEdge 8kW omvormer.
---
FR-001 — entity pv switch in de solar-sectie (AC-omvormer) | Prioriteit: Hoog
DAO ondersteunt "entity pv switch" al in de battery/dc-sectie, maar niet in de solar (AC-omvormer) sectie. Bij negatieve EPEX-prijzen zetten AC-omvormers zoals SolarEdge, Fronius en SMA zichzelf automatisch uit via hun eigen app-logica. DAO weet dit niet en houdt rekening met PV-productie die er feitelijk niet is. Het gevolg: DAO verwacht PV-overschot en plant geen grid-import in, terwijl de werkelijkheid PV = 0W is. De accu laadt dan onnodig uit het grid tegen positieve prijs. De forecast-error loopt op tot 3-8 kWh per curtailment-dag.
Gewenste oplossing: voeg "entity pv switch" toe als optioneel veld in de solar (AC) sectie, identiek aan de bestaande implementatie in de dc/battery-sectie. Gedrag: als entity pv switch = off rekent DAO pv_forecast = 0 voor die installatie, en DAO mag de boolean zelf op off zetten bij negatieve terugleververgoeding.code:Huidige workaround: input_boolean + automation die de curtailment-sensor synchroniseert. Werkt, maar is omslachtig en niet officieel ondersteund.
"solar": [ { "name": "SolarEdge 8kW", "entity pv switch": "input_boolean.dao_pv_solaredge_active", "ml_prediction": "true", "entities sensors": "sensor.solaredge_lifetime_energy", "strings": [...] } ]
---
FR-002 — Pre-13:00 prijsfallback vóór Nordpool-publicatie | Prioriteit: Hoog
Nordpool NL publiceert dag-vooruit prijzen rond 13:00 CET. DAO draait zijn optimalisatie op vaste tijdstippen en gebruikt vóór 13:00 statische fallback-waarden (regular high / regular low) voor de volgende dag. Het gevolg: de ochtend-optimalisatie (bijv. 07:00) plant de volgende dag verkeerd in. Bij verwachte piekprijzen (Dunkelflaute) wordt de accu te vroeg leeggemaakt; bij verwachte negatieve prijzen wordt de accu niet maximaal geladen vóór de goedkope periode.
Gewenste oplossing optie A: integratie met EpexPredictor (https://github.com/b3nn0/EpexPredictor) als optionele prijsfallback-bron. Dit project gebruikt LightGBM op weerdata + ENTSO-E load + gasprijs en ondersteunt de NL regio. Nauwkeurigheid: nacht <0,5 ct/kWh, pieken 1-1,5 ct/kWh fout. Publieke API is gratis beschikbaar.code:Gewenste oplossing optie B: een "source_day_ahead_fallback" veld dat een HA-sensor accepteert met forecast-attributen, zodat gebruikers zelf een prijsmodel kunnen koppelen. Referentie: bvweerd/battery_controller ALGORITHM.md §9 en §14 voor een zelflerend historisch prijsmodel op basis van weerdata en recorder-data.
"prices": { "source_day_ahead": "nordpool", "source_forecast_fallback": "epexpredictor", "epexpredictor_url": "https://epexpredictor.batzill.com/prices_short", "epexpredictor_region": "NL" }
---
FR-003 — Shadow price als horizon-eindconditie voor batterij | Prioriteit: Middel
DAO's batterij-optimalisatie gebruikt "entity min soc end opt" en "entity max soc end opt" als harde eindconditie. Deze waarden zijn statisch of handmatig ingesteld. De optimizer weet daardoor niet wat opgeslagen energie ná de planningshorizon waard is. Het gevolg: bij horizon-einde wordt de accu irrationeel leeg- of voorgepland, en gebruikers moeten dao_min_soc_einde_opt handmatig bijstellen op basis van verwachtingen voor de volgende dag.
Gewenste oplossing: een rolling shadow price als terminal condition. De shadow price is de marginale waarde van 1 kWh opgeslagen energie, afgeleid uit de vorige optimizer-run. Na ongeveer een week convergeert dit naar een stabiele waarde.code:Praktisch effect: de optimizer stopt met irrationeel ontladen vlak voor het horizon-einde en dao_min_soc_einde_opt hoeft niet meer handmatig bijgesteld te worden. Volledige wiskundige uitwerking in bvweerd/battery_controller ALGORITHM.md §5 en §9.
---
FR-004 — Oscillation filter (anti-micro-cyclus) | Prioriteit: Middel
DAO kan kwartieren plannen waarbij de accu afwisselend laadt en ontlaadt met een klein prijsverschil. Elke cyclus kost degradatie plus round-trip rendementsverlies. De minimaal winstgevende spread voor arbitrage is:code:Laden bij 0,10 €/kWh en ontladen bij 0,13 €/kWh geeft slechts 0,03 €/kWh spread, wat na degradatiekosten niet winstgevend is. Gewenste oplossing: een post-processing filter op de optimizer-output waarbij een laad→ontlaad of ontlaad→laad overgang die minder dan min_arbitrage_spread oplevert wordt vervangen door idle. Alternatief als config-parameter: "min_price_spread": 0.03 die de optimizer zelf meeneemt in de kostenfunctie. Referentie: bvweerd/battery_controller ALGORITHM.md §8.1 voor het iteratieve lookahead-algoritme.
min_spread = (2 x cycle_cost_per_kWh + min_price_spread) / sqrt(RTE) = (2 x 0.015 + 0.005) / sqrt(0.93) ≈ 0.036 EUR/kWh
---
FR-005 — Write-throttling / dispatch cooldown voor battery setpoint | Prioriteit: Laag
DAO schrijft naar "entity set power feedin" bij elke optimizer-tick, ook als de waarde identiek is aan de vorige. Dit genereert onnodig HA state-changes, database-writes en downstream REST-calls naar omvormers. Gewenste oplossing: schrijf alleen naar entity set power feedin als de waarde ≥ X Watt afwijkt van de vorige (configureerbaar, bijv. 25W), of als meer dan Y seconden verstreken zijn zonder write (heartbeat, bijv. 60s). Inspiratie: Utini2000/zendure_control.yaml gebruikt een vergelijkbaar dispatch-cooldown patroon met een mismatch-check en force-flag.
---
FR-006 — EpexPredictor configuratievoorbeeld in DOCS.md | Prioriteit: Laag
Verzoek om in DAO DOCS.md een officieel configuratievoorbeeld toe te voegen voor EpexPredictor als pre-13:00 prijsfallback sensor. Dit betreft alleen documentatie, geen code-wijziging.code:Bron: https://github.com/b3nn0/EpexPredictor — NL regio ondersteund, gratis publieke API, self-hosting mogelijk via Docker Compose, ENTSO-E API key verhoogt nauwkeurigheid significant voor NL.
sensor: - platform: rest resource: "https://epexpredictor.batzill.com/prices_short?region=NL&surcharge=10.154&taxPercent=21&unit=EUR_PER_KWH&hours=48" method: GET unique_id: epex_price_prediction_nl name: "EPEX Price Prediction NL" unit_of_measurement: "EUR/kWh" scan_interval: 3600 value_template: "{{ value_json.t[0] }}" json_attributes: - s - t
---
FR-007 — Native zero-export / balance controller met hysterese | Prioriteit: Hoog
DAO ondersteunt via "entity balance switch" al een balanceerstand, maar de daadwerkelijke regeling van het setpoint tijdens balanceren valt volledig buiten DAO. DAO schrijft dan geen waarden meer naar "entity set power feedin" en verwacht dat de omvormer zelf balanceert. Dit werkt goed voor hybride omvormers met ingebouwde zero-export logica (bijv. Victron ESS, SolarEdge StorEdge), maar niet voor AC-gekoppelde batterijsystemen zoals Zendure, SolarFlow, Enphase IQ Battery, of andere systemen die via een HA-helper worden aangestuurd. Voor die systemen moet de gebruiker zelf een volledige real-time regelaar bouwen.
Bewijs van de noodzaak: onze productie-implementatie
Testopstelling: Zendure 3x SolarFlow 2400 AC+ (24,48 kWh totaal, 3-fase, 1 unit per fase), SolarEdge 8kW AC-omvormer, Panasonic Aquarea 7kW warmtepomp, HomeWizard P1 meter (1s update), NL dynamische prijzen via Nordpool. Aansturing via @gielz en @gast777 proxy over zenSDK REST.
Omdat DAO tijdens balance-uren stopt met schrijven maar Zendure geen eigen zero-export logica heeft, was volledige import/export ongecontroleerd. Oplossing: een bang-bang controller met hysterese-timers gebouwd als HA-automatisering bovenop DAO. Gefaseerde implementatie:
Fase 1 — helpers (geen impact op bestaande DAO werking):code:Fase 2 — bang-bang controller (elke 6s tijdens balance, SoC-aware power limits):
Native ondersteuning voor een zero-export regelaar als optionele module binnen DAO, actief tijdens balance-uren. Minimale vereisten: configureerbare import/export drempels, hysterese-timer (anti-flapping), SoC-aware vermogensbegrenzing, en EV-pause logica. De regelaar schrijft naar "entity set power feedin" tijdens balance-uren in plaats van te stoppen met schrijven.
Dit voorkomt dat elke gebruiker met een AC-gekoppeld batterijsysteem zelf een volledige real-time regelaar moet bouwen. De Tweakers DAO-thread toont meerdere vergelijkbare implementaties (@pimNH , @KC27 , @Bravo , @Xom , @Beekforel ) — allemaal varianten van dezelfde ontbrekende DAO-functionaliteit.
Referenties: Utini2000/Zendure-Solarflow-Local-HomeAssistant (bewezen 1-15W precisie op productie), @pimNH bang-bang implementatie (Tweakers DAO-topic), @KC27 dubbele-helper patroon (Tweakers DAO-topic).
---
Samenvatting
FR-001 entity pv switch AC-omvormer — Hoog — Bugfix/Feature
FR-002 Pre-13:00 prijsfallback / EpexPredictor — Hoog — Feature
FR-003 Shadow price terminal condition — Middel — Algoritme
FR-004 Oscillation filter — Middel — Algoritme
FR-005 Write-throttling setpoint — Laag — Optimalisatie
FR-006 EpexPredictor documentatie — Laag — Docs
FR-007 Native zero-export / balance controller — Hoog — Feature
FR-001 en FR-007 hebben de meeste directe impact. FR-007 in het bijzonder omdat meerdere gebruikers in de Tweakers DAO-thread onafhankelijk van elkaar dezelfde workaround hebben gebouwd — een duidelijk signaal dat dit een structureel ontbrekende maar veel gewenste feature is.
Alvast bedankt voor de reacties!
En kun je niet gewoon GitHub gebruiken en issues aanmaken voor je feature requests?
edit: correctie, waarom neem je niet de moeite om GitHub issues aan te maken voor je feature requests??
en als toevoeging, lees aub even de huisregels rondom gebruik AI, oa.:
"Kunstmatige intelligentie (AI) mag als hulpmiddel worden gebruikt, maar grotendeels gegenereerde teksten zijn niet toegestaan. "
Dank allen voor jullie inhoudelijke reacties, mooi wat er hier samen allemaal gerealiseerd wordt, dat doet me denken aan de hechte open source community van 25-10 jaar geleden toen ik nog dagelijks actief was ik het OpenPLi opensource python wereldje...
Ter informatie, een stukje geschiedenis en info over de laatste weken.
DAO draait hier nu een paar weken. Werkt prima voor het bepalen wanneer de accu moet laden/ontladen op basis van de prijzen. Maar ik ervaarde een probleem: zodra DAO de accu in "balance mode" zet voor nul op de meter, stopt DAO met het schrijven van setpoints. Mijn Zendure heeft geen eigen zero-export logica, dus dan gebeurde er niets meer. Import en export liepen ongecontroleerd.
Ik heb samen met Claude Code (AI programmeerassistent) een controller gebouwd die actief wordt tijdens die balance-uren. Die kijkt elke 6 seconden naar de P1 meter. Als we te veel stroom van het net halen (>80W) wacht hij 10 seconden. Blijft het zo? Dan gaat de accu ontladen om dat te compenseren. Omgekeerd bij terugleveren (>200W): dan gaat de accu laden.
Die wachttijd voorkomt dat hij heen en weer schakelt als de waterkoker even aangaat. En we hebben limieten ingebouwd afhankelijk van hoe vol de accu is. Bijna vol? Dan maar langzaam laden. Bijna leeg? Dan minder hard ontladen. Bij starten van de EV laadpaal forceert hij idle zodat er geen conflicten ontstaan.
Mijn SolarEdge zet zichzelf uit bij negatieve prijzen via de app. DAO wist dat niet, dus die rekende met PV opbrengst die er niet was. Met hulp van de AI heb ik een sensor gemaakt die checkt of de all-in prijs onder nul is, en die synct met een boolean in DAO. Daardoor weet DAO: panelen staan uit, reken met 0W PV.
Ik had eerst alle panelen op 0 graden gezet in DAO, maar dat klopte niet. Met de iPhone heb ik alles opgemeten: plat dak op 219 graden, zuidgevel 203 graden, etc. Samen met de AI omgezet naar DAO's coordinaten en nu staan alle 5 strings correct. ML model opnieuw getraind, Forecast.Solar devices geüpdatet. Totale capaciteit is 12.37 kWp.
Draait sinds vanavond. DAO denkt per kwartier na, onze oplossing per seconde. Eindelijk echt 24/7 nul op de meter.
Net live gezet. DAO op strategie (per kwartier), onze controller op tactiek (per seconde). De komende nacht de eerste test van écht 24/7 nul op de meter. Hoop ik dan
Alle code: github.com/hemertje/home-assistant-dao-zendure-nom-controller
Willen jullie eens meelezen , input is gewenst...
Ter informatie, een stukje geschiedenis en info over de laatste weken.
DAO draait hier nu een paar weken. Werkt prima voor het bepalen wanneer de accu moet laden/ontladen op basis van de prijzen. Maar ik ervaarde een probleem: zodra DAO de accu in "balance mode" zet voor nul op de meter, stopt DAO met het schrijven van setpoints. Mijn Zendure heeft geen eigen zero-export logica, dus dan gebeurde er niets meer. Import en export liepen ongecontroleerd.
Ik heb samen met Claude Code (AI programmeerassistent) een controller gebouwd die actief wordt tijdens die balance-uren. Die kijkt elke 6 seconden naar de P1 meter. Als we te veel stroom van het net halen (>80W) wacht hij 10 seconden. Blijft het zo? Dan gaat de accu ontladen om dat te compenseren. Omgekeerd bij terugleveren (>200W): dan gaat de accu laden.
Die wachttijd voorkomt dat hij heen en weer schakelt als de waterkoker even aangaat. En we hebben limieten ingebouwd afhankelijk van hoe vol de accu is. Bijna vol? Dan maar langzaam laden. Bijna leeg? Dan minder hard ontladen. Bij starten van de EV laadpaal forceert hij idle zodat er geen conflicten ontstaan.
Mijn SolarEdge zet zichzelf uit bij negatieve prijzen via de app. DAO wist dat niet, dus die rekende met PV opbrengst die er niet was. Met hulp van de AI heb ik een sensor gemaakt die checkt of de all-in prijs onder nul is, en die synct met een boolean in DAO. Daardoor weet DAO: panelen staan uit, reken met 0W PV.
Ik had eerst alle panelen op 0 graden gezet in DAO, maar dat klopte niet. Met de iPhone heb ik alles opgemeten: plat dak op 219 graden, zuidgevel 203 graden, etc. Samen met de AI omgezet naar DAO's coordinaten en nu staan alle 5 strings correct. ML model opnieuw getraind, Forecast.Solar devices geüpdatet. Totale capaciteit is 12.37 kWp.
Draait sinds vanavond. DAO denkt per kwartier na, onze oplossing per seconde. Eindelijk echt 24/7 nul op de meter.
Net live gezet. DAO op strategie (per kwartier), onze controller op tactiek (per seconde). De komende nacht de eerste test van écht 24/7 nul op de meter. Hoop ik dan
Alle code: github.com/hemertje/home-assistant-dao-zendure-nom-controller
Willen jullie eens meelezen , input is gewenst...
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
:strip_exif()/f/image/ucKfy7bixf8lKouolJxaIKn4.png?f=user_large)
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Dank voor je testen en de terugkoppeling.:
[...]
Hier draait het, maar ik geloof niet dat ik gebruik maak van de delen die je verandert hebt. Wel blijft het lastig om te zien wanneer iets fout gaat. Ik heb de test versie normaal uit staan en test alleen wanneer je een nieuwe versie hebt. Dat betekent dat de meteo/epex/ml altijd achterlopen.
Na run met debug komt er een groen vinkje maar geen resultaat, en ook geen duidelijke foutmelding. Hierdoor is het moeilijk achterhalen wat je moet doen om het aan de praat te krijgen. Ik weet intussen wat ik moet doen, maar het zou duidelijker kunnen.
===
na ophalen van prijzen krijg ik dit bij run:
[...]
===
na ophalen meteo verdwijnt de foutmelding. Nu kan ik wel een debug run doen, met groen vinkje als resultaat. De eerste keer dat ik dan terug ga naar Home zag ik nog de niet geoptimaliseerde grafiek, na nog een run wel.
===
Uiteindelijk kon ik wel een ml training afstarten maar kwam ik op deze melding:code:en dit in de addon log in HA:
[2026-05-09 07:50:05,126] ERROR in app: Exception on /log [GET] Traceback (most recent call last): File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app response = self.full_dispatch_request() File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request rv = self.handle_user_exception(e) File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request rv = self.dispatch_request() File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ File "/root/dao/webserver/app/routes.py", line 652, in show_log logfile = task_state["logfile"] ~~~~~~~~~~^^^^^^^^^^^ KeyError: 'logfile'
Ik ben wel heel erg blij met DAO overigens! Petje af voor al het werk dat er verzet wordt door jou en de andere programmeurs.
Ik ga kijken of en hoe ik deze fout-meldingen wat gebruikersvriendelijker kan maken zodat de gebruiker kan lezen wat ie moet doen!
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
/u/331221/crop575c6f41e9c1e_cropped.png?f=community)
@Undertilted :strip_exif()/f/image/6jfdVXuBejLFeq4dTNw2r7f4.png?f=user_large)
Zoals je hier ziet: prijs hoog == volle bak ontladen, prijs laag == volle bak opladen.
In die situatie zet DAO de entity_balance_switch uit en zet de waarde in W die hij heeft bedacht naar entity_set_power_feedin.
Zoals je hier ziet: prijs hoog == volle bak ontladen, prijs laag == volle bak opladen.In die situatie zet DAO de entity_balance_switch uit en zet de waarde in W die hij heeft bedacht naar entity_set_power_feedin.
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
:strip_icc():strip_exif()/u/153524/crop56b4c089f1b16.jpeg?f=community)
Als de EV laadt, laadt de thuisbatterij meestal ook, dus alle kWh's komen uit het net en/of PV. Wie dat regelt? DAO.:
[...]
Hoi, dankjewel voor deze informatie!
ik krijg een 404 foutmelding op je Github link
@Bravo ik lees in je handtekening dat ook jij in een prachtige EV mag rijden
hoe voorkom jij dat je wanneer je de EV laad je de kWh uit je thuisbatterijen haalt?
En ja, DAO stuurt allerlei helper entitities in HA aan die vervolgens met een automation worden doorgezet naar de verschillende integraties in HA die de daadwerkelijke sturing doen.
Battery setpoint -> automation -> setpoint batterij (Victron), indien NOM doet de batterij zelf NOM (default state). Stuurt HA niet actief, dan gaat de batterij na 15 seconden naar default state (fail safe)
Auto laden -> automation -> if 16A laden dan evcc: fast charge, if 6-15A laden dan evcc: Solar, else evcc: off (nog wel last van de bug die ik hier genoemd heb met wel A instellen, maar end time in het verleden)
PV is AC en wordt gewoon gestuurd vanuit DAO via de helpers pv
:strip_exif()/f/image/yIjOjbVAWuI5x6yHtFNxnBc2.png?f=user_large)
Het kost even tijd om te doorgronden en alles in je huis mee te laten werken, ik denk dat ik er meerdere maanden over heb gedaan om al deze apparaten te integreren in DAO. Pas vorige maand de PV helpers aangemaakt, omdat de prijzen echt ver onder 0 gingen.
Dit overzicht hierboven is leuk, maar daarmee ben je er nog niet. DAO regiseert, maar doet niet de daadwerkelijke uitvoering. Achter al deze (combinatie van) helpers zitten dus automations die via HA integraties de daadwerkelijke uitvoering doen. Allemaal op hun eigen wijze.
Voorbeeld: Vaatwasser wordt aangestuurd via Home Local (home connect van BSH, maar dan lokaal). Veranderd het tijdstip van VW DAO Start in een moment in het verleden ten opzichte van nu, dan wordt het programma ingesteld en vervolgens de vaatwasser gestart.
Wasmachine (ook BSH) is niet slim, dus die vul ik, kies een programma, zet de machine aan en zet vervolgens de tussenstekker (Ikea inspelning) handmatig uit. Veranderd het tijdstip van WM DOA Start in een moment in het verleden ten opzichte van nu, dan wordt de schakelaar weer ingeschakeld en gaat de wasmachine zijn ding doen.
[ Voor 19% gewijzigd door Bravo op 11-05-2026 09:04 ]
🚗 Ioniq 6 LR Lounge 20" 🔌⚡ Elli Pro gestuurd door evcc
🔋 Victron 6k5 + 16kWh | ☀️ 2700Wp SSW 30° @ SE2200 | ☀️ 1720Wp SSW 5° @ HM-1500
📷 Canon 6D | 🔭 17-40mm f/4 + 50mm f/1.8 II + 70-200mm f/4 | 💥 2x 430EX II | 🎛️ Sirui T005 + C10
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
:strip_exif()/f/image/xDYyLiDx2UOng0G39H6chD5D.png?f=user_large)
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
/u/528703/crop565b8adf732d6_cropped.png?f=community)
1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh
:strip_exif()/f/image/ZQW22hC32PjhyoZxBoHasWUf.png?f=user_large)
Hij rekent met de waardes die in jouw config staan. Want je hebt calc_baseload uit staan. Met die waardes en de stroomprijs bij jou vind DAO het het voordeligst om de batterij te gebruiken tot die leeg is. Hij gaat pas opladen wanneer het interessant is prijs technisch, met een cycle cost van 0.05 gaat dat pas gebeuren bij een grotere spread tussen de koop en verkoop prijs.
Ik woon in Nederland dus mijn kosten zijn wat anders maar zo zien mijn grafiek er momenteel uit, het is gewoon geen denderende dag vandaag:
:strip_exif()/f/image/hrulFpdmFi7kBrHjztVPMSRc.png?f=user_large)
[ Voor 4% gewijzigd door thomvh op 11-05-2026 10:59 ]
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
:strip_exif()/u/159605/crop5bb7c558dfaa1.gif?f=community)
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
deze bedoel je?
/f/image/vu1Sz7q2kkeAqL7uXFpt5o2d.png?f=fotoalbum_large)
/f/image/W4BrbUWt1RNK9DO94O0dDS5X.png?f=fotoalbum_large)
:strip_exif()/f/image/vu1Sz7q2kkeAqL7uXFpt5o2d.png?f=user_large)
:strip_exif()/f/image/W4BrbUWt1RNK9DO94O0dDS5X.png?f=user_large)
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
Mhh, je hebt bijna constant een negatieve baseload. Ben geen expert, maar dat kan natuurlijk de berekening de verkeerde kant op trekken.
Bij mij deed die vanochtend dit:
Ik snap ook nog niet helemaal waarom ik alles tussen 9 en 13 uur het net op gooi, voelt een beetje verspillend aan... Ik zou zelf ook denken de zonnestroom is goedkoper dan van het net aftrekken, want hij begint bij het dal pas te laden, en zeker omdat hij hem niet vol laad. Maar misschien dat iemand anders hier meer toelichting kan geven.
:strip_exif()/f/image/s7JGOLViiPKWMqqNHq8CXDWu.png?f=user_large)
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Dit is afhankelijk van je configuratie::
De inhoud van je batterij (in netto kWh) aan het einde wordt gewaardeerd tegen het gemiddelde inkoop tarief, maar als je cycle kosten hebt geconfigureerd en je hebt ook nog eens "opslag" verlies (efficiency) dan kan het netto net iets minder opleveren om op te slaan dan terug te leveren. Ik denk dat het vanmorgen "kantje boord" was.
Bij mij gebeurde er in die periode ook niks:
:strip_exif()/f/image/3HD1Cziopsv53ODz0l1VtnvR.png?f=user_large)
![[Afbeelding]](https://tweakers.net/i/nHBxsjlanRFV1h_TAlfQdBK38x4=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/NY54ZKphpiVYSIJUXGIsHVZX.png?f=user_large){kind=link}
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
de DAO berekeningen van vandaag
/f/image/9XGGvGXxe7TjpF6gDNFwgSrG.png?f=fotoalbum_large)
/f/image/wVsZnYuW2R8nTWDX0mLMgqxr.png?f=fotoalbum_large)
de HomeWizard P1 metingen van vandaag
:strip_exif()/f/image/1k1IsAMpQMPGdDbbTh72SDts.jpg?f=fotoalbum_large)
:strip_exif()/f/image/Qu35kfbJkPVjfLv323Tl5Qzj.jpg?f=fotoalbum_large)
:strip_exif()/f/image/pUhOOskVsSGe8SOxRJkSgOMu.jpg?f=fotoalbum_large)
:strip_exif()/f/image/7C9Hq0vd96uyAamVgdDJGqSc.jpg?f=fotoalbum_large)
:strip_exif()/f/image/FK3QZKXzQcUEazGbhmMXtYpi.jpg?f=fotoalbum_large)
En SolarEdge omvormer van vandaag
/f/image/J0dVAuNrVt5P76TwwTKYRA8b.png?f=fotoalbum_large)
:strip_exif()/f/image/9XGGvGXxe7TjpF6gDNFwgSrG.png?f=user_large)
:strip_exif()/f/image/wVsZnYuW2R8nTWDX0mLMgqxr.png?f=user_large)
de HomeWizard P1 metingen van vandaag
:no_upscale():strip_icc():strip_exif()/f/image/1k1IsAMpQMPGdDbbTh72SDts.jpg?f=user_large)
:no_upscale():strip_icc():strip_exif()/f/image/Qu35kfbJkPVjfLv323Tl5Qzj.jpg?f=user_large)
:no_upscale():strip_icc():strip_exif()/f/image/pUhOOskVsSGe8SOxRJkSgOMu.jpg?f=user_large)
:no_upscale():strip_icc():strip_exif()/f/image/7C9Hq0vd96uyAamVgdDJGqSc.jpg?f=user_large)
:no_upscale():strip_icc():strip_exif()/f/image/FK3QZKXzQcUEazGbhmMXtYpi.jpg?f=user_large)
En SolarEdge omvormer van vandaag
:strip_exif()/f/image/J0dVAuNrVt5P76TwwTKYRA8b.png?f=user_large)
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Om er zelf nog even in te duiken en ook om beter toe te lichten heb ik de rekentijden uit alle logs getrokken en in een grafiek geplot.
:strip_exif()/f/image/iLVSEAift3WHGWKvCvV21aGU.png?f=user_large)
Voor 8 mei waren de rekentijden eigenlijk altijd onder de seconde. Je ziet mooi de rekentijd afnemen totdat de nieuwe prijzen zijn opgehaald. Maar sinds gisteren is zonder aanleiding het hek van de dam met rekentijden structureel meer dan 300 seconden.Ik heb nu de max-gap naar 0.1 bijgesteld, en dat zal vast wat helpen. Maar misschien ook wel verhullen wat hier fout gaat. Restart van de docker mocht ook niet echt baten. Ik draai 2026.4.4 al sinds 2026-04-25.
Zou het iets in de prijsdata of solardata kunnen zijn geweest?
Ga ik even over nadenken ... als ik nou niks te doen had
Je mag altijd een PR indienen in Github.
DAO neemt nu standaard de solar-data van de laatste drie jaar.
Dus als je twee jaar geleden je pv-installatie hebt uitgebreid nog een jaar.
[ Voor 22% gewijzigd door KC27 op 12-05-2026 22:27 ]
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer